ETSI TR 102 327-2004 Broadband Radio Access Networks (BRAN) HIPERACCESS Application Programming Interface (API) definition for the UDP IP based testing of HIPERACCESS protocol prot_1.pdf

《ETSI TR 102 327-2004 Broadband Radio Access Networks (BRAN) HIPERACCESS Application Programming Interface (API) definition for the UDP IP based testing of HIPERACCESS protocol prot_1.pdf》由会员分享，可在线阅读，更多相关《ETSI TR 102 327-2004 Broadband Radio Access Networks (BRAN) HIPERACCESS Application Programming Interface (API) definition for the UDP IP based testing of HIPERACCESS protocol prot_1.pdf（44页珍藏版）》请在麦多课文档分享上搜索。

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