1、 ETSI TR 102 327 V1.1.1 (2004-04)Technical Report Broadband Radio Access Networks (BRAN);HIPERACCESS;Application Programming Interface (API) definition for the UDP/IP based testing of HIPERACCESS protocol prototypesfloppy3 ETSI ETSI TR 102 327 V1.1.1 (2004-04) 2 Reference DTR/BRAN-0030007 Keywords a
2、ccess, API, broadband, HIPERACCESS, IP, network, 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
3、Important 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 i
4、s the 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.
5、Information 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, send your comment to: editoretsi.org Copyright Notification No part may be reproduced except as authorized by written permission.
6、The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2004. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks cu
7、rrently 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 327 V1.1.1 (2004-04) 3 Contents Intellectual Property Rights5 Foreword.5 1 Scope 6 2 References 6 3 Defi
8、nitions 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 data on the wire interface .11 4.2.2 Advantages and spin-offs12 4.3 PL
9、T 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 HIPERACCESS DLC protocol .17 5.1 Test architecture for the DLC layer17 5.1.1 Test configurations .18 5.1.1.1 Test configurations for AT18 5.1.1.
10、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 .22 5.2.2 Developed components.23 5.2.2.1 Wire datagram.23 5.2.2.2 The API for HIPERACCESS DLC.24 5.2.2.3 W
11、ire transport module.27 5.2.3 Clocks and timing .27 5.2.4 Heuristics for defining an API 27 6 The SDL model as an IUT prototype .28 6.1 SDL model adaptation layer.29 6.2 SDL model suitable for test validation.31 7 Conclusions 31 7.1 Applicability to Protocols Under Test (PUT).31 7.2 Applicability to
12、 interoperability events 31 7.3 Applicability to full-featured test systems31 Annex A: HIPERACCESS Wire Datagram Specification .32 A.1 Wire datagram ASN.1 module .32 A.2 An example wire datagram.33 Annex B: HIPERACCESS API Specifications34 B.1 DatagramSocketAPI Specification.34 B.2 SocketAddress spe
13、cification.36 ETSI ETSI TR 102 327 V1.1.1 (2004-04) 4 B.3 Java interface37 Annex C: Wire transport module.38 Annex D: Clocks and timing .39 D.1 Clocks and timing.39 D.1.1 Clocks.39 D.1.2 Timing 40 D.1.3 Time warping .40 D.1.4 Using time warping 42 Annex E: Abstract Test Suite (ATS) text block.43 E.1
14、 The TTCN Graphical form (TTCN.GR) 43 E.2 The TTCN Machine Processable form (TTCN.MP)43 History 44 ETSI ETSI TR 102 327 V1.1.1 (2004-04) 5 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these
15、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 the ETSI Secretariat. Latest up
16、dates 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 SR 000 314 (or the updates on t
17、he 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). ETSI ETSI TR 102 327 V1.1.1 (2004-04) 6 1 Scope The present document presents the results of work
18、to develop a generic solution for inexpensively testing any protocol and a specific implementation of this solution for the HIPERACCESS DLC protocol 1. The generic solution provides an inexpensive means to test any protocol implementation. The implementation is software-based but can be hardware as
19、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 radio-based test equipment. 2 References For the purposes of this Technical Report (TR), the following references apply: 1
20、 ETSI TS 102 000: “Broadband Radio Access Networks (BRAN); HIPERACCESS; DLC protocol specification“. 2 ETSI TS 102 149-3: “Broadband Radio Access Networks (BRAN); HIPERACCESS; Conformance Testing for the Data Link Control (DLC) layer; Part 3: Abstract Test Suite (ATS)“. 3 ETSI ES 201 873-5: “Methods
21、 for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)“. 4 ETSI ES 201 873-6: “Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI)“. 3 Definitions a
22、nd abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: Protocol Layer Tester (PLT): virtual test system for the testing of protocol layers virtual tester: a PC-based test system that replaces hardware components of sophisticated test equ
23、ipment with software components 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AP Access Point API Application Programming Interface ASP Abstract Service Primitive AT Access Terminal ATS Abstract Test Suite ATSP Abstract Testing Service Pimitives DL Do
24、wnLink DLC Data Link Control ETS Executable Test Suite FTP File Transfer Protocol IUT Implementation Under Test LT Lower Tester MAC Medium Access Control MTU Maximum Transmission Unit for IPv4 PA Platform Adaptor PCO Point of Control and Observation ETSI ETSI TR 102 327 V1.1.1 (2004-04) 7 PDU Protoc
25、ol Data Unit PHY PHYsical PLT Protocol Layer Tester PUT Protocol Under Test SA System AdaptorSAP Service Access Point SAR Segmentation And Reassembly SDL Specification and Description Language SUT System Under Test TCP Transmission Control Protocol TE Test EquipmentTRA Test Runtime Adapter TSO Test
26、Suite Operation 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 UL UpLink WD Wire Datagram WI Wire Interface 4 The concepts 4.1 The requirement The terms of reference for the present docum
27、ent call for a virtual tester that will 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 (API) for UDP/IP b
28、ased testing with services that the executable 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 HIPERACCESS companies to test and debug DLC protocol stacks early in their development stage and would facili
29、tate and speed up the development of a full-fledged 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 possi
30、ble reasons for interoperability failures. 4.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 requireme
31、nts. The test suite usually mirrors these in 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 perform
32、ance protocols such as those for broadband radio 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 ha
33、nd, prototypes and implementations need to be 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. During
34、 prototyping 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 p
35、rototypes in software or implementations, then product development and testing would be cheaper and quicker. ETSI ETSI TR 102 327 V1.1.1 (2004-04) 8 Is there a way to inexpensively conformance test the protocols in development or finalized that normally require expensive test equipment? The work des
36、cribed in the present document shows that there 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 ch
37、eaper software components. The development of 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 develop
38、ment to test the implementations behaviour over 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 prot
39、otyping and development could be of benefit to 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
40、a virtual tester is to test protocols destined 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 inexpe
41、nsive interface during design and development. Finally, a virtual tester could be used at interoperability or similar events to conformance test implementations and prototypes. The Abstract Test Suite (ATS) used for protocol testing would remain the same whether for a virtual tester or classical tes
42、t equipment. Thus, no additional costs would be incurred 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 t
43、ypes of data such as frames. The transmission of data 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
44、other type of testing other than protocol conformance 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
45、testing of MAC/radio link layer type protocols including their behaviour 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 p
46、hysical layer. These effects are included in the Abstract 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
47、 the protocol and included in the radio link layer ATS. 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 re
48、sult of radio link protocol layer behaviour should be 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
49、the HIPERACCESS 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 environment characteristics can be modelled with binary data; e.g. PDUs, frames, waveforms, transmission frequency, transmission power, received power, etc.; Abstract Test Suites(ATS) written in the ETSI-used testing languages TTCN-2 and TTCN-3. Howev
