TIA-EIA-732-920-2001.pdf

《TIA-EIA-732-920-2001.pdf》由会员分享，可在线阅读，更多相关《TIA-EIA-732-920-2001.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 Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 21:41:55 MDTNo reproduction or networking permitted without license from IHS -,-,- NOT

3、ICE 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 purchaser in selecting and obtaining with minimum de

4、lay 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, nor shall the existence of such Standards and Pu

5、blications 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 Standards Institute (ANSI) patent policy. By such action,

6、 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 applicable regulatory requirements. It is the responsib

7、ility 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 TR-45.6 Subcommittee on Adjunct Data Packet Wirele

8、ss 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 ENGINEERING PUBLICATIONS or call Global Engineering Docum

9、ents, USA and Canada (1-800-854-7179) International (303-397-7956) All rights reserved Printed in U.S.A. Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 21:41:55 MDTNo reproduction

10、 or networking permitted without license from IHS -,-,- PLEASE! DONT VIOLATE THE LAW! This document is copyrighted by the TIA and may not be reproduced without permission. Organizations may obtain permission to reproduce a limited number of copies through entering into a license agreement. For infor

11、mation, 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 Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Be

12、rnie Not for Resale, 03/29/2007 21:41:55 MDTNo reproduction or networking permitted without license from IHS -,-,- Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 21:41:55 MDTNo re

13、production or networking permitted without license from IHS -,-,- 920i TIA/EIA-732-920 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 Contents 1Introduction . . . . . . . . . .

14、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920-1 2Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920-1 2.1State Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15、. . . . . . . . . . . . . . . . . . .920-1 2.1.1User Side (M-ES) Forward Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-2 2.1.2User Side (M-ES) Reverse Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-2 2.1.3Network Side (MD

16、BS) Forward Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-2 2.1.3.1Busy/Idle Flag States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920-2 2.1.4Network Side (MDBS) Reverse Channel States . . . . . . . . . . . . . . . . . . . .

17、 . . . . . . . . . .920-3 2.2Other Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920-3 3Testing Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920-4 3.1Relationship Between

18、the TSS others are defined elsewhere, such as ISO-9646. 2.1State Definitions The states defined in this Part correspond to those defined in Part 402. Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for R

19、esale, 03/29/2007 21:41:55 MDTNo reproduction or networking permitted without license from IHS -,-,- TIA/EIA-732-920MAC Abstract Test Suite 9202 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

20、 56 57 58 59 60 2.1.1User Side (M-ES) Forward Channel States The states used for the User Side forward channel (receive side) are: GState 1: CLOSED GState 2: SYNC SEARCH GState 3: SYNC ACQUIRED 2.1.2User Side (M-ES) Reverse Channel States The states used for the User Side reverse channel (transmit s

21、ide) are: GState 1: CLOSED GState 2: IDLE WAIT GState 3: IDLE Substate 3.1: CHANNEL IDLE Substate 3.2: CHANNEL BUSY GState 4: DEFER Substate 4.1: CHANNEL IDLE Substate 4.2: CHANNEL BUSY GState 5: TRANSMIT BLOCK GState 6: DECODE WAIT GState 7: BACKOFF Substate 7.1: CHANNEL IDLE Substate 7.2: CHANNEL

22、BUSY 2.1.3Network Side (MDBS) Forward Channel States The MDBS continually transmits on the forward channel except in the instances of an RF channel hop. The states of the MDBS, for transmission on the forward channel, are based on the activity sensed by the MDBS on the associated reverse channel of

23、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. Therefore there is no separate state for data transmission on the forward channel. The states used for the Network Side forward channel

24、(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 reverse channel. The states used for the Network Side forward channel are described in the following subsections. 2.1.3.1Busy/Idle Flag Sta

25、tes GState 1: CLOSED GState 2: CHANNEL IDLE GState 3: SYNC SEARCH Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 21:41:55 MDTNo reproduction or networking permitted without licens

26、e from IHS -,-,- 9203 Definitions TIA/EIA-732-920 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 GState 4: SYNC LOCK GState 5: BUSY HANG GState 6: SYNC HOLD 2.1.4Network Side (

27、MDBS) Reverse Channel States The states used for the Network Side reverse channel (receive side) are: GState 1: CLOSED GState 2: DECODE IDLE GState 3: RECEIVE BLOCKS GState 4: EOT WAIT For complete details of MAC User Side and Network Side events and state transitions, readers should refer to Part 4

28、02 Tables for the CDPD MAC Procedures. 2.2Other Definitions Implementor An organization that implements a protocol to be tested. Testing can be carried out in-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 mechani

29、sm 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 ISO 9646-3. MMIMan-Machine Interface. Term used to describe the interface used for interacting with an IUT. This interface is typically a h

30、uman operator sitting at a console or a programmatic interface. SupplierAn organization that supplies IUTs and SUTs to a client. The supplier may also be the implementor of the supplied IUTs and SUTs. AcceptAn IUT is said to accept a message when the decode status flag pertaining to the transmitted

31、message indicated success. IgnoreAn IUT is said to ignore a message when the IUT does nothing receiving the message. Ignoring a message is equivalent to not having received it. Valid FrameA valid frame or block is an expected frame or block which arrives at the correct state or phase and does not be

32、long to any of the categories listed under invalid frames. Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 21:41:55 MDTNo reproduction or networking permitted without license from

33、IHS -,-,- TIA/EIA-732-920MAC Abstract Test Suite 9204 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 Invalid FrameAn invalid frame or block that: IDoes not consist of an integr

34、al number of blocks or octets IFrame with less than two octets IFrame with greater than 136 octets IA transmission burst containing seven or more continuous “1” bits. Inopportune Frame An inopportune frame is a syntactically valid frame arriving at a time (IUTs state) when it should be considered ir

35、relevant by the IUT. 3Testing Methodology The testing methodology used in this part complies with the requirements of the OSI Conformance Testing Methodology and Framework as specified in ISO 9646-2 and is further defined in Part 900. 3.1Relationship Between the TSS a TX test case on the Network Sid

36、e would imply the IUT transmits something on the forward channel. State xxThe state which the test cases apply, refer to Section 2.2 State Definitions for valid IUT States and substates. The state identifier xx will be prefixed with “S”. Under the Common group the State field is not applicable. “xx”

37、Indicates the IUTs state, which may be a numeric or a alphanumeric identifier TypeTest cases for any group/sub-group/state combination are further collected into groups based on the type of test case. These Types are for valid, invalid and inopportune testing. The definitions and syntax for these te

38、st case types follow: ValidThis subgroup contains those test cases where the tester transmits syntactically and semantically correct/valid frames. VALID is used in the test group path to identify these type of tests. InvalidThis subgroup contains those test cases where the tester transmits invalid f

39、rames Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 21:41:55 MDTNo reproduction or networking permitted without license from IHS -,-,- 9207 MAC ATS Test Suite Structure TIA/EIA-7

40、32-920 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 or frames which are syntactically and or semantically incorrect. INVALID is used in the test group path to identify these

41、type of tests. InopportuneThis subgroup contains those test cases where the tester transmits syntactically and semantically correct frames but arriving at an inopportune moment. INOP is used in the test group path to identify these type of tests. Test cases can be identified by the test group refere

42、nce 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 naming convention for test cases is defined. Test case names are of the form: Group/Sub-group/State_/PTnn where: PTIndicat

43、es 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 contain more than 99 test cases. Further, test cases 0 through 9 use a leading 0 such that 2 characters are always used. E

44、xample: Given the following reference: MAC/C/RX/VALID/CRX_V01 MAC/CThe ATS is for the MAC Common testing procedures group. RXThe sub-group for receive tests, no state is used for the Common group so it is not present in the path. VALIDThe test case involves the testing of a valid IUT behavior. CRX_V

45、01The 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 test case for that particular test case sub-group. Copyright Telecommunications Industry Association Provided by IHS

46、 under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 21:41:55 MDTNo reproduction or networking permitted without license from IHS -,-,- TIA/EIA-732-920MAC Abstract Test Suite 9208 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 2

47、7 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 5Introduction to MAC Layer PIXIT Protocol implementations can vary extensively (i.e., different designs, different hardware, different operating systems) and may have system specific requirements. Th

48、e 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 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 preparat