TIA TSB-102 CABA-2002 Project 25 Interoperability Test Procedures Conventional Voice Equipment《电信系统公告项目25互用性测试规程常规语音设备》.pdf

《TIA TSB-102 CABA-2002 Project 25 Interoperability Test Procedures Conventional Voice Equipment《电信系统公告项目25互用性测试规程常规语音设备》.pdf》由会员分享，可在线阅读，更多相关《TIA TSB-102 CABA-2002 Project 25 Interoperability Test Procedures Conventional Voice Equipment《电信系统公告项目25互用性测试规程常规语音设备》.pdf（60页珍藏版）》请在麦多课文档分享上搜索。

1、TIA/EIA TELECOMMUNICATIONS SYSTEMS BULLETIN Project 25 Interoperability Test Procedures Conventional Voice Equipment TSB- 1 02 .CABA FEBRUARY 2002 TELECOMMUNICATIONS INDUSTRY ASSOCIATION The Teleconmiunications Industry Association represents the conmiunications sector of NOTICE TIA/EIA Engineering

2、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 delay the proper product f

3、or 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 Publications preclude thei

4、r voluntary use by those other than TIA/EIA members, whether the standard is to be used either domestically or internationally. Standards, Publications and Bulletins are adopted by EIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TIA/EIA does not

5、 assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard, Publication, or Bulletin. Technical Bulletins are distinguished from TIA/EIA Standards or Interim Standards, in that they contain a compilation of engineering data or information u

6、seful to the technical community, and represent approaches to good engineering practices that are suggested by the formulating committee. This Bulletin is not intended to preclude or discourage other approaches that similarly represent good engineering practice, or that may be acceptable to, or have

7、 been accepted by, appropriate bodies. Parties who wish to bring other approaches to the attention of the formulating committee to be considered for inclusion in future revisions of this Bulletin are encouraged to do so. It is the intention of the formulating committee to revise and update this Bull

8、etin from time to time as may be occasioned by changes in technology, industry practice, or government regulations, or for other appropriate reasons. (From Project No. 3-0022, formulated under the cognizance of the TIA TR-8 Committee on Mobile therefore, the following items (though associated with c

9、onventional voice systems) are excluded from interoperability testing as described in this document: . Supplementary Services such as: Call Interrupt, Discrete Listening, Silent Emergency, Talking Party Identification, Call Alerting (TSBI 02-A, Table 5-2). . Control Features such as: Emergency Alarm

10、, Radio Check, Radio Inhibit and Uninhibit, Status Update, Status Request and Response, Messaging, Radio Unit Monitor (TSBI 02.AABG). . Networking operations such as: Inter-system or Intra-system roaming (TSBI 02-A, Table 5-2). . Procedures related to low speed data imbedded in conventional voice (T

11、INEIA- 102.BAAA, Section 8). . Mutual aid frequency channel capability (TSBI 02-A, p. 30). While an attempt is made to systematically test all functionality, it is impractical within the time allotted to test all possible combinations of all settings. For instance, performing all of the interoperabi

12、lity tests at all of the available channels of a radio is impractical. It is unlikely, though still possible, that a test unit may not operate properly on one or more channels. Likewise, It is possible that certain settings of a test unit do not behave independently even though it is expected that t

13、hey do so. For instance, if one changes the settings on a test unit from an individual call to a group call, it is expected that this will have no effect on the status symbol operations. In an improperly operating test unit, the status symbol could show a dependancy such that it changes with a trans

14、ition from individual to group call. Testing for these types of problems fall more under the category of performance testing and not interoperability; therefore, interoperability testing of all possible combinations of settings is not performed. Many of the functional capabilities tested in this doc

15、ument are considered standard options - meaning that, while a manufacturer is not required to provide the function, if they do provide the function, it must be compliant with the TIA1 02 standards; therefore, because a functionality is listed within the requirements for interoperability testing, it

16、does not imply that it is a required service. Only those services that are provided by the device and/or services that are mandatory need be tested. The reader is referred to pp. 38-40 of the System and Standards Definition document I (TSBI 02-A) for further discussion. 6 TSB-I 02.CABA In a similar

17、light, there are certain services for which the implementation may depend upon the needs of the user and the choices made by the manufacturer. However, whatever the choice for implementation, it must meet the requirements as defined in the TIAI 02 standards. An example is the manner in which a subsc

18、riber receiver responds to a busy status symbol. The subscriber may be inhibited from transmission during a busy status symbol or it may be allowed to transmit despite the state of the status symbol. Because the inhibition of transmission during a busy assertion may be desirable under certain circum

19、stances, interoperability testing is required if the functionality is implemented in this way. However, just because the test is required does not imply that the response to the busy status symbol has to be implemented one way or the other. 2.1 Test Approach There are two distinct avenues of testing

20、. One approach evaluates a unit under test (UUT) against a reference (or in some cases two references). This is referred to as reference-to-system (RTS) testing. The other approach tests UUTs against each other. This is referred to as system-to-system (STS) testing. The RTS approach makes the assump

21、tion that by testing functional capabilities of individual systems against a reference and verifying that each UUT meets certain requirements under the TIAI 02 digital radio standards, the UUT should be interoperable with all other systems that also meet the requirements. While this method has some

22、distinct advantages, it is possible that a UUT could pass an RTS test but fail to verify interoperability with other systems. The advantage, however, is that, as remote as it may be, it is possible that most of the manufacturers could potentially interpret the standards in error and still be interop

23、erable. The RTS approach, in this case, could potentially identify these errors (provided the reference properly implements the st and a rds) . The reference, as defined in this document, has the characteristics of a diagnostic device such as a test set. Operating at the bit level may be a requireme

24、nt since, in some cases, there is no functional response defined for a particular CAI bit configuration. This is true, for instance, with the emergency bit for which it is left to the system operator to define the response to a positive assertion. Interoperability is then inferred through low level

25、understanding of the proper settings. There are circumstances in which the reference may not be able to perform certain advanced functional capabilities (e.g., trunking). It may be impractical (due to complexity) to develop a reference with sufficient capability to test this advanced functionality.

26、In this case, the STS approach should be used and/or a modified RTS approach should be used in which the reference is augmented with an additional piece of equipment (such as a trunking controller) from a TIA 102 equipment manufacturer. The STS approach verifies interoperability of UUTs by systemati

27、cally testing each functional capability (which must be TIAI 02 compliant) against each of the other UUTs. 7 TSB-I 02.CABA This requires that every possible combination of UUTs under consideration be tested at each interface. The difference between this method and the RTS approach is that, in this c

28、ase, the UUTs are truly being tested for interoperability, as opposed to making inferences through testing against a reference. After verification, it is possible to confidently state whether certain combinations of radio systems can interoperate for specific functional capabilities (provided the UU

29、Ts are configured properly). One disadvantage to this approach is that, should two UUTs fail to interoperate, the STS approach does not necessarily identify (but may provide information to deduce) which UUT is noncompliant. Another disadvantage to the STS approach is that it may be impossible to tes

30、t certain functional capabilities. One example of this might be the setting of the emergency bit in a UUT transmission. A UUT (UUT #I) may provide a capability of transmitting in the emergency mode where the emergency bit in the CAI is set. Since the UUT Rx (UUT #2) does not have a provision to perf

31、orm some action upon reception of the emergency bit, then the emergency mode capability of UUT #I cannot be verified. The RTS approach would be able to test this functional capability by observing the set emergency bit in the received transmission from UUT #l. In the description of the testing for t

32、he STS approach each test is described in terms of two different test units. It must be kept in mind that these tests must actually be repeated for every possible combination of test unit under consideration. When a test passes using the STS approach, then the functionality is verified. However, the

33、 STS approach does not isolate specific test units or functionality, .e., both the transmitter and receiver (and a repeater if being used) are being tested at the same time as well as multiple functions. This test will therefore not allow identification of the specific unit or function that is at fa

34、ult if the test fails. 8 TSB-I 02.CABA approach. Tables 2.1 and 2.2 below list some of the advantages and disadvantages of each approach. 4. It cannot be guaranteed that the reference is compliant with the standards. Table 2.1. System to System (STS) Approach Advantages I. 2. Verification of interop

35、erability is assured This approach may be required for some tests since It is unlikely that all functional capabilities can be tested against an unbiased reference. Disadvantages I. 2. 3. 4. 5. Requires one complete set of tests for every combination of UUT that is being considered. If the number of

36、 UUTs considered is very large, this approach requires testing a tremendous number of different combinations of equipment. Does not assure compliance to the standards. Does not necessarily identify (but may provide information to deduce) which UUT is noncompliant May not be able to test for some fun

37、ctional capabilities May be less automated than the RTS approach Table 2.2. Reference to System (RTS) Approach II Advantages I Disadvantages I. Requires only one complete set of tests for each UUT. This becomes a significant advantage as the number of UUTs increases. 2. Verifies standards compliance

38、 for certain functional capabilities. 3. May be more automated than the STS I. Interoperability is inferred and not assu red. 2. It is unlikely that all functional capabilities can be tested against an unbiased reference. 3. Requires sophisticated hardware test equipment as a reference. To assure in

39、teroperability, it is recommended that the STS approach be taken as a minimum, when possible. In addition, the RTS approach may be necessary for any one of the following three conditions: . the test requires examination of individual bits, as in the case when no specific response is defined for the

40、bit configuration, and/or . identification of a specific UUT causing an interoperability problem is desired/necessary, and/or . a means to determine why a specific UUT causes an interoperability problem is 9 TSB-I 02.CABA desired/necessary. The RTS approach may be the preferred approach if the numbe

41、r of UUTs considered for interoperability becomes large and, therefore, the number of combinations of all the different equipment required for STS testing becomes unwieldy. 2.2 Subscriber Configurations A subscriber is any radio unit that can terminate voice or data transmissions. This includes mobi

42、le, or portable radios and/or base stations. There are three general categories of equipment that can transmit or receive CAI signals: a) mobile radios, b) control stations, and c) fixed transceivers (base stations). A control station is a fixed subscriber that interfaces with the user through a wir

43、eline audio connection and has only simplex or half-duplex operation; therefore, it does not have repeater capabilities. At the CAI, the control station operates identical to a mobile unit. A fixed transceiver can be a simplex, half-duplex, or full-duplex base station, or a full-duplex repeater. Add

44、itionally, a transceiver may have a wireline input for: console audio, local audio, telephony audio, or audio routed from another fixed transceiver. Figure 1 shows four configurations with respect to status symbol assignment at the slot boundaries for subscriber transmitters (shown in light gray box

45、es). Transceivers with associated wireline audio connection are placed under the general block heading of FNE. Group I subscribers use talkaround, without the use of a repeater, to communicate directly between units. All units, whether transmitting or receiving, use simplex operation. All Group I su

46、bscriber-transmitters, whether mobile radios, control stations, or FNEs, set the status symbol, at the slot boundary, to O0 (unknown, talkaround). Group II subscribers, whether they are mobile radios, control stations, or FNEs, use half-duplex operation to transmit to a radio receiver unit. The stat

47、us symbol, at the slot boundary, is set to 1 O (unknown, use for inbound or outbound). The radios receiver can be either half-duplex or full-duplex (includes repeaters). Group III subscriber-transmitters are FNEs with full-duplex operation and may or may not have repeater capabilities. User interfac

48、e to the subscriber-transmitter is made possible through wireline audio connections. The receiving units use half-duplex or full- duplex operation. Group III subscriber-transmitters set the status symbol, at the slot boundaries, to 11 (idle) if the inbound channel is idle, or O1 (busy) if the inboun

49、d channel is in use. 10 TSB-I 02.CABA Group I Subscriber Transmitter - status symbol O0 Simplex Operation Mobile Radio (simplex), or Control Station (simplex), or FNE (simplex - no repeater - with wireline audio connection) transmits to Radio Unit Rx (simplex - no repeater) Group II Subscriber Transmitter - status symbol 10 Half-duplex Subscriber Tx Mobile Radio (half-duplex), or Control Station (half-duplex), or FNE (half-duplex - no repeater - with wireline audio connection) transmits to Radio Unit Rx (half-duplex or full-duplex) Group III Subscriber Transmitter (status symbol O1 or 11) F