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

Test Configuration A single test configuration is used for TCAP testing.. Example 1: Clearing Before Subsequent Message; Valid Clearing from Initiating Side; Prearranged Ending, Test 1

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

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

Multiple

transaction

1.4.1.1–1.4.1.2, 1.4.2.1–1.4.2.2 4

encoding

Table 16-7 Component Sublayer Tests

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

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

Dialogue portion,

unexpected APDUs

2.3.4.1–2.3.4.8 8

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

Example 1: Clearing Before Subsequent Message; Valid Clearing from

Initiating Side; Prearranged Ending, 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

Example 2: First Continue Message; 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

Example 3: Inopportune Reject 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)

Summary

New 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

particular 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