TIA EIA-732-920-2001 Cellular Digital Packet Data (CDPD) System Specification MAC Abstract Test Suite《蜂窝数字分组数据(CDPD)系统规范 MAC抽象试验组 TIA EIA IS-732-920的更新件》.pdf

《TIA EIA-732-920-2001 Cellular Digital Packet Data (CDPD) System Specification MAC Abstract Test Suite《蜂窝数字分组数据(CDPD)系统规范 MAC抽象试验组 TIA EIA IS-732-920的更新件》.pdf》由会员分享，可在线阅读，更多相关《TIA EIA-732-920-2001 Cellular Digital Packet Data (CDPD) System Specification MAC Abstract Test Suite《蜂窝数字分组数据(CDPD)系统规范 MAC抽象试验组 TIA EIA IS-732-920的更新件》.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、 TIA/EIA STANDARD Cellular Digital Packet Data (CDPD) System Specification MAC Abstract Test Suite TIA/EIA-732-920 (Upgrade of TIA/EIA/IS-732-920) JULY 2001 TELECOMMUNICATIONS INDUSTRY ASSOCIATION The Telecommunications Industry Association represents the communications sector of ANSI/TIA/EIA-732-92

2、0-2001 Approved: June 7, 2001 TIA/EIA-732-920 NOTICE TIA/EIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the pur

3、chaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards and Publications shall not in any respect preclude any member or nonmember of TIA/EIA from manufacturing or selling products not conforming to such Standards and Publications,

4、 nor shall the existence of such Standards and Publications preclude their voluntary use by those other than TIA/EIA members, whether the standard is to be used either domestically or internationally. Standards and Publications are adopted by TIA/EIA in accordance with the American National Standard

5、s Institute (ANSI) patent policy. By such action, TIA/EIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to address all safety problems associated with its use or all applic

6、able regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (From Standards Proposal No. 4033-920-UG, formulated under the cognizance of the TIA T

7、R-45.6 Subcommittee on Adjunct Data Packet Wireless Technology.) Published by TELECOMMUNICATIONS INDUSTRY ASSOCIATION 2001 Standards and Technology Department 2500 Wilson Boulevard Arlington, VA 22201 PRICE: Please refer to current Catalog of EIA ELECTRONIC INDUSTRIES ALLIANCE STANDARDS and ENGINEER

8、ING PUBLICATIONS or call Global Engineering Documents, USA and Canada (1-800-854-7179) International (303-397-7956) All rights reserved Printed in U.S.A. PLEASE! DONT VIOLATE THE LAW! This document is copyrighted by the TIA and may not be reproduced without permission. Organizations may obtain permi

9、ssion to reproduce a limited number of copies through entering into a license agreement. For information, contact: Global Engineering Documents 15 Inverness Way East Englewood, CO 80112-5704 or call U.S.A. and Canada 1-800-854-7179, International (303) 397-7956 920iTIA/EIA-732-9201234567891011121314

10、15161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960Contents1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920-12 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11、 . . . . . . . . . . . . . . 920-12.1 State Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-12.1.1 User Side (M-ES) Forward Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-22.1.2

12、User Side (M-ES) Reverse Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-22.1.3 Network Side (MDBS) Forward Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-22.1.3.1 Busy/Idle Flag States . . . . . . . . . . . . . . . . . . . . . . .

13、 . . . . . . . . . . . . . . . . . . . . 920-22.1.4 Network Side (MDBS) Reverse Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-32.2 Other Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-

14、33 Testing Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920-43.1 Relationship Between the TSS others are defined elsewhere, such as ISO-9646.2.1 State DefinitionsThe states defined in this Part correspond to those defined in Part 402.TIA/EIA-732-920 MA

15、C Abstract Test Suite92021234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859602.1.1 User Side (M-ES) Forward Channel StatesThe states used for the User Side forward channel (receive side) are:a71 State 1: CLOSEDa71 State 2: SYNC SEARCHa71 Sta

16、te 3: SYNC ACQUIRED2.1.2 User Side (M-ES) Reverse Channel StatesThe states used for the User Side reverse channel (transmit side) are:a71 State 1: CLOSEDa71 State 2: IDLE WAITa71 State 3: IDLE Substate 3.1: CHANNEL IDLE Substate 3.2: CHANNEL BUSYa71 State 4: DEFER Substate 4.1: CHANNEL IDLE Substate

17、 4.2: CHANNEL BUSYa71 State 5: TRANSMIT BLOCKa71 State 6: DECODE WAITa71 State 7: BACKOFF Substate 7.1: CHANNEL IDLE Substate 7.2: CHANNEL BUSY2.1.3 Network Side (MDBS) Forward Channel StatesThe MDBS continually transmits on the forward channel except in the instances of an RF channel hop. The state

18、s of the MDBS, for transmission on the forward channel, are based on the activity sensed by the MDBS on the associated reverse channel of the channel stream pair. Data destined for an M-ES (or group of M-ESs) on the channel stream is interleaved in the block between synchronization and control flags

19、. Therefore there is no separate state for data transmission on the forward channel.The states used for the Network Side forward channel (transmit side) are divided into two separate and independent state machines based on the status of the reverse channel and the status of data received over the re

20、verse channel. The states used for the Network Side forward channel are described in the following subsections.2.1.3.1 Busy/Idle Flag Statesa71 State 1: CLOSEDa71 State 2: CHANNEL IDLEa71 State 3: SYNC SEARCH9203Definitions TIA/EIA-732-9201234567891011121314151617181920212223242526272829303132333435

21、36373839404142434445464748495051525354555657585960a71 State 4: SYNC LOCKa71 State 5: BUSY HANGa71 State 6: SYNC HOLD2.1.4 Network Side (MDBS) Reverse Channel StatesThe states used for the Network Side reverse channel (receive side) are:a71 State 1: CLOSEDa71 State 2: DECODE IDLEa71 State 3: RECEIVE

22、BLOCKSa71 State 4: EOT WAITFor complete details of MAC User Side and Network Side events and state transitions, readers should refer to Part 402 Tables for the CDPD MAC Procedures.2.2 Other DefinitionsImplementor An organization that implements a protocol to be tested. Testing can be carried out in-

23、house or by a third party testing agency hired by the Implementor. The Implementor can be a client and/or a supplier.Implicit Send A mechanism used in Remote Test Methods for specifying that the IUT should be made to initiate a particular service primitive or transmit a particular protocol data unit

24、 ISO 9646-3.MMI Man-Machine Interface. Term used to describe the interface used for interacting with an IUT. This interface is typically a human operator sitting at a console or a programmatic interface.Supplier An organization that supplies IUTs and SUTs to a client. The supplier may also be the im

25、plementor of the supplied IUTs and SUTs.Accept An IUT is said to accept a message when the decode status flag pertaining to the transmitted message indicated success.Ignore An IUT is said to ignore a message when the IUT does nothing receiving the message. Ignoring a message is equivalent to not hav

26、ing received it.Valid Frame A valid frame or block is an expected frame or block which arrives at the correct state or phase and does not belong to any of the categories listed under invalid frames.TIA/EIA-732-920 MAC Abstract Test Suite920412345678910111213141516171819202122232425262728293031323334

27、3536373839404142434445464748495051525354555657585960Invalid Frame An invalid frame or block that:a73 Does not consist of an integral number of blocks or octetsa73 Frame with less than two octetsa73 Frame with greater than 136 octetsa73 A transmission burst containing seven or more continuous “1” bit

28、s.Inopportune FrameAn inopportune frame is a syntactically valid frame arriving at a time (IUTs state) when it should be considered irrelevant by the IUT.3 Testing MethodologyThe testing methodology used in this part complies with the requirements of the OSI Conformance Testing Methodology and Frame

29、work as specified in ISO 9646-2 and is further defined in Part 900.3.1 Relationship Between the TSS a TX test case on the Network Side would imply the IUT transmits something on the forward channel.State xx The state which the test cases apply, refer to Section 2.2 State Definitions for valid IUT St

30、ates and substates. The state identifier xx will be prefixed with “S”. Under the Common group the State field is not applicable.“xx” Indicates the IUTs state, which may be a numeric or a alphanumeric identifierType Test cases for any group/sub-group/state combination are further collected into group

31、s based on the type of test case. These Types are for valid, invalid and inopportune testing. The definitions and syntax for these test case types follow:Valid This subgroup contains those test cases where the tester transmits syntactically and semantically correct/valid frames. VALID is used in the

32、 test group path to identify these type of tests.Invalid This subgroup contains those test cases where the tester transmits invalid frames 9207MAC ATS Test Suite Structure TIA/EIA-732-920123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960or

33、 frames which are syntactically and or semantically incorrect. INVALID is used in the test group path to identify these type of tests.Inopportune This subgroup contains those test cases where the tester transmits syntactically and semantically correct frames but arriving at an inopportune moment. IN

34、OP is used in the test group path to identify these type of tests.Test cases can be identified by the test group reference that define the location of the test case within the structure of the test suite and also by a unique name given to each test case. To ensure uniqueness of test case names a nam

35、ing convention for test cases is defined. Test case names are of the form:Group/Sub-group/State_/PTnn where:PT Indicates PDU Type. Its value shall be “V”, “N” or “I” denoting valid, invalid (not valid), or inopportune respectively.“nn” Indicates the test case number. 0 = nn = 99. No group shall cont

36、ain more than 99 test cases. Further, test cases 0 through 9 use a leading 0 such that 2 characters are always used.Example:Given the following reference: MAC/C/RX/VALID/CRX_V01MAC/C The ATS is for the MAC Common testing procedures group.RX The sub-group for receive tests, no state is used for the C

37、ommon group so it is not present in the path.VALID The test case involves the testing of a valid IUT behavior.CRX_V01 The test case name, summarizes everything. CRX indicates that it is a Common Receive test case, “V” indicates that the test is of the Valid behavior type, and 01 indicates the first

38、test case for that particular test case sub-group.TIA/EIA-732-920 MAC Abstract Test Suite92081234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859605 Introduction to MAC Layer PIXITProtocol implementations can vary extensively (i.e., different

39、designs, different hardware, different operating systems) and may have system specific requirements. The PICS which identifies the capabilities and options provided by a given implementation must be complemented with extra information identifying system specific requirements. This extra information

40、is provided in a document called a Protocol Implementation eXtra Information for Testing (PIXIT) proforma.A PIXIT proforma, as defined in ISO 9646-1, is a document in the form of a questionnaire provided by the test laboratory, which when completed during the preparation for testing of an OSI protoc

41、ol implementation or system, becomes a PIXIT.The PIXIT is completed by the party submitting its equipment for testing. It is not part of the base standard and is normally found as part of the Abstract Test Suite (ATS). This PIXIT proforma applies to both the user and Network Side MAC protocol proced

42、ures.A completed PIXIT proforma is the PIXIT for the IUT.5.1 Purpose A completed PIXIT provides further information not provided in a PICS. It contains system specific information outside the scope of the base standard e.g., in MAC the Equipment Identifier for the Implementation Under Test (IUT).Fur

43、ther, the PIXIT combined with information provided in the accompanying PICS, helps to ensure that the IUT can be tested for conformance against relevant requirements, and against those requirements only.The PIXIT:a71 Identifies the equipment under testa71 Complements the information provided in the

44、PICS proformaa71 Provides additional information about the SUT required by the test laboratory to enable it to execute test cases in the IUTs own testing environmenta71 Partially determines which tests are selected for execution against the IUT during test suite parameterization (based on the capabi

45、lities claimed to be supported by the IUT)a71 Is provided in a standard format, allowing vendors/manufacturers to supply IUT specific information in a standardized manner. This benefits both Vendors/Manufacturers and Testing Agencies9209Introduction to MAC Layer PIXIT TIA/EIA-732-9201234567891011121

46、31415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960NoteBecause of implementation differences or implementation specific details, the PIXIT proforma may need to be accompanied by further “non-standard” information.a71 Benefits Abstract Test Suite developers

47、 as they can determine whether all relevant parameters have been identified and adequately tested.Further information regarding the PIXIT can be found in Knightson and ISO 9646-1.5.2 Instructions for Completing the PIXIT Proforma5.3 General StructureThe PIXIT proforma consists of several parts. The

48、first section identifies this PIXIT, the second section identifies the parties involved in testing the given implementation. The third section identifies the IUT and the SUT. The fourth section captures relevant Man-Machine Interface (MMI) information to be used for interacting with either the SUT a

49、nd/or IUT. The MMI is typically an Application Programming Interface (API) or a human operator interacting with the SUT/IUT.The main part of the PIXIT proforma is a fixed-format questionnaire, containing tables requesting values for timers, retransmission counters, equipment identifiers and other information required for the execution of tests. These values are determined by the IUT manufacturer or provider and the test laboratory.5.4 PICS/PIXIT RelationshipThe MAC PICS proforma must be completed prior to filling in the MAC PIXIT proforma.The features su