| 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 message .
Check B: State of AS at SGP is not disturbed.
Anjali Gurmukhani, HSS [Page 75]
Internet Draft SUA Conformance Test Plan Aug 2003
"ERROR Message Handling"
+ TEST NUMBER : MGMT_8
+ PURPOSE: To check that if an error is received then that is reported
to the SM and no action is taken against that.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. ASP is active. Arrange data in ASP such that ERROR with cause
invalid version is sent to the SGP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
ERROR ---------------->
cause=Invalid version
Error ------->
TEST DESCRIPTION:
1. Send ERROR message with cause invalid version from ASP to SGP.
Check A: Error should be reported to the SM.
Check B: Further action at the SGP is implementation dependent.
2. Repeat the test case for other cause values in ERROR message.
Anjali Gurmukhani, HSS [Page 76]
Internet Draft SUA Conformance Test Plan Aug 2003
"Reception of Unpadded Message"
+ TEST NUMBER : MGMT_9
+ PURPOSE: If the SGP receives a Message from the ASP which is not
padded, then also the Message should be Processed.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. ASP is in ASP-Down state. Arrange data in ASP such that ASPUP
is sent to SGP with size of Info String such that the Total
Message Length is 35 Bytes and this Message should not be padded.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Down
ASPUP ---------------->
(Length is 35 Bytes)
<---------------- ASPUP-Ack
<---------------- Ntfy (AS-Inactive)
TEST DESCRIPTION:
1. Send the ASPUP message as described from ASP to SGP on Stream 0.
2. Check A: The Message should not be rejected at the SGP.
3. Check B: ASP UP Ack and NTFY should be sent from the SGP side.
Anjali Gurmukhani, HSS [Page 77]
Internet Draft SUA Conformance Test Plan Aug 2003
5.Test Cases for Testing SUA at ASP
5.1 ASPSM
"ASPDN-ACK message in ASP-INACTIVE state"
+ TEST NUMBER: ASPSM_1
+ PURPOSE: To check that if ASPDN-ACK message is received in
ASP-INACTIVE state then the ASP Should move to ASP-Down, and the
Procedure to bring the ASP into ASP-INACTIVE State may be initiated
by ASP itself.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
ASP is INACTIVE
<--------------- ASPDN-Ack
(ASP SHOULD Move to Down State)
<<<< ASP may Initiate the procedures to bring itself to it's
previous State >>>>
ASPUP ---------------->
<--------------- ASP-Up-Ack
<--------------- NTFY(AS-Inactive)
TEST DESCRIPTION:
1. Send ASPDN-ACK message to the ASP in ASP-InActive state.
Check A: ASP MUST move to ASP-Down State.
Check B: The ASP may Now initiate Procedures to bring itself
to it's previous state.
2. The ASP Sends ASPUP message to the SGP in ASP-Down state.
Check A: ASP-Up-Ack and NTFY (AS-Inactive) messages will come from
the SGP.
Check B: ASP notifies SM about the ASP becoming Up.
Anjali Gurmukhani, HSS [Page 78]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPDN-ACK message in ASP-Active state"
+ TEST NUMBER : ASPSM_2
+ PURPOSE: To check that if ASPDN-ACK message is received in ASP-
Active state then the ASP Should move to ASP-Down, and the
procedure to bring the ASP into ASP-ACTIVE state may be initiated
by the ASP itself.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
<--------------- ASPDN-Ack
(ASP SHOULD Move to Down State)
<<<< ASP may Initiate the procedures to bring itself to it's
previous State >>>>
ASPUP ---------------->
<--------------- ASP-Up-Ack
<--------------- NTFY(AS-InActive)
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPDN-ACK message to the ASP in ASP-Active state.
Check A: ASP Should move to ASP-Down State.
Anjali Gurmukhani, HSS [Page 79]
Internet Draft SUA Conformance Test Plan Aug 2003
Check B: The ASP may Now initiate Procedures to bring itself
to it's previous state.
2. ASP Sends ASPUP message to the SGP in ASP-Down state.
Check A: ASP-Up-Ack and NTFY (AS-Inactive) are received at ASP.
3. The ASP Sends ASPAC message to the same ASP.
Check A: ASP-Act-Ack message should be received at ASP.
Check B: State of ASP at SGP is now ASP-ACTIVE.
Check C: NTFY(AS-Active) is received at ASP.
Anjali Gurmukhani, HSS [Page 80]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPUP-Ack message is not received in response to ASPUP message"
+ TEST NUMBER: ASPSM_4
+ PURPOSE: To check that if Ack message is not received in response to
the ASPUP message then ASP keeps on sending ASPUP message at an
interval for some time and after some tries will report the SM.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. Also arrange the data in ASP such that SM sends ASP Up primitive
to the SUA. Arrange data in SGP such that Ack message
is not sent in response to the ASPUP message.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
<----------- ASP-Up
<------------ ASPUP
|
|time t1
<------------ ASPUP
|
|time t1
<------------ ASPUP
.
. n tries
.
Status Ind ---------->
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM at ASP. ASP will send ASPUP message
to the SGP. Don't send Ack message from the SGP.
Check A: ASPUP message will be retransmitted to the SGP.
Check B: The ASPUP Message will be retransmitted as many times as
has been configured in the implementation
Check C: After Maximum number of retries as configured by the
implementation, the ASP Down Ind would be received at SM.
Anjali Gurmukhani, HSS [Page 81]
Internet Draft SUA Conformance Test Plan Aug 2003
2. Repeat the above test case for ASPDN message also
i.e. Ack message is not sent in response to ASPDN message.
Anjali Gurmukhani, HSS [Page 82]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASP-Up-Ack is received in response to ASPDN message"
+ TEST NUMBER : ASPSM_5
+ PURPOSE: To check that if ASP-Up-Ack message is received in
response to the ASPDN then the Ack message is rejected and ASPDN is
sent again.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is Up. Arrange data in SGP such that ASP-Up-Ack is sent
to ASP in response to ASPDN message on stream 0.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Inactive
<--------- ASP-Down
<----------- ASPDN
ASP-Up-Ack ------------>
<----------- ASPDN
<n retries>
-------->Status Ind (Down)
TEST DESCRIPTION:
1. Send ASP-Down Primitive to the ASP. ASPDN message will be sent to
the SGP.
2. Send ASP-Up-Ack message in response to the ASPDN message.
Check A: ASPDN message is received again at the SGP and ASP keeps
retransmitting ASPDN message till it gets ASPDN-ack.
Check B: After n number of retries as configured by implementation
ASP down indication is given to SM.
3. Repeat the above test case if Ack message is sent.
Note: The above test holds true for ASPIA/ASPAC acks in response to
ASPDN message
Anjali Gurmukhani, HSS [Page 83]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASP-Up-Ack is received in response to ASPAC message"
+ TEST NUMBER: ASPSM_6
+ PURPOSE: To check that if ASP-Up-Ack message is received in
response to the ASPAC then the Ack message is accepted and ASPAC
retransmission is stopped.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is Up. Arrange data in SGP such that ASP-Up-Ack is sent
to ASP in response to ASPAC message .
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Inactive
<--------- ASP-Active
<----------- ASPAC
ASP-Up-Ack ------------>
Accepted and Inactive indicated to SM
TEST DESCRIPTION:
1. Send ASP-Active Primitive to the ASP. ASPAC message will be sent
to SGP.
2. Send ASP-Up-Ack message in response to the ASPAC message.
Check A: ASPAC retransmission is stopped and status indication
indicating Inactive is sent to SM.
Note: The above test can be run when ASPIA-Ack is received in response
to ASPAC.
Anjali Gurmukhani, HSS [Page 84]
Internet Draft SUA Conformance Test Plan Aug 2003
5.2 ASPTM
"ASPDN-ack received in response to ASPAC"
+ TEST NUMBER: ASPTM_1
+ PURPOSE: To Check that if ASPDN-ack is received in response to
ASPAC, ASPAC retransmissions are stopped.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 is inactive.
EXPECTED MESSAGE SEQUENCE:
SM ASP SGP NIF
ASPAC ---------------->
<----------------ASPDN-ack
<----------------
Accepted and indicated DN to
SM.
TEST DESCRIPTION:
1. Send ASPAC message to the SGP in ASP-Inactive state.
2. Send ASPDN-ack from the peer SGP.
Check A: ASPAC retransmissions are stopped .
Check B: ASP informs the SM with Down indication.
Anjali Gurmukhani, HSS [Page 85]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPIA -Ack received in response to ASPAC"
+ TEST NUMBER: ASPTM_2
+ PURPOSE: To check that if ASPIA-ack is received in response to
ASPAC, ASPAC retransmissions are stopped.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 is inactive.
EXPECTED MESSAGE SEQUENCE:
SM ASP SGP NIF
ASPAC ---------------->
<----------------ASPIA-ack
<----------------
Accepted and indicated Inactive to SM
TEST DESCRIPTION:
1. Send ASPAC message to the SGP in ASP-Inactive state.
2. Send ASPIA-ack from the peer SGP.
Check A: ASPAC retransmissions are stopped.
Check B: ASP informs the SM about Inactive state of ASP.
Anjali Gurmukhani, HSS [Page 86]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPAC-ack with multiple duplicate Routing contexts"
+ TEST NUMBER : ASPTM_3
+ PURPOSE: To Check that if ASPAC-ack with multiple duplicate Routing
contexts is sent, the message is accepted at ASP and ASPAC
retransmissions stop.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 is inactive. AS has been added
with RC value P.
EXPECTED MESSAGE SEQUENCE:
SM ASP SGP NIF
ASPAC ---------------->
<----------------ASPAC-ack
<----------------
Accepted and indicated Active
SM.
TEST DESCRIPTION:
1. Send ASPAC message to the SGP in ASP-Inactive state.
2. SGP sends the ack for ASPAC with multiple duplicate Routing
context values .
Check A: ASPAC retransmissions are stopped as ASPAC-ack is accepted
by ASP.
Check B: ASP informs the SM about ASP active for AS with RC value P.
Anjali Gurmukhani, HSS [Page 87]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASP-Active-Ack is received in response to ASPIA message"
+ TEST NUMBER: ASPTM_4
+ PURPOSE: To check that if ASP-Active-Ack message is received in
response to the ASPIA then the Ack message is discarded and ASPIA is
sent again.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is active. Arrange the data in SGP such that
ASP-Active-Ack with routing context P is sent to ASP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is active
<--------- ASP-Inactive
<----------- ASPIA
ASP-Active-Ack ------------>
<----------- ASPIA
TEST DESCRIPTION:
1. Send ASP-Inactive Primitive to the ASP. ASPIA message will be sent
to the SGP.
2. Send ASP-Active-Ack message in response to the ASPIA message.
Check A: ASPIA message is received again at the SGP.
Anjali Gurmukhani, HSS [Page 88]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASP-Down-Ack is received in ASP Active/Inactive State"
+ TEST NUMBER: ASPTM_5
+ PURPOSE: To check that if ASP-Down-Ack message is received in
any state, the state of the ASP changes to Down.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is Active/Inactive. Arrange the data in SGP such that
ASP-Down-Ack is sent to ASP on stream 0.
EXPECTED MESSAGE SEQUENCE:
SGP ASP SM
ASP is Active/Inactive
ASP-Down-Ack ------------>
Status Ind ---------> ASP is Down
TEST DESCRIPTION:
1. Send ASP-Down-Ack Message from SGP.
2. Check A: Status Ind with ASP State Down is received at ASP.
Anjali Gurmukhani, HSS [Page 89]
Internet Draft SUA Conformance Test Plan Aug 2003
"Multiple ASP-Active-Ack are received in response to ASP Active"
+ TEST NUMBER : ASPTM_6
+ PURPOSE: To Check that ASP successfully processes RCs spread
over Multiple ASP Active Ack Messages.
+ TEST CONFIGURATION: I
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP is Inactive. Arrange the data in SGP such that ASP-Active-Ack
with RC value P or Q are sent to ASP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Inactive
<--------- ASP-Active
<------------ ASPAC (RC P, RC Q)
ASP-Active-Ack ------------>
(RC P)
NTFY (AS-Active) ------------>
(RC P) | Status Ind --------->
|
| Timer Expires
<------------ ASPAC (only RC Q)
ASP-Active-Ack ------------>
(RC Q)
NTFY (AS-Active) ------------>
(RC Q)
Status Ind --------->
TEST DESCRIPTION:
1. Invoke ASP Active Primitive from ASP with RC value as P and Q.
Check A: ASPAC is received at SGP with Routing Contexts P and Q.
2. Send ASP Active Ack and NTFY from SGP with only one RC value P.
Check B: Status Ind for RC P is received at ASP and after time-out
ASPAC is retransmitted with just one RC = Q.
3. Send ASP Active Ack and NTFY from SGP with only one RC value Q.
Check C: Status Ind for RC Q is indicated at ASP.
Anjali Gurmukhani, HSS [Page 90]
Internet Draft SUA Conformance Test Plan Aug 2003
Note: In some Implementations Retransmission is not done. Here a
negative Indication to the SM would be given regarding RC Q and
ASPAC will not be resent.
Anjali Gurmukhani, HSS [Page 91]
Internet Draft SUA Conformance Test Plan Aug 2003
"ASPIA-ACK message in ASP-Active state"
+ TEST NUMBER : ASPTM_7
+ PURPOSE: To check that if ASPIA-ACK message is received in
ASP-Active state then the ASP Should move to ASP-INACTIVE,
and the procedure to bring the ASP into ASP-ACTIVE state should be
initiated by the ASP itself.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
<--------------- ASPIA-Ack
(ASP SHOULD Move to INACTIVE State)
<<<< ASP may Initiate the procedures to bring itself to it's
previous State >>>>
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPIA-ACK message to the ASP in ASP-Active state.
Check A: ASP Should move to ASP-INACTIVE State.
Check B: The ASP may Now initiate Procedures to bring itself
to it's previous state.
2. ASP Sends ASPAC message for the same ASP.
Check A: ASP-Act-Ack message should be received at ASP.
Check B: State of ASP at SGP is now ASP-ACTIVE.
Anjali Gurmukhani, HSS [Page 92]
Internet Draft SUA Conformance Test Plan Aug 2003
5.3 SSNM
"Reception of SSNM messages"
+ TEST NUMBER: SSNM_1
+ PURPOSE: To check that if SSNM message is received at the ASP then
it is reported to the ULP.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is Active. Also arrange the data in SGP such that DUNA,
DAVA, DUPU, DRST and SCON messages are sent from the SGP to the ASP
with valid parameters and they are sent on stream number 0.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU
AS is active
a)
DUNA --------------->
N-Pcstate-Ind-------->
b)
DAVA --------------->
N-Pcstate-Ind -------->
c)
SCON --------------->
N-Pcstate-Ind -------->
d)
DUPU --------------->
N-Pcstate-Ind -------->
e)
DRST --------------->
Anjali Gurmukhani, HSS [Page 93]
Internet Draft SUA Conformance Test Plan Aug 2003
N-Pcstate-Ind -------->
TEST DESCRIPTION:
1. Send DUNA message from SGP to ASP containing Routing Context Value
P and Affected DPC any value.
Check A: N-PCState indication primitive will be received at the SU.
2. Repeat the above test case for other messages like DAVA, SCON, DRST
and DUPU messages.
3. Repeat the above test case for multiple Point Codes.
Note: If in the SSNM messages , only Point code is included, the
message should result in N-Pcstate indication and if SSN is
included ,SSNM message results in N-State indication being given
to SU.
Anjali Gurmukhani, HSS [Page 94]
Internet Draft SUA Conformance Test Plan Aug 2003
"Selection of Route to Point Code: Routes Restricted & Unavailable "
+ TEST NUMBER: SSNM_2
+ PURPOSE: To check that when a Restricted and unavailable Routes are
available for a Point code, ASP routes through RESTRICTED Route.
+ TEST CONFIGURATION: H
+ PRE-TEST CONDITIONS: SCTP association is established between SG1,
and ASP and SG2 and ASP. SGP1 serves SG1 and SGP2 serves SG2.
ASP is Active for RC P in all SGPs.
Also arrange the data in ASP such that SU sends Unitdata Indication
primitive to SUA containing the RC value P. Also arrange Data at SGPs
to send SSNM for PC Y. Route to PC Y is available from both SG1
and SG2. The routes through both the SGs are equi-priority routes
and ASP loadshares between two SGs.
EXPECTED MESSAGE SEQUENCE:
SGP ASP SU
ASP is Active in all SGPs.
<----------- CLDT
DPC Y
To SGP1 <--------------- DATA
<----------- CLDT
DPC Y
To SGP2 <--------------- DATA
From SGP1
DUNA --------------->
(for PC Y)
<----------- CLDT
DPC Y
To SGP2 <--------------- DATA
Anjali Gurmukhani, HSS [Page 95]
Internet Draft SUA Conformance Test Plan Aug 2003
<----------- CLDT
DPC Y
To SGP2 <--------------- DATA
From SGP1
DAVA --------------->
(for PC Y)
From SGP2
DRST --------------->
(for PC Y)
<----------- CLDT
DPC Y
To SGP1 <--------------- DATA
<----------- CLDT
DPC Y
To SGP1 <--------------- DATA
From SGP1
DUNA --------------->
(for PC Y)
<----------- CLDT
DPC Y
To SGP2 <--------------- DATA
TEST DESCRIPTION:
1. Send two Unitdata Request Primitive from the SU at ASP side.
Check A: DATA message 1 reaches SGP1, and Data Message 2
reaches SGP2.
2. Send a DUNA from SGP1 to ASP with Affected Point Code as Y.
2. Repeat the Step1 with appropriate Seq control (S,T) for
Loadsharing.
Check B: Data Message 1 as well as Data Message 2 are both received
SGP1 as well as SGP2.
4. Send a DAVA from SGP1 to ASP with Affected Point Code as Y and
a DRST from SGP2 to ASP with Affected Point Code as Y.
5. Repeat the Step1 with appropriate Sequence ctrl (S,T) for
Loadsharing.
Check C: DATA message 1 reaches SGP1, and Data Message 2
reaches SGP2.
Anjali Gurmukhani, HSS [Page 96]
Internet Draft SUA Conformance Test Plan Aug 2003
6. Send a DUNA from SGP1 to ASP with Affected Point Code as Y.
7. Send Data for Point Code Y.
Check B: Data Message will be received at SGP2.
Note: Corresponding to the different SSNM messages received at ASP i.e
DUNA,DAVA verify that proper N-PCState/N-state indications are
received at ASP.
Anjali Gurmukhani, HSS [Page 97]
Internet Draft SUA Conformance Test Plan Aug 2003
" Selection of Route to Point Code: Routes Congested & Restricted "
+ TEST NUMBER: SSNM_3
+ PURPOSE: To check that when a Restricted and Congested Routes are
available for a Point code, ASP routes through Congested Route.
+ TEST CONFIGURATION: H
+ PRE-TEST CONDITIONS: SCTP association is established between SGP1,
SGP2 and ASP. ASP is Active for RC P in all SGPs.
Also arrange the data in ASP such that SU sends a Unitdata
Indication primitive to SUA containing the RC value P. Also arrange
Data at SGPs to send SSNM for PC Y. Route to PC Y is available from
both SG1 and SG2. SG mode for ASP is Loadshare.
EXPECTED MESSAGE SEQUENCE:
SGP ASP SU
ASP is Active in all SGPs.
<----------- CLDT
DPC Y & Seq. ctrl S
To SGP1 <--------------- DATA
<----------- CLDT
DPC Y & Seq ctrl T
To SGP2 <--------------- DATA
From SGP1
DRST --------------->
(for PC Y)
<----------- CLDT
DPC Y & Seq ctrl S
To SGP2 <--------------- DATA
From SGP2
SCON ------------------->
Anjali Gurmukhani, HSS [Page 98]
Internet Draft SUA Conformance Test Plan Aug 2003
<----------- CLDT
DPC Y & Seq ctrl T
To SGP2 <--------------- DATA
From SGP1
DAVA --------------->
(For PC Y)
From SGP2
DRST --------------->
(for PC Y)
<----------- CLDT
DPC Y & Seq ctrl S
To SGP1 <--------------- DATA
<----------- CLDT
DPC Y & Seq ctrl T
To SGP1 <--------------- DATA
From SGP1
DUNA --------------->
(for PC Y)
<----------- CLDT
DPC Y
To SGP2 <--------------- DATA
TEST DESCRIPTION:
1. Send two Unitdata Primitive from the SU at ASP side with Seq. ctrl
values S and T respectively.
Check A: DATA message 1 reaches SGP1, and Data Message 2
reaches SGP2.
2. Send a DRST from SGP1 to ASP with Affected Point Code as Y.
3. Repeat the Step1 with appropriate Seq. ctrl values (S,T) for
Loadsharing .
Check B: Data Message 1 as well as Data Message 2 are both received
SGP2.
4. Send a SCON from SGP2 to ASP with Affected Point Code as Y .
5. Repeat the step1 with appropriate Seq ctrl values for loadsharing.
Check A: Data message should be routed through the Congested route.
Anjali Gurmukhani, HSS [Page 99]
Internet Draft SUA Conformance Test Plan Aug 2003
Note: Corresponding to the different SSNM messages received at ASP i.e
DUNA,DAVA,SCON, verify that proper N-PCState/N-state indications are
received at ASP.
Anjali Gurmukhani, HSS [Page 100]
Internet Draft SUA Conformance Test Plan Aug 2003
5.4 Dynamic Routing Key Procedures
"RK Registration Request"
+ TEST NUMBER: DRKM_1
+ PURPOSE: To check that when SM invokes Registration Request a
valid REG_REQ message is sent to the SGP.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive in SGP. Also arrange the data in ASP
such that Layer Mgmt sends a Reg. Req Primitive to SUA containing a
valid Routing Key (Indicator). Also arrange Data at SGPs to send
REG RESP with a RC value.
EXPECTED MESSAGE SEQUENCE :
SGP ASP LM
ASP is Inactive in SGP.
<----------- REG REQ (RK = RK1)
To SGP <--------------- REG_REQ (RK1)
REG_RSP --------------->
(RC1) REG RESPONSE ----------->
TEST DESCRIPTION:
1. Invoke RK Registration Request from LM with a valid Routing Key.
Check A: A REG_REQ Message with RK1 packed is sent from the
ASP to SGP.
3. Send a REG_RSP with SUCCESS and RC Value RC1 from the SGP to
the ASP.
Check B: A Registration Success Response is sent to the SM
at ASP and this is indicated to SM.
Anjali Gurmukhani, HSS [Page 101]
Internet Draft SUA Conformance Test Plan Aug 2003
"RK Deregistration Request"
+ TEST NUMBER: DRKM_2
+ PURPOSE: To check that when SM invokes Deregistration Request a
valid DEREG_REQ message is sent to the SGP.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive in SGP. Also arrange the data in ASP
such that Layer Mgmt sends a DeReg Req Primitive to SUA containing a
valid Routing Context. Also arrange Data at SGPs to send
DEREG RESP with a RC value.
EXPECTED MESSAGE SEQUENCE :
SGP ASP LM
ASP is Inactive in SGP.
<----------- DEREG REQ (RC = RC1)
To SGP <--------------- DEREG_REQ (RC1)
DEREG_RSP --------------->
(RC1)
DEREG RESPONSE ----------->
TEST DESCRIPTION:
1. Invoke RK Deregistration Request from LM with a valid Routing
Context.
Check A: A DEREG_REQ Message with RC1 is sent from the
ASP to SGP.
2. Send a DEREG_RSP with SUCCESS and RC Value RC1 from the SGP to
the ASP.
Check B: A Deregistration Success Response is indicated to SM
at ASP.
Anjali Gurmukhani, HSS [Page 102]
Internet Draft SUA Conformance Test Plan Aug 2003
"RK Registration Response with Invalid LRK Identifier"
+ TEST NUMBER : DRKM_3
+ PURPOSE: To check that for a sent Registration Request, if the ASP
receives response with Invalid/Non-Matching LRK, it is rejected.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive in SGP. Also arrange the data in ASP
such that SU sends a Reg. Req. Primitive to SUA containing a
valid Routing Context. Also arrange Data at SGP to send
Reg RESP with Invalid Local Routing Key identifier.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM+NIF
-----------> REG REQ (RK1,LRK1)
<--------------- REG_RESP (Invalid LRK)
REG_RESP rejected
TEST DESCRIPTION:
1. Invoke RK Registration Request from LM with a valid Routing Key.
Check A: A REG_REQ Message with valid Routing key is sent from the
ASP to SGP and LRK Id as 1.
2. Send Registration response from SGP with Invalid LRK Id from SGP to
ASP.
Check B: Registration Response is rejected at the ASP.
Anjali Gurmukhani, HSS [Page 103]
Internet Draft SUA Conformance Test Plan Aug 2003
5.5 MANAGEMENT
"Handling of Invalid messages at ASP"
+ TEST NUMBER: MGMT_1
+ PURPOSE: To check that if the ASP receives an ASP-UP
message ,it discards the message.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams.)
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
<--------------- ASP-UP
------------>
ERROR (error code = Protocol Error)
TEST DESCRIPTION:
1. Generate an ASP-UP Message to be destined to the ASP.
Check A: The ASP should discard this message and report
an error to SM. A
Check B: Error message is sent back to SGP with error code "Protocol
Error"
The Above test case MUST be carried out for the following combinations
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ASP DAUD
ASPUP
ASPDN
ASPAC
ASPIA
REG_REQ
DEREG_REQ
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Anjali Gurmukhani, HSS [Page 104]
Internet Draft SUA Conformance Test Plan Aug 2003
"Message length less than the length of mandatory Parameters"
+ TEST NUMBER : MGMT_2
+ 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: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP, and ASP is Down. Arrange the data in SGP such that ASPUP-Ack
message with length parameter filled with value less than the length
of Common Message Header.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
<--------- ASP-Up
<----------- ASPUP
ASP-Up-Ack ------------>
<----------- ERROR
<----------- ASPUP(sent after T(ack))
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to the SUA at the ASP. ASPUP message
will be sent to the SGP.
2. Send ASP-Up-Ack message with length field less than the length of
Common Message Header from the SGP.
Check A: ASP will send an ERROR message to the SGP and discard the
Message.
Check B: ASPUP message will be sent again after ASPSM Timer Expiry.
Note: Resending of ASPUP is implementation Dependent.
Anjali Gurmukhani, HSS [Page 105]
Internet Draft SUA Conformance Test Plan Aug 2003
"Invalid MASK Value in DUPU message"
+ TEST NUMBER : MGMT_3
+ PURPOSE: To check that if DUPU message with MASK value other than 0
is received ,an error is sent back to SGP.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is active. Arrange the data in SGP such that DUPU message
with mask value not equal to 0 is sent to the ASP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is active
DUPU --------------->
Mask not equal to 0
<-------------- ERROR
Cause = Invalid Parameter value
CLDT --------------->
RC-A
Unitdata-Ind --------->
TEST DESCRIPTION:
1. Send DUPU message with Mask not equal to 0.
Check A: ASP will send an ERROR Message with Invalid Parameter
Value to SGP.
2. Send a CLDT Message to the ASP.
Check B: Unitdata Indication will be given to the SU at ASP and
State of ASP is not disturbed.
Anjali Gurmukhani, HSS [Page 106]
Internet Draft SUA Conformance Test Plan Aug 2003
"Parameter Field Error"
+ TEST NUMBER: MGMT_4
+ PURPOSE: To check that if a message is sent with the length of one
of its parameter incorrect, ASP responds with Error message
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP and ASP is UP. Arrange the data in SGP such that DUNA
with Affected point code as Z and length of this parameter as 0xa is
sent.
EXPECTED MESSAGE SEQUENCE:
SGP ASP SM
ASP is active
DUNA --------------->
(Single PC=Z)
<-------------- ERROR
Cause = Parameter Field Error
CLDT --------------->
RC-A
Unitdata-Ind --------->
TEST DESCRIPTION:
1. Send DUNA message with Affected point code as Z and length of the
point code field as 0xa.
Check A: ASP will send an ERROR Message with Parameter Field Error.
2. Send a CLDT Message to the ASP.
Check B: Unitdata Indication will be given to the SU at ASP and
State of ASP is not disturbed.
Anjali Gurmukhani, HSS [Page 107]
Internet Draft SUA Conformance Test Plan Aug 2003
6. Test cases for testing SUA at ASP and SGP.
The following section lists test cases that can be executed by both
ASP and SGP implementations.
6.1 Connectionless Data Transfer
"Connectionless Data Transfer for Protocol Class 0"
+ TEST NUMBER: CL_1
+ PURPOSE: To check that successful Connectionless Data transfer
occurs from one PC to another.
+ 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
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY (AS-InActive)
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY (AS-Active)
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
Anjali Gurmukhani, HSS [Page 108]
Internet Draft SUA Conformance Test Plan Aug 2003
N-UNITDATA REQ CLDT ------------->
---------> N-UNITDATA IND
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-DOWN state.
Check A: ASPUP-Ack message will come from SGP.
2. Send ASPAC message to the SGP in ASP-UP state.
Check A: ASPAC-Ack message will come from SGP.
Check B: NTFY message will come from SGP.
3. Send N-UNITDATA Primitive from the NIF at SGP to send to ASP.
Check A: CLDT message should be received at the ASP containing
data passed by the SCCP.
Check B: Check the protocol class field in the message received.
It should be class 0.
4. Send CLDT message from ASP containing Protocol Data and Protocol
Class 0.
Check C: N-UNITDATA Ind. Primitive is received at the NIF with
Protocol Data and protocol class as 0.
Check D: Check the protocol class field in message received.
It should be class 0.
Send different CLDT messages from both the directions several times.
The Above Test case should be carried out for Protocol Class "0" and
"1".
Anjali Gurmukhani, HSS [Page 109]
Internet Draft SUA Conformance Test Plan Aug 2003
"CL Data response message generation "
+ TEST NUMBER: CL_2
+ PURPOSE: To check that in case a CLDT Message is sent and at the
peer the SSN is not present for which Unitdata is meant, CLDR is
returned if the return on error option is set.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 is active. Also arrange the
data at SGP such that Unitdata primitive is sent to SUA
with return option set as "1"(Bit 8 in the protocol class
parameter should be set to 1)to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<------------- CLDT
(DPC=X, SSN=Y)
(No user with SSN=Y)
CLDR ------------->
---------> N-NOTICE IND
TEST DESCRIPTION:
1. Send Unitdata primitive from SGP with Address parameters with Point
code X and SSN as Y.
2. SSN Y is not registered as user at ASP.
Check A: Check that a CLDR Message is sent in response to this
CLDT Message with Reason for return as "Unequipped User".
Check B: This CLDR is indicated at ASP as Notice Indication.
Anjali Gurmukhani, HSS [Page 110]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connectionless Data response message not generated if return option is
not set "
+ TEST NUMBER: CL_3
+ PURPOSE: To check that in case CLDT Message is sent and at the peer
the SSN is not present for which Unitdata is meant, CLDR is NOT
returned if return on error option is not set.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONSSCTP association is established between SGP and
ASP (with two or more streams). ASP1 is active. Also arrange the
data at SGP such that Unitdata primitive is sent to SUA
with return option set as "0"(Bit 8 in the protocol class parameter
should be set to 0)to be sent to DPC X
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<------------- CLDT
(DPC=X,SSN=Y)
(No user with SSN=Y)
(Discard message)
<------
Error
TEST DESCRIPTION:
1 Send Unitdata primitive from SGP with Address parameters with Point
code X and SSN as Y.
SSN Y is not registered as user at ASP.
Check A: No CLDR Message is generated.
Check B: Error may be generated locally.
Anjali Gurmukhani, HSS [Page 111]
Internet Draft SUA Conformance Test Plan Aug 2003
"Ordered Delivery for CLDT for Protocol Class 1"
+ TEST NUMBER: CL_4
+ PURPOSE: To check that CLDT Messages with Protocol class 1 are
delivered in order.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with more than two streams). ASP1 is active. Also arrange
the data in SGP such that NIF sends Unitdata primitive to
SUA containing protocol class "1" and sequence control parameter
set to "1", to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-UNITDATA IND <------------- CLDT
Data=abc (Seq. Control 1)(data=abc)
N-UNITDATA IND <------------- CLDT
Data=xyz (Seq. Control 1)(data=xyz)
N-UNITDATA IND <------------- CLDT
Data=mno (Seq. Control 1)(data=mno)
TEST DESCRIPTION:
1. Send 3 CLDT (with Seq. Control 1) to the ASP.
Check A: CLDT messages should be received at the ASP1 in the same
order as was sent by the originating side.
Check B: Check the stream identifier in each of above cases.
It should be same.
Anjali Gurmukhani, HSS [Page 112]
Internet Draft SUA Conformance Test Plan Aug 2003
"Loadsharing of CL messagesö
+ TEST NUMBER: CL_5
+ PURPOSE: To check that Loadsharing of CLDT Messages .
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 and ASP2 both are active. Also
arrange the data such that Unitdata primitive is sent to SUA
containing protocol class "0" and with different sequence control
values.
EXPECTED MESSAGE SEQUENCE:
ASP1 ASP2 SGP NIF
ASPs are active
<-------
Unitdata(Seq. ctrl=X)
N-Unitdata-Ind
<------
.-------
Unitdata (Seq_ctrl = Y)
N-Unitdata-Ind
<------
TEST DESCRIPTION:
1.Send CLDT from SGP varying the sequence control 0.
Check A: CLDT message should be received at ASP1.
2.Send CLDT from SGP with sequence control as 1.
Check B: CLDT message should be sent to ASP2.
Repeat the above with different values of sequence control. The
data should be Loadshared .
3. Now send ASP-inactive from ASP1.
4. Send CLDT from SGP with different seq. ctrl. All messages should go
to ASP2.
Repeat the Above Test case for Protocol Class "1" with different
values for the message length field.
Anjali Gurmukhani, HSS [Page 113]
Internet Draft SUA Conformance Test Plan Aug 2003
"CLDT received with Optional parameters before Mandatory parameters"
+ TEST NUMBER: CL_6
+ PURPOSE: To check that CLDT Message received with optional
parameters before Mandatory parameters is not rejected at IUT.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 is active. Also
arrange the data such that Unitdata primitive is
sent to SUA containing protocol class "0" to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
SGP ASP
ASP is active
CLDT ------------>
------------>N-unitdata Ind
TEST DESCRIPTION:
1. Send CLDT to the SGP with Hop counter before any of the mandatory
parameters.
Check A: CLDT message received at SGP is not rejected
Check B: Data is Indicated to the user at the ASP.
Repeat the Above Test case for different combinations and reordering
of Mandatory and optional parameters.
Anjali Gurmukhani, HSS [Page 114]
Internet Draft SUA Conformance Test Plan Aug 2003
"CL Data Transfer (Different Seq. Control values)"
+ TEST NUMBER: CL_7
+ PURPOSE: To check that CLDT Messages with different value of
sequence control parameter are sent on different SCTP streams.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with more than two streams). ASP1 is active. Also arrange the
data such that Unitdata primitives are sent to SUA containing protocol
class "0" to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
SGP ASP
ASP is active
CLDT ------------>
Seq ctrl X
------------>N-unitdata Ind
CLDT ------------->
Seq ctrl Y
------------>N-unitdata Ind
CLDT ------------->
Seq ctrl Z
------------>N-unitdata Ind
TEST DESCRIPTION:
1. Send CLDT to the SGP with different values of Sequence control
parameter.
Check A: CLDT message is sent on different SCTP non-zero streams.
Check B: CLDT Data is received and indicated to user at SGP.
Anjali Gurmukhani, HSS [Page 115]
Internet Draft SUA Conformance Test Plan Aug 2003
6.2 Routing Procedures
"CL Data Transfer, Route on GT"
+ TEST NUMBER: RP_1
+ PURPOSE: To check that successful GT Translation takes place and
Connectionless Data transfer occurs from one PC to another.
+ TEST CONFIGURATION: A.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange the data
In SGP such that NIF sends UNITDATA primitive to SUA containing
protocol class "0" to be sent to GT "X". Configure the SCCP Routing
control route GT "X" to DPC of ASP and SSN available at ASP.
Set the Routing Indicator in called address as Route on GT.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(Route on GT)
<------------- CLDT
(Route on GT)
<------------
N-UNITDATA IND
(GT Translated to local PC and SSN)
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to GT "X".
Check A: GT translation at SGP gives point code X being served by
ASP1.Proper Routing and address indicators are filled in CLDT
message.
Check B: CLDT message should be received at the ASP1 containing
data passed by the SCCP.
Check C: At ASP1 GT translation occurs and gives SSN available on ASP
and hence Unitdata Indication is given.
Anjali Gurmukhani, HSS [Page 116]
Internet Draft SUA Conformance Test Plan Aug 2003
"CL Data Transfer for Protocol Class 0, Route on GT Failure,
with return Option set"
+ TEST NUMBER: RP_2
+ PURPOSE: To check that if GT Translation fails and return
option is set Connectionless Data response is sent back.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP . ASP1 is active. Also arrange the data in
SGP such that NIF sends UNITDATA primitive to SUA containing
protocol class "0" to be sent to GT "X". Configure the SCCP Routing
control route GT "X" to DPC of ASP and SSN that is NOT AVAILABLE at
ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<------------- CLDT
(Route on GT)
(return option set)
<------------
ERROR
CLDR ------------->
(Route on GT FAILURE) ---------> N-NOTICE IND
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to GT "X".
Check A: GT translation at SGP gives point code X being served by
ASP1.Proper Routing and address indicators are filled in CLDT
message.
Check B: CLDT message should be received at the ASP1 containing
data passed by the SCCP.
Check C: At ASP1 GT translation occurs and gives SSN unavailable on
ASP and hence CLDR is sent back to SGP.
Anjali Gurmukhani, HSS [Page 117]
Internet Draft SUA Conformance Test Plan Aug 2003
"CL Data Transfer for Protocol Class 0, Route on DPC+SSN "
+ TEST NUMBER: RP_3
+ PURPOSE: To check that Connectionless Data transfer occurs from one
PC to another, when routing is DPC+SSN based.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. ASP1 is active. Also arrange the data in
SGP such that NIF sends UNITDATA primitive to SUA with protocol
class "0" to be sent to DPC "X" and SSN "Y".
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-UNITDATA REQ
(Route on DPC+SSN)
<------------- CLDT
(Route on DPC+SSN)
<------------
N-UNITDATA IND
(IND is given to user with SSN "Y")
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to
DPC "X" and SSN "Y".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
The Above Test case should be carried out for Protocol Class
"0" and "1".
Anjali Gurmukhani, HSS [Page 118]
Internet Draft SUA Conformance Test Plan Aug 2003
"CL Data Transfer for Protocol Class 0, Route on DPC+SSN
FAILURE with return option set"
+ TEST NUMBER: RP_4
+ PURPOSE: To check that when routing is DPC+SSN based, and the peer
fails to locate a user, a CLDR message is sent back if return option
is set.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active. Also arrange
the data in SGP such that NIF sends UNITDATA primitive to SUA
containing protocol class "0" to be sent to DPC "X" and SSN "Y". No
user should be registered with the SSN "Y" on the ASP side.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-UNITDATA REQ
(Route on DPC+SSN)
(Return option set)
<------------- CLDT
(Route on DPC+SSN)
<------------
ERROR(no SSN found)
CLDR ------------->
(Route on DPC+SSN FAILURE)---------> N-NOTICE IND
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to
DPC "X" and SSN "Y".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: A CLDR Message should be sent back with appropriate error
code, indicating no user with the desired SSN exists.
Anjali Gurmukhani, HSS [Page 119]
Internet Draft SUA Conformance Test Plan Aug 2003
Note: Check the behavior when return option is not set.
No CLDR is sent in that case.
Anjali Gurmukhani, HSS [Page 120]
Internet Draft SUA Conformance Test Plan Aug 2003
"CL Data Transfer, Route on IP "
+ TEST NUMBER: RP_5
+ PURPOSE: To check that successful Connectionless Data transfer
occurs from one PC to another, when routing is based on IP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 is active. Also arrange the
data in SGP such that NIF sends UNITDATA primitive to SUA containing
protocol Class "0ö, to be sent to the ASP serving the AS with
Routing Key as A.B.C.D
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(To be sent to ASP handling traffic
AS with routing key as IP=A.B.C.D, RC A)
<------------- CLDT
(containing RC A)
<------------
N-UNITDATA IND
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to be sent to the ASP
serving the AS with Routing Key as IP/IP+SSN.
Check A: CLDT message should be received at the ASP1
Note: The above test case should be repeated for Routing key IP(v6)
based.
Anjali Gurmukhani, HSS [Page 121]
Internet Draft SUA Conformance Test Plan Aug 2003
"Successful connection establishment and termination Route on
GT"
+ TEST NUMBER: RP_6
+ PURPOSE: To check connection establishment and termination Route on
GT .
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
(Route on GT)
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
<--------- N-DISCONNECT REQ
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
RELCO------------>
(Dest ref. number "A") ---------> N-DISCONNECT IND
N-DATA REQ -------->
Anjali Gurmukhani, HSS [Page 122]
Internet Draft SUA Conformance Test Plan Aug 2003
<--------- ERROR (Connection Does not exist)
TEST DESCRIPTION:
1. Send N-CONNECT REQ(Dest Address should be in GT form ) Primitive
from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODT message should be received for Dest Ref. number "A".
4. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: RELRE message should be received at the ASP.
Check B: RELCO message should be received at the SGP.
5. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: Should result in error.
Anjali Gurmukhani, HSS [Page 123]
Internet Draft SUA Conformance Test Plan Aug 2003
6.3 Reassembly Procedures
"Successful Reassembly of segmented messages"
+ TEST NUMBER: SR_1
+ PURPOSE: To check that if segmented messages (CLDT) are received
, Reassembly is done and reassembled data indicated to user.
+ TEST CONFIGURATION: A/G
+ PRE-TEST CONDITIONS: SCTP association is established between
ASP and SGP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
<------------- CLDT
(Segmentation
param ,bit 8 =1,remain=1)
CLDT <----------
T(reass) start
<------------- CLDT
(Segmented
Data, Bit 8 =0,remain=0)
CLDT <----------
N-Unitdata-Ind
<----
TEST DESCRIPTION:
1.Send segmented CLDT messages from SGP such that the message has
Segmentation parameter with bit 8 of ôfirstö field set. Also the
number of remaining segments as 1.
Check A: CLDT is received at ASP.
Check B: ASP starts Reassembly timer.
Anjali Gurmukhani, HSS [Page 124]
Internet Draft SUA Conformance Test Plan Aug 2003
3. Send another segmented CLDT from SGP such that Bit 8 of the
ôfirst/remainö field is not set but the remaining segments is 0.
Check A: CLDT is received at ASP.
Check B: Reassembly timer is stopped
Check C: The two segmented messages are reassembled and indicated to
SU.
Anjali Gurmukhani, HSS [Page 125]
Internet Draft SUA Conformance Test Plan Aug 2003
"Reassembly Timer Expiry"
+ TEST NUMBER: SR_2
+ PURPOSE: To check that if segmented messages (CLDT) are received
, but if remaining segments are not received during reassembly
timer.Reassembly procedure is stopped and messages discarded.
+ TEST CONFIGURATION: A/G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP1 is active. Also arrange the data
in SGP such segmented messages are sent to ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
<------------- CLDT
(Segmentation
param ,bit 8 =1,remain=1)
CLDT <----------
T (reass) start
-
-
-
\/Timer expires
Message Discarded
TEST DESCRIPTION:
1.Send segmented CLDT messages from SGP such that the message has
Segmentation parameter with bit 8 of ôfirstö field set. Also the
number of remaining segments as 1.
Check A: CLDT is received at ASP.
Check B: ASP starts Reassembly timer.
2. Do not send any other segment. Let the Reassembly timer expire at
ASP.
Check A: Segmented message sent earlier is discarded
Check B: Any other message sent from peer for the earlier segmented
reference is discarded.
Anjali Gurmukhani, HSS [Page 126]
Internet Draft SUA Conformance Test Plan Aug 2003
"CLDR message sent back if Reassembly of segmented message cannot be done"
+ TEST NUMBER: SR_3
+ PURPOSE: To check that if segmented message (CLDT) is received and
Reassembly cannot be done, CLDR is sent back with appropriate SCCP
cause.
+ TEST CONFIGURATION: A/G
+ PRE-TEST CONDITIONS: SCTP association is established between
ASP and SGP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
<------------- CLDT
(Segmentation
param ,bit 8 =1,remain=4)
CLDT <----------
T(reass) start
<------------- CLDT
(Segmented
Data, Bit 8 =0,remain=0)
CLDT <----------
CLDR------------->
SCCP cause "cannot perform Reassembly"
TEST DESCRIPTION:
1.Send segmented CLDT messages from SGP such that the message has
Segmentation parameter with bit 8 of ôfirstö field set. Also the
number of remaining segments as 4.This CLDT has return on error set.
Anjali Gurmukhani, HSS [Page 127]
Internet Draft SUA Conformance Test Plan Aug 2003
Check A: CLDT is received at ASP.
Check B: ASP starts Reassembly timer.
2. Send another segmented CLDT from SGP such that Bit 8 of the
ôfirst/remainö field is not set but the remaining segments is 0.The
return
on error is set in Protocol class.
Check A: CLDT is received at ASP.
Check B: Reassembly timer is stopped
Check C: CLDR is received and indicated to user as N-Notice
indication.
Anjali Gurmukhani, HSS [Page 128]
Internet Draft SUA Conformance Test Plan Aug 2003
6.4 Relay Functionality
"Relay mode operation (Connectionless)"
+ TEST NUMBER: RE_1
+ PURPOSE: To check the Relay node functionality.
+ TEST CONFIGURATION: RELAY
+ PRE-TEST CONDITIONS: SCTP association is established between ASP1
and ASP2 AND ASP2 and ASP3. Also both the associations (ASP1-ASP2)
(ASP2-ASP3) are Active.
EXPECTED MESSAGE SEQUENCE:
IPSP1 IPSP2 IPSP3
----.
CLDT (Called_addr=Y)
----.
------.N-UnitdataInd
<---------
CLDT(Called_addr=X)
<-------
N-UnitdataInd
<----------
TEST DESCRIPTION:
1. Send CLDT from IPSP1 to IPSP2 with called address as Y.
Check A: CLDT message should be received at the IPSP2.
Check B: CLDT is received at IPSP3 and indicated to user.
2. Send CLDT from IPSP3 with called address with point code = X.
Check A: CLDT message should be received at IPSP2.
Check B: CLDT message is sent from IPSP2 to IPSP1 and indicated to SU.
Anjali Gurmukhani, HSS [Page 129]
Internet Draft SUA Conformance Test Plan Aug 2003
"Relay mode operation (Connection-oriented)"
+ TEST NUMBER: RE_2
+ PURPOSE: To check the Relay node functionality.
+ TEST CONFIGURATION: RELAY
+ PRE-TEST CONDITIONS: SCTP association is established between ASP1
and ASP2 AND ASP2 and ASP3. Also both the associations (ASP1-ASP2)
(ASP2-ASP3) are Active.
EXPECTED MESSAGE SEQUENCE:
IPSP1 IPSP2 IPSP3
----.
CORE (Called_addr=Y)
----.
------.N-connectInd
<---------
COAK
<-------
N-Connect ConfirmInd
<----------
--------.
CODT(Y)
----.
-----.n-DATA iND
TEST DESCRIPTION:
1. Send CORE from IPSP1 to IPSP2 with called address as Y.
Check A: CORE message should be received at the IPSP2.
Check B: CORE is received at IPSP3 and indicated to user.
Check C: IPSP3 sends back COAK and two connection sections are
established.
Anjali Gurmukhani, HSS [Page 130]
Internet Draft SUA Conformance Test Plan Aug 2003
2.Send CODT from IPSP1 with called address with point code = y.
Check A: CODT message should be received at IPSP2.
Check B: CODT message is sent from IPSP2 to IPSP3 and indicated to as
Data-Ind.
Anjali Gurmukhani, HSS [Page 131]
Internet Draft SUA Conformance Test Plan Aug 2003
6.5 Connection Oriented Procedures
"Successful connection establishment and termination"
+ TEST NUMBER: CO_1
+ PURPOSE: To check connection establishment and termination.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(Ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
<--------- N-DISCONNECT REQ
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
Anjali Gurmukhani, HSS [Page 132]
Internet Draft SUA Conformance Test Plan Aug 2003
RELCO------------>
(Dest ref. number "A") ---------> N-DISCONNECT IND
N-DATA REQ -------->
<--------- ERROR (Connection Does not exist)
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODT message should be received for Dest Ref. number "A".
4. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to
ASP.
Check A: RELRE message should be received at the ASP.
Check B: RELCO message should be received at the SGP.
5. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: Should result in error.
Anjali Gurmukhani, HSS [Page 133]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connection release during Connection Establishment"
+ TEST NUMBER: CO_2
+ PURPOSE: To check if the CORE message is responded with a COREF
Message the connection is not established.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-DISCONNECT REQ -------->
COREF------------>
(Dest ref. number "A") ---------> N-DISCONNECT IND
<--------- N-DATA REQ
------------> ERROR
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-DISCONNECT REQ Primitive from the SU to SGP.
Check A: COREF message should be received at the ASP, with
refusal cause value.
The Above Test case should be carried out for Protocol Class "2" and
"3".
Anjali Gurmukhani, HSS [Page 134]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connection oriented Data with mandatory parameter missing"
+ TEST NUMBER: CO_3
+ PURPOSE: To check if the CODT message is received with a
mandatory parameter missing it is responded with an COERR Message.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active. SCCP connection
exists between ASP and SGP. Arrange the CODT message
so that it does not contain the mandatory parameter Routing
Context.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-DATA REQ
<------------- CODT (Routing Context missing)
COERR------------>
(Error cause) ------------> ERROR
TEST DESCRIPTION:
1. Send N-DATA REQ (without protocol class parameter )Primitive from
the NIF at SGP to send to ASP.
Check A: CODT message should be received at the ASP.
Check B: COERR message should be received at the SGP, with error
cause value.
Anjali Gurmukhani, HSS [Page 135]
Internet Draft SUA Conformance Test Plan Aug 2003
The Above Test case should be carried out for Protocol Class "2" and
"3".
The above Test case should also be carried for the messages listed below
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Message parameters to be checked for
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CODT Routing Context
Sequence Number(NOT in case of N-EXPED.DATA REQ)
Destination Reference Number
Data
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CODA Routing Context
Destination Reference Number
Receive Sequence number[mandatory in case of data ack]
Credit
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CORE Routing Context
Protocol Class
Source Reference Number
Destination Address
Sequence Control
Sequence Number[in case of class 3]
Credit(in case of Protocol class 3)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COAK Routing Context
Protocol Class
Destination Reference Number
Source Reference Number
Sequence Control
Destination address
[Mandatory when CORE contains src addr]
Credit(in case of Protocol class 3)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COREF Routing Context
Anjali Gurmukhani, HSS [Page 136]
Internet Draft SUA Conformance Test Plan Aug 2003
Destination Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RELRE Routing Context
Destination Reference Number
Source Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RELCO Routing Context
Destination Reference Number
Source Reference Number
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RESRE Routing Context
Destination Reference Number
Source Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RESCO Routing Context
Destination Reference Number
Source Reference Number
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COERR Routing Context
Destination Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COIT Routing Context
Protocol Class
Source Reference Number
Destination Reference number
Sequence Number
Credit
Anjali Gurmukhani, HSS [Page 137]
Internet Draft SUA Conformance Test Plan Aug 2003
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Anjali Gurmukhani, HSS [Page 138]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connection response message parameter validation"
+ TEST NUMBER: CO_4
+ PURPOSE: To check that if the CORE Message carries the Source
address then the COAK Message also carries the Destination address
parameter.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (With Source Address parameter
present)
(Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Contains Dest. Address parameter)
TEST DESCRIPTION:
1. Send N-CONNECT REQ(with Source address parameter present)
Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
Check A: COAK message should contain the Destination Address
parameter.
Anjali Gurmukhani, HSS [Page 139]
Internet Draft SUA Conformance Test Plan Aug 2003
The Above Test case should be carried out for Protocol Class "2" and
"3".
"Connection response message parameter validation"
+ TEST NUMBER: CO_5
+ PURPOSE: To check that if the CORE Message carries the Source
address then the COREF Message also carries the Destination
address parameter.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (With Source Address parameter
present)
(Source ref. number "A")
COREF ------------>
(Dest ref. number "A")
--------->
oes not Contains Dest. Address parameter,
Message is rejected)
TEST DESCRIPTION:
1.Send N-CONNECT REQ(with Source address parameter present) Primitive
from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COREF message from the ASP to SGP without source address
parameter.
Anjali Gurmukhani, HSS [Page 140]
Internet Draft SUA Conformance Test Plan Aug 2003
Check A: COREF message should be received at the SGP.
Check B: COREF message received is rejected due to absence of
Destination address parameter.
The Above Test case should be carried out for Protocol Class "2" and
"3".
Anjali Gurmukhani, HSS [Page 141]
Internet Draft SUA Conformance Test Plan Aug 2003
"RELRE retransmissions"
+ TEST NUMBER: CO_6
+ PURPOSE: To check that if RELRE message is sent and it is not
responded with either RELRE/RELCO RELRE is retransmitted.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams). ASP1 is active.Also ASP and SGP
have a SCCP connection between them.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-DISCONNECT REQ
N-DISCONNECT IND <------------- RELRE
(Source ref. number "A",
Dest ref number "B" )
TEST DESCRIPTION:
1. Send N-DISCONNECT REQ primitive from the NIF at SGP to send to
ASP.
Check A: RELRE message should be received at the ASP.
2. Do not send any RELRE/RELCO message from ASP.
Check A: SGP should keep retransmitting RELRE.
Check B: Reference numbers are freed after maximum number of
retransmissions.
Anjali Gurmukhani, HSS [Page 142]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connection Oriented Data Ack. Received in response to CODT with
Protocol Class 3, when the receive window becomes full"
+ TEST NUMBER: CO_7
+ PURPOSE: To check that a CODA message is received in response
to a CODT message in case of Protocol Class 3, when the
receive window becomes full.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(credit 3)
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(credit 3)
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(seq number "A")
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(seq. number "A + 1")
Anjali Gurmukhani, HSS [Page 143]
Internet Draft SUA Conformance Test Plan Aug 2003
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(seq. number "A + 2")
<------------- CODA
(Recv Seq number "A + 2")
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send 3 N-DATA REQ Primitive from the ASP to send to SGP.
Check A: 3 CODT messages should be received at the SGP.
Check B: CODA message should be received at ASP with
sequence Ref. number "A + 2".
Anjali Gurmukhani, HSS [Page 144]
Internet Draft SUA Conformance Test Plan Aug 2003
"Missequencing in Protocol Class 3 for send Seq. Number"
+ TEST NUMBER: CO_8
+ PURPOSE: To check that in case of protocol class 3 if mis-
sequencing Occurs, for send Seq. Number, then the connection
is reset by peer.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
CODT ------------>
(Send Seq. Number 2) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
CODT ------------>
(Send Seq. Number 4) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
---------> Error
Anjali Gurmukhani, HSS [Page 145]
Internet Draft SUA Conformance Test Plan Aug 2003
N-RESET IND <------------- RESRE
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 1 to the SGP Side.
4. Send CODT message with Seq. number 2 to the SGP Side.
Check A: CODT message should be received at the SGP.
5. Send CODT message with Seq. number 4 to the SGP Side.
Check A: CODT message should be received at the SGP.
Check B: RESRE Message should be received at the ASP side.
Check C: Reset Indication is given to SU.
Anjali Gurmukhani, HSS [Page 146]
Internet Draft SUA Conformance Test Plan Aug 2003
"Missequencing in Protocol Class 3 for Recv Seq. Number"
+ TEST NUMBER: CO_9
+ PURPOSE: To check that in case of protocol class 3 if mis-
sequencing occurs, for receive Seq. Number, then the connection is
reset by peer.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
N-DATA IND<------------- CODT
(Send Seq. Number 0)
(recv Seq. Number 2)
Anjali Gurmukhani, HSS [Page 147]
Internet Draft SUA Conformance Test Plan Aug 2003
CODT ------------>
(Send Seq. Number 2) ---------> N-DATA IND
(recv Seq. Number 1) (Ref. number "A")
CODT ------------>
(Send Seq. Number 3) ---------> N-DATA IND
(recv Seq. Number 1) (Ref. number "A")
N-DATA IND<------------- CODT
(Send Seq. Number 1)
(recv Seq. Number 1)
ERROR<-----
RESRE------------> ---------> N-RESET IND
N-RESET CONFIRM<------------- RESCO
TEST DESCRIPTION:
1. Send CORE message from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
5. Send CODT message to the ASP Side.
Check A: CODT message should be received at the SGP.
Check B: Send Seq Number should be 0 and Recv. Seq. Number should be
2.
6. Send CODT message with Seq. number 2 to the SGP Side.
7. Send CODT message with Seq. number 3 to the SGP Side.
8. Send CODT message to the ASP Side, with RECV SEQ NUMBER AS 1.
Check A: peer should reset Connection.
Anjali Gurmukhani, HSS [Page 148]
Internet Draft SUA Conformance Test Plan Aug 2003
"Credit parameter negotiation in Protocol Class 3"
+ TEST NUMBER: CO_10
+ PURPOSE: To check the credit parameter negotiation in case
of protocol class 3.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(credit size 110)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(credit size 100) (credit size 100)
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
TEST DESCRIPTION:
1. Send N-CONNECT REQ(with credit size as 110) Primitive from
the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK(with a different credit value than what is received,
credit = 100) message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
Anjali Gurmukhani, HSS [Page 149]
Internet Draft SUA Conformance Test Plan Aug 2003
2. Send CODT(with Sequence number 1) message from the ASP to send to
SGP.
Check A: CODT message should be received at the SGP.
Note: Repeat the above test case when the size of credit as sent by
the SGP is less and as returned by the peer is more.
Anjali Gurmukhani, HSS [Page 150]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connection Oriented Inactivity test in Protocol Class 3"
+ TEST NUMBER: CO_11
+ PURPOSE: To check the Connection Oriented Inactivity test
procedures in Protocol Class 3.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
<<<< No Data transfer for "T(ias),Inactivity Send timer= 7 minutes"
>>>>>
<------------- COIT
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message to the SGP.
Check A: COAK message should be received at the SGP.
Anjali Gurmukhani, HSS [Page 151]
Internet Draft SUA Conformance Test Plan Aug 2003
3. Send CODT message to the SGP.
Check A: CODT message should be received at the SGP.
4. Send No Data for the inactivity Send Timer interval = 7 Minutes.
Check A: COIT message should flow from the SGP to the ASP.
Anjali Gurmukhani, HSS [Page 152]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connection Oriented Inactivity test invalid parameters
in Protocol Class 3"
+ TEST NUMBER: CO_12
+ PURPOSE: To check the Invalid Connection Oriented Inactivity test
procedures in Protocol Class 3.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
COIT ------------>
(Source ref. number "B")
---------> Error
N-RELEASE IND<------------- RELRE
TEST DESCRIPTION:
Anjali Gurmukhani, HSS [Page 153]
Internet Draft SUA Conformance Test Plan Aug 2003
1. Send N-CONNECT REQ(with credit size as 100) Primitive from
the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
4. Send a COIT message with an invalid value of Dest. ref. number
(ref. number B).
Check A: peer should Release Connection. A RELCO Message should
be received.
The above Test case should be carried for Protocol class "2" and "3"
for the following parameters
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
parameter Behavior to be observed
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Source Reference Number Connection Released by Peer.
Protocol Class Connection Released by Peer.
Sequence Number(only in protocol class 3)Connection Reset by Peer.
Credit(only in protocol class 3) Connection Reset by Peer.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Anjali Gurmukhani, HSS [Page 154]
Internet Draft SUA Conformance Test Plan Aug 2003
"No Response to RELRE Message"
+ TEST NUMBER: CO_13
+ PURPOSE: To check that if a RELRE message is sent and is not
responded with, it will retry a number of times and then release
the connection.
+ TEST CONFIGURATION: A.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
---------> N-DATA IND
(ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
<--------- N-DISCONNECT REQ
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
Anjali Gurmukhani, HSS [Page 155]
Internet Draft SUA Conformance Test Plan Aug 2003
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
N-DISCONNECT IND<------------- RELCO (Source ref. number "A")
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message from the ASP to send to SGP.
Check A: CODT message should be received at the SGP for
Source Ref. number "A".
3. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to
ASP.
Check A: RELRE message should be received at the ASP.
Check B: No RELCO message MUST be sent to the SGP.
Check C: The RELRE message is retransmitted a number of times,
till the inactivity timer expires and a RELCO message
is sent.
Anjali Gurmukhani, HSS [Page 156]
Internet Draft SUA Conformance Test Plan Aug 2003
"Protocol Class negotiation"
+ TEST NUMBER: CO_14
+ PURPOSE: To check the protocol Class negotiation procedures in
SUA.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Protocol Class 2) (Protocol Class 2)
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
<------------- CODA
TEST DESCRIPTION:
1. Send N-CONNECT REQ(with protocol class 3) Primitive from the
NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message(with protocol class 2) from the ASP to send to
SGP.
Anjali Gurmukhani, HSS [Page 157]
Internet Draft SUA Conformance Test Plan Aug 2003
Check A: COAK message with protocol class 2, should be received at
the SGP.
3. Send CODT message from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODA message should be received at ASP.
Anjali Gurmukhani, HSS [Page 158]
Internet Draft SUA Conformance Test Plan Aug 2003
"Connection refusal due to Route on DPC+SSN FAILURE,
no SSN available"
+ TEST NUMBER: CO_15
+ PURPOSE: To check that when routing is DPC+SSN based, and
the peer fails to locate a user, a COREF message is sent back.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.Also arrange
the data in SGP such that NIF sends Connect- Req primitive to SUA
with Routing Context A, containing protocol class "2/3" to be sent
to DPC "X" and SSN "Y". No user should be registered with the SSN
"Y" on the ASP side.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-CONNECT REQ
(Route on DPC+SSN)
<------------- CORE
(Route on DPC+SSN)
<------------
ERROR(no SSN found)
COREF ------------->
(Route on DPC+SSN FAILURE)---------> N-DISCONNECT IND
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to
DPC "X" and SSN "Y".
Check A: CORE message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: A COREF Message should be sent back with appropriate error
code, indicating no user with the desired SSN exists.
Anjali Gurmukhani, HSS [Page 159]
Internet Draft SUA Conformance Test Plan Aug 2003
"Reset Connection procedures in Protocol Class 3"
+ TEST NUMBER: CO_16
+ PURPOSE: To check that in case of protocol class 3, Connection
can be reset by the user.
+ TEST CONFIGURATION: A.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams). ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
<------------- CODA
<--------- N-RESET REQ
N-RESET IND <------------- RESRE (Source ref. number "A")
(Protocol Class 3)
RESCO------------>
(Dest ref. number "A") ---------> N-RESET CONFIRM IND
TEST DESCRIPTION:
Anjali Gurmukhani, HSS [Page 160]
Internet Draft SUA Conformance Test Plan Aug 2003
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ(with Sequence number 1) Primitive from
the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODA message should be received at ASP with Source
Ref. number "A".
4. Send N-RESET REQ Primitive from the SGP to send to ASP.
Check A: RESRE message should be received at the ASP.
5. Send RESCO message from the ASP to send to SGP.
Check B: RESCO Message should be received at the SGP side.
Anjali Gurmukhani, HSS [Page 161]
Internet Draft SUA Conformance Test Plan Aug 2003
"Missequencing in Protocol Class 3 for Recv Seq. Number"
+ TEST NUMBER: CO_17
+ PURPOSE: To check that in case of protocol class 3 if mis-
sequencing occurs, for recv Seq. Number, then the connection is
reset by peer.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the same
MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM
IND
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
N-DATA IND<------------- CODT
(Send Seq. Number 0)
(recv Seq. Number 2)
Anjali Gurmukhani, HSS [Page 162]
Internet Draft SUA Conformance Test Plan Aug 2003
CODT ------------>
(Send Seq. Number 2) ---------> N-DATA IND
(recv Seq. Number 1) (Ref. number "A")
CODT ------------>
(Send Seq. Number 3) ---------> N-DATA IND
(recv Seq. Number 1) (Ref. number "A")
N-DATA IND<------------- CODT
(Send Seq. Number 1)
(recv Seq. Number 1)
ERROR<-----
RESRE------------> ---------> N-RESET IND
N-RESET Ind<------------- RESRE
RESCO ------------------> Reset Confirm Indication
TEST DESCRIPTION:
1. Send CORE message from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
5. Send CODT message to the ASP Side.
Check A: CODT message should be received at the SGP.
Check B: Send Seq Number should be 0 and Recv. Seq. Number should be
2.
6. Send CODT message with Seq. number 0 to the SGP Side.
7. Send CODT message with Seq. number 1 to the SGP Side.
8. Send CODT message to the ASP Side, with RECV SEQ NUMBER AS 1.
Check A: peer should reset Connection.
Anjali Gurmukhani, HSS [Page 163]
Internet Draft SUA Conformance Test Plan Aug 2003
"Missequencing in Protocol Class 3 for Recv Seq. Number,
in CODA message"
+ TEST NUMBER: CO_18
+ PURPOSE: To check that in case of protocol class 3 if mis-
sequencing occurs, for recv Seq. Number, then the connection
is reset by peer.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(Credit 2)
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Credit 2)
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
Anjali Gurmukhani, HSS [Page 164]
Internet Draft SUA Conformance Test Plan Aug 2003
<------------- CODA
(Send Seq. Number 0)
(recv Seq. Number 1)
<------------- CODA
(Send Seq. Number 1)
(recv Seq. Number 1)
ERROR<-----
RESRE------------> ---------> N-RESET IND
N-RESET CONFIRM<------------- RESCO
TEST DESCRIPTION:
1. Send CORE message from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
Check A: CODA Message with Send Seq. Number 0 and recv Seq
number 1 should be received.
5. Send CODA message to the ASP Side, with Send Seq. Number as 1
and recv Seq. number as 1.
Check A: Connection should be reset by peer.
Anjali Gurmukhani, HSS [Page 165]
Internet Draft SUA Conformance Test Plan Aug 2003
"Missequencing in Protocol Class 3 for Send Seq. Number,
Outside Rx Window"
+ TEST NUMBER: CO_19
+ PURPOSE: To check that in case of protocol class 3 if mis-
sequencing occurs, for send Seq. Number, then the connection is
reset by peer.
+ TEST CONFIGURATION: A.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(Credit 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Credit 3)
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
CODT ------------>
(Send Seq. Number 10) ---------> Error
(recv Seq. Number 0)
N-RESET IND<------------- RESRE (Source ref. number "A")
Anjali Gurmukhani, HSS [Page 166]
Internet Draft SUA Conformance Test Plan Aug 2003
RESCO------------> ---------> N-RESET CONFIRM IND
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
5. Send CODT message with Seq. number 10 to the SGP Side.
Check A: The Connection is reset by peer.
Anjali Gurmukhani, HSS [Page 167]
Internet Draft SUA Conformance Test Plan Aug 2003
6.6 SCTP Connection Management
"SCTP Connection Establishment"
+ TEST NUMBER : SCM_1
+ PURPOSE: To check that on receiving M-SCTP-Establish primitive from
SM, ASP initiates and establishes an SCTP association with the SGP.
+ TEST CONFIGURATION: A/G
+ PRE-TEST CONDITIONS: SCTP association is not established between SGP
and ASP. Also arrange the data in ASP such that SM sends
M-SCTP-Establish primitive to SUA with the SGP id to which the
connection is to be established.
EXPECTED MESSAGE SEQUENCE:
SGP ASP SU + SM
<--------- M-SCTP-Establish Request
<------------------->
SCTP association will be established by SCTP
ASP will receive Communication-Up primitive from SCTP
M-SCTP-Establish Ind------->
TEST DESCRIPTION:
1. Send M-SCTP-Establish Request Primitive from the SM at ASP side to
establish an SCTP association with the SGP.
2. Check A: SCTP association will be established and M-SCTP-Establish
indication will be received at the SM.
Anjali Gurmukhani, HSS [Page 168]
Internet Draft SUA Conformance Test Plan Aug 2003
"SCTP Connection Termination"
+ TEST NUMBER: SCM_2
+ PURPOSE: To check that on receiving SCTP-Communication Down
indication primitive from SCTP, ASP will send the M-SCTP Status
primitive to the upper layer.
+ TEST CONFIGURATION: A/G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. ASP is in Inactive state. Also arrange the data in SGP such that
SCTP association is terminated between SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM + SU
ASP is Inactive
<-------------- ASPDN
ASP-Down-Ack -------------->
SCTP association is terminated
ASP will receive Communication-Down primitive from SCTP
M-SCTP Status -------->
<-------- Unitdata
Send Failure --------->
TEST DESCRIPTION:
1. Terminate the association between SGP and ASP.
Check A: SCTP association will be down and on receiving
Communication Down primitive from SCTP, M-SCTP Status indication
will be received at the SM.
Check B: State of ASP will be down. Send Unitdata primitive from
the SU to send some Protocol DATA. ASP will report send failure.
Anjali Gurmukhani, HSS [Page 169]
Internet Draft SUA Conformance Test Plan Aug 2003
Note: It may be possible that SCTP connection is terminated without
exchanging the ASPDN message.
Anjali Gurmukhani, HSS [Page 170]
Internet Draft SUA Conformance Test Plan Aug 2003
"SCTP Connection Restart"
+ TEST NUMBER : SCM_3
+ PURPOSE: To check that on receiving SCTP-Communication Restart
Indication primitive from SCTP, ASP will send the M-SCTP Status
primitive to the upper layer.
+ TEST CONFIGURATION: A/G
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. ASP is in active state. Also arrange in SGP such that SCTP
association is restarted between SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM + SU
ASP is active
ASP will receive Communication-Restart Primitive from SCTP
M-SCTP Status -------->
Status Ind --------> ASP Down
N-PCState Ind -------->
(PC Z)
<-------- Unitdata
Send Failure --------->
TEST DESCRIPTION:
1. Invoke a Connection Restart on the association between SGP and ASP.
Check A: SCTP association will be restarted and on receiving
Communication Restart primitive from SCTP, M-SCTP Status indication
and an ASP Status Ind will be received at the SM.
Check B: State of ASP will be Down. Send Unitdata primitive from
the SU to send some Protocol DATA. ASP will report send failure.
Anjali Gurmukhani, HSS [Page 171]
Internet Draft SUA Conformance Test Plan Aug 2003
"SCTP Connection Establishment"
+ TEST NUMBER : SCM_4
+ PURPOSE: To check that on receiving Communication Up primitive from
SCTP, SG SUA will send M-SCTP-Establish indication to the SM.
+ TEST CONFIGURATION: A/G
+ PRE-TEST CONDITIONS: SCTP association is not established between SGP
and ASP1. Also arrange the data in ASP such that SCTP association is
established between ASP1 and SGP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
SCTP Establish request to SCTP
SCTP association will be established by SCTP
ASP will receive Communication-Up primitive from SCTP
M-SCTP-Establish Ind ------->
<--------- ASP-UP
<------------------ ASPUP
ASP-Up-Ack ------------------>
NTFY ------------------>
(AS-Inactive)
Status Ind --------->
Anjali Gurmukhani, HSS [Page 172]
Internet Draft SUA Conformance Test Plan Aug 2003
TEST DESCRIPTION:
1. Make an SCTP association between SGP and ASP. ASP will receive
Communication Up primitive from SCTP.
2. Check A: SM receives M-SCTP-Establish indication.
3. Send ASPUP message from ASP to SGP.
4. Send ASP-Up-Ack and NTFY message with status ASP-Inactive from
the SGP.
5. Check B: Status Ind for ASP State as Inactive is received at SM.
Anjali Gurmukhani, HSS [Page 173]
Internet Draft SUA Conformance Test Plan Aug 2003
7 Acknowledgements
The authors would like to thank Anshoo Sharma, Akhtar Iqbal,Kamesh
Kaul, Yogesh Gahlaut, Manish Rajpal, Sandeep Mahajan for their
insightful comments and suggestions.
Funding for the RFC editor function is currently provided by the
Internet Society.
Anjali Gurmukhani, HSS [Page 174]
Internet Draft SUA Conformance Test Plan Aug 2003
8 Authors' Addresses
Anjali Gurmukhani
Plot-17,Hughes Software Systems
Electronic city,Gurgaon.
India.
Email_id:agurmukhani@hss.hns.com
anj_gur@yahoo.com
Dipak Aggarwal
Hughes Software Systems
Electronic City,Gurgaon
India
Email_id:diaggarwal@hss.hns.com
9 References
[2960] RFC 2960 "Stream Control Transmission Protocol" R.
Stewart, et al, November 2000.
[ITU SCCP] ITU-T Recommendations Q.711-714, 'Signaling System
No. 7 (SS7) - Signaling Connection Control Part
(SCCP)'
[SUA] SCCP-User Adaptation Layer <draft-ietf-sigtran-sua-
15.txt>
[SUA-CONF] Test Specification for SUA <draft-diaggarwal-
sigtran-sua-conformance-00.txt>
[M3UA-CONF] Test Specification for MTP3 User Adaptation <draft-
anshoo-test-spec-m3ua-01.txt>
Anjali Gurmukhani, HSS [Page 175]
Internet Draft SUA Conformance Test Plan Aug 2003
Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
Be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Anjali Gurmukhani, HSS [Page 176]
|
Documentation