Signaling System No.7 Protocol Architecture And Sevices part 64 pps

TCAP Testing The TCAP specification is found in ITU Q.787 [93 ]. The purpose of the tests is to ensure validation and compatibility of an SP's TCAP protocol according to ITU Q.771–775 [82 –86], to a reasonable but not exhaustive degree. The tests are split into the TC Transaction sublayer (TSL) test specification and the TC Component sublayer (CSL) test specification. These test categories along with the tests that they contain are shown below in Tables 16-6 and 16-7. Table 16-6. Transaction Sublayer Test Categories and Test Numbers Found in Q.787 Category Test Number(s) Total Valid function Unstructured dialogue 1.1.1.1–1.1.1.2 2 Structured dialogue 1.1.2.1.1.1–1.1.2.1.2, 1.1.2.1.2.1–1.1.2.1.2.2, 1.1.2.2.1.1.1–1.1.2.2.1.1.3, 1.1.2.2.1.2.1– 1.1.2.2.1.2.3, 1.1.2.2.2.1.1–1.1.2.2.2.1.3, 1.1.2.2.2.2.1–1.1.2.2.2.2.3, 1.1.2.3–1.1.2.5 25 Encoding and value variations 1.1.3.1.1.1.1–1.1.3.1.1.1.2, 1.1.3.1.1.2.1, 1.1.3.1.1.3, 1.1.3.2.1.1–1.1.3.2.1.2 6 Syntactically invalid behavior Invalid values for information elements 1.2.1.1.1–1.2.1.1.2, 1.2.1.2.1, 1.2.1.3.1, 1.2.1.4.1, 1.2.1.5.1–1.2.1.5.2 7 Invalid structure 1.2.2.1.1, 1.2.2.2.1–1.2.2.2.2, 1.2.2.3.1–1.2.2.3.5, 1.2.2.4.1–1.2.2.4.2, 1.2.2.5.1, 1.2.2.6.1, 1.2.2.7.1– 1.2.2.7.3, 1.2.3.1.1, 1.2.3.2.1 17 Inopportune messages 1.3.1.1, 1.3.2.1, 1.3.3.1 3 Multiple transaction 1.4.1.1–1.4.1.2, 1.4.2.1–1.4.2.2 4 encoding Totals 64 Table 16-7. Component Sublayer Tests Category Test Number(s) Total Valid function Invoke component, unlinked operations 2.1.1.1.1–2.1.1.1.5, 2.1.1.2.1–2.1.1.2.2, 2.1.1.3.1–2.1.1.3.2, 2.1.1.4.1 10 Invoke component, linked operations 2.1.2.1.1–2.1.2.1.4, 2.1.2.2.1–2.1.2.2.2, 6 Remote reject 2.1.3.1.1–2.1.3.1.4, 2.1.3.2.1 –2.1.3.2.3, 2.1.3.3.1–2.1.3.3.4 11 Reception of component leading to TC-User reject 2.1.4.1.1–2.1.4.1.4, 2.1.4.2.1, 2.1.4.3.1– 2.1.4.3.3, 8 Segmentation for return result 2.1.5.1.1–2.1.5.1.2, 2.1.5.2.1 3 User cancel 2.1.6 1 Encoding variations 2.1.7.1–2.1.7.3, 2.1.7.4.1.1–2.1.7.4.1.2, 2.1.7.4.2 6 Multiple components grouping 2.1.8.1–2.1.8.3 3 Dialogue portion 2.1.9.1.1–2.1.9.1.3, 2.1.9.2.1–2.1.9.2.2, 2.1.9.3, 2.1.9.4, 2.1.9.5.1–2.1.9.5.4, 2.1.9.6, 2.1.9.7.1–2.1.9.7.4 16 Syntactically invalid behaviour Invalid values for information elements 2.2.1.1–2.2.1.2 2 Invalid structure 2.2.2.1.1, 2.2.2.1.2, 2.2.2.2.1–2.2.2.2.3, 2.2.2.3.1, 2.2.2.3.2, 2.2.2.4.1, 2.2.2.4.2, 17 2.2.2.5.1–2.2.2.5.8 Invalid encoding for invoke component 2.2.3.1–2.2.3.3 3 Inopportune behaviour Inopportune invoke component 2.3.1.1 1 Unrecognized invoke ID 2.3.2.1–2.3.2.4 4 Unexpected components 2.3.3.1–2.3.3.6 6 Dialogue portion, unexpected APDUs 2.3.4.1–2.3.4.8 8 Totals 105 The remainder of this section explains three of these tests: 1.1.2.1.1 (1), 1.2.3.3 (1), and 2.3.2.4 (1). These numbers refer to the test numbers allocated in Q.787. Test Configuration A single test configuration is used for TCAP testing. This configuration is the same one configuration 1 used in SCCP testing. E xample 1: Clearin g Be f ore Subsequent Messa g e; Valid Clearin g f rom I nitiatin g Side; Prearran g ed Endin g , Test 1.1.2.1.1 (1) This test verifies that the DUT is able to correctly send a begin message and then terminate the transaction locally using the "prearranged end" method. It is used for both validation and compatibility testing purposes. The DUT should send a begin message to the Tester; however, so that the Tester does not have a chance to reply, TR-END request primitive (prearranged) destined for the TSL at the DUT should follow immediately. Figure 16-29 shows the expected primitive and message sequence for this test. Figure 16-29. Expected Message Sequence for Test 1.1.2.1.1 (1) The transaction ID should be released at SP A. Consider the test passed if the DUT sends the begin message, but does not send an end message. E xample 2: First Continue Messa g e; OTID Absent, Test 1.2.2.3 (1) This test is to check that the DUT discards a corrupt continue message. It is used for validation testing purposes only. Both SP A (DUT TSL) and SP B (Tester TSL) should be in the idle state before testing commences. The DUT should send a begin message to the Tester, and the Tester should respond with a corrupt continue message. The continue should have a syntax error and an OTID that is not deliverable. Figure 16-30 shows the expected primitive and message sequence for this test. Figure 16-30. Expected Message Sequence for Test 1.2.2.3 (1) Consider the test passed if the DUT sends the begin message, does not inform the TR-User of the continue, and does not respond to the continue. E xample 3: Inopportune Re j ect Component, Test 2.3.2.4 (1) This test is to check that the DUT does not affect any active invocation(s) if it receives a Reject component with an Invoke ID that does not correspond to any active invocation. It is used for validation testing purposes only. Both SP A (DUT TSL) and SP B (Tester TSL) should be in the idle state before testing commences. The DUT should initiate an operation invocation (send an Invoke component Class 1 or 2) to the Tester, which should respond with a Reject component that has an invalid Invoke ID. Figure 16-31 below shows the expected primitive and message sequence for this test. Figure 16-31. Expected Message Sequence for Test 2.3.2.4 (1) < Day Day Up > < Day Day Up > Summary N ew SS7 implementations must be tested for both validation and compatibility. Validation is performed before the implementation is connected to a live network and is used to check that the implementation functions correctly; that is, it conforms to the appropriate protocol standards. Compatibility testing is executed after the implementation has passed the validation phase of testing. Compatibility seeks to check interoperability and requires the implementation to be connected to the live network. The ITU-T has specified test documents, which cover both validation and compatibility testing for the core SS7 protocols. These documents should be tailored to suit the implementation under test—specifically, the implemented protocol variants and the nature of the solution itself. This is achieved by aligning the ITU-T test specifications to the national (or regional) variant specifications and the nature of the implementation itself. For example, particular country (or regional) variants might not use particular messages so that any tests relating to these messages can be removed; in addition, where a variant adds messages or parameters, tests should be added to check these areas. Where a p articular solution under test does not have an area of functionality (for example, it can only terminate calls), tests surrounding the areas of functionality that do not require implementation can be removed (for example, the ability to originate calls). Each of the core SS7 protocols (MTP 2, MTP 3, ISUP, ISUP supplementary services, SCCP, and TCAP) has a corresponding ITU-T test specification. These specifications aim to broadly test the main functional areas of each protocol. The IETF is currently working on similar test specifications, which are to be used for the SigTran protocol suite.  . found in ITU Q .78 7 [93 ]. The purpose of the tests is to ensure validation and compatibility of an SP's TCAP protocol according to ITU Q .77 1 77 5 [82 –86], to a reasonable but not exhaustive. 1.2.1.5.1–1.2.1.5.2 7 Invalid structure 1.2.2.1.1, 1.2.2.2.1–1.2.2.2.2, 1.2.2.3.1–1.2.2.3.5, 1.2.2.4.1–1.2.2.4.2, 1.2.2.5.1, 1.2.2.6.1, 1.2.2 .7. 1– 1.2.2 .7. 3, 1.2.3.1.1, 1.2.3.2.1 17 Inopportune messages. 2.1.5.1.1–2.1.5.1.2, 2.1.5.2.1 3 User cancel 2.1.6 1 Encoding variations 2.1 .7. 1–2.1 .7. 3, 2.1 .7. 4.1.1–2.1 .7. 4.1.2, 2.1 .7. 4.2 6 Multiple components grouping 2.1.8.1–2.1.8.3 3 Dialogue portion