Signaling System No.7 Protocol Architecture And Sevices part 63 potx

It is used for both validation and compatibility testing purposes.. Expected Message Sequence for Test 2.1.1 Consider the test passed if the IAM contains the CUG interlock code parameter

ISUP Supplementary Services Testing

The ISUP supplementary test specification is found in ITU Q.785 [91] The

purpose of the tests is to ensure validation and compatibility of an SP's user-to-user

signaling (UUS), closed user group (CUG), calling line identification (CLI), and

connected line identification (COL) supplementary services according to ITU

Q.730 [69]—to a reasonable, but not exhaustive degree Tests for the other

supplementary services have not been specified

The tests are split into four categories according to supplementary service Table

16-4 shows the test categories and the tests therein

Table 16-4 Test Categories and Test Numbers in Q.785

Category Test Number(s) Total

User-to-User Signaling

(UUS)—implicit request

1.1.1.1.1–1.1.1.1.2, 1.1.1.2.1–1.1.1.2.2, 1.1.1.3.1–1.1.1.3.2

6

Closed User Group

(CUG)—decentralized

2.1.1–2.1.8 9

Calling Line Identification

(CLI)

3.1.1–3.1.2, 3.2.1–3.2.2, 3.3.1–3.3.2, 3.4.1–

3.4.2, 3.5.1–3.5.2, 3.6.1–3.6.4, 3.7.1–3.7.2

16

Connected Line

Identification (COL)

6.1.1–6.1.2, 6.2.1–6.2.2, 6.3.1–6.3.2, 6.4.1–

6.4.2, 6.5.1–6.5.2, 6.6.1 – 6.6.2, 6.7.1–6.7.2, 6.8.1

15

The remainder of this section provides an explanation of three of these tests: 2.1.1,

3.1.1, and 6.1.1 These numbers refer to the test numbers allocated in Q.785

Test Configuration

Only a single test configuration is used: the same one that is used in ISUP basic

call control testing 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 The test

specification makes use of stimulus in relation to creating certain conditions

Example 1: CUG Call with Outgoing Access Allowed and Sent, Test 2.1.1

This test is to check that the DUT can correctly send the parameters that are

necessary for a CUG call with outgoing access allowed It is used for both

validation and compatibility testing purposes

The DUT should generate an IAM that contains the optional CUG interlock code parameter set to "interlock code included" and the forward call indicators

parameter with the CUG call indicator set to "CUG call, outgoing access allowed."

It is up to the person(s) carrying out the testing how "invoke" should be used A call should be established even if SP B is not connected to a network that supports the CUG service

Figure 16-24 shows the expected message sequence for this test

Figure 16-24 Expected Message Sequence for Test 2.1.1

Consider the test passed if the IAM contains the CUG interlock code parameter and forward call indicators with the contents specified previously, and if the call is successfully set up and cleared

Example 2: CLIP—Network Provided and Sent, Test 3.1.1

This test is to verify that the DUT can correctly send an IAM with calling line identification presentation (CLIP) set in the calling party number parameter It is used for both validation and compatibility testing purposes

The DUT should generate an IAM that contains the optional calling party number parameter, with the fields presentation restriction indicator set to 00 (presentation allowed) and screening indicator set to 11 (network provided)

Consider the test passed if the received IAM contains the calling party number parameter with the contents specified previously, and the call is successfully set up and cleared

Example 2: COL—Requested and Sent, Test 6.1.1

This test is to check that the DUT can correctly send an IAM with a request for COL It is used for both validation and compatibility testing purposes

The DUT should generate an IAM containing the optional forward call indicators parameter with the field connected line identification indicator set to 1 (requested)

It is up to the person(s) carrying out the testing to decide how to provoke such an IAM

Consider the test passed if the IAM contains the forward call indicators parameter with the contents specified above, and the call is successfully setup and cleared

The SCCP test specification is found in ITU Q.786 [92] The purpose of the tests is

to ensure validation and compatibility of an SP's SCCP connectionless protocol

according to ITU Q.711–716 [58–63], with a degree of confidence There are no

tests covering management, segmentation, or connection-oriented procedures—

these are listed in the specification for further study This test specification can be

considered inadequate for many purposes, leading some European operators to

write their own in-house test specifications completely from scratch

The tests are split up into three categories Table 16-5 shows the test categories and

the tests that they contain

Table 16-5 Test Categories and Test Numbers in Q.786

Category Test Number(s) Total

Messages from SCCP users

Route not on GT 1.1.1.1.1.1–1.1.1.1.1.2, 1.1.1.1.2–1.1.1.1.6 7

Route on GT 1.1.1.2.1.1–1.1.1.2.1.2, 1.1.1.2.2–1.1.1.2.3,

1.1.1.2.4.1–1.1.1.2.4.2, 1.1.1.2.5–1.1.1.2.9

11

Messages from MTP

Route not on GT 1.1.2.2.1.1–1.1.2.2.1.2, 1.1.2.2.2–1.1.2.2.3 4

Data transfer

Data transfer with sequential

delivery capability

1.2.1.1–1.2.1.2 2

Data transfer with syntax

error

1.2.2 1

The remainder of this section explains three of these tests: 1.1.1.1.1, 1.1.1.1.6, and 1.1.2.2.1.2 These numbers refer to the test numbers allocated in Q.786

Test Configuration

Two test configurations(named 1 and 2) are used for SCCP testing For the three tests presented in this section, only configuration 1 is used Figure 16-25 shows configuration 1

Figure 16-25 The Test Configuration 1, Used for SCCP Testing

Example 1: Local DPC and SSN Included, DPC and SSN Available, GT and SSN Included and Sent, Test 1.1.1.1.1.1

This test is to check that the DUT SCCP can deliver user data to the correct SCCP user at the DUT when routing is not on Global Title (GT) It is used for validation testing purposes only

An SSN should be made available at the DUT

The DUT should request delivery of user data to a DUT SCCP user with a DPC and SSN of the DUT in the request

Figure 16-26 shows the primitive sequence for this test

Figure 16-26 Expected Message Sequence for Test 1.1.1.1.1.1

Consider the test passed if the DUT does not send a message to SPB B and the data

is correctly delivered to the SCCP user at the DUT

Example 2: Remote DPC and SSN Included, DPC and/or SSN Unavailable—

Return Option Not Set, Test 1.1.1.1.6

This test checks that the DUT does not return user data sent from the DUT SCCP user when the return option is not set (and the route is not on GT) It is used for validation testing purposes only

The SCCP routing control data should be set such that the DPC of SP B is

unavailable and/or SSN at SP B is unavailable

The DUT SCCP user should request delivery of user data to the remote DPC and the SSN at SP B

Figure 16-27 shows the primitive sequence for this test

Figure 16-27 Expected Message Sequence for Test 1.1.1.1.6

Consider the test passed if the DUT does not send a message to SPB B, and if the data is not returned to the SCCP user at the DUT

Example 3: Local DPC and SSN, and SSN Available GT Not Included, SSN Included, Test 1.1.2.2.1.2

This test is to check that the user data sent to the DUT SCCP user can be delivered

to the correct DUT SCCP user when routing is not on GT It is used for validation testing purposes only

An SSN should be made available at the DUT

The Tester should generate a Unitdata (UDT) message toward the DUT that is addressed with the SSN, no GT, and route on DPC+SSN

Figure 16-28 shows the primitive sequence for this test

Figure 16-28 Expected Message Sequence for Test 1.1.2.2.1.2

Consider the test passed if the DUT does not send an error message to SPB B and the data is delivered to the correct SCCP user at the DUT