1、 ETSI TR 102 365 V1.2.1 (2005-06)Technical Report Broadband Radio Access Networks (BRAN);HIPERLAN Type 2;Application Programming Interface (API) definitionfor the UDP/IP based testing of HIPERLAN Type 2protocol prototypesfloppy3 ETSI ETSI TR 102 365 V1.2.1 (2005-06) 2 Reference RTR/BRAN-00200011R1 K
2、eywords access, API, broadband, HIPERLAN, IP, radio, testing ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Imp
3、ortant notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is t
4、he Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Inf
5、ormation on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No
6、part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2005. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the ben
7、efit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 102 365 V1.2.1 (2005-06) 3 Contents Intel
8、lectual Property Rights5 Foreword.5 1 Scope 6 2 References 6 3 Definitions and abbreviations.6 3.1 Definitions6 3.2 Abbreviations .6 4 The concepts.7 4.1 The requirement .7 4.2 Virtual tester/Protocol Layer Tester (PLT) 7 4.2.1 A generic, technology-neutral, and inexpensive solution .8 4.2.1.1 The d
9、ata on the wire interface .11 4.2.2 Advantages and spin-offs12 4.3 PLT components 13 4.3.1 Wire interface data/wire datagrams 13 4.3.2 The API.16 4.3.3 Wire transport module/Adaptation layer.17 5 Implementing the PLT for the HiperLAN2 DLC protocol.17 5.1 Test architecture for the DLC layer17 5.1.1 T
10、est Configurations.18 5.1.1.1 Test Configurations for MT 18 5.1.1.2 Test Configurations for AP .19 5.2 PLT components 19 5.2.1 Existing components.19 5.2.1.1 Test system19 5.2.1.2 Abstract Test Suite (ATS).20 5.2.1.3 Test System Prototype.20 5.2.1.3.1 Codecs .21 5.2.2 Developed components.23 5.2.2.1
11、 Wire datagram.23 5.2.2.2 The API for HiperLAN2 DLC 23 5.2.2.3 Wire transport module.26 5.2.3 Clocks and timing .26 5.2.4 Heuristics for defining an API 26 Annex A: HiperaLAN2 Wire Datagram Specification .28 A.1 Wire datagram ASN.1 module .28 A.2 DatagramSocketAPI Java interface33 A.3 Specialized Hi
12、perlan2 Datagrams as Java interface.34 Annex B: HiperLAN2 API Specifications37 B.1 DatagramSocketAPI Specification.37 B.2 SocketAddress specification.39 B.3 Java interface40 Annex C: Clocks and timing .41 C.1 Clocks and timing.41 C.1.1 Clocks.41 C.1.2 Timing 42 ETSI ETSI TR 102 365 V1.2.1 (2005-06)
13、4 C.1.3 Time Warping 42 C.1.4 Using Time Warping44 Annex D: The Java code of UDP/IP based virtual tester prototype 45 History 46 ETSI ETSI TR 102 365 V1.2.1 (2005-06) 5 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The in
14、formation pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from t
15、he ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI S
16、R 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). Compared to the version 1.1.1 of TR 102 365, the present document in
17、troduces changes to annex D. ETSI ETSI TR 102 365 V1.2.1 (2005-06) 6 1 Scope The present document presents the results of work to develop a generic solution for inexpensively testing any protocol and a specific implementation of this solution for the HIPERLAN2 DLC protocol. The generic solution prov
18、ides an inexpensive means to test any protocol implementation. The implementation is software-based but can be hardware as well. The implementation in software on a PC-based platform is a “virtual“ test system. The implementation in hardware with radio transport and frequency capabilities is classic
19、 radio-based test equipment. 2 References For the purposes of this Technical Report (TR), the following references apply: 1 ETSI/Hiperlan2 Global Forum document: “BRAN, Hiperlan2, Data Link Control (DLC) and Convergence Layers, Interoperability Testing Event - July 2002; Test Bed Description“. 2 ETS
20、I TS 101 761-2: “Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data Link Control (DLC) Layer; Part 2: Radio Link Control (RLC) sublayer“. 3 ETSI TS 101 823-2-3 (V1.3.1): “Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Conformance testing for the Data Link Control (DLC) layer; Pa
21、rt 2: Radio Link Control (RLC) sublayer; Sub-part 3: Abstract Test Suite (ATS) specification“. 4 ETSI ES 201 873-5: “Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)“. 5 ETSI ES 201 873-6: “Methods for Testing and Sp
22、ecification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI)“. 6 ISO/IEC 9646: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework“. 7 ETSI TR 102 327: “Broadband Radio Access Networks (BRAN); HIPERACCES
23、S; Application Programming Interface (API) definition for the UDP/IP based testing of HIPERACCESS protocol prototypes“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: Protocol Layer Tester (PLT): virtual test syste
24、m for the testing of protocol layers virtual tester: PC-based test system that replaces hardware components of a sophisticated test equipment with software components 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AP Access Point API Application Progra
25、mming Interface ASP Abstract Service Primitive ATS Abstract Test Suite DLC Data Link Control IUT Implementation Under Test ETSI ETSI TR 102 365 V1.2.1 (2005-06) 7 MAC Medium Access Control MT Mobile Terminal MTU Maximum Transmission Unit for IPv4 PA Platform Adaptor PCO Point of Control and Observat
26、ion PDU Protocol Data Unit PHY PHYsical PLT Protocol Layer Tester PUT Protocol Under Test RLC Radio Link Control SA System Adaptor SAP Service Access Point SAR Segmentation And Reassembly SDL Specification and Description Language SUT System Under Test TCP Transmission Control Protocol TE Test Equip
27、mentTR Technical Report TTCN-2 Tree and Tabular Combined Notation version 2 TTCN-3 Testing and Test Control Notation version 3 UDP/IP User Datagram Protocol over the Internet Protocol 4 The concepts 4.1 The requirement The Terms of Reference for the present document call for a virtual tester that wi
28、ll run existing test specifications. This virtual tester would consist of the following: a subset of the existing test suite; an adaptation layer that would map the protocol messages into UDP/IP packets; and an Application Programming Interface for UDP/IP based testing with services that the executa
29、ble test suite could use to transport messages and other information to and from the system under test (SUT). Such a virtual tester would allow the HiperLAN2 companies to test and debug DLC protocol stacks early in their development stage and would facilitate and speed up the development of a full-f
30、ledged radio-based test tool. Such a tool could be used at interoperability events as well to provide a cheap and fast means to conformance test prototypes. Such conformance testing would be useful to determine errors in implementations and identify possible reasons for interoperability failures. 4.
31、2 Virtual tester/Protocol Layer Tester (PLT) The ETSI Abstract Test Suites (ATS) are designed to test a device to see if it conforms to the base specification. Usually this base specification specifies the devices protocol layers and performance requirements. The test suite usually mirrors these in
32、its organization and function. The layers may be according to the OSI model or per the protocol designers concept. The ATS can be executed only if there is test equipment to run it upon. Test equipment does not come “off the shelf“ for todays high performance protocols such as those for broadband ra
33、dio networks. Test equipment for such protocols requires much the same development effort as the implementation itself. Simply said, full-featured conformance test equipment development is very expensive. This leads to a chicken-and-egg problem. On one hand, prototypes and implementations need to be
34、 tested to ensure they are conformant and interoperate and give them the chance to win in the marketplace. On the other hand, test equipment with all the required features for conformance testing is too expensive during prototyping and development. ETSI ETSI TR 102 365 V1.2.1 (2005-06) 8 During prot
35、otyping and developing, much of the systems design and implementation is done in software. Only when development and debugging are complete should the design become reality in firmware and hardware. If protocol layer conformance testing could be conducted in parallel during design on protocol protot
36、ypes in software or implementations, then product development and testing would be cheaper and quicker. Is there a way to inexpensively conformance test the protocols in development or finalized that normally require expensive test equipment? The work described in the present document shows that the
37、re are low-cost off-the-shelf technology-neutral components requiring a minimum of “glue“ to make a “virtual tester“. A “virtual tester“ is a PC-based test system that replaces the expensive hardware components of sophisticated test equipment with much cheaper software components. The development of
38、 advanced protocols requires testing and the testing equipment to run these tests. Radio protocols complicate these tasks and increase development times and testing costs. For radio protocols, test equipment is usually not available in time during development to test the implementations behaviour ov
39、er the air interface. The expensive up-front cost of radio-based test equipment precludes their arrival in time for use during protocol development. Therefore, some type of relatively inexpensive means to test protocol implementation behaviour during prototyping and development could be of benefit t
40、o manufacturers and testers. This testing would, of necessity, not be conducted over the air interface because of the expense of developing such equipment. Proven wire interfaces are cheaper and more reliable than new air interfaces. Thus, one reason for a virtual tester is to test protocols destine
41、d for an expensive interface in their prototyping and/or development stage. The tester would use a substitute wire interface for the lower transport layers. Another reason for a virtual tester is to conformance test any protocol for an expensive or inexpensive interface during design and development
42、. Finally, a virtual tester could be used at interoperability or similar events to conformance test implementations and prototypes. The Abstract Test Suite used for protocol testing would remain the same whether for a virtual tester or classical test equipment. Thus, no additional costs would be inc
43、urred for writing Abstract Test Suites to run over either test equipment. The present document is concerned only with protocol messages. However, the use of wire transport layers for testing data normally transmitted using radio can apply to other types of data such as frames. The transmission of da
44、ta in frames is not similar to protocol behaviour, e.g. a MAC protocol. However, the frame data can still be captured and transmitted over any type of wire protocol such as UDP over IP. The present document does not investigate frame testing or any other type of testing other than protocol conforman
45、ce testing. Subsequent BRAN Technical Reports on UDP/IP testing substituting for radio testing may cover these non-classic protocol types of testing. Answering the question of “What is being tested?“ is important. The present document addresses the testing of MAC/radio link layer type protocols incl
46、uding their behavior and effects upon radio transmission characteristics. The radio link layer protocol can force changes in transmission frequency, channel, and power. Otherwise said, the radio link layer sometimes changes the performance of the physical layer. These effects are included in the Abs
47、tract Test Suite. Thus, device behaviour such as signal strength is tested as well as protocol behaviour if such behaviour is directly linked to the protocol function. In our view, such behaviour is not PHY layer specific but linked intimately with the protocol and included in the radio link layer A
48、TS. One could argue that such tests are PHY layer tests. Our view is that such PHY behaviour, being the result of radio link layer protocol actions, is rightfully included in the link layer ATS. Only that PHY level behaviour that is not a direct result of radio link protocol layer behaviour should b
49、e included in a PHY layer ATS, if such exists. Because the work in the present document specifically address classic protocol layer testing, the virtual tester becomes a “Protocol Layer Tester“ (PLT). The protocol used for the feasibility study is the HiperLAN2 DLC protocol. 4.2.1 A generic, technology-neutral, and inexpensive solution To be generic, the PLT concept must not be tied to technology that is either hardware or software-expensive. A generic solution should have the following characteristics: Apply to any protocol or transfer scheme where e
