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

ISUP Supplementary Services Testing
The ISUP supplementary test specification is found in ITU Q.785 [91
]. The
p
urpose of the
t
ests 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
Totals 46

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.
E
xample 1: CUG Call with Out
g
oin
g
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
p
arameter set to "interlock code included" and the forward call indicators
p
arameter 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.
E
xample 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
p
arameter, 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
p
arameter with the contents specified previously, and the call is successfully set up
and cleared.
E
xample 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
p
arameter 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.

< Day Day Up >

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 on GT 1.1.2.1.1–1.1.2.1.9 9
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
Message return 1.2.3 1
UDTS deliverable 1.2.3.1.1–1.2.3.1.2 2
UDTS undeliverable 1.2.3.2.1 1
Totals 38

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


E
xample 1: Local DPC and SSN Included, DPC and SSN Available, GT and
S
SN 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.
E
xample 2: Remote DPC and SSN Included, DPC and/or SSN Unavailable—
R
eturn 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.
E
xample 3: Local DPC and SSN, and SSN Available GT Not Included, SSN
I
ncluded, 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.
