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.
