Signaling System No.7 Protocol Architecture And Sevices part 62

Chia sẻ: Dasdsadqwe Dsadasdsadsa | Ngày: | Loại File: PDF | Số trang:9

Thêm vào BST

Báo xấu

97
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

MTP 3 Testing The MTP 3 test specification is found in ITU Q.782 [88]. The purpose of the tests is to ensure complete validation and compatibility of an SP's MTP 3 protocol according to ITU Q.704 [53

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Signaling System No.7 Protocol Architecture And Sevices part 62

MTP 3 Testing The MTP 3 test specification is found in ITU Q.782 [88]. The purpose of the tests is to ensure complete validation and compatibility of an SP's MTP 3 protocol according to ITU Q.704 [53]. See Chapter 7, "Message Transfer Part 3 (MTP3)," for a description of the MTP 3 protocol. The tests are split up by functional area into thirteen categories. Table 16-2 shows the test categories and the tests that they contain. Table 16-2. Test Categories and Test Numbers found in Q.782 Category Test Number(s) Total Signaling link 1.1–1.3 3 management Signaling message 2.1–2.3, 2.4.1–2.4.2, 2.5.1–2.5.4, 2.6.1–2.6.3, 2.7 13 handling Changeover 3.1–3.21 21 Changeback 4.1–4.11 11 Forced rerouting 5 1 Controlled 6 1 rerouting Management 7.1.1–7.1.2, 7.2.1–7.2.4, 7.3.1–7.3.2, 7.4, 7.5, 7.6.1– 28 inhibiting 7.6.2, 7.7–7.9, 7.10.1–7.10.2, 7.11–7.16, 7.17.1– 7.17.4 Signaling traffic 8.1–8.4 4 flow control Signaling route 9.1.1–9.1.2, 9.2.1–9.2.2, 9.3, 9.4.1–9.4.2, 9.5.1– 11 management 9.5.2, 9.6, 9.7 Signaling point 10.1.1–10.1.1, 10.2.1–10.2.1, 10.3–10.6, 10.7.1– 11 restart 10.7.2 Traffic test 11 1 Signaling link test 12.1–12.6 6
Invalid messages 13.1–13.12 12 Totals 123 The remainder of this section explains three of these tests: 1.1, 2.41, and 2.61. These numbers refer to the test numbers allocated in Q.782. Test Configuration Four test configurations (named A, B, C, and D) are used for MTP3 testing. Only configuration A is used for the three tests presented in this section. Figure 16-17 shows configuration A. Figure 16-17. Configuration A [View full size image] Links are identified as follows: "number of linkset"—"number of link in the linkset" (1–1 means link 1 of the linkset 1). This identification is independent of SLC that is attributed to these links. When the number of the link is X, the concerned message can use any link in the linkset. Example 1: First Signaling Link Activation, Test 1.1 This test checks that a link can be activated properly. It is used for both validation and compatibility testing purposes. The link should be deactivated before commencing this test. Signaling link activation is the process of making a link ready to carry signaling traffic. If the initial alignment procedure (MTP2) is successful, a signaling link test that utilizing MTP3 SLTM and SLTA messages is started. If this test is successful, the link becomes ready to convey traffic. Chapter 7 describes the sending of SLTM/SLTA. Additional details can be found in ITU Q.707 [56].
The test is performed by activating the link. MTP2 should bring the link into service via the alignment procedure. Next, MTP3 should use the SLTM/SLTA mechanism to make sure that the MTP3 peers can communicate. The DUT should reply to the SLTM with a SLTA. The test pattern received in the SLTA should match the one that is sent in the SLTM. Next, some variable length MSUs should be sent to and from the DUT. The test should be repeated with different SLC values. Figure 16-18 shows the expected message sequence for this test. Figure 16-18. Expected Message Sequence for Test 1.1 Consider the test passed if all messages are correctly received (no loss of messages, no duplication, and no mis-sequencing). Example 2: Load Sharing within a Linkset (All Links Available), Test 2.4.1 This test checks that DUT performs load sharing when all links are available. The linkset should be activated before commencing this test. The test is performed by sending traffic from the DUT to SP B (and SP C for validation testing) on all SLS. When two or more links are used between two points, the load-sharing function should distribute traffic among them. Figure 16-19 shows the expected message sequence for this test. Figure 16-19. Expected Message Sequence for Test 2.4.1
Consider the test passed if all messages are correctly received (no loss of messages, no duplication, and no mis-sequencing) and the messages were transmitted on the correct link, according to the SLS field. Example 3: Inaccessible Destination—Due to a Linkset Failure, < Day Day Up > < Day Day Up >
ISUP Testing The ISUP test specification is found in ITU Q.784.1 [90]. The purpose of the tests is to ensure complete validation and compatibility of an SP's ISUP protocol for basic call control according to ITU Q.704 [75–78, 80–81]. See Chapter 8, "ISDN User Part (ISUP)," for a description of the ISUP protocol. The tests are split into six major categories according to functional area. Table 16- 3 shows the test categories and the tests that they contain. Table 16-3. Test Categories and Test Numbers in Q.784.1 Category Test Number(s) Total Circuit supervision and signaling supervision Circuit supervision 1.1 1 Reset of circuits 1.2.1–1.2.7 7 Circuit group blocking/unblocking 1.3.1.1–1.3.1.2, 1.3.2.1– 7 1.3.2.5 Continuity check procedure 1.4.1–1.4.6 6 Receipt of unreasonable signaling 1.5.1–1.5.3 3 information messages Receipt of unknown signaling information 1.6.1, 1.6.1.1–1.6.1.2, 1.6.2.1– 6 1.6.2.2, 1.6.3.1–1.6.3.2 Receipt of unknown signaling information 1.7.1.1–1.7.1.7, 1.7.2.1– 19 (compatibility procedure) 1.7.2.10, 1.7.3.1–1.7.3.2 Normal call setup—ordinary speech calls Both-way circuit selection 2.1.1–2.1.2 2 Called address sending 2.2.1–2.2.2 2 Successful call setup 2.3.1–2.3.6 6 Propagation delay determination 2.4.1–2.4.5 5 procedure Normal call release 3.1–3.8 8
Unsuccessful call setup 4.1 1 Abnormal situations during a call 5.1 1 Timers 5.2.1–5.2.11 11 Reset of circuits during a call 5.3.1–5.3.2 2 Special call setup Continuity check call 6.1–6.1.5 5 Automatic repeat attempt 6.2.1–6.2.5 5 Dual seizure 6.3.1 1 Semi-automatic operation 6.4.1–6.4.4 4 Simple segmentation 6.5.1–6.5.5 5 Signaling procedures for connection type 6.6.1–6.6.4 4 with Fallback capability Bearer services 64 kbit(s) unrestricted 7.1.1–7.1.3 3 3.1 kHz audio 7.2.1 1 Multirate connection types 7.3.1–7.3.6 6 Congestion control and user flow control Automatic congestion control 8.1.1, 8.1.2 2 ISDN user part availability control 8.2.1–8.2.3 3 Echo control procedure Echo control procedure according to 9.1.1–9.1.2, 9.2 2 Q.767 Totals 128 The remainder of this section explains three of these tests: 1.4.1, 2.2.2, and 5.2.3. These numbers refer to the test numbers allocated in Q.784.1. Test Configuration
Only a single test configuration is used. The test configuration consists of SP A and SP B. SP A is the device under test (DUT), while SP B is the Tester or an SP whose ISUP protocol has been verified. Links and bearers are provided between the two SPs. Example 1: CCR Received—Successful, Test 1.4.1 This test verifies that the DUT performs the continuity check procedure correctly. It is used for both validation and compatibility testing purposes. The circuit should be in the idle condition before commencing the test. The test is performed by sending a continuity check request (CCR) message from the Tester to the DUT. Associated timers are not verified as part of this test. Unlike channel associated signaling (CAS), SS7/C7 does not pass over a bearer— therefore, no inherent circuit testing is present. It is for this reason that a continuity test can be performed to check a circuit before placing a call over it. For more details on the continuity-check procedures, see Q.764 [78] Clause 2.1.8 and Chapter 8. Figure 16-21 below shows the expected message sequence for this test. Figure 16-21. Expected Message Sequence for Test 1.4.1 Consider the test passed if the DUT successfully performs a continuity test (routes the tone back to SP B) and the circuit is still in the idle state at the end of the test. Example 2: Overlap Operation (with SAM), Test 2.2.2 This test verifies that the DUT can set up a call using overlap address signaling. It is used for both validation and compatibility testing purposes. The circuit should be in the idle condition, and both SPs should be configured for overlap operation before commencing the test. The IAM should not contain enough digits to complete the call, thereby ensuring that at least one Subsequent
Address Message (SAM) is sent. The test is performed by initiating an overlap call setup (IAM plus one or more SAMs) from the DUT; following communications establishment, the circuit should then be released. Overlap signaling entails sending the called party number in installments. See Q.764 [78] Clause 2.1.2 and Chapter 8 for additional details. Figure 16-22. Message Sequence for Test 2.2.2 Consider the test passed if the DUT successfully establishes and releases the call. Example 3: Timers T1 and T5—Failure to Receive a RLC, Test 5.2.3 This test checks that the DUT performs appropriate actions at the expiration of timers T1 and T5. It is used for validation testing purposes only. The circuit should be in the idle condition before commencing the test. The test is performed by setting up a call and then only partially clearing it down. When the DUT indicates that it has released the call, the Tester should be programmed not to respond with a release complete message (RLC) message. The value of timers T1 and T5 should be measured. See Q.764 [78] Clause 2.9.6 for more on the use of T1 and T5 on failure to receive RLC. Figure 16-23 shows the message sequence for this test. Figure 16-23. Expected Message Sequence for Test 5.2.3 Consider the test passed if the DUT sends a REL message upon T1's expiration,
sends a reset circuit (RSC) message upon T5's expiration, alerts the "maintenance system" (on many "soft" implementations this could just be the sending of an alarm to a log file), and removes the circuit from service.