《TIA-TSB-102.CABA-2002.pdf》由会员分享，可在线阅读，更多相关《TIA-TSB-102.CABA-2002.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 Copyright Telecommunication
2、s Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 02:05:38 MDTNo reproduction or networking permitted without license from IHS -,-,- NOTICE TIA/EIA Engineering Standards and Publications are designed to serve
3、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 for his particular need. Existence of such Standar
4、ds 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 their voluntary use by those other than TIA/EIA membe
5、rs, 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 assume any liability to any patent owner, nor do
6、es 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 useful to the technical community, and represent a
7、pproaches 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 been accepted by, appropriate bodies. Parties wh
8、o 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 Bulletin from time to time as may be occasioned by ch
9、anges 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 conventional voice systems) are excluded from inte
10、roperability 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, Radio Check, Radio Inhibit and Uninhibit, Statu
11、s 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 (TINEIA- 102.BAAA, Section 8). . Mutual aid frequen
12、cy 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 interoperability tests at all of the available channels of a
13、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 they do so. For instance, if one changes the setti
14、ngs 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 transition from individual to group call. Testing for
15、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 document are considered standard options - meaning t
16、hat, 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 does not imply that it is a required service. Onl
17、y 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 Copyright Telecommunications Industry Association Provided by IHS under lice
18、nse with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 02:05:38 MDTNo reproduction or networking permitted without license from IHS -,-,- TSB-I 02.CABA In a similar light, there are certain services for which the implementation may depend upon the needs of the us
19、er 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 subscriber receiver responds to a busy status symbol. The subscriber may be inhibited from transmission
20、 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 circumstances, interoperability testing is required if the functionality is implemented in this way. How
21、ever, 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. One approach evaluates a unit under test (UUT) against a reference (or in some cases two referen
22、ces). 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 assumption that by testing functional capabilities of individual systems against a reference and verifyi
23、ng 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 distinct advantages, it is possible that a UUT could pass an RTS test but fail to verify interoper
24、ability 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 interoperable. The RTS approach, in this case, could potentially identify these errors (provided the refe
25、rence 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 requirement since, in some cases, there is no functional response defined for a particular CAI bit configur
26、ation. 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 understanding of the proper settings. There are circumstances in which the reference may not be ab
27、le 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. In this case, the STS approach should be used and/or a modified RTS approach should be used in whi
28、ch 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 systematically testing each functional capability (which must be TIAI 02 compliant) against each of the oth
29、er UUTs. 7 Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 02:05:38 MDTNo reproduction or networking permitted without license from IHS -,-,- TSB-I 02.CABA This requires that every
30、 possible combination of UUTs under consideration be tested at each interface. The difference between this method and the RTS approach is that, in this case, the UUTs are truly being tested for interoperability, as opposed to making inferences through testing against a reference. After verification,
31、 it is possible to confidently state whether certain combinations of radio systems can interoperate for specific functional capabilities (provided the UUTs are configured properly). One disadvantage to this approach is that, should two UUTs fail to interoperate, the STS approach does not necessarily
32、 identify (but may provide information to deduce) which UUT is noncompliant. Another disadvantage to the STS approach is that it may be impossible to test 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
33、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 perform some action upon reception of the emergency bit, then the emergency mode capability of UUT #I cannot be verified. The RTS approach would be abl
34、e 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 the 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
35、 every possible combination of test unit under consideration. When a test passes using the STS approach, then the functionality is verified. However, the STS approach does not isolate specific test units or functionality, .e., both the transmitter and receiver (and a repeater if being used) are bein
36、g 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 fault if the test fails. 8 Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001,
37、 User=Wing, Bernie Not for Resale, 03/29/2007 02:05:38 MDTNo reproduction or networking permitted without license from IHS -,-,- 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
38、 with the standards. Table 2.1. System to System (STS) Approach Advantages I . 2. Verification of interoperability 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.
39、Requires one complete set of tests for every combination of UUT that is being considered. If the number of 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 ident
40、ify (but may provide information to deduce) which UUT is noncompliant May not be able to test for some functional 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
41、UUT. This becomes a significant advantage as the number of UUTs increases. 2. Verifies standards compliance 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 a
42、gainst an unbiased reference. 3. Requires sophisticated hardware test equipment as a reference. To assure interoperability, 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: . th
43、e test requires examination of individual bits, as in the case when no specific response is defined for the 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 interoperabili
44、ty problem is 9 Copyright Telecommunications Industry Association Provided by IHS under license with EIALicensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 03/29/2007 02:05:38 MDTNo reproduction or networking permitted without license from IHS -,-,- TSB-I 02.CABA desired/necessary.
45、The RTS approach may be the preferred approach if the number 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 ca
46、n terminate voice or data transmissions. This includes mobile, 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 f
47、ixed subscriber that interfaces with the user through a wireline 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,
48、or full-duplex base station, or a full-duplex repeater. Additionally, 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 boun
49、daries for subscriber transmitters (shown in light gray boxes). 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 subscriber-transmi