| draft-agurmukhani-test-spec-sua-00 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-agurmukhani-test-spec-sua-00.txt.
INTERNET-DRAFT Anjali Gurmukhani (Editor)
Dipak Aggarwal
Hughes Software Systems (HSS)
Issued: Aug 2003
Expires: Feb 2004
SS7 SCCP-User Adaptation Layer (SUA) Conformance Test plan
<draft-agurmukhani-test-spec-sua-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as 'work in
progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This draft expires in Feb 2004.
Anjali Gurmukhani, HSS [Page 1]
Internet Draft SUA Conformance Test Plan Aug 2003
Abstract
This document presents the test specification for SUA(SCCP User
Adaptation layer )protocol, which can be used to test SUA
implementations for conformance to the protocol definition. The
list of tests is exhaustive and covers almost all the categories
of test. This draft can also be used in conjunction with SUA
specification by implementers of protocol as implementers guide,
as the pictorial representation of various scenarios help easy
understanding of the protocol.
Abstract.............................................................2
1. Introduction......................................................3
1.1 Scope............................................................3
1.2 Terminology......................................................3
2 General Principles of SUA Tests....................................5
2.1 Presentation of test descriptions................................6
3 Test Configurations................................................6
3.1 Configurations for IUT at SGP....................................7
3.2 Configurations for IUT at ASP...................................11
4 Test Cases - SUA at SGP...........................................16
4.1 ASPSM...........................................................16
4.2 ASPTM...........................................................22
4.3 SSNM............................................................45
4.4 Dynamic Routing Key Management..................................56
4.5 Management......................................................68
5 Test Cases - SUA at ASP...........................................78
5.1 ASPSM...........................................................78
5.2 ASPTM...........................................................85
5.3 SSNM............................................................93
5.4 Dynamic Routing Key Management.................................101
5.5 Management.....................................................104
6 Test Cases - SUA at SGP/ASP......................................108
6.1 Connectionless Procedures.................................... 108
6.2 Routing Procedures.............................................116
6.3 Reassembly Procedures ...................................124
6.4 Relay Functionality............................................129
6.5 Connection Oriented Procedures ................................132
6.6 SCTP Connection Management.....................................168
7 Acknowledgements.................................................174
8 Authors' Addresses...............................................175
9 References.......................................................175
Copyright Statement................................................176
Anjali Gurmukhani, HSS [Page 2]
Internet Draft SUA Conformance Test Plan Aug 2003
1. Introduction
1.1 Scope
This document details the Conformance of the SUA( SCCP User
Adaptation Layer) Protocol as per <draft-ietf-sigtran-sua-15.txt>
The next version of the draft will cover any additions done to
Protocol revision and any subsequent RFC published by IETF.
1.2 Terms Used
Signaling Gateway (SG) - Network element that terminates SCN
Signaling and transports SCCP-User signaling over IP to an IP
Signaling endpoint. A Signaling Gateway could be modeled as one
Or more Signaling Gateway Processes, which are located at the
Border of the SS7 and IP networks. Where an SG contains more than
one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7
network and to the supported Application Servers.
Application Server (AS) - A logical entity serving a specific
Routing Key. An example of an Application Server is a virtual IP
Database element handling all requests for an SCCP-user. The AS
Contains a set of one or more unique Application Server Processes,
Of which one or more is normally actively processing traffic.
Application Server Process (ASP) - An Application Server Process
Serves as an active or backup process of an Application Server
(e.g., part of a distributed signaling node or database element).
Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs. An ASP
Contains an SCTP end-point and may be configured to process
traffic Within more than one Application Server.
IP Server Process (IPSP) - A process instance of an IP-based
Application. An IPSP is essentially the same as an ASP, except
that It uses SUA in a peer-to-peer fashion. Conceptually, an IPSP
does Not use the services of a Signaling Gateway.
Anjali Gurmukhani, HSS [Page 3]
Internet Draft SUA Conformance Test Plan Aug 2003
Signaling Gateway Process (SGP) - A process instance of a
Signaling Gateway. It serves as an active, load-sharing or
Broadcast process of a Signaling Gateway.
Signaling Process - A process instance that uses SUA to
communicate With other signaling process. An ASP, a SGP and an
IPSP are all Signaling processes.
Association - An association refers to an SCTP association. The
Association provides the transport for the delivery of SCCP-User
Protocol data units and SUA layer peer messages.
Routing Key - The Routing Key describes a set of SS7 parameters
And/or parameter-ranges that uniquely defines the range of
Signaling traffic configured to be handled by a particular
Application Server. An example would be where a Routing Key
consists Of a particular SS7 SCCP SSN plus an identifier to
uniquely mark the network that the SSN belongs to, for which all
traffic would be Directed to a particular Application Server.
Routing Keys are mutually exclusive in the sense that a received
SS7 signaling Message cannot be directed to more than one Routing
Key. Routing Keys can be provisioned, for example, by a MIB or
registered using SUA's dynamic registration procedures.
Routing Context - An Application Server Process may be configured
to Process traffic within more than one Application Server. In
this Case, the Routing Context parameter is exchanged between the
SGP and the ASP (or between two ASPs), identifying the relevant
Application Server. From the perspective of an SGP/ASP, the
Routing Context Uniquely identifies the range of traffic
associated with a Particular Application Server, which the ASP is
configured to receive. There is a 1:1 relationship between a
Routing Context values and a Routing Key within an AS. Therefore
the Routing Context can be viewed as an index into an AS Table
containing the AS Routing Keys. The Routing Context also uniquely
identifies an SS7 entity (Point code) into a SS7 network, as
presented by the SGP.
Address Mapping Function (AMF) - The AMF is an implementation
Dependent function that is responsible for resolving the address
Presented in the incoming SCCP/SUA message to correct SCTP
Association for the desired endpoint. The AMF MAY use routing
Context / rouging key information as selection criteria for the
Appropriate SCTP association.
Anjali Gurmukhani, HSS [Page 4]
Internet Draft SUA Conformance Test Plan Aug 2003
Fail-over - The capability to re-route signaling traffic as
Required to an alternate Application Server Process, or group of
ASPs, within an Application Server in the event of failure or
Unavailability of a currently used Application Server Process.
Fail-over may apply upon the return to service of a previously
Unavailable Application Server Process.
Network Byte Order - Most significant byte first, a.k.a. Big
Endian.
Layer Management - Layer Management is a nodal function that
Handles the inputs and outputs between the SUA layer and a local
Management Entity.
Host - The computing platform that the SGP or ASP process is
running On.
Stream - A stream refers to an SCTP stream; a uni-directional
Logical channel established from one SCTP endpoint to another
Associated SCTP endpoint, within which all user messages are
Delivered in-sequence except for those submitted to the un-ordered
Delivery service.
Transport address - an address that serves as a source or
Destination for the unreliable packet transport service used by
SCTP. In IP networks, a transport address is defined by the
Combination of an IP address and an SCTP port number. Note, only
One SCTP port may be defined for each endpoint, but each SCTP
Endpoint may have multiple IP addresses.
2 General Principles of SUA Tests
These tests aim to verify a given implementation of a protocol in
Accordance with the relevant draft. The specification is
independent Of a given implementation and does not generally imply
any modification of The endpoint under test. However, it is
recognized that certain tests Require capabilities of the system
that are not explicitly defined in The draft, and these
capabilities may not be present in all Implementations. As a
consequence, certain tests may not be possible in All
implementations.
Anjali Gurmukhani, HSS [Page 5]
Internet Draft SUA Conformance Test Plan Aug 2003
2.1 Presentation of test descriptions
Each test description includes the environment in which the
implementation under test must be inserted in order to pass the
test. Nine test Configurations are defined (named A, B, C, D, G, H
and I, Relay); they are presented in clause 3.
Each test is precisely described. Nevertheless, some events not
Directly concerning the point under test, or without direct link
With the test nature, are not explicitly described. In order to
preserve the Test description implementation independence,
certain flexibility has been left in the test descriptions. This
is particularly the case when it is necessary to terminate the
SCTP association (where it is only mentioned, "Terminate" with no
more precision). The operator will choose according to the
implementation particularities and the events
expected in the test description, the appropriate Termination
means (MML- Man Machine Language, provoked failure, etc.).
2.1.1 Pre Test Condition
Before starting the test we need to get the setup into a condition
From where test can be started. These conditions are specified in
Pre- Test condition in each test.
Note: Where NIF has been written, it means that NIF+SM. In some
implementation these may be two entities and in some, they may be
implemented in single entity.
3 Test Configurations:
The set of tests described in this Recommendation assumes that the
Point under test is inserted in a test environment called "test
Configuration".
Anjali Gurmukhani, HSS [Page 6]
Internet Draft SUA Conformance Test Plan Aug 2003
3.1 Configuration A: For Testing the IUT at SGP
Configuration A :
This simple configuration is used for all the procedures of tests
Concerning only one AS. Configuration A is shown in figure 1.
AS is Handling the traffic for routing context P and N/w
Appearance A. AS is having only one ASP ASP1.SG routes data to Point
code Z and SGP serves SG.
Routing Context P may Be based on the following information:
1. DPC.
2. DPC+SSN.
3. IP Address.
4. IP Address + SSN.
5. Hostname
SG
------------- --------------
| SGP/IPSP | | AS DPC = X |
| under Test | | ------- |
| DPC = Z |-------------------------------|--| ASP1 | |
| | | ------- |
------------- --------------
Fig 1: Configuration A
Anjali Gurmukhani, HSS [Page 7]
Internet Draft SUA Conformance Test Plan Aug 2003
Configuration B:
This configuration is used for all the procedures of tests concerning
one ASP in two AS which are handling traffic for both AS.
Configuration B is shown in figure 2. AS1 is handling the traffic
for routing context P and N/w Appearance A. AS2 is handling the
traffic for routing context Q and N/w Appearance A. ASP1 is in both
AS. Point Code of SGP/IPSP is Z.
Routing Context P and Q may be based on the following information:
1. DPC.
2. DPC+SSN.
3. IP Address.
4. IP Address + SSN
5. hostname.
--------------
SG | AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SGP/IPSP | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC Y |
------------- | ------- |
| | ASP1 | |
| ------- |
--------------
Fig 2: Configuration B
Anjali Gurmukhani, HSS [Page 8]
Internet Draft SUA Conformance Test Plan Aug 2003
Configuration C :
This configuration is used for all the procedures of tests concerning
two or more ASP in one AS. Configuration C is shown in figure 3. AS
is handling the traffic for routing context P and N/w Appearance A.
ASP1 and ASP2 can be in FAIL-OVER /LOADSHARE/BROADCAST mode of
traffic handling.
Point Code of SGP/IPSP is Z. Routing Context P may be based on the
following information:
1. DPC.
2. DPC+SSN.
3. IP Address.
4. hostname.
5. IP Address + SSN
--------------
SG | AS DPC X |
------------- | ------- |
| |-------------------------------|-| ASP1 | |
| SGP/IPSP | | ------- |
| Under Test | | ------- |
| DPC Z | | | ASP2 | |
| |-------------------------------|- ------- |
------------- --------------
Fig 3: Configuration C
Anjali Gurmukhani, HSS [Page 9]
Internet Draft SUA Conformance Test Plan Aug 2003
Configuration D :
This configuration is used for all the procedures of tests concerning
two or more AS which are handling traffic for different network
appearance and different routing context. Configuration D is shown in
figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and
AS3 is handling traffic for N/w appearance B. AS1 is handling traffic
for Routing Context P, AS2 is handling traffic for Routing Context Q
and AS3 is handling traffic for Routing Context R.
1. DPC.
2. DPC+SSN.
3. IP Address.
4. IP Address + SSN.
5. Hostname
--------------
SG | AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SGP/IPSP | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC Y |
------------- -------+ | ------- |
| | | ASP2 | |
| | ------- |
| --------------
| --------------
| | AS3 DPC z |
+-----------------------|- ------- |
| | ASP 3 | |
| ------- |
--------------
Fig 4: Configuration D
Anjali Gurmukhani, HSS [Page 10]
Internet Draft SUA Conformance Test Plan Aug 2003
3.2 Configurations for Testing the IUT at ASP
Configuration G :
This simple configuration is used for all the procedures of tests
concerning only one SGP/IPSP. Configuration G is shown in figure 7.
Point Code of SGP is Z. ASP is handling the traffic for routing
context P.
Routing Context P may be based on the following information:
1. DPC.
2. DPC+SSN.
3. Hostname
4. IP Address
5. IP Address + SSN.
------------- --------------
| ASP1 | | SGP/IPSP |
| Under Test | | DPC = Z |
| DPC = X |-------------------------------| SG |
| | | |
------------- --------------
Fig 7: Configuration G
Anjali Gurmukhani, HSS [Page 11]
Internet Draft SUA Conformance Test Plan Aug 2003
Configuration H:
This configuration is used for all the procedures of tests concerning
Two SGPs/IPSPs connected to the same ASP and handling traffic for the
same DPC In the SEP network. Configuration H is shown in figure 8.
SG1/IPSP1 and SG2/IPSP2 are handling the traffic for N/w Appearance
A.Point Code of SG1/IPSP1 is Y and of SG2/IPSP2 is Z. Routing Context
P may be based on the following information:
1. DPC.
2. DPC+SSN.
3. IP Address
4. Hostname.
5. IP Address + SSN
--------------
| SG1/IPSP1 |
------------- | DPC Y |
| |-------------------------------| |
| ASP1 | | SG1 |
| Under Test | --------------
| DPC X | --------------
| |-------------------------------| SG2/IPSP2 |
------------- | DPC Z |
| SG2 |
| |
--------------
Fig 8: Configuration H
Anjali Gurmukhani, HSS [Page 12]
Internet Draft SUA Conformance Test Plan Aug 2003
Configuration I:
This simple configuration is used for all the procedures of tests
Concerning one ASP in two AS. Configuration I is shown in figure 9.
Point Code of SGP/IPSP is Z. ASP1 is in two AS, AS1 and AS2. AS1 is
handling Traffic for routing context P and AS2 is handling traffic
for routing Context Q. Routing Context P and Q may be based on the
following Information:
1. DPC.
2. DPC+SSN.
3. IP Address/IP Address + SSN.
4. Hostname.
+--------------+
| Under Test |
| AS1 DPC X |
| ------- | +----------------+
| | ASP1 | | ---------------------| |
| ------- | | SGP / IPSP |
+--------------+ | |
+--------------+ | DPC Z |
| AS2 DPC Y | | SG |
| ------- | ---------------------| |
| | ASP1 | | +----------------+
| ------- |
| Under Test |
+--------------+
Fig 9: Configuration I
Configuration Note: The SG can have same Point Code as one of
The AS in the SEP mode of operation.
Anjali Gurmukhani, HSS [Page 13]
Internet Draft SUA Conformance Test Plan Aug 2003
Configuration J:
This configuration is used for all the procedures of tests concerning
two SGPs in an SG connected to the same ASP. SG is handling traffic
for Point Code Y and SGP1 and SGP2 are serving the SG. The ASP is
handling Traffic for Routing Context P. Configuration J is shown in
figure 10. The SG can be in Broadcast, Loadshare or Override Mode.
Routing Context P may be based on the following information:
1. DPC.
2. DPC+SSN.
3. Global Title GT.
4. Hostname.
5. IP Address
6. IP Address + SSN.
+--------------+
| SGP1 |
+-------------+ | DPC Y |
| |-------------------------------| SG |
| ASP1 | | |
| Under Test | +--------------+
| DPC X | +--------------+
| |-------------------------------| SGP2 |
+-------------+ | DPC Y |
| SG |
| |
+--------------+
Fig 10 : Configuration J
Anjali Gurmukhani, HSS [Page 14]
Internet Draft SUA Conformance Test Plan Aug 2003
Configuration RELAY:
This configuration is used for all the procedures of tests concerning
Relay functionality of SUA. Here IPSP1 is connected to IPSP2 which is
connected to another IPSP3.
Routing Context P may be based on the following information:
1. DPC.
2. DPC+SSN.
3. Global Title GT.
4. IP Address
5. IP Address + SSN
Configuration RELAY is shown in figure 11.
+-------------+ +-------------+ +--------------+
| | | | | |
| +-------+ | | +--------+ | | +---------+ |
| | | ----------| | | --------- | | | |
| | IPSP1| | | | IPSP2 | | | | IPSP3 | |
| +-------+ | | +--------+ | | +---------+ |
+-------------+ +-------------+ +--------------+
DPC X AS1 AS2
DPC=Y
Fig 11: Configuration Relay
Anjali Gurmukhani, HSS [Page 15]
Internet Draft SUA Conformance Test Plan Aug 2003
4.Test Cases for Testing SUA at SGP
4.1 ASPSM
"Heartbeat and Heartbeat Ack"
+ TEST NUMBER: ASPSM_1
+ PURPOSE:: To check that an ASP sends Heartbeat messages (to ensure
that the SUA peers are still available to each other) and receives a
Heartbeat Ack from the remote peer.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. ASP is active. Also arrange the data in ASP such that BEAT
message is sent from ASP to SGP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM
ASP is Active
a) BEAT (ASP1) ----------------->
Timer 2*T(beat) |
is started |
<---------------- BEAT ACK
b) BEAT (ASP1) ----------------->
Timer 2*T(beat) |
is started |
|
Timer 2*T(beat) is expired and no BEAT ACK is from SGP.
TEST DESCRIPTION:
1. Send BEAT Message from ASP to the SGP.
2. The beat message should be acknowledge by BEAT ACK before the Timer
expires.
3. Send the Beat message again.
4. The timer expires and no beat Ack message is received, the ASP will
Anjali Gurmukhani, HSS [Page 16]
Internet Draft SUA Conformance Test Plan Aug 2003
consider remote SUA peer as unavailable. Transmission of Heartbeat
messages is stopped and the signalling process SHOULD attempt to
re- establish communication if it is configured as the client for
the disconnected SUA peer.
Note: The recommended value of Heartbeat timer is 30sec.
Anjali Gurmukhani, HSS [Page 17]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPUP_ACK message wait state"
+ TEST NUMBER : ASPSM_2
+ PURPOSE: To check that if ASPUP message is sent to the SGP, then
the ASP should discard any other message, till an ASPUP_ACK message
is received .
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in
ASP such that ASPUP message is sent to the SGP two times on stream
0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Down
ASPUP ---------------->
Status Ind ------->
REG_REQ ---------------->
<------------
ERROR to SM
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Down state.
2. send a REG_REQ message from the ASP, before it gets an ASPUP_ACK
message from the SGP.
Check A: The ASP should discard the message and may indicate SM
with Error Indication.
The above test case should be applicable to all the SUA MGMT messages
The ASP Should not send any Messages across unless until an ASPUP_ACK
message is received, after sending an ASPUP message.
Anjali Gurmukhani, HSS [Page 18]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPUP message in ASP-Up state"
+ TEST NUMBER : ASPSM_3
+ PURPOSE: To check that if ASPUP message is received in ASP-Up state
then ASP-Up-Ack message is sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and AS is in AS-Down state. Arrange
the data in ASP such that ASPUP message is sent to the
SGP two times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Down
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
ASPUP ---------------->
<--------------- ASP-Up-Ack
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Down state.
Check A: ASP-Up-Ack is received at ASP.
Check B: NTFY (AS-Inactive) message will come from the SGP.
2.Send ASPUP message again from the ASP on the same association.
Check A: ASP-Up-Ack message should be received at ASP.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains in
the Up state.
Anjali Gurmukhani, HSS [Page 19]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPUP message in ASP-ACTIVE state"
+ TEST NUMBER: ASPSM_4
+ PURPOSE: To check that if ASPUP message is received in ASP-ACTIVE
state then message ASP-Up-Ack is sent to the ASP, and the ASP
state is changed in all the relevant AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and AS is in AS-Active state i.e. ASP is ACTIVE.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
ASP is Active
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- ERR(Unexpected message)
(ASP State Changes to INACTIVE in all
the AS it belongs to)
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Active state.
Check A: ASP-Up-Ack message should be received at ASP.
Check B: State of ASP at SGP Should change to ASP-INACTIVE.
Check C: An ERR message with error code "Unexpected message"
should be received at the ASP.
Anjali Gurmukhani, HSS [Page 20]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPDN message in ASP-Down state"
+ TEST NUMBER : ASPSM_5
+ PURPOSE: To check that if ASPDN message is received in ASP-Down
state then ASP-Down-Ack message is sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is in Up state. Arrange the data in ASP such
that ASPDN message is sent to the SGP two times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Up
ASPDN ---------------->
Status Ind ------->
<--------------- ASP-Down-Ack
ASPDN ---------------->
<--------------- ASP-Down-Ack
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(AS-InActive)
TEST DESCRIPTION:
1. Send ASPDN message to the SGP in ASP-Up state.
Check A: ASP-Down-Ack message will come from the SGP.
2. Send ASPDN message again from the ASP1.
Check A: ASP-Down-Ack message should be received at ASP.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the
Down state.
3. Send ASPUP message for the ASP.ASP-Up-Ack and NTFY with status AS-
Inactive should be received at ASP.
Anjali Gurmukhani, HSS [Page 21]
Internet Draft SUA Conformance Test Plan Aug 2003
4.2 ASPTM
"Invalid Routing Context in ASP-Active Message"
+ TEST NUMBER: ASPTM_1
+ PURPOSE: To check that if ASPAC message carries multiple Routing
Contexts, and the SGP cannot Activate One of the Routing
Context, then the SGP MUST Send ERROR Message for each
Routing Context value that cannot be successfully activated.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is INACTIVE
ASPAC ---------------->
(RC1, RC2, RC3)
<--------------- ASPAC-Ack
(RC1)
<--------------- NTFY(AS-Active)
<--------------- ERR(Invalid Routing Context
RC2)
<------------
ERROR
<--------------- ERR(Invalid Routing Context
RC3)
<------------
ERROR
TEST DESCRIPTION:
Anjali Gurmukhani, HSS [Page 22]
Internet Draft SUA Conformance Test Plan Aug 2003
1. Send ASPAC message(With 3 Routing Contexts
Routing Context RC1 should be a valid value
Routing Context RC2 should be a INVALID value
Routing Context RC3 should be a INVALID value)
to the SGP in ASP-Inactive state.
Check A: The SGP Should send ASPAC-ACK Message in response
to the ASPAC message(For Routing Context RC1).
Check B: ASP Should move to ASP-Active State.
Check C: The SGP MUST Send individual ERROR messages for the Routing
Context RC2 and RC3.
Note: Repeat the above test case for ASPIA message also.
Anjali Gurmukhani, HSS [Page 23]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPAC Message Out-Of-The-Blue"
+ TEST NUMBER : ASPTM_2
+ PURPOSE: To check that if ASPAC message is received at the SGP
end, for an ASP that is not registered with the SGP and also SGP has
no knowledge of ASP through static configuration, SGP MAY Discard
this message silently.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Not Registered with SGP
ASPAC ---------------->
(No reaction)
TEST DESCRIPTION:
1. Send ASPAC message to the SGP from the ASP which has not been
registered with SGP .
Check A: ASP Should discard this message silently.
Anjali Gurmukhani, HSS [Page 24]
Internet Draft SUA Conformance Test Plan Aug 2003
"Validation of AS pending Behavior: recovery case"
+ TEST NUMBER: ASPTM_3
+ PURPOSE: To check that if ASP Inactive is received when AS is active
and if the AS has a single ASP, AS moves to Pending state which
changes to Active when Active message is received from Asp.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams). ASP is active and is the only
ASP serving the AS
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is Active
ASPIA ---------------->
Status Ind ------->ASP-inact
(Since this is the only Active ASP
in the AS the AS moves to pending state)
Status Ind ------->AS-pending
<--------------- NTFY(AS-Pending)
(timer tr=2 seconds starts)
<<Messages are buffered>> <--------- N-CONNECT REQ
<<Messages are buffered>> <--------- N-UNITDATA REQ
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(AS-Active)
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-UNITDATA IND <------------- CLDT
COAK ------------>
Anjali Gurmukhani, HSS [Page 25]
Internet Draft SUA Conformance Test Plan Aug 2003
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
---------> N-DATA IND
(ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
TEST DESCRIPTION:
1. Send ASPIA message to the SGP in ASP-active state.
Check A: Since this is the only ASP in the AS, the AS
should move to AS Pending State.
2. Send N-CONNECT REQ destined to the ASP.
Check A: The CORE Message should not be sent to the ASP.
3. Send N-UNITDATA REQ destined to the ASP.
Check A: The CLDT Message should not be sent to the ASP.
4. Send ASPAC Message to the SGP, before the timer t(r)=2
Seconds expires.
Check A: The CORE and the CLDT Messages should now reach
the ASP.
5. Send COAK Message to the SGP.
Check A: The COAK Message should reach the SGP, and the connection
should be established.
6. Send CODT Messages in both directions.
Check A: The CODT Messages should reach the both ends.
Anjali Gurmukhani, HSS [Page 26]
Internet Draft SUA Conformance Test Plan Aug 2003
"Validation of AS pending Behavior: recovery Failure"
+ TEST NUMBER: ASPTM_4
+ PURPOSE: To check that if ASP Down is received when AS is active and
if the AS has a single ASP, AS moves to Pending state which changes
to Down if no Up message is received from ASP when the Pending
timer is running.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP is active and this is the only
ASP serving the AS.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is Active
ASPDN ---------------->
Status Ind ------->ASP-down
(Since this is the only Active ASP
in the AS the AS moves to pending state)
Status Ind ------->AS-pending
<--------------- NTFY(AS-Pending)
(timer tr=2 seconds starts)
<<Messages are buffered>> <--------- N-CONNECT REQ
<<Messages are buffered>> <--------- N-UNITDATA REQ
(timer tr=2 seconds Expires)
Status Ind ------->AS-down
TEST DESCRIPTION:
1. Send ASPIA message to the SGP in ASP-active state.
Check A: Since this is the only ASP in the AS, the AS
should move to AS Pending State.
Anjali Gurmukhani, HSS [Page 27]
Internet Draft SUA Conformance Test Plan Aug 2003
2. send N-CONNECT REQ destined to the ASP.
Check A: The CORE Message should not be sent to the ASP.
3. Send N-UNITDATA REQ destined to the ASP.
Check A: The CLDT Message should not be sent to the ASP.
Check B: The Timer T(r) will expire on the SGP Side.
Check C: The AS Should move to AS-Down state .
The above test case MUST be carried out for both AS-INACTIVE
and AS-DOWN Transitions.
Anjali Gurmukhani, HSS [Page 28]
Internet Draft SUA Conformance Test Plan Aug 2003
"Alternative ASP-ACTIVE in Override Mode"
+ TEST NUMBER: ASPTM_5
+ PURPOSE: To check that if ASPAC message is sent to an SGP
which carries an already active ASP for that AS, then all the new
traffic should be directed to this ASP and the SGP MUST send a NTFY
message with code "Alternate ASP Active " to the other ASP.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1,ASP2. The AS to which the ASPs belong is configured
at the SGP with mode as OVERIDE. ASP1 is active and
handling Traffic.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
ASP1 is ACTIVE and Handling traffic
(ASP 2 Sends ASPAC)
ASPAC ---------------->
<--------------- ASPAC-Ack
<--------------- NTFY(Alternate ASP Active)
to ASP1
TEST DESCRIPTION:
1. Send ASPAC message for ASP2 to the SGP.
Check A: All the Traffic henceforth MUST be routed to ASP2, and
the ASP1 should be moved to INACTIVE in the AS, and
a NTFY Message MUST be generated to the Previous
ACTIVE ASP, with status "Alternate ASP Active ".
Anjali Gurmukhani, HSS [Page 29]
Internet Draft SUA Conformance Test Plan Aug 2003
"Loadshare Mode for AS"
+ TEST NUMBER: ASPTM_6
+ PURPOSE: To verify that if an AS is configured to operate in
Loadshare mode, then any data should be distributed amongst all the
ASPs present in that AS.
+ TEST CONFIGURATION: C(with three ASPs)
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASPs. The AS to which the ASP1, ASP2, ASP3 belongs is configured
at the SGP with mode as LOADSHARE.
EXPECTED MESSAGE SEQUENCE :
ASP3 ASP2 ASP1 SGP
NIF
(AS is in Loadshare Mode
with ASP1, ASP2 and ASP3
as the ACTIVE ASPs )
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP1
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP2
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP3
TEST DESCRIPTION:
1. Send Several N-UNITDATA Req. from the SGP.
Check A: The Data MUST be distributed amongst the Three ACTIVE
ASPs(the mechanism for Distribution is implementation
dependent).
Anjali Gurmukhani, HSS [Page 30]
Internet Draft SUA Conformance Test Plan Aug 2003
Repeat the Above test case after moving one of the ACTIVE ASPs
to INACTIVE State(An Additional NTFY Message MAY be generated
with status "Insufficient ASP resources active in AS", to inactive
ASP/ASPs if number of ASPs actually active in AS goes less than the
required value).
Anjali Gurmukhani, HSS [Page 31]
Internet Draft SUA Conformance Test Plan Aug 2003
"Loadshare Mode for AS: ASP Inactive-Active Transition"
+ TEST NUMBER: ASPTM_7
+ PURPOSE: To verify behavior of AS with Loadshare Traffic mode when
one/more ASPs in it move to Inactive .
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASPs. The AS to which the ASP1, ASP2, ASP3 belongs is configured
at the SGP with mode as LOADSHARE. The minimum number ASPs required
to be Active in AS is 1.
EXPECTED MESSAGE SEQUENCE :
ASP3 ASP2 ASP1 SGP
(AS is in Loadshare Mode
with ASP1, ASP2 and ASP3
as the ACTIVE ASPs )
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP1
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP2
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP3
ASPIA
---------->
ASPIA-ack to ASP3
<--------
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP1
Anjali Gurmukhani, HSS [Page 32]
Internet Draft SUA Conformance Test Plan Aug 2003
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP2
ASPIA(ASP2)
---------->
ASPIA-ack to ASP2
<--------
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP1 only
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP1 only
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
ASP1 only
ASPAC
--------->
ASPAC-ack to ASP2
<--------
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
To ASP1
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
To ASP2
TEST DESCRIPTION:
1. Send Several N-UNITDATA Req. from the SGP.
Anjali Gurmukhani, HSS [Page 33]
Internet Draft SUA Conformance Test Plan Aug 2003
Check A: The Data MUST be distributed amongst the Three ACTIVE
ASPs(the mechanism for Distribution is implementation
Dependent, can be e.g. SLS basis).
2. Send ASPIA from ASP3.
Check A: ASPIA-ack is received at ASP3
Check B: State of AS at SGP is not disturbed.
3. Now SEND SEVERAL N-Unitdata Req. from SGP.
Check A: Data MUST be Loadshared amongst Two ASPs , ASP1 and ASP2.
4. Send ASPIA from ASP2.
Check A: ASPIA-ack is received at ASP.
Check B: State of AS is not disturbed since the minimum number of
ASP active is 1.
5. Send several Unitdata Req from SGP.
Check A: All Data goes to ASP1.
Repeat Active procedure (both ASPs coming back to Active). Data should
be Loadshared again amongst the three ASPs.
Anjali Gurmukhani, HSS [Page 34]
Internet Draft SUA Conformance Test Plan Aug 2003
"Broadcast Mode for AS"
+ TEST NUMBER: ASPTM_8
+ PURPOSE: To verify that if ASPs are operating in Broadcast mode
all the Data MUST be sent to all the Active ASPs.
+ TEST CONFIGURATION: C (AS has three ASPs)
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASPs. The AS to which the ASP1, ASP2, ASP3 belongs is configured at
the SGP with mode as BROADCAST.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF
(AS is in BROADCAST Mode
with ASP1, ASP2 and ASP3
as the ACTIVE ASPs )
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
(ASP1)
N-UNITDATA IND <------------- CLDT
(ASP2)
N-UNITDATA IND <------------- CLDT
(ASP3)
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
(ASP1)
N-UNITDATA IND <------------- CLDT
(ASP2)
N-UNITDATA IND <------------- CLDT
(ASP3)
TEST DESCRIPTION:
1. Send Several N-UNITDATA REQs from the SGP.
Check A: The Data MUST be sent to ALL the ACTIVE ASPs (ASP1,
ASP2 and ASP3).
Repeat the Above test case after moving one of the ACTIVE ASPs
to INACTIVE State(An Additional NTFY Message MAY be generated
Anjali Gurmukhani, HSS [Page 35]
Internet Draft SUA Conformance Test Plan Aug 2003
with status code "Insufficient ASP resources active in AS", to
inactive ASPs) .
Anjali Gurmukhani, HSS [Page 36]
Internet Draft SUA Conformance Test Plan Aug 2003
"Broadcast Mode for ASP, Unique Correlation ID"
+ TEST NUMBER: ASPTM_9
+ PURPOSE: To verify that if ASPs are operating in Broadcast mode
the SGP MUST tag the first DATA message broadcast in each SCTP
stream with a unique Correlation Id parameter.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASPs. The AS to which the ASP1, ASP2 belongs is configured at
the SGP with traffic handling mode as BROADCAST.
EXPECTED MESSAGE SEQUENCE :
ASP2 ASP1 SGP NIF
(AS is in BROADCAST Mode
with ASP1, ASP2
as the ACTIVE ASPs )
<--------- N-UNITDATA REQ
N-UNITDATA IND
<------------- CLDT
(ASP1)
N-UNITDATA IND
<------------- CLDT
(ASP2)
ASPIA (ASP2)
------------->
ASPIA-ack to ASP2
<--------------------
<--------- N-UNITDATA REQ
N-UNITDATA IND <---- CLDT
(ASP1)
ASPAC (ASP2)
------------->
Anjali Gurmukhani, HSS [Page 37]
Internet Draft SUA Conformance Test Plan Aug 2003
ASPAC-ack to ASP2
<------------------
<--------- N-UNITDATA REQ
N-UNITDATA IND <-------- CLDT
(ASP1, Correlation ID)
N-UNITDATA IND
<------------- CLDT
(ASP2, Correlation ID)
TEST DESCRIPTION:
1. Send Several N-UNITDATA Req. from the SGP.
Check A: The Data MUST be sent to both the ASPs.
2. Now send ASPIA from ASP2.
Check A: ASPIA-ack should be received at ASP2.
Check B: State of AS is not disturbed at SGP.
3. Send Unitdata-Req from SGP.
Check A: Data must be received at ASP1 only.
4. Send ASPAC from ASP2.
Check A: ASPAC -ack is received at ASP2.
Check B: State of the AS at SGP is same ACTIVE.
5. Send Unitdata-Req from SGP.
Check A: Data is received at ASP1, ASP2 with a unique correlation
Id.
Anjali Gurmukhani, HSS [Page 38]
Internet Draft SUA Conformance Test Plan Aug 2003
"Last ASP Transition to INACTIVE state"
+ TEST NUMBER: ASPTM_10
+ PURPOSE: To check that if an AS has only 1 ASP in the ACTIVE state,
and it moves to ASP-INACTIVE state, SGP MUST send a Notify message
("AS-Pending") to all the ASPs in the AS which are in the state ASP-
INACTIVE.
+ TEST CONFIGURATION: C (with three ASPs in AS)
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASPs.AS has three ASPs, ASP1 is in ACTIVE State,
ASP2 is in INACTIVE State and ASP3 is in DOWN State.
EXPECTED MESSAGE SEQUENCE :
ASP2 ASP1 SGP SM + NIF
ASPIA ---------------->
Status Ind ------->
<--------------- ASPIA-Ack
<--------------- NTFY(AS-Pending)
ASP1,ASP2
TEST DESCRIPTION:
1. Send ASPIA message to the SGP from ASP1in ASP-Active state.
Check A: ASP Should move to ASP-INACTIVE State.
Check B: The AS Should now move to AS PENDING State and
a NTFY message with AS-Pending should be sent to
ASP2 and ASP1.
Check C: The NTFY Message MUST not be sent to ASP3, since
it is in DOWN State.
Anjali Gurmukhani, HSS [Page 39]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPAC message in ASP-Active State"
+ TEST NUMBER: ASPTM_11
+ PURPOSE: To check that if ASPAC message is received in ASP-Active
state then ASP-Active-Ack message is sent to the AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and AS is in AS-Inactive state. Arrange
the data in AS such that ASPAC message with correct Traffic Mode
and routing context P is sent to the SGP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Inactive
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<-------------- Ntfy(AS-active)
ASPAC ---------------->
<--------------- ASP-Active-Ack
CLDT ---------------->
N-Unitdata Ind ------->
TEST DESCRIPTION:
1. Send ASPAC message to the SGP in AS-inactive state.
This ASPAC message should contain RC parameter.
Check A: ASP-Active-Ack message comes from the SGP.
Check B: This Ack message MUST contain RC parameter.
2. Send ASPAC message again from the ASP for the same AS.
Check A: ASP-Active-Ack message should be received at ASP.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains in
the Active state.
Send DATA message for the ASP, SGP should send
N-DATA indication to the NIF.
Anjali Gurmukhani, HSS [Page 40]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPIA message in ASP-Inactive state"
+ TEST NUMBER: ASPTM_12
+ PURPOSE: To check that if ASPIA message is received in ASP-Up state
then ASP-Inactive-Ack message is sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and AS is in AS-Active state i.e. ASP1 is active.
Arrange the data in AS such that ASPIA message and Routing
Context P is sent to the SGP two times.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Active
ASPIA ---------------->
Status Ind ------->
<--------------- ASP-Inactive-Ack
<------------ NTFY(AS-pending)
Pending timer expiry
.------------ NTFY(AS-Inactive)
ASPIA ---------------->
<--------------- ASP-Inactive-Ack
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPIA message to the SGP in ASP-Active state. ASP-Inactive-Ack
and NTFY (AS-Pending) messages will come from the SGP. Let the
pending timer expire.
2. Send ASPIA message again from the AS for the same ASP.
Anjali Gurmukhani, HSS [Page 41]
Internet Draft SUA Conformance Test Plan Aug 2003
Check A: ASP-Inactive-Ack message will come from SGP.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains
in the Inactive state. Send ASPAC message with
correct traffic mode (traffic mode defined at SGP for
the AS) for the ASP1 and SGP should respond with
ASP-Active-Ack message.
Anjali Gurmukhani, HSS [Page 42]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPAC message in ASP-Down state"
+ TEST NUMBER : ASPTM_13
+ PURPOSE: To check that if ASPAC message is received in ASP-Down
state then message is discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is down. Arrange the data in ASP such that ASPAC is sent
to SGP .
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
AS is Down
ASPAC ---------------->
Message silently discarded
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(AS-InActive)
TEST DESCRIPTION:
1. Send ASPAC message to the SGP in ASP-Down state.
Check A: State of ASP at SGP is not disturbed i.e. ASP remains in
the Down state.
2. Send ASPUP message for the ASP and SGP .
Check B: SGP should respond with ASP-Up-Ack and NTFY message with
status AS Inactive.
3. Repeat the above test case for ASPIA message.
Anjali Gurmukhani, HSS [Page 43]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPAC message without any Routing Context"
+ TEST NUMBER: ASPTM_14
+ PURPOSE: To check that if ASPAC message is received without any
Routing Context then status of ASP is active in all the AS
which this ASP serves.
+ TEST CONFIGURATION: B
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. ASP is Inactive in both the AS at the SGP. Arrange data in ASP
such that ASPAC messages is sent to the SGP from ASP.
Don't fill any routing context parameter in ASPAC.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS1 & AS2 are Inactive
ASPAC ------------------>
No Routing Context Status Ind --------->
<----------------- ASP-Active-Ack
<----------------- NTFY (AS Active)
TEST DESCRIPTION:
1. Send ASPAC Message without any Routing context to the SGP.
2. Check A: ASP-Active-Ack and NTFY message with status AS-Active
should be received at ASP without any routing context.
3. Check B: Check that state of ASP is active using configuration Data
present at the SGP.
Note: If there is no Configuration Data present at the SGP and the ASP
has not dynamically registered for any Routing Context, then the
ASP Active Message is silently discarded at the SGP. No Ack or
NTFY as shown above is sent in that case.
Anjali Gurmukhani, HSS [Page 44]
Internet Draft SUA Conformance Test Plan Aug 2003
4.3 SSNM
"Point Code Unavailability"
+ TEST NUMBER: SSNM_1
+ PURPOSE: To check that if N-PCState indication primitive is received
(with Point code status as Unavailable)from NIF at SGP then SGP sends
DUNA message to the concerned ASPs.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 ASP3 SGP NIF
All AS are active
<---------- N-PCState
Affected DPC M
<---------------------------- DUNA
<----------------- DUNA
<---------- N-PCState
Affected DPC M
<--------- DUNA
TEST DESCRIPTION:
1. Send N-PCState indication Primitive message from NIF in the SGP
containing Affected Point code M and Point code status as
Unavailable.
2. Check A: DUNA message will be received at the ASP1 and ASP2
containing the RC A and RC B and Affected DPC M.
3. Check B: DUNA message is sent on the Stream number 0.
4. Repeat the above test case with Affected Point code as M but with
nw appearance for AS3. In this case DUNA
message should be sent to ASP3.
Anjali Gurmukhani, HSS [Page 45]
Internet Draft SUA Conformance Test Plan Aug 2003
Note: Repeat the above test case when there are multiple point codes
in SSNM Message.
Note: Also if the Indication from the NIF is N-Status which includes
Affected Subsystem also, then DUNA message being sent SHOULD include
SSN parameter also.
Anjali Gurmukhani, HSS [Page 46]
Internet Draft SUA Conformance Test Plan Aug 2003
"Point Code Availability"
+ TEST NUMBER: SSNM_2
+ PURPOSE: To check that if N-PCState indication primitive is received
(with Point code status as Available)from NIF at SGP then SGP sends
DAVA message to the concerned ASPs.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B.
EXPECTED MESSAGE SEQUENCE:
ASP1 ASP2 ASP3 SGP NIF
All AS are active
<---------- N-PCState
Affected DPC M
<---------------------------- DAVA
<----------------- DAVA
<---------- N-PCState
Affected DPC M
<--------- DAVA
TEST DESCRIPTION:
1. Send N-PCState indication Primitive from NIF in the SGP containing
the Affected DPC M and Point code status as "Available"
Check A: DAVA message is received at ASP1 and ASP2 containing the
Corresponding RCs and Affected DPC M.
Check B: DAVA message is sent on the Stream number 0.
2. Repeat the test case for N/w appearance B and affected destination
any value. Check that message is being sent to ASP3.
Note: Repeat the above test case when there are multiple point codes
in SSNM Message.
Anjali Gurmukhani, HSS [Page 47]
Internet Draft SUA Conformance Test Plan Aug 2003
Note: Also if the Indication from the NIF is N-Status which includes
Affected Subsystem also, then DAVA message being sent SHOULD include
SSN parameter also.
Anjali Gurmukhani, HSS [Page 48]
Internet Draft SUA Conformance Test Plan Aug 2003
"Route Congestion Indication"
+ TEST NUMBER : SSNM_3
+ PURPOSE: To check that if N-PCState indication primitive with point
code status as congested is received from NIF at SGP then SGP sends
SCON message to the concerned ASPs.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B.
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 AS3 SGP NIF
All AS are active
<---------- N-PCState
DPC M remote sccp
status 2
<---------------------------- SCON
<----------------- SCON
<---------- N-PCState
DPC M remote sccp status 2
<--------- SCON
TEST DESCRIPTION:
1. Send N-PCState indication Primitive from NIF in the SGP containing
the Affected DPC M and network info as corresponding to network
appearance and Sccp status as 2.
Check A: SCON message is received at the ASP1 and ASP2 containing
the corresponding RC values, Affected DPC M, Congestion Level 2
Anjali Gurmukhani, HSS [Page 49]
Internet Draft SUA Conformance Test Plan Aug 2003
from NIF.
Check B: SCON message is received on the Stream number 0.
2. Repeat the above test case for all congestion level 0, 1, 2 and 3.
SCON message will be received from NIF.
3. Repeat the above test case with different congestion level for
different affected DPC. SCON message should contain the correct
congestion level for each affected destination.
Note: If SSN is included in the SCON message, it should be 1. This
corresponds to the N-PCSTATE primitive used to convey the
Restricted Importance Level to the SCCP user
Anjali Gurmukhani, HSS [Page 50]
Internet Draft SUA Conformance Test Plan Aug 2003
"User Part Unavailable"
+ TEST NUMBER : SSNM_4
+ PURPOSE: To check that if N-PCState indication primitive with cause
User Part Unavailable is received from NIF at SGP then SGP sends DUPU
message to the concerned ASPs.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 ASP3 SGP NIF
All AS are active
<---------- N-PCState
DPC M
<---------------------------- DUPU
<----------------- DUPU
<---------- N-PCState
DPC M
<--------- DUPU
TEST DESCRIPTION:
1. Send N-PCState indication Primitive from NIF in the SGP containing
Affected DPC M and Remote SCCP status as User Part Unavailability.
Check A: SGP SHOULD send DUPU message containing corresponding RCs
Anjali Gurmukhani, HSS [Page 51]
Internet Draft SUA Conformance Test Plan Aug 2003
for AS Affected DPC M, cause as received from NIF.
Check B: DUPU message is received at ASP1 and ASP2.
Check C: DUPU message is sent on the Stream number 0.
2. Repeat the above test case with cause values Unequipped Remote User
and Inaccessible Remote User and other parameters being the same as
in the above tests. DUPU message will be received with these cause
values.
Also try the test case without sending anything in User/Cause
parameter. This should result in an Error with Mandatory Parameter
missing error cause.
Anjali Gurmukhani, HSS [Page 52]
Internet Draft SUA Conformance Test Plan Aug 2003
"Route Restricted"
+ TEST NUMBER: SSNM_5
+ PURPOSE: To check that if N-PCState indication primitive with status
as Restricted is received from NIF at SGP then SUA at SGP sends DRST
Message to the concerned ASPs.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic
for N/w Appearance B.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 ASP3 SGP NIF
All AS are active
<---------- N-PCState
status Restricted
<---------------------------- DRST
<----------------- DRST
<---------- N-PCState
Cause Restricted
<--------- DRST
TEST DESCRIPTION:
1.Send N-PCState indication Primitive message from NIF in the SGP
containing Affected DPC M and cause restricted.
Check A: DRST message will be received at the ASP1 and ASP2
containing the corresponding RCs and Affected DPC M.
Check C: DRST message is sent on the Stream number 0.
2.Repeat the above test case by sending the N-PCState indication with
the affected Point code belonging to the network corresponding to
the network appearance being served by AS3.
Then the DRST should go to ASP3.
Anjali Gurmukhani, HSS [Page 53]
Internet Draft SUA Conformance Test Plan Aug 2003
Note: When SSN is included in the message parameter, the DRST message
corresponds to the SCCP N-COORD primitive. If the SMI parameter is
also included in the message, the DRST message corresponds to the N-
COORD Request and N-COORD Indication primitives, otherwise, the DRST
message corresponds to the N-COORD Response and N-COORD Confirm
primitives. The Affected Point Code can only contain one point code
when SSN is present.
Anjali Gurmukhani, HSS [Page 54]
Internet Draft SUA Conformance Test Plan Aug 2003
"DAUD without Mandatory Parameter"
+ TEST NUMBER : SSNM_6
+ PURPOSE: To verify that DAUD received at SGP without Mandatory
parameter is rejected.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP1. AS1 is in Active state. Also arrange the data in ASP such that
DAUD is sent to SGP without Affected Point code parameter.
EXPECTED MESSAGE SEQUENCE :
ASP1 SGP NIF
AS1 is active
Daud without Mandatory param
------------------------->
----------------- >Received Rejected
<---------- Error sent
Mandatory param missing
TEST DESCRIPTION:
1. Send DAUD message from ASP1 to SGP without "Affected Point code"
param.
Check A: DAUD message is received at SGP and rejected.
Check B: Error message with "Mandatory Parameter Missing" error cause
is sent to ASP.
Anjali Gurmukhani, HSS [Page 55]
Internet Draft SUA Conformance Test Plan Aug 2003
4.4 DYNAMIC ROUTING KEY MANAGEMENT
"Routing Key Registration"
+ TEST NUMBER: DRKM_1
+ PURPOSE: To check that on receiving a Routing Key Registration
Request for a new valid RK from an ASP, the SGP adds a RK and
confirms the registration to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. The ASP is in Inactive state. The Routing Key RK1 is not
configured at the SGP side.
Arrange Data in ASP such that a Routing Key Registration request is
sent from ASP to SGP on stream 0.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
ASP is Inactive
<-------- UNITDATA (For RK1)
Send Failure --------->
REG REQ(RK1) ----------------->
RK REG Ind -------->
<----------------- REG RSP (SUCCESS, RC1)
<---------------- NTFY(AS - InActive)
ASPAC(RC1) ---------------->
Status Ind ------->
To ASP <---------------- ASP-Active-Ack
<-------- UNITDATA(For RK1)
To ASP <--------------- DATA
Anjali Gurmukhani, HSS [Page 56]
Internet Draft SUA Conformance Test Plan Aug 2003
TEST DESCRIPTION:
1. Select a valid RK1 (Eg. DPC = Z, SSN = 5) that is not already
configured at the SGP. Send Data for RK1 from SGP
side.
Check A: A Send Failure would be reported at the SGP Side.
2. Send a valid Reg Req message from ASP to SGP Stack.
Check B: A REG_IND would be received at the NIF(SM) and a
REG_RSP message would be received at the ASP side with RC
value and a Success Status for REG_RSP. Check that the AS
to which ASP has been added has the same configuration as
requested in the Dynamic Registration.
Check C: Ntfy (AS-inactive) is sent to ASP.
3. Send a ASPAC from ASP to SGP for RC1.
Check C: A Status Ind for ASP Active for RC1 is received at
the NIF(SM). Active-Ack with RC1 is received at ASP and Notify
with State AS Active for RC1 is received at the SGP.
4. Send Data for RK1 from SGP.
Check D: Data Message is received at the ASP side.
Note: In some implementations, when Data is sent for an
unconfigured RK then instead of giving a Send Failure the Stack
may route the Data through a Default AS .
Anjali Gurmukhani, HSS [Page 57]
Internet Draft SUA Conformance Test Plan Aug 2003
"Routing Key Deregistration"
+ TEST NUMBER: DRKM_2
+ PURPOSE: To check that on receiving a Routing Key Deregistration
Request for a existing RK from an ASP, the SGP removes the
requesting ASP from the List of ASPs serving that RK.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. The Routing Key RK1 is configured at the SGP side.
The ASP is in Active State for RK1 at the SGP. Arrange Data in
ASP such that a Routing Key Deregistration request for RK1 is
sent from ASP to SGP on stream 0.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
ASP is Active in AS with RK1.
ASPIA(RC1) ---------------->
Status Ind ------->
To ASP <---------------- ASP-Inactive-Ack
<---------------- NTFY(AS - Pending)
<---------------- NTFY(AS - Inactive)[after
timer expiry]
DEREG REQ(RC1) ----------------->
RK DEREG Ind -------->
<----------------- DEREG RSP (SUCCESS, RC1)
TEST DESCRIPTION:
1. Send an ASPIA message to the SGP from ASP with the RC as the
RC with which RK1 is configured at the SGP.
Check A: A Status Ind is received at the NIF. ASPIA-Ack is
received at the ASP and NTFY with RC1 and Status AS-Inactive
is received at the ASP After pending timer expiry.
Anjali Gurmukhani, HSS [Page 58]
Internet Draft SUA Conformance Test Plan Aug 2003
2. Send DeReg Req message with RC as RC1 from ASP to SGP.
Check B: A DEREG_IND would be received at the NIF(SM) and a
DEREG_RSP message would be received at the ASP side with RC
value as RC1 and a Success Status for DEREG_REQ.
Anjali Gurmukhani, HSS [Page 59]
Internet Draft SUA Conformance Test Plan Aug 2003
ôRegistration in an existing AS at SGP."
+ TEST NUMBER : DRKM_3
+ PURPOSE: To check that on receiving a Routing Key Registration
Request for a existing RK from an ASP, the SGP adds the
requesting ASP to the List of ASPs serving that RK.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1 .ASP2. The Routing Key RK1 is configured at
the SGP side. The ASP1 is in Inactive State at the SGP and ASP2
is actively handling Traffic for RK1 with RC value as RC1. The
AS for RK1 is in Traffic handling Mode Override. Arrange Data in ASP
such that a valid Routing Key Registration request with Traffic Mode
consistent with mode at SG for RK1 is sent from ASP1 to
SGP on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP1 is Inactive
<-------- UNITDATA(For RK1)
To ASP2 <--------------- DATA
From ASP1
REG REQ(RK1) ----------------->
RK REG Ind -------->
<----------------- REG RSP (SUCCESS, RC1)
From ASP1
ASPAC(RC1) ---------------->
Status Ind ------->
To ASP1 <---------------- ASP-Active-Ack
To ASP2 <---------------- Ntfy(Alternate ASP-Act)
Anjali Gurmukhani, HSS [Page 60]
Internet Draft SUA Conformance Test Plan Aug 2003
<-------- UNITDATA(For RK1)
To ASP1 <--------------- DATA
TEST DESCRIPTION:
1. Send a Data Message from SGP for RK1.
Check A: Data would be received at ASP2.
2. Send a valid Registration Req message for RK1 from ASP1 to SGP
Stack.
Check B: A REG_IND would be received at the NIF(SM) and a
REG_RSP message would be received at the ASP1 with RC
value as RC1 and a Success Status for REG_REQ.
3. Send a ASPAC with Traffic Mode Override from ASP1 to SGP for RC1.
Check C: A Status Ind for ASP Active for RC1 is received at
the NIF(SM). Active-Ack with RC1 is received at ASP1 and Notify
with Alt-ASP Act is received at the ASP2.
4. Send a Data Message from SGP for RK1.
Check D: Data would be received at ASP1.
Anjali Gurmukhani, HSS [Page 61]
Internet Draft SUA Conformance Test Plan Aug 2003
" RK Registration Fails when ASP is Active for the RK "
+ TEST NUMBER: DRKM_4
+ PURPOSE: To check that on receiving a Routing Key Registration
Request for an existing RK from an ASP that is already active
for the RK, the Registration Fails and a Negative Response
Message is sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. The Routing Key RK1 is configured at the SGP side.
The ASP is in Active State for RK1 at the SGP. Arrange Data in
ASP such that a Routing Key Registration request for RK1 is sent
from ASP to SGP on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active for RK1
REG REQ(RK1) ----------------->
<----------------- REG RSP (FAILURE)
<-------- UNITDATA(For RK1)
To ASP <--------------- DATA
TEST DESCRIPTION:
1. Send a valid Reg Req message for RK1 from ASP to SGP Stack.
2. Check A: REG_RSP message would be received at the ASP side with
Failure Response.
3. Send a Data Message from SGP for RK1.
4. Check C: Data would be received at ASP.
Anjali Gurmukhani, HSS [Page 62]
Internet Draft SUA Conformance Test Plan Aug 2003
" RK Deregistration Fails when ASP is Active for the RK "
+ TEST NUMBER: DRKM_5
+ PURPOSE: To check that on receiving a Routing Key Deregistration
Request for an existing RK from an ASP which is active
for the RK, the Deregistration Fails and a Failure Response
Message is sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. The Routing Key RK1 is configured at the SGP side.
The ASP is in Active State for RK1 at the SGP. Arrange Data in
ASP such that a Routing Key Deregistration request for RK1 is sent
from ASP to SGP on stream 0.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
ASP is Active for RK1
DEREG REQ(RC1) ----------------->
<----------------- DEREG RSP (FAILURE)
Err Code: ASP Currently Active for RC
TEST DESCRIPTION:
1. Send a valid DeReg Req message for RK1 from ASP to SGP Stack.
2. Check A: A DEREG_RSP would be received at the ASP side with
Registration Status as Failed and Error Code as "ASP Currently
Active for Routing Context".
Anjali Gurmukhani, HSS [Page 63]
Internet Draft SUA Conformance Test Plan Aug 2003
" Unique RC Value for a given RK "
+ TEST NUMBER : DRKM_6
+ PURPOSE: To check that on receiving a Routing Key Registration
Request from two different ASPs at the SGP Stack, the SGP
allocates the same RC ID to both of these.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1 , ASP2. Both ASP1 and ASP2 are in Inactive
State at the SGP. Arrange Data in ASP1 and ASP2 such that a
valid Routing Key Registration request for RK1 is sent from ASP
to SGP on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP1 and ASP2 are Inactive
From ASP1
REG REQ(RK1) ----------------->
RK REG Ind -------->
<----------------- REG RSP (SUCCESS, RC1)
From ASP2
REG REQ(RK1) ----------------->
RK REG Ind -------->
<----------------- REG RSP (SUCCESS, RC1)
TEST DESCRIPTION:
1. Send a valid Reg Req message for RK1 from ASP1 to SGP Stack.
Check A: A REG_IND would be received at the NIF(SM) and a
REG_RSP message would be received at the ASP1 with RC
value as RC1 and a Success Status for REG_REQ.
Anjali Gurmukhani, HSS [Page 64]
Internet Draft SUA Conformance Test Plan Aug 2003
2. Send a valid Reg Req message for RK1 from ASP2 to SGP Stack.
Check B: A REG_IND would be received at the NIF(SM) and a
REG_RSP message would be received at the ASP2 with RC
value again as RC1 and a Success Status for REG_REQ.
Anjali Gurmukhani, HSS [Page 65]
Internet Draft SUA Conformance Test Plan Aug 2003
"AS does not Loadshare the data to ASP that has deregistered from the AS"
+ TEST NUMBER: DRKM_7
+ PURPOSE: To verify that after an ASP has successfully deregistered
from the AS, data is not routed to that ASP.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP1, ASP2. Both ASP1 and ASP2 have been added dynamically to
AS.AS is routing data to both the ASPs on Loadshare basis.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 SGP SM + NIF
ASPs are active
<-------- UNITDATA (For RK1)
<-------CLDT
ASP1 receives data
<-------- UNITDATA (For RK1)
<-------CLDT
ASP2 receives data
ASP1
ASPIA-------------------->
ASPIA-ack
<------------
Indication to SM
<----------------
DEREG REQ(RK1) ----------------->
<------------ DEREG RSP (SUCCESS, RC1)
ASP1
Anjali Gurmukhani, HSS [Page 66]
Internet Draft SUA Conformance Test Plan Aug 2003
<-------
Dereg Indication
<-------- UNITDATA(For RK1)
To ASP2 <---------------CLDT
<-------- UNITDATA(For RK1)
To ASP2 <---------------CLDT
TEST DESCRIPTION:
1. Send ASPIA from ASP1.
Check A: SGP receives ASPIA and sends back ASPIA-ack
Check B: ASP indicates Inactive to SM.
The state of AS is Active if the minimum number of ASPs that can be
Active in the AS is 1.
2. Send a valid DeReg Req message from ASP1 to SGP Stack.
Check B: A DEREG_IND would be received at the NIF(SM) and a
DEREG_RSP message would be received at the ASP1 side with RC value
and a Success Status for DEREG_REQ. Check that ASP1 is removed from
the AS.
3. Send CLDT from SGP.
Check C: Data should go to only ASP2
4. Send another CLDT from SGP, it should again go to ASP2.
Anjali Gurmukhani, HSS [Page 67]
Internet Draft SUA Conformance Test Plan Aug 2003
4.5 MANAGEMENT
"Handling of Invalid messages at SGP"
+ TEST NUMBER: MGMT_1
+ PURPOSE: To check that if the SGP receives an ASP-UPACK
message it discards the message.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams.)
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
---------------> ASP-UPAck
<------------
ERROR
TEST DESCRIPTION:
1. Generate an ASP-UPAck Message to be destined to the SGP.
Check A: The SGP Should discard this message and report
an error to SM. Also it sends Error message back to ASP with error
code "Protocol Error".
The Above test case MUST be carried out for the following combinations
Anjali Gurmukhani, HSS [Page 68]
Internet Draft SUA Conformance Test Plan Aug 2003
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SGP DUNA
DAVA
DUPU
ASPUP_ACK
ASPDN_ACK
ASPAC_ACK
ASPIA_ACK
REG_RSP
DEREG_RSP
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Anjali Gurmukhani, HSS [Page 69]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPUP message for an ASP which is in LOCKED state"
+ TEST NUMBER: MGMT_2
+ PURPOSE: To check that if ASPUP message is received for an ASP,
which has been marked as LOCKED for MGMT purposes, the SGP
sends an error message with error code "Refused -
Management Blocking".
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange
the data in AS such that ASPUP message is sent to the SGP
two times on stream 0.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
AS is Down
<--------- LOCK ASP
ASPUP ---------------->
<--------------- ERR(Refused - Management Blocking)
<------------
ERROR
TEST DESCRIPTION:
1. Lock the ASP on the SGP side for MGMT purposes.
2. Send ASPUP message to the SGP in ASP-Down state.
Check A: No ASP-Up-Ack and NTFY message will come from the SGP.
3. Send ASPUP message again from same ASP.
Check A: an ERROR Message should be sent in response to the ASPUP
message with error code "Refused - Management Blocking".
Anjali Gurmukhani, HSS [Page 70]
Internet Draft SUA Conformance Test Plan Aug 2003
"Invalid Traffic mode in ASP-Active Message"
+ TEST NUMBER: MGMT_3
+ PURPOSE: To check that if ASPAC message carries a Traffic mode
which is incompatible at the SGP, then an error message
with code "Unsupported / Invalid Traffic Handling Mode" MUST be
sent.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP. The AS to which the ASP belongs MUST be configured at
the SGP with traffic handling mode OVERIDE.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is INACTIVE
ASPAC ---------------->
(Traffic mode = Loadshare)
<--------------- ERR(Unsupported /
Invalid Traffic Handling Mode)
<------------
ERROR
TEST DESCRIPTION:
1. Send ASPAC message(With Traffic mode as Loadshare)
to the ASP in ASP-Inactive state.
Check A: SGP Should send an error message with error code
"Unsupported / Invalid Traffic Handling Mode".
Anjali Gurmukhani, HSS [Page 71]
Internet Draft SUA Conformance Test Plan Aug 2003
"Unrecognized Message Type"
+ TEST NUMBER : MGMT_4
+ PURPOSE: To check that if a message with message type not defined is
received at SGP, SGP responds with ERROR message containing cause
"Unsupported Message Type".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP1 is active. Arrange the data in ASP such that a message
with Message type not defined is sent to SGP. Let the other
parameters in the message be like any other message.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
Message ---------------->
Message Type=0x408
<--------------- ERROR
Cause = Unsupported Message Type
TEST DESCRIPTION:
1. Send a message with message type 0x408 or any other value which is
not defined for SUA protocol.
Check A: ERROR message is received at the ASP containing cause
Invalid Message Type.
2. Check B: State of AS at SGP is not disturbed.
Anjali Gurmukhani, HSS [Page 72]
Internet Draft SUA Conformance Test Plan Aug 2003
"Unrecognized Message Class"
+ TEST NUMBER : MGMT_5
+ PURPOSE: To check that if a message with message Class not defined
is received at SGP, SGP responds with ERROR message containing cause
"Unsupported Message Class".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP1 is active. Arrange the data in ASP such that a message
with Message class not defined is sent to SGP. Let the other
parameters in the message be like any other message.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
Message ---------------->
Message CLASS=0x408
<--------------- ERROR
Cause = Unsupported Message CLASS
TEST DESCRIPTION:
1. Send a message with message class 0x408 or any other value which is
not defined for SUA protocol.
Check A: ERROR message is received at the ASP containing cause
Unsupported Message Class.
Check B: State of AS at SGP is not disturbed.
Anjali Gurmukhani, HSS [Page 73]
Internet Draft SUA Conformance Test Plan Aug 2003
"Invalid Stream Identifier"
+ TEST NUMBER : MGMT_6
+ PURPOSE: To check that if ASPSM(except BEAT/BEAT-ack) is received on
an unexpected SCTP stream, error containing error code "Invalid
Stream Identifier" is sent back.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established (with multiple
streams)between SGP and ASP and ASP1 is down.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is down
ASPUP ---------------->
Stream Identifier 2
<--------------- ERROR
Cause = Invalid Stream Identifier
TEST DESCRIPTION:
1. Send ASPUP on SCTP stream Id 2.
2. Check A: ERROR message is received at the ASP containing cause
Invalid Stream Identifier.
3. Check B: State of AS at SGP is not disturbed.
Note: The above test case can be repeated for
SUA MGMT,RKM messages also.
Anjali Gurmukhani, HSS [Page 74]
Internet Draft SUA Conformance Test Plan Aug 2003
"Message length less than the length of mandatory Parameters"
+ TEST NUMBER: MGMT_7
+ PURPOSE: To check that if a message with value of length parameter
less than length of mandatory parameters is received then message is
discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and AS is in AS-Active state. Arrange the data in ASP such that
Error message with length parameter filled with value less than the
length of error code parameter is sent.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
AS is Active
Error ---------------->
Message Length = 2
<--------------- Error
(Protocol Error)
TEST DESCRIPTION:
1. Send Error message with length parameter filled with value less
than the length of error code field to the SGP.
Check A: SGP will send an Error me |
Documentation