Reminder,
There is a MidWest (ICC) Test Plan team conference call tomorrow,
Thursday, July 24 at 13:00 CDT.
The callin numbers is:
800-708-XXXX, code XXXX
Attached is a proposed section 4.9.3 that I have put together on SCP
error testing. It is not exhaustive, but is instructive and I propose it
be added to the test plan for completeness sake, not run during the
field trial. I have executed all of these eror tests (and many more) in
my lab and think they are a good set. These are part of the discussion
tomorrow.
Other items:
- cutting down on the ISDN tests.
- Readout from Bill Belshaw on latest version of the test plan
- turnover procedures to the NIIF?? Will probably need help from Robin
Meier.
- Action Item list.
Walt Subora
******************************************************************
4.9.3 LSP SCP Failure
4.9.3.1 SCP Overload testing
4.9.3.1.1 LNP Set-up and Baseline for LNP Application
SYNOPSIS: This test is run after all interconnections are established.
The purpose of the test is to "soak" the configuration with LNP
Application Traffic and allow testers to understand how the network
looks and behaves without any failures present. This view will be used
as a baseline to compare the network s reaction during other tests.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure X.
TRAFFIC LOAD: The traffic is a mix of AIN 0.1 LNP Messages, and IN LNP
Messages. The traffic load is 20% per LNP SCP A-link.
TEST PROCEDURES:
. Start traffic at the SSPs (or simulators) to provide an LNP AIN 0.1/IN
query traffic load of 20% per LNP SCP A-link. Start the traffic at one
SSP at a time. During the first run, the SSPs may have to be adjusted
to get the traffic load correct. Start the traffic mix (AIN/IN LNP
Queries) at the 5ESS, DMS-100 and the EWSD (or simulators)
. After the traffic has stabilized, observe all reports, and messages as
they occur and justify any abnormal results for a period of thirty
minutes.
. Allow traffic to run for a least one hour at this default load level
to determine the stability of the network. Collect all half hour, hour
and daily reports from each system component.
TEST RESULTS:
. Traffic is started and the SCP handles the traffic without overload.
. Measurements reports correctly reflect the traffic load over the test
interval.
4.9.3.1.2 LNP Set-up and Baseline for LNP GTT Function
SYNOPSIS: This test is run after all interconnections are established.
The purpose of the test is to "soak" the configuration with LNP GTT
Function traffic and allow testers to understand how the network looks
and behaves without any failures present. This view will be used as a
baseline to compare the network s reaction during other tests.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure X.
TRAFFIC LOAD: The default traffic is a mix of intersystem messages
using the LNP GTT Function at the SCP (i.e., CLASS, LIDB, CNAM). The
default traffic load is 20% per LNP SCP A-link.
TEST PROCEDURES:
. Start traffic at the SSPs (simulated) to provide an LNP GTT Messages
traffic load of 20% per LNP SCP A-link. Start the traffic at one
simulated SSP at a time. During the first run, the NSTS scripts may
have to be adjusted to get the traffic load correct. Start the traffic
mix (LNP GTT Messages) at the 5ESS, DMS-100 and the EWSD.
. After the traffic has stabilized, observe all reports, and messages
as they occur and justify any abnormal results for a period of thirty
minutes.
. Allow traffic to run for a least one hour at this default load level
if possible to determine the stability of the network. Collect all half
hour, hour and daily reports from each system component.
TEST RESULTS:
. Traffic is started and the SCP handles the traffic without overload.
. Measurements reports correctly reflect the traffic load over the test
interval.
4.9.3.1.3 General Overload - LNP (LRN) Application Traffic
SYNOPSIS: This test examines the effect on the network when a
sufficient level of LNP Application traffic is sent to the LNP SCP
resulting in LNP SCP Overload. A low level of traffic is the initial
traffic for this test and then the traffic level is increased causing
the LNP SCP to go into overload and include ACGs in the responses. Once
the test is complete the traffic load should be reduced and the LNP SCP
should go out of overload.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure 2.
TRAFFIC LOAD: The traffic is a mix of AIN 0.1 LNP Messages and IN LNP
Messages. The traffic load is 20% per LNP SCP A-link. Once the 20% per
A-Link is established, the traffic load should be increased to cause LNP
SCP Overload.
TEST PROCEDURES:
. Start traffic at the SSPs (simulated) to provide an LNP AIN 0.1/IN
query traffic load of 20% per LNP SCP A-link. Start the traffic mix (LNP
AIN 0.1 and IN Queries) at the 5ESS, DMS-100 and the EWSD and simulated
SSPs.
. After the traffic has stabilized, observe all reports, and messages
as they occur and justify any abnormal results for a period of 10
minutes.
. Increase the SSPs (simulated) traffic from the current load to LNP
SCP Overload level.
. Let the traffic run at this level for at least 2 minutes. The LNP
SCP reaction to this query load should be observed. Any abnormal
messages displayed at the LNP SCP should be reported. Also, observe if
there is any decrease in responses from the LNP SCP.
. The simulated SSPs should cut back future queries for LNP dialed
numbers (for duration specified in ACG component).
. Observe if there are any unusual maintenance messages at the SSPs or
if the SSPs time out waiting for responses.
. The analyst will verify that the LNP SCP sends the ACG message
component in its responses while it is in overload and that each of the
SSPs have sent the ACGEncountered parameter in the AIN 0.1 queries to
the LNP SCP.
. Remove the LNP SCP from Overload by reducing the SSPs
(simulated)traffic to 20% per LNP SCP A-link.
. Let the traffic run for at least 5 minutes. Once the traffic level
is at 20% per LNP SCP A-link, verify that no more ACGs are sent by the
LNP SCP and no abnormal messages are displayed at the SSP and the LNP
SCP.
TEST RESULTS:
. Traffic is started and the SCP handles the traffic without overload.
. The SCP goes into overload and sends ACG for the LRN.
. Measurements reports correctly reflect the traffic load over the test
interval, including the lost messages that were discarded.
. SSP measurements should indicate messages discarded due to ACG as well
as messages handled.
4.9.3.1.4 General Overload - LNP Application and LNP GTT Function
Traffic
SYNOPSIS: This test examines the effect on the network when a
sufficient level of LNP Application and LNP GTT Function traffic is sent
to the LNP SCP resulting in LNP SCP Overload. A low level of traffic is
the initial traffic for this test and then the traffic level is
increased causing the LNP SCP to go into overload and include ACGs in
the responses (ACGs will not be sent for the LNP GTT Function Messages).
The SSPs should then reduce the traffic load and the LNP SCP should go
out of overload.
Since no ACGs components will be returned to the SSPs for the LNP GTT
Function Messages during the LNP SCP overload these messages should be
monitored closely to find if they are processed by the LNP SCP or if
they are discarded.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure X.
TRAFFIC LOAD: The traffic is a mix of AIN 0.1 LNP Messages, IN LNP
Messages and intersystem messages using the LNP GTT Function (i.e.,
CLASS, LIDB, CNAM). The traffic load is 20% per LNP SCP A-link. Once
the 20% per A-Link is established, the traffic load should be increased
to cause LNP SCP Overload.
TEST PROCEDURES:
. Start traffic at the SSPs (simulated) to provide an LNP AIN 0.1/IN
query traffic load of 20% per LNP SCP A-link. Start the traffic mix (LNP
AIN 0.1, IN Queries and Intersystem Messages (i.e., CLASS, LIDB, CNAM))
at the 5ESS, DMS-100 and the EWSD and the
. After the traffic has stabilized, observe all reports, and messages as
they occur and justify any abnormal results for a period of 10 minutes.
. Increase the SSPs (simulated) traffic from the current load to LNP SCP
Overload level.
. Let the traffic run at this level for at least 2 minutes. The LNP SCP
reaction to this query load should be observed. Any abnormal messages
displayed at the LNP SCP should be reported. Also, observe if there is
any decrease in responses from the LNP SCP.
. The SSPs should cut back future queries for LNP dialed numbers (for
duration specified in ACG component).
. Observe if there are any unusual maintenance messages at the SSPs or
if the SSPs time out waiting for responses.
. Observe what is occurring with the Intersystem Messages.
. The analyst will verify that the LNP SCP sends the ACG message
component in its responses (for AIN 0.1 and IN LNP Messages) while it is
in overload and that each of the SSPs have sent the ACGEncountered
parameter in AIN 0.1 queries to the LNP SCP.
. Remove the LNP SCP from Overload by reducing the SSPs (simulated)
traffic to 20% per LNP SCP A-link.
. Let the traffic run for at least 5 minutes. Once the traffic level is
at 20% per LNP SCP A-link, verify that no more ACGs are sent by the LNP
SCP and no abnormal messages are displayed at the SSP and the LNP SCP.
TEST RESULTS:
. Traffic is started and the SCP handles the traffic without overload.
. The SCP goes into overload and sends ACG for the LRN traffic but not
for the GTT traffic.
. Measurements reports correctly reflect the traffic load over the test
interval, including the lost messages that were discarded.
. SSP measurements should indicate messages discarded due to ACG as well
as messages handled.
4.9.3.1.5 General Overload - Repeated Overload and Sustained Overload
SYNOPSIS: During the first part of this test, the effect on the network
when sufficient level of LNP Application traffic is sent to the LNP SCP
causing overload will be evaluated. This overload should result in ACGs
being sent in the response message to the SSPs. This test then reduces
traffic to terminate overload conditions. After a short period of time
at the reduced traffic load, the LNP traffic will be increased causing
the LNP SCP to enter (once again) and remain in overload. The SSPs
should reduce their traffic due to the activation of ACG.
During the second part of this test, the LNP SCP will remain in overload
long enough to progress through all levels of overload. When the LNP
SCP has reached its most severe overload level, SSPs (simulated) traffic
will be reduced. The LNP SCP should then reduce the overload level and
eventually go out of overload.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure X.
TRAFFIC LOAD: During the first part of this test, the traffic is a mix
of AIN 0.1 LNP Messages, and IN LNP Messages. The traffic load is
initially 20% per LNP SCP A-link and then traffic load should be
increased to cause LNP SCP Overload. Traffic will be then be reduced to
20% per LNP SCP A-link and then increased once again to cause LNP SCP
Overload.
During the second part of this test the traffic mix will stay the same,
and the traffic will start at 20% per LNP SCP A-link. The traffic will
then be increased to reach all levels of LNP SCP Overload. Once the LNP
SCP has been in most severe level of overload, SSPs (simulated) traffic
should be reduced to 20% per LNP SCP A-link allowing the LNP SCP to step
down through each overload level until it is no longer in overload.
TEST PROCEDURES:
Part 1:
. Start traffic at the SSPs (simulated)to provide an LNP AIN 0.1/IN
query traffic load of 20% per LNP SCP A-link. Start the traffic mix (LNP
AIN 0.1 and IN Queries) at the 5ESS, DMS-100 and the EWSD.
. After the traffic has stabilized, observe all reports, and messages
as they occur and justify any abnormal results for a period of 10
minutes.
. Increase the SSPs (simulated)traffic from the current load to LNP SCP
Overload level.
. Let the traffic run at this level for at least 2 minutes. The LNP
SCP reaction to this query load should be observed. Any abnormal
messages displayed at the LNP SCP should be reported. Also, observe if
there is any decrease in responses from the LNP SCP.
. The SSPs should cut back future queries for LNP dialed numbers (for
duration specified in ACG component).
. Observe if there are any unusual maintenance messages at the SSPs or
if the SSPs time out waiting for responses.
. The analyst will verify that the LNP SCP sends the ACG message
component in its responses while it is in overload and that each of the
SSPs have sent the ACGEncountered parameter in AIN 0.1 queries to the
LNP SCP.
. Remove the LNP SCP from Overload by reducing the SSPs
(simulated)traffic to 20% per LNP SCP A-link.
. Let the traffic run for at least 5 minutes. The LNP SCP reaction
should be observed. Any abnormal messages displayed at the LNP SCP
should be reported.
. Observe if there are any unusual maintenance messages at the SSPs.
. Once again, increase the SSPs (simulated)traffic from the current
load to LNP SCP Overload level.
. Let the traffic run at this level for at least 2 minutes. The LNP
SCP reaction to this query load should be observed. Any abnormal
messages displayed at the LNP SCP should be reported. Also, observe if
there is any decrease in responses from the LNP SCP.
. The SSPs should cut back future queries for LNP dialed numbers (for
duration specified in ACG component).
. Observe if there are any unusual maintenance messages at the SSPs or
if the SSPs time out waiting for responses.
. The analyst will verify that the LNP SCP sends the ACG message
component in its responses while it is in overload and that each of the
SSPs have sent the ACGEncountered parameter in AIN 0.1 queries to the
LNP SCP (while the LNP SCP was in overload).
. Remove the LNP SCP from Overload by reducing the SSPs
(simulated)traffic to 20% per LNP SCP A-link.
. Let the traffic run for at least 5 minutes. The LNP SCP reaction
should be observed. Any abnormal messages displayed at the LNP SCP
should be reported.
. Observe if there are any unusual maintenance messages at the SSPs.
. Stop all traffic.
. Part II:
. After 10 minutes of no traffic, start traffic at the SSPs
(simulated)to provide an LNP AIN 0.1/IN query traffic load of 20% per
LNP SCP A-link. Start the traffic mix (LNP AIN 0.1 and IN Queries) at
the 5ESS, DMS-100 and the EWSD.
. Let the traffic run for at least 10 minutes. The LNP SCP reaction to
this query load should be observed. Any abnormal messages displayed at
the LNP SCP should be reported.
. Observe if there are any unusual maintenance messages at the SSPs.
. Increase the SSPs (simulated)traffic from the current load to LNP SCP
Overload level.
. Let the traffic run at this level until the LNP SCP has reached its
most severe overload level and remain at this level for 2 minutes. The
LNP SCP reaction to this query load should be observed. Any abnormal
messages displayed at the LNP SCP should be reported. This should
include information such as the query load and overload level as well as
observing is there is any decrease in responses from the LNP SCP.
. Observe if there are any unusual maintenance messages at the SSPs or
if the SSPs time out waiting for responses.
. The analyst will verify that the LNP SCP sends the ACG message
component in its responses while it is in overload and that each of the
SSPs have sent the ACGEncountered parameter in AIN 0.1 queries to the
LNP SCP (while the LNP SCP was in overload).
. Remove the LNP SCP from Overload by reducing the SSPs
(simulated)traffic to 20% per LNP SCP A-link.
. Let the traffic run for at least 15 minutes. The LNP SCP reaction
should be observed. Any abnormal messages displayed at the LNP SCP
should be reported.
. Observe if there are any unusual maintenance messages at the SSPs.
TEST RESULTS:
. Traffic is started and the SCP handles the traffic without overload.
. The SCP goes into overload and sends ACG for the LRN traffic but not
for the GTT traffic.
. Measurements reports correctly reflect the traffic load over the test
interval, including the lost messages that were discarded.
. SSP measurements should indicate messages discarded due to ACG as well
as messages handled.
4.9.3.1.6 LNP SCP A-Link Failure During LNP SCP Overload
SYNOPSIS: This test examines the effect on the network of a failure of
the A-links from one of the STPs to the LNP SCP during a period in which
a LNP SCP is experiencing general overload.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure X.
TRAFFIC LOAD: The traffic is a mix of AIN 0.1 LNP Messages, and IN LNP
Messages. The initial traffic load is 20% per LNP SCP A-link and then
is increased to reach LNP SCP Overload.
Once the LNP SCP has been in overload for 2 minutes, SSPs (simulated)
traffic should be reduced to 20% per LNP SCP A-link.
TEST PROCEDURES:
. Start traffic at the SSPs (simulated) to provide an LNP AIN 0.1/IN
query traffic load of 20% per LNP SCP A-link. Start the traffic mix (LNP
AIN 0.1 and IN Queries) at the 5ESS, DMS-100 and the EWSD and simulated
SSPs.
. After the traffic has run at this level for 5 minutes, observe all
reports, and messages as they occur and justify any abnormal results.
. Observe if there are any unusual maintenance messages at the SSPs or
if the SSPs time out waiting for responses.
. Increase the SSPs (simulated) traffic from the current load to LNP SCP
Overload level.
. Fail the 4 A-links between the DSC STP and the LNP SCP. This will
cause the LNP SCP to reroute all responses to the MGTS STP. The DSC STP
should send a TFP message to the MGTS STP and broadcast TFR messages to
its other adjacent signaling points. Observe if there is any congestion
on the C-link or on the MGTS STP-LNP SCP links.
. Let the traffic run at this rate until the network has stabilized.
Restore the failed links. The DSC STP should broadcast TFA messages to
the adjacent signaling points. The LNP SCP should reroute traffic back
onto the available links and the DSC STP should route queries onto the
recovered links. Observe if there is congestion on any of the links.
TEST RESULTS:
. Traffic is started and the SCP handles the traffic without overload.
. The SCP goes into overload and sends ACG for the LRN traffic but not
for the GTT traffic.
. Measurements reports correctly reflect the traffic load over the test
interval, including the lost messages that were discarded.
. SSP measurements should indicate messages discarded due to ACG as well
as messages handled.
4.9.3.2 LNP SCP Protocol Error Testing - AIN 0.1 Messaging
4.9.3.2.1 Fatal Transaction Portion Protocol Errors - Unrecognized
Package Type
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Unrecognized Package Type" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. [Case 1] The test system sends an Info_Analyzed message with a Package
Type of "Query Without Permission" which is not defined (used) in AIN
0.1.
. [Case 2] The test system sends an Info_Analyzed message with a Package
Type of "Query Without Permission" which is not defined (used) in AIN
0.1. In addition, the Info_Analyzed message contains a Transaction ID
which is 3 octets long. (Note The Transaction ID can only have a length
of 0, 4, or 8.)
TEST RESULTS:
. [Case 1] The SCP should report the error using a P-Abort cause of
"Unrecognized Package Type" in a message with the Abort Package Type to
close the transaction.
. [Case 2] The SCP should not report the error (sends no reply) since
the Transaction ID is not derivable.
4.9.3.2.2 Fatal Transaction Portion Protocol Errors - Underivable
Transaction ID
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Underivable Transaction ID" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends an Info_Analyzed message (Query - Invoke (Last))
with a 3-octet long originating Transaction ID to the SCP.
TEST RESULTS:
. Upon receiving the Info_Analyzed message, the SCP should not generate
any response message to report the error since the Transaction ID of the
message is not derivable. (sends no reply)
4.9.3.2.3 Fatal Transaction Portion Protocol Errors - Incorrect
Transaction Portion
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Incorrect Transaction Portion" and initiate actions based on
the abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. [Case 1] The test system sends an Info_Analyzed message (Query -
Invoke (Last)) to the SCP. The octet that should contain the Transaction
ID Identifier in the transaction portion of the message is coded as
"0xD0" (the value for Operation Code Identifier). (Note that whether the
Transaction ID is considered "derivable" in this case may be
implementation dependent.)
. [Case 2] The test system sends an Info_Analyzed message (Query -
Invoke (Last)) to the SCP. The three octets "0xD70105" are inserted
between the Transaction ID and the Component Sequence Identifier.
TEST RESULTS:
. [Case 1] Upon receiving the Info_Analyzed message, the SCP should not
generate any response message to report the "Incorrect Transaction
Portion" error since the Transaction ID is not derivable.
. [Case 2] Upon receiving the Info_Analyzed message, the SCP should
respond with an Abort message with the P-Abort cause of "Incorrect
Transaction Portion".
4.9.3.2.4 Fatal Transaction Portion Protocol Errors - Badly Structured
Transaction Portion
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Badly Structured Transaction Portion" and initiate actions
based on the abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. [Case 1] The test system sends an Info_Analyzed message (Query -
Invoke (Last)) to the SCP. In addition, the message does not contain a
Transaction ID, and the TCAP Message Length is populated with an
incorrect value.
. [Case 2] The test system sends an Info_Analyzed message (Query -
Invoke (Last)) populated with an incorrect TCAP Message Length to the
SCP.
TEST RESULTS:
. [Case 1] Upon receiving the Info_Analyzed message, the SCP should not
generate any response message to report the "Badly Structured
Transaction Portion" error since the Transaction ID is not derivable.
. [Case 2] Upon receiving the Info_Analyzed message, the SCP should
respond with a P-Abort message with the P-Abort cause of "Badly
Structured Transaction Portion".
4.9.3.2.4 Fatal Component Portion Protocol Errors - Unrecognized
Component Type
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Unrecognized Component Type" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends an Info_Analyzed message (Query - Return Result
(Not Last)) to the SCP.
TEST RESULTS:
. Upon receiving the Info_Analyzed message, the SCP should send a
Response message containing a Reject component with a Problem Code of
"Unrecognized Component Type".
4.9.3.2.5 Fatal Component Portion Protocol Errors - Unrecognized
Operation Code
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Unrecognized Operation Code" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends a message (Query - Invoke (Last)) to the SCP.
The Operation Code is coded as "0x6018" which is not used in AIN 0.1.
TEST RESULTS:
. Upon receiving the message, the SCP should send a Response message
containing a Reject component with a Problem Code of "Unrecognized
Operation Code".
4.9.3.2.6 Fatal Component Portion Protocol Errors - Incorrect Component
Portion
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Incorrect Component Portion" and initiate actions based on the
abnormal protocol procedures
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends an Info_Analyzed message (Query - Invoke (Last))
to the SCP. The octet that should contain the Component Type Identifier
in the component portion of the message is coded as "0xC7" (i.e. the
value for a Transaction ID identifier).
TEST RESULTS:
. Upon receiving the Info_Analyzed message, the SCP should send a
Response message containing a Reject component with a Problem Code of
"Incorrect Component Portion".
4.9.3.2.7 Fatal Application Error - Unexpected Message
SYNOPSIS: To test the SCP s capability to detect the fatal application
error of "Unexpected Message" and initiate actions based on the abnormal
protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends an Info_Analyzed message (Invoke - (Last)) and
an Origination_Attempt message (Invoke (Last)) as a multi-component TCAP
message in a Query Package Type to the SCP.
TEST RESULTS:
. Upon receiving the multi-component Info_Analyzed/Origination_Attempt
message, the SCP should respond with a message (Response - Return Error)
with the Error Code of Application_Error and an ApplicationErrorString
containing the ErrorCause of "unexpectedMessage". (Note The SSP is not
allowed to send multi-component messages in AIN 0.1).
4.9.3.2.8 Fatal Application Errors - Unexpected Parameter Sequence
SYNOPSIS: To test the SCP s capability to detect the fatal application
error of "Unexpected Parameter Sequence" and initiate actions based on
the abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends a Info_Analyzed message (Query - Invoke (Last))
to the SCP. The sequence of the parameters contained in the message is
different from the sequence in R 5-70 of TR-NWT-001285.
TEST RESULTS:
. Upon receiving the Info_Analyzed message, the SCP should respond with
a message (Response - Return Error) with the Error Code of
Application_Error and an ApplicationErrorString containing the
ErrorCause of "unexpectedParameterSequence".
4.9.3.2.9 Application Errors - Erroneous Data Value
SYNOPSIS: To test the SCP s capability to detect the application error
of "Erroneous Data Value" and initiate actions based on the abnormal
protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends a Info_Analyzed message (Query - Invoke (Last))
to the SCP with the BearerCapability value coded as "0x99" (which is not
defined in AIN 0.1).
TEST RESULTS:
. Upon receiving the Info_Analyzed message, the SCP should respond with
a message (Response - Return Error) with the Error Code of
Application_Error and an ApplicationErrorString containing the
ErrorCause of "erroneousDataValue".
4.9.3.2.10 Application Errors - Unexpected Communication
SYNOPSIS: To test the SCP s capability to detect the application error
of "Unexpected Communication" and initiate actions based on the abnormal
protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends a Resource_Clear message (Query - Invoke (Last))
to the SCP.
TEST RESULTS:
. Upon receiving the Resource_Clear message, the SCP should respond with
a message (Response - Return Error) with the Error Code of
Application_Error and an ApplicationErrorString containing the
ErrorCause of "unexpectedCommunication". (Note The Resource_Clear
message can only be sent in a Conversation or Response Package Type.)
4.9.3.3 LNP SCP Protocol Error Testing - IN Messaging
4.9.3.3.1 Fatal Transaction Portion Protocol Errors - Unrecognized
Package Type
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Unrecognized Package Type" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. [Case 1] The test system sends a ProvideInstructions message with a
Package Type of "Query Without Permission" which is not defined (used)
in IN.
. [Case 2] The test system sends a ProvideInstructions message with a
Package Type of "Query Without Permission" which is not defined (used)
in IN. In addition, the ProvideInstructions message contains a
Transaction ID which is 3 octets long. (Note The Transaction ID can only
have a length of 0, 4, or 8.)
TEST RESULTS:
. [Case 1] The SCP should send a Response Package Type message with a
Reject Component back to the test system.
. [Case 2] The SCP should not send a Response Package Type message with
a Reject Component back to the test system because the Transaction ID is
underivable. (sends no reply)
4.9.3.3.2 Fatal Transaction Portion Protocol Errors - Underivable
Transaction ID
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Underivable Transaction ID" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends an ProvideInstruction message (Query - Invoke
(Last)) with a 3-octet long originating Transaction ID to the SCP.
TEST RESULTS:
. The SCP should not send a Response Package Type message with a Reject
Component back to the test system as the Transaction ID is underivable.
(sends no reply)
4.9.3.3.3 Fatal Transaction Portion Protocol Errors - Incorrect
Transaction Portion
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Incorrect Transaction Portion" and initiate actions based on
the abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. [Case 1] The test system sends a ProvideInstruction message (Query -
Invoke (Last)) to the SCP. The octet that should contain the Transaction
ID Identifier in the transaction portion of the message is coded as
"0xD0" (the value for Operation Code Identifier).
. [Case 2] The test system sends a ProvideInstruction message (Query -
Invoke (Last)) to the SCP. The three octets "0xD70105" are inserted
between the Transaction ID and the Component Sequence Identifier.
TEST RESULTS:
. [Case 1] The SCP should not send a Response Package Type message with
a Reject Component back to the test system as the Transaction ID is
underivable.
. [Case 2] The SCP should send a Response Package Type message with a
Reject Component back to the test system.
4.9.3.3.4 Fatal Transaction Portion Protocol Errors - Badly Structured
Transaction Portion
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Badly Structured Transaction Portion" and initiate actions
based on the abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. [Case 1] The test system sends a ProvideInstruction message (Query -
Invoke (Last)) to the SCP. In addition, the message does not contain a
Transaction ID, and the TCAP Message Length is populated with an
incorrect value.
. [Case 2] The test system sends a ProvideInstruction message (Query -
Invoke (Last)) populated with an incorrect TCAP Message Length to the
SCP.
TEST RESULTS:
. [Case 1] The SCP should not send a Response Package Type message with
a Reject Component back to the test system as the Transaction ID is
underivable.
. [Case 2] The SCP should send a Response Package Type message with a
Reject Component back to the test system.
4.9.3.3.5 Fatal Component Portion Protocol Errors - Unrecognized
Component Type
SYNOPSIS: To test the SCP s capability to detect the fatal protocol
error of "Unrecognized Component Type" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. The test system sends a ProvideInstruction message (Query - Return
Result (Not Last)) to the SCP.
TEST RESULTS:
. Upon receiving the ProvideInstruction message, the SCP should send a
Response message containing a Reject component with a Problem Code of
"General" and the Correlation ID should contain the value of the initial
query.
4.9.3.3.6 Fatal Application Errors - Unexpected Data Values
SYNOPSIS: To test the SCP s capability to detect the fatal application
error of "Unexpected Data Value" and initiate actions based on the
abnormal protocol procedures.
Requirement ID:. GR, Issue 0.95: Sections 4.5; p. 40, 41.
TEST CONFIGURATION DESCRIPTION: Please refer to Figure Y.
TEST PROCEDURES:
. [Case 1] The test system sends a ProvideInstruction message (Query -
Invoke (Last)) to the SCP. The Digit Dialed (Called) parameter has the
value "0".
. [Case 2] The test system sends a ProvideInstruction message (Query -
Invoke (Last)) to the SCP. The Digits Dialed (Called) parameter has the
"Nature Of Number" field containing the value "0xf" (representing an
invalid value).
. [Case 3] The test system sends a ProvideInstruction message (Query -
Invoke (Last)) to the SCP. The Digits Dialed (Called) parameter has the
"Encoding Scheme" field containing the value "0" (representing the value
of "not used").
TEST RESULTS:
. [Case 1] Upon receiving the ProvideInstruction message, the SCP
should send a Response message with a Return Error component to the
test system. The ProblemData parameter will contain the Digits Dialed
(Called) data element received.
. [Case 2] Upon receiving the ProvideInstruction message, the SCP
should send a Response message with a Return Error component to the
test system. The ProblemData parameter will contain the Digits Dialed
(Called) data element received.
. [Case 3] Upon receiving the ProvideInstruction message, the SCP
should send a Response message with a Return Error component to the
test system. The ProblemData parameter will contain the Digits Dialed
(Called) data element received.