INTERNET-DRAFT Manish Sharma
Hughes Software Systems
Issued: Oct 2003
Expires: May 2004
Test Specification for MTP2 User Adaptation
<draft-sharmam-test-spec-m2ua-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.
Abstract
This document presents the test specifications for M2UA (MTP2 User
Adaptation) protocol (RFC 3331), which can be used to test M2UA
implementations for conformance to the protocol definition. The list of
test is exhaustive and covers almost all the categories of test.
This draft can also be used in conjunction with M2UA specification by
implementers of protocol as implementers guide, as the pictorial
representation of various scenarios help easy understanding of the
Manish Sharma, HSS [Page 1]
Internet Draft M2UA Conformance Test Plan Oct 2003
protocol. Next revision of the draft will cover the additions done to
the protocol revision and any subsequent RFC published by IETF.
Table of Contents
1. Introduction...................................................3
1.1 Terms Used...................................................3
2. General Principles of M2UA Tests...............................5
2.1 Presentation of test descriptions............................5
3. Test Configurations............................................6
3.1 Presentation of test Configurations..........................6
3.2 Configuration for testing the M2UA at SGP....................6
3.3 Configuration for testing the M2UA at ASP....................9
4. Test Cases for Testing M2UA at SGP........................... 9
4.1 Layer Management Messages................................... 9
4.2 ASPM Messages...............................................15
4.3 MGMT Messages...............................................45
4.4 MAUP Messages.............................................. 83
5. Test Cases for Testing M2UA at ASP...........................110
5.1 Layer Management Messages .................................110
5.2 ASPM Messages..............................................113
5.3 MGMT Messages..............................................123
5.4 MAUP Messages..............................................140
6. Interface Identifier Management Messages.....................151
7. Acknowledgements.............................................160
8. Authors' Addresses...........................................161
9. References...................................................161
Manish Sharma, HSS [Page 2]
Internet Draft M2UA Conformance Test Plan Oct 2003
1. Introduction
The M2UA is a protocol for the transport of any SS7 MTP2-User signaling
(e.g. MTP3 messages) over IP using the Stream Control Transport
protocol(SCTP) or any other suitable transport protocol. This protocol
would be used between a Signaling Gateway (SG) and an Application
server process(ASP)(e.g. Media Gateway Controller - MGC) or IP-resident
Database.
1.1 Terms Used
Application Server (AS) - A logical entity serving a specific
application instance. An example of an Application Server is a MGC
handling the MTP Level 3 and call processing for SS7 links terminated
by the Signaling Gateways. Practically speaking, an AS is modeled at
the SG as an ordered list of one or more related Application Server
Processes (e.g., primary, secondary, tertiary,..).
Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup
MGC instances.
Association - An association refers to a SCTP association. The
association will provide the transport for the delivery of protocol
data units for one or more interfaces.
Backhaul - Refers to the transport of signaling from the point of
interface for the associated data stream (i.e., SG function in the MGU)
back to the point of call processing (i.e., the MGCU), if this is not
local.
Fail-over - The capability to re-route signaling traffic as required to
an alternate Application Server Process within an Application Server in
the event of failure or unavailability of a currently used
Application Server Process. Fail-back MAY apply upon the return to
service of a previously unavailable Application Server Process.
Host - The computing platform that the ASP process is running on.
Manish Sharma, HSS [Page 3]
Internet Draft M2UA Conformance Test Plan Oct 2003
Interface - For the purposes of this document, an interface is a SS7
signaling link.
Interface Identifier - The Interface Identifier identifies the physical
interface at the SG for which the signaling messages are sent/received.
The format of the Interface Identifier parameter can be text or
integer, the values of which are assigned according to network operator
policy. The values used are of local significance only, coordinated
between the SG and ASP.
Layer Management (LM)- Layer Management is a nodal function in an SG or
ASP that handles the inputs and outputs between the M2UA layer and a
local management entity.
Link Key - The link key is a locally unique (between ASP and SG) value
that identifies a registration request for a particular Signaling Data
Link and Signaling Terminal pair.
MTP - The Message Transfer Part of the SS7 protocol.
MTP2 - MTP Level 2, the signaling datalink layer of SS7
MTP3 - MTP Level 3, the signaling network layer of SS7.
MTP2-User - A protocol that uses the services of MTP Level 2(i.e.
MTP3).
Network Byte Order: Most significant byte first, a.k.a. Big Endian.
Signaling Link Terminal (SLT) - Refers to the means of performing all
of the functions defined at MTP level 2 regardless of their
implementation[2].
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 unordered delivery service.
Signaling Gateway Process (SGP) - A process instance of a Signaling
Gateway. It serves as an active, backup, load-sharing or broadcast
Manish Sharma, HSS [Page 4]
Internet Draft M2UA Conformance Test Plan Oct 2003
process of a Signaling Gateway.
Signaling Gateway - An SG is a signaling agent that receives/sends SCN
native signaling at the edge of the IP network [1]. An SG appears to
the SS7 network as an SS7 Signaling Point. An SG contains a set of one
or more unique Signaling Gateway Processes, of which one or more is
normally actively processing traffic. 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.
ASPSM, ASPTM, SSNM - ASP State Maintenance Messages, ASP Traffic
Maintenance Messages, Signaling System Network Management Messages.
2. General Principles of M2UA 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.
2.1 Presentation of test descriptions
Each test description includes the environment in which the point under
test must be inserted in order to pass the test. The test
configurations are defined (named A, B, C, D, E); 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
Manish Sharma, HSS [Page 5]
Internet Draft M2UA Conformance Test Plan Oct 2003
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. And where SM is written, it means LM+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".
3.1 Presentation of test configurations:
There are different configurations for testing the M2UA protocol. These
configurations and hence test cases have been divided on the basis of
M2UA at SG and M2UA at ASP.
3.2 Configuration for testing the M2UA at SGP:
3.2.1 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 Interface Identifier X and Y.
AS is having only one ASP ASP1.
Manish Sharma, HSS [Page 6]
Internet Draft M2UA Conformance Test Plan Oct 2003
SG
+-------------+ +--------------+
| SGP | | AS |
| under Test | | -------- |
| |-------------------------------|--| ASP1 | |
| | | -------- |
+-------------+ +--------------+
Fig 1: Configuration A
3.2.2 Configuration B:
This configuration is used for all the procedures of tests concerning
one ASP in two AS which are handling traffic for different interface
identifiers. Configuration B is shown in figure 2. AS1 is handling the
traffic for Interface Identifier X and Y. AS2 is handling the traffic
for Interface Identifier P and Q. ASP1 is in both AS.
+----------------------+
| AS1 |
SG | |
+-------------+ | +----------------+ |
| | | | ------- | |
| |--------------------------|--|--| ASP1 | | |
| SGP | | | ------- | |
| Under Test | +--|----------------|--+
| | | AS2 |
+-------------+ +----------------+
Fig 2: Configuration B
3.2.3 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
Manish Sharma, HSS [Page 7]
Internet Draft M2UA Conformance Test Plan Oct 2003
handling the traffic for Interface Identifier X and Y. ASP1 and ASP2
are in Over-ride mode of traffic handling.
+--------------+
SG | AS |
+-------------+ | ------- |
| |-------------------------------|-| ASP1 | |
| SGP | | ------- |
| Under Test | | ------- |
| | | | ASP2 | |
| |-------------------------------|- ------- |
+-------------+ +--------------+
Fig 3: Configuration C
3.2.4 Configuration D:
This configuration is used for all the procedures of tests concerning
two or more AS which are handling traffic for different interface
identifiers. Configuration D is shown in figure 4. AS1 is handling the
traffic for Interface Identifier X and Y. AS2 is handling the traffic
for Interface Identifier P and Q. AS3 for Interface Identifier S, T.
ASP1 is in AS1 and ASP2 is in AS2 and ASP3 in AS3.
+--------------+
SG | AS1 |
+-------------+ | ------- |
| |-------------------------------| | ASP1 | |
| SGP | | ------- |
| Under Test | +--------------+
| | +--------------+
| |-------------------------------| AS2 |
| |-------+ | ------- |
+-------------+ | | | ASP2 | |
| | ------- |
| +--------------+
| +--------------+
| | AS3 |
+-----------------------|- ------- |
| | ASP3 | |
| ------- |
+--------------+
Fig 4: Configuration D
Manish Sharma, HSS [Page 8]
Internet Draft M2UA Conformance Test Plan Oct 2003
3.3 Configuration for testing the M2UA at ASP
3.3.1 Configuration E:
This simple configuration is used for all the procedures of tests
concerning only one SG. Configuration E is shown in figure 5. ASP1 is
handling the traffic for Interface Identifier X and Y.
+-------------+ +--------------+
| ASP1 | | SGP |
| under Test | | |
| |-------------------------------| SG |
| | | |
+-------------+ +--------------+
Fig 5: Configuration E
The above conditions with each Test Configuration are meant only to be
the Default conditions in case no specific conditions are mentioned.
4. Test Cases for Testing M2UA at SGP
4.1 Layer Management Messages
4.1.1 SCTP Connection Management
"SCTP Connection Management"
+ TEST NUMBER : 4.1.1
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Establishment
+ PURPOSE: To check that on receiving Communication Up primitive
from SCTP, SGP-M2UA will send M-SCTP-Establish indication to the
SM.
Manish Sharma, HSS [Page 9]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is not established between
SGP and ASP. ASP is acting as client and SGP as server.
Let the SM at ASP send M-SCTP-ESTABLISH request to M2UA at ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
SCTP_ASSOCIATE request sent to SCTP from M2UA at ASP.
SCTP association established between ASP and SGP.
SGP M2UA will receive SCTP-Communication_Up Primitive from SCTP.
M-SCTP_Establish Indication--------->
ASPUP --------------->
State Ind --------------->
(ASP-Up)
<-------------------- ASPUP-Ack
<-------------------- NTFY(AS-Inactive)
TEST DESCRIPTION:
1. Make an SCTP association between ASP and SGP.
SGP M2UA will receive Communication Up primitive from SCTP.
2. Check A: M-SCTP-Establish indication will be sent to the SM.
3. To check association is established correctly, send ASPUP message
from ASP to SGP.
4. Check B: ASP-Up-Ack and NTFY message with status AS-Inactive should
be received at the ASP.
Manish Sharma, HSS [Page 10]
Internet Draft M2UA Conformance Test Plan Oct 2003
"SCTP Connection Management"
+ TEST NUMBER : 4.1.2
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Status
+ PURPOSE: To check on receiving M-SCTP_STATUS request from SM,
M2UA will send the M-SCTP_STATUS Indication primitive to SM at SGP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP. ASP is active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
<-------------- M-SCTP_STATUS Request
M-SCTP_STATUS Ind ------------------->
TEST DESCRIPTION:
1. Let the SM at SGP send M-SCTP_STATUS request to M2UA at SGP.
2. Check A: M-SCTP_STATUS Indication will be received at SM indicating
the SCTP Status.
Manish Sharma, HSS [Page 11]
Internet Draft M2UA Conformance Test Plan Oct 2003
"SCTP Connection Management"
+ TEST NUMBER : 4.1.3
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Termination
+ PURPOSE: To check that on receiving SCTP-Communication Down
Indication (SCTP CDI) primitive from SCTP in case of a graceful
-shutdown, the SGP will send the M-SCTP Status primitive to the SM.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP and ASP is active. Let the SM at ASP send
M-SCTP_RELEASE request to M2UA at ASP. M2UA will send SCTP_SHUTDOWN
primitive to local SCTP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
SCTP association terminated.
M2UA at SGP will receive SCTP CDI(SCTP-SHUTDOWN_COMPLETE) from SCTP
at SGP.
M-SCTP release Indication(to SM) ------>
M-SCTP_Status Ind--------->
M-ASP_Status Ind------------>
(ASP Down)
M-AS_Status Ind------------->
(AS-Pending)
<-------- Data
Send Failure --------------->
Manish Sharma, HSS [Page 12]
Internet Draft M2UA Conformance Test Plan Oct 2003
TEST DESCRIPTION:
1. Terminate the association between SGP and ASP.
2. Check A: SCTP association will be down and on receiving
SCTP-SHUTDOWN_COMPLETE(Communication Down Indication)from SCTP,
M-SCTP Status indication will be received at SM.
3. Check B: State of AS will be pending for T(r) time and will become
AS-Down after the expiry of the timer T(r).
4. Check C: State of ASP will be down at the SG. Send data primitive
from the NIF to send some Protocol DATA. SGP will report send
failure.
5. Repeat the test for Inactive state of ASP including only Check A and
Check C.
"SCTP Connection Management"
+ TEST NUMBER : 4.1.4
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Termination
+ PURPOSE: To check that on receiving SCTP-Communication Down
Indication (SCTP CDI) primitive from SCTP for an ungraceful
shutdown, M2UA at SGP will change the state of ASP to ASP-DOWN.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
Manish Sharma, HSS [Page 13]
Internet Draft M2UA Conformance Test Plan Oct 2003
SCTP at SGP detects loss of Communication with peer SCTP
M2UA at SGP will receive SCTP CDI(SCTP-COMMUNICATION_LOST)from SCTP
At SGP
M-SCTP-Release Ind---------------->
M-ASP-Status--------->
(ASP Down)
M-AS-Status---------->
(AS-Pending )
<------------------- Data
Send Failure --------------->
TEST DESCRIPTION:
1. Make SCTP at SGP send SCTP CDI to M2UA at SGP by letting it detect
loss of Communication with peer SCTP.
2. Check A: M-SCTP_Status indication will be received at SM.
3. Check B: State of AS will be pending for T(r) time and will become
AS-Down after the expiry of the timer T(r).
4. Check C: State of ASP will be down at the SG. Send data primitive
from the NIF to send some Protocol DATA.SGP will report send
failure.
5. Repeat the test for ASP in Inactive state including only Check A and
Check C.
"SCTP Connection Management"
+ TEST NUMBER : 4.1.5
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Restart
Manish Sharma, HSS [Page 14]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ PURPOSE: To check that on receiving SCTP-RI indication primitive
from SCTP, M2UA at SG will change the state of ASP to ASP-DOWN.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP is active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
SCTP at SGP detects a restart from ASP's peer SCTP Layer
SCTP at SGP sends an SCTP RI to M2UA at SGP
ASP Status Ind--------->
(ASP Down)
AS Status Ind --------->
(AS-Pending)
Timer T(r) expires
AS Status Ind --------->
(AS-Down)
<-------- Data
Send Failure --------------->
TEST DESCRIPTION:
1. Make the SCTP at SGP send an SCTP RI to M2UA at SGP by letting it
detect a restart from Asp's peer SCTP Layer.
2. Check A: ASP Down Status indication will be received at SM. AS-
Pending Status Indication will be received at SM and after the
expiry of Timer T(r) AS-Down Status indication will be received at
SM.
Manish Sharma, HSS [Page 15]
Internet Draft M2UA Conformance Test Plan Oct 2003
3. Check B: State of ASP will be down at the SGP. Send data primitive
from the NIF to send some Protocol DATA.
SGP will report send failure.
4. Repeat the test for ASP in Inactive state including Check A and
Check B. There will not be any Timer expiry in this case, the state
of AS will be directly changed to AS-Down.
4.2 ASPM Messages
4.2.1 ASPSM and ASPTM Messages
"Heartbeat and Heartbeat Ack"
+ TEST NUMBER :4.2.1
+ TITLE : Heartbeat Message
+ SUBTITLE : Heartbeat Message
+ PURPOSE: To check that if an ASP sends Heartbeat Messages (to
ensure that the M2UA peers are still available to each other) , SGP
sends Heartbeat Ack to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. ASP is configured as the Client.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
BEAT ----------------->
Timer 2*T(beat) is Started
|
|
|
<------------------ BEAT Ack
Manish Sharma, HSS [Page 16]
Internet Draft M2UA Conformance Test Plan Oct 2003
BEAT ----------------->
Timer 2*T(beat) is Started
|
|
|
Timer 2*T(beat) expires
TEST DESCRIPTION:
1. Send BEAT message from ASP to SGP.
2. Check A: A BEAT Ack will be receive at the ASP before the Timer
T(beat) expires.
3. Send BEAT message again from ASP to SGP and restrict the BEAT Ack
from SGP.
4. Check B: No BEAT Ack is received while Timer T(beat) is running.
5. Check C: After Timer T(beat) expires Transmission of BEAT message
stops and the Signaling Process will attempt to re-establish
communication.
6. Repeat the above Test case when the BEAT message is sent by SGP.
Results will be analogous.
Note: The Signaling Process at an M2UA peer will attempt re-
establishment of communication only if it is configured as the Client
for the disconnected M2UA peer.
"ASPM messages"
+ TEST NUMBER :4.2.1
+ TITLE : ASPUP messages
+ SUBTITLE : ASPUP messages when SGP has locked the ASP for
Manish Sharma, HSS [Page 17]
Internet Draft M2UA Conformance Test Plan Oct 2003
Management reasons.
+ PURPOSE: To check that if ASPUP message is received when SGP has
locked the ASP for management reason then error
(Refused-Management Blocking) is sent to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Down.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Down
<-------- Lock AS
ASPUP --------------->
<-------- Error
(Cause - Refused-Management Blocking)
<-------- UnLock ASP
ASPUP --------------->
Status Ind.----------------->
(ASP Inactive)
<-------- ASPUP-Ack
<-------- NTFY(AS-Inactive)
TEST DESCRIPTION:
1. Lock out the ASP at the SGP by sending primitive for locking ASP
from SM. Now send ASPUP message with valid parameters from ASP to
SGP on SCTP Stream 0.
2. Check A: Error(Cause = Refused-Management Blocking)is received at
ASP.
3. UnLock out the ASP at the SGP by sending primitive for un-locking
ASP from SM. Now send ASPUP message with valid parameters from ASP
Manish Sharma, HSS [Page 18]
Internet Draft M2UA Conformance Test Plan Oct 2003
to SGP on SCTP Stream 0.
4. Check B: ASPUP-Ack will be received at ASP.
5. Check C: A NTFY message with Status AS-Inactive is received at ASP.
"ASPM messages"
+ TEST NUMBER : 4.2.2
+ TITLE : ASPUP messages
+ SUBTITLE : ASPUP messages when SGP doesn't send ASPUP-Ack.
+ PURPOSE: To check that if ASPUP message is received at SGP
and it does not send the ASPUP-Ack, then ASP re-tries it.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Down.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Down
ASPUP --------------->
T(ack) expires
ASPUP --------------->
T(ack) expires
n-1 tries....
ASPUP --------------->
Manish Sharma, HSS [Page 19]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP State Ind---------->
AS State Ind----------->
<----------------ASPUP-Ack
<----------------NTFY(AS-Inactive)
TEST DESCRIPTION:
1. Send ASPUP message with valid parameters from ASP to SGP on SCTP
Stream 0 and restrict ASPUP-Ack from SGP to ASP.
2. Check A: ASPUP message is received at SGP repeatedly.
3. Don't restrict ASPUP-Ack from SGP to ASP for the next ASPUP message
from ASP.
4. Check B: ASPUP-Ack, NTFY(AS-Inactive), will be received at ASP.
5. Check C: ASP State Ind, AS-State Ind will be received at SM of SGP.
Note: Number of repetitions are implementation dependent.
Manish Sharma, HSS [Page 20]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Duplicate Message Handling"
+ TEST NUMBER :4.2.3
+ TITLE : ASPUP messages
+ SUBTITLE : ASPUP message when ASP is in ASP-Inactive state at SGP
+ PURPOSE: To check that if ASPUP message is received when ASP is in
ASP-Inactive state at SGP then ASP-Up-Ack message is sent to the
ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Down.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Down
ASPUP --------------->
Status Ind --------------->
(ASP Inactive)
<--------------ASPUP-Ack
<--------------NTFY(AS-Inactive)
ASPUP --------------->
<--------------ASPUP-Ack
ASPAC --------------->
Status Ind --------------->
(ASP Active)
<--------------ASPAC-Ack
<--------------NTFY(AS-active)
Manish Sharma, HSS [Page 21]
Internet Draft M2UA Conformance Test Plan Oct 2003
TEST DESCRIPTION:
1. Send ASPUP message to the SGP with ASP in ASP-Down state.
2. Check A: ASP-Up-Ack and NTFY message will come from the SGP with
status AS-Inactive.
3. Send ASPUP message again from the ASP.
4. Check B: ASP-Up-Ack message will be received at the ASP.
5. Check C: State of ASP at SGP is not disturbed i.e. ASP remains in
the Inactive state. Send ASPAC message for the ASP, ASP-Active-Ack
and NTFY with AS-Active should come.
"Different Message Handling"
+ TEST NUMBER : 4.2.4
+ TITLE : ASPUP messages
+ SUBTITLE : ASPUP message when ASP is in ASP-Active state at SGP
+ PURPOSE: To check that if ASPUP message is received when ASP is in
ASP-Active state at SGP then ASPUP-Ack is sent to ASP and Error
message also sent to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPUP --------------->
<--------------Error
(Cause = Unexpected Message)
Manish Sharma, HSS [Page 22]
Internet Draft M2UA Conformance Test Plan Oct 2003
<--------------ASPUP-Ack
ASP state Ind --------------->
(ASP Inactive)
TEST DESCRIPTION:
1. Send ASPUP message to the SGP when ASP is in ASP-Active state.
2. Check A: Error message with Cause "Unexpected Message" should be
received at the ASP.
3. Check B: ASPAC-Ack message should be received at the ASP.
4. Check C: State of ASP at SGP changes to ASP-Inactive.
"ASPM messages"
+ TEST NUMBER : 4.2.5
+ TITLE : ASPDN messages
+ SUBTITLE : ASPDN messages when SGP doesn't send ASPDN-Ack.
+ PURPOSE: To check that if ASPDN message is received at SGP and it
does not send the ASPDN-Ack, then ASP re-tries it.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Inactive
Manish Sharma, HSS [Page 23]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASPDN --------------->
T(ack) expires
ASPDN --------------->
T(ack) expires
n-1 tries....
ASPDN --------------->
ASP State Ind---------->
AS State Ind----------->
<----------------ASPDN-Ack
<----------------NTFY(AS-Down)
TEST DESCRIPTION:
1. Send ASPDN message with valid parameters from ASP to SGP and dont
send(restrict) ASPDN-Ack from SGP to ASP.
2. Check A: ASPDN message is received at SGP repeatedly.
3. Don't restrict ASPDN-Ack from SGP to ASP for the next ASPDN message.
4. Check B: ASPDN-Ack, NTFY(AS-Down), will be received at ASP.
5. Check C: ASP State Ind, AS-State Ind will be received at SM of SGP.
6. Check D: A NTFY message with Status AS-Down is receivd at the ASP.
Note 1: Number of repetition is Implementation dependent.
Note 2: When the AS transitions to the AS down state, all the SS7 link
(Interface Identifier) for this AS should be taken out of service.
Manish Sharma, HSS [Page 24]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Duplicate Message Handling"
+ TEST NUMBER : 4.2.6
+ TITLE : ASPDN message
+ SUBTITLE : ASPDN message when ASP is in ASP-Down state at SGP
+ PURPOSE: To check that if ASPDN message is received when ASP is in
ASP-Down state at SGP then SGP sends an ASP-DN-Ack message to the
ASP and no further action is taken at SGP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Down.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Down
ASPDN --------------->
<--------------ASPDN-Ack
ASPUP --------------->
Status Ind. ------------>
<--------------ASPUP-Ack
<--------------NTFY(AS-Inactive)
TEST DESCRIPTION:
1. Send ASPDN message to the SGP when ASP is in ASP-Down state.
2. Check A: ASPDN-Ack will come from the SGP to ASP and no further
action will be taken.
3. Check B: The State of the ASP at SGP is not disturbed.
Manish Sharma, HSS [Page 25]
Internet Draft M2UA Conformance Test Plan Oct 2003
4. Now send ASPUP message from the ASP.
5. Check B: ASP-Up-Ack message and a NTFY message with Status AS-
Inactive will be received at the ASP.
"Different Message Handling"
+ TEST NUMBER : 4.2.7
+ TITLE : ASPDN message
+ SUBTITLE : ASPDN message when ASP is in ASP-Active state at SGP
+ PURPOSE: To check that if ASPDN message is received when ASP is in
ASP-Active state at SGP then ASPDN-Ack is sent to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPDN --------------->
ASP state Ind --------------->
(ASP Down)
AS state Ind --------------->
(AS-Pending)
<--------------ASPDN-Ack
<--------------NTFY(AS-Pending)
T(r) expires
AS State Ind --------------->
Manish Sharma, HSS [Page 26]
Internet Draft M2UA Conformance Test Plan Oct 2003
(AS-Down)
DATA --------------->
<--------------Error
(Unexpected Message)
TEST DESCRIPTION:
1. Send ASPDN message to the SGP with ASP is in ASP-Active state.
2. Check A: ASPDN-Ack, NTFY(AS-Pending) is received at ASP.
3. Check B: ASP State Ind, AS State Ind is received at SGP.
4. Send DATA from ASP to SGP after Timer T(r) expires.
5. Error message with parameter Unexpected message should be received
at the ASP.
Note: When the AS transitions to the AS down state, all the SS7 link
(Interface Identifier) for this AS should be taken out of service.
"ASPM messages"
+ TEST NUMBER : 4.2.8
+ TITLE : ASPAC messages
+ SUBTITLE : ASPAC message when ASP is in ASP-Inactive state at SGP
+ PURPOSE: To check that if ASPAC message is received at SGP with ASP
in ASP-Inactive state then ASPAC-Ack is sent to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
Manish Sharma, HSS [Page 27]
Internet Draft M2UA Conformance Test Plan Oct 2003
and ASP. ASP is Inactive.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Inactive
ASPAC --------------->
ASP State Ind --------------->
(ASP-active)
AS State Ind --------------->
(AS-active)
<--------------ASPAC-Ack
<--------------NTFY(AS-active)
TEST DESCRIPTION:
1. Send ASPAC message with Interface Identifiers X and Y to the SGP
with ASP in ASP-Inactive state.
2. Check A: ASPAC-Ack, NTFY(AS-active)message is received at the ASP.
3. Check B: State of ASP, AS at SGP is changed to active.
"ASPM messages"
+ TEST NUMBER : 4.2.9
+ TITLE : ASPAC messages
+ SUBTITLE : ASPAC messages when SGP doesn't send ASPAC-Ack.
+ PURPOSE: To check that if ASPAC message is received at SGP and it
does not send the ASPAC-Ack, then ASP re-tries it.
+ TEST CONFIGURATION: A
Manish Sharma, HSS [Page 28]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Inactive
ASPAC --------------->
T(ack) expires
ASPAC --------------->
T(ack) expires
n-1 tries....
ASPAC --------------->
ASP State Ind---------->
AS State Ind----------->
<--------------- ASPAC -Ack
<----------------NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPAC message with valid parameters from ASP to SGP and dont
send(restrict) ASPAC-Ack from SGP to ASP.
2. Check A: ASPAC message is received at SGP repeatedly.
3. Don't restrict ASPAC -Ack from SGP to ASP for the next ASPAC
message.
4. Check B: ASPAC-Ack, NTFY(AS-active), will be received at ASP.
5. Check C: ASP State Ind, AS-State Ind will be received at SM of SGP.
Manish Sharma, HSS [Page 29]
Internet Draft M2UA Conformance Test Plan Oct 2003
Note: Number of repetitions is implementation dependent.
"Duplicate Message Handling"
+ TEST NUMBER : 4.2.10
+ TITLE : ASPAC message
+ SUBTITLE : ASPAC message when ASP is in ASP-Active state at SGP
+ PURPOSE: To check that if ASPAC message is received when ASP is in
ASP-Active state at SGP then ASPAC-Ack message is sent to
the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPAC --------------->
<--------------ASPAC-Ack
ASPAC --------------->
<--------------ASPAC-Ack
DATA Msg-------------->
Data Receive Ind --------->
TEST DESCRIPTION:
1. Send ASPAC message from ASP to the SGP with ASP in ASP-Active state.
ASPAC-Ack message will be sent from the SGP .
Manish Sharma, HSS [Page 30]
Internet Draft M2UA Conformance Test Plan Oct 2003
2. Send ASPAC message again from the ASP.
3. Check A: ASPAC-Ack message will be received at the ASP.
4. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
Active state. Send DATA message from ASP, Data Receive Indication
Will be received at NIF at SGP.
"Different Message Handling"
+ TEST NUMBER : 4.2.11
+ TITLE : ASPAC message
+ SUBTITLE : ASPAC message when ASP is in ASP-Down state at SGP
+ PURPOSE: To check that if ASPAC message is received when ASP is in
ASP-Down state at SGP then it is discarded and ASPDN-Ack is sent to
ASP and optionally Error (Unexpected message) is sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Down.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Down
ASPAC --------------->
<------------ASPDN-Ack
<--------------ERROR
(Cause = Unexpected Message)
Manish Sharma, HSS [Page 31]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASPUP --------------->
State Ind --------------->
(ASP Inactive)
<--------------ASPUP-Ack
<--------------NTFY(AS-Inactive)
TEST DESCRIPTION:
1. Send ASPAC message with Interface Identifiers X, Y to the SGP with
ASP in ASP-Down state.
2. Check A: ASPDN-Ack is received at the ASP.
ERROR message with Cause Unexpected message should be received at
the ASP.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
Down state. Send ASPUP message for the ASP and SGP should respond
with ASP-Up-Ack and NTFY message with status AS-Inactive.
4. Repeat the above test case for ASPIA message i.e. ASPIA message is
received in ASP-Down state with the same parameters as were in the
ASPAC message. Response should be same.
Note: The above ERROR message with Cause Unexpected Message is optional
depending upon the implementation.
"ASPAC message with no Interface Identifier"
+ TEST NUMBER : 4.2.12
+ TITLE : ASPAC message
+ SUBTITLE : ASPAC message with no Interface Identifier
+ PURPOSE: To check that if ASPAC message is received with no
Interface Identifier then status of ASP is made Active for all the
Interface Identifier of the AS to which ASP belongs at SGP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
Manish Sharma, HSS [Page 32]
Internet Draft M2UA Conformance Test Plan Oct 2003
SGP and ASP. ASP is Inactive.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Inactive
ASPAC --------------->
(No Interface Id)
Status Ind ---------->
<--------------- ASPAC-Ack
<--------------- ASPAC-Ack
<--------------- NTFY (AS-active)
<--------------- NTFY (AS-active)
DATA Msg--------------->
(Interface Id = X)
Data Receive Ind ---------->
DATA Msg--------------->
(Interface Id = Y)
Data Receive Ind ---------->
TEST DESCRIPTION:
1. Send ASPAC Message containing no Interface Identifier from ASP to
the SGP with ASP in ASP-Inactive state.
2. Check A: ASP-Active-Ack and NTFY(AS-Active) messages should be
received at ASP with Interface Identifiers X, Y.
3. Check B: NTFY message is received on stream 0.
4. Check C: Check that state of ASP is active in all the Interface
Identifier of the AS to which this ASP belongs. This can be checked
by sending DATA message with Interface Identifier X and Y.
Manish Sharma, HSS [Page 33]
Internet Draft M2UA Conformance Test Plan Oct 2003
5. Execute the test case for both types of Interface Identifiers
(Integer and Text).
6. Repeat the above test for other ASPTM messages. Response should be
as per the above rule.
Note: Usage of multiple ASP Active Ack messages in response to an ASP
Active message containing multiple Interface Identifier allowing the
SGP to independently acknowledge the ASP Active messages for different
(sets of) Interface Identifier is implementation dependent. A single
ASPAC-Ack message can also be sent for all the Interface Identifiers.
"ASPAC message with subset of Interface Identifier"
+ TEST NUMBER : 4.2.13
+ TITLE : ASPAC message
+ SUBTITLE : ASPAC message with subset of Interface Identifiers
+ PURPOSE: To check that if ASPAC message is received with subset of
Interface Identifiers at SGP then status of ASP is made Active in
all the Interface Identifiers of the corresponding AS at SGP.
+ TEST CONFIGURATION: B
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive. Traffic handling mode in AS1 and AS2
configured at SG is Over-ride and ASPAC messages will use the
Over-ride mode in Traffic Mode Type parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Inactive
ASPAC --------------->
(Interface Id = X,P)
Status Ind ---------->
Manish Sharma, HSS [Page 34]
Internet Draft M2UA Conformance Test Plan Oct 2003
(ASP Active)
<--------------- ASPAC-Ack(for AS1)
<--------------- ASPAC-Ack(for AS2)
<--------------- NTFY (AS-active)(for AS1)
<--------------- NTFY (AS-active)(for AS2)
DATA Msg --------------->
(Interface Id = X)
Data Receive Ind --------------->
DATA Msg --------------->
(Interface Id = P)
Data Receive Ind --------------->
DATA Msg--------------->
(Interface Id = Y)
Data Receive Ind ---------->
DATA Msg--------------->
(Interface Id = Q)
Data Receive Ind ---------->
TEST DESCRIPTION:
1. Send ASPAC Message containing Interface Identifier X, P from ASP to
the SGP.
2. Check A: ASP-Active-Ack and NTFY(AS-Active) messages should be
received at ASP with Interface Identifier X, Y, P and Q both for
AS1 and AS2.
3. Check B: NTFY messages are received on stream 0.
4. Check C: Check that state of ASP is active in all the AS to which
this ASP belongs and for all the Interface Ids of the ASs. This can
be checked by sending DATA messages with Interface Identifier Y, P,
X and Q respectively.
5. Execute the test case for both types of Interface Identifier
(Integer and Text).
Manish Sharma, HSS [Page 35]
Internet Draft M2UA Conformance Test Plan Oct 2003
6. Do this for ASPIA message also.
Response(Inactive) will be as per the above rule .
"Duplicate Message Handling"
+ TEST NUMBER : 4.2.14
+ TITLE : ASPIA message
+ SUBTITLE : ASPIA message when ASP is in ASP-Inactive state at SGP
+ PURPOSE: To check that if ASPIA message is received when ASP is in
ASP-Inactive state at SGP then ASPIA-Ack message is sent to the
ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPIA --------------->
Status Ind --------------->
(ASP Inactive)
<--------------ASPIA-Ack
<--------------NTFY(AS-Pending)
Timer T(r) expires
<--------------NTFY(AS-Inactive)
ASPIA --------------->
<--------------ASPIA-Ack
Manish Sharma, HSS [Page 36]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASPAC --------------->
Status Ind --------------->
(ASP Active)
<--------------ASPAC-Ack
<--------------NTFY(AS-active)
ASP is active
ASPIA --------------->
T(ack) expires
ASPIA --------------->
|
|
|
T(ack) expires...n-1 times
ASPIA --------------->
Status Ind ---------------->
(ASP Inactive)
<--------------ASPIA-Ack
<--------------NTFY(AS-Pending)
Timer T(r) expires
<--------------NTFY(AS-Inactive)
ASPDN --------------->
ASP State Ind --------------->
(ASP Down)
AS State Ind ---------------->
(AS Down)
<--------------ASPDN-Ack
Manish Sharma, HSS [Page 37]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASPIA --------------->
<--------------ASPDN-Ack
<--------------ERROR
(Cause = Unexpected Message)
TEST DESCRIPTION:
1. Send ASPIA message from ASP to SGP with ASP in ASP-Active state.
2. Check A: ASPIA-Ack and NTFY message will be sent from the SGP with
status AS-Pending. After the expiry of Timer T(r) a NTFY message
with Status AS-Inactive will be sent by the SGP to ASP.
3. Send ASPIA message again from the ASP.
4. Check A: ASPIA-Ack message will be received at the ASP.
5. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in
the Inactive state. Send ASPAC message from ASP, ASPAC-Ack, NTFY(AS-
Active)will be received at ASP and State of ASP at SGP will be
changed to ASP-Active.
6. Send ASPIA message from ASP to SGP and restrict SGP from sending
ASPIA-Ack to ASP.
7. Check C: SGP repeatedly receives ASPIA messages from ASP.
8. Don't restrict ASPIA-Ack from SGP for the next ASPIA message from
ASP.
9. Check D: ASPIA-Ack and NTFY message will come from the SGP with
status AS-Pending. After the expiry of Timer T(r) SGP will send a
NTFY message with Status AS-Inactive to the ASP.
10. Send ASPDN message to SGP from ASP.
11. Check E: ASPDN-Ack and NTFY message will come from the SGP with
status AS-Pending.
12. Send ASPIA message from ASP to SGP.
13. Check F: ASPDN-Ack is received by the ASP sent by SGP.
Manish Sharma, HSS [Page 38]
Internet Draft M2UA Conformance Test Plan Oct 2003
14. Check G: SGP sends error message with cause "Unexpected Message" to
ASP.
Note: Number of re-tries are implementation dependent. The above Error
message with cause "Unexpected Message" is optional depending upon the
implementation.
"ASPIA message with a subset of Interface Identifiers"
+ TEST NUMBER : 4.2.15
+ TITLE : AS management
+ SUBTITLE : ASPIA message with a Subset of Interface Identifiers
+ PURPOSE: To check that if ASPIA message is received with 0 or more
Interface Identifiers at SGP then status of ASP is set to Inactive
in all the AS to which this ASP belongs at SGP.
+ TEST CONFIGURATION: B
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. Traffic handling mode in AS1 and AS2
configured at SG is Over-ride and ASPAC messages will use the Over-
ride mode in Traffic Mode Type parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPIA --------------->
(Interface Id = X,P)
Status Ind ---------->
(ASP Inactive)
<--------------- ASPIA-Ack(for AS1)
Manish Sharma, HSS [Page 39]
Internet Draft M2UA Conformance Test Plan Oct 2003
<--------------- ASPIA-Ack(for AS2)
<--------------- NTFY (AS-Inactive)(for AS1)
<--------------- NTFY (AS-Inactive)(for AS2)
<---------------Data
Send Failure ---------->
<---------------Data
Send Failure ---------->
TEST DESCRIPTION:
1. Send ASPAC Message containing Interface Identifiers X and P from ASP
to the SGP.
2. Check A: ASP-Active-Ack and NTFY(AS-Active) messages should be
received at ASP with Interface Identifier X, Y, P and Q both for
AS1 and AS2.
3. Check B: NTFY message is received on stream 0.
4. Check C: Check that state of ASP is inactive in all the AS to which
this ASP belongs.
5. Send DATA Send Primitives with Interface Identifiers X, P, Y and Q
respectively from NIF to M2UA at SGP.
6. Check D: A failure message will be received by NIF for all Interface
Identifiers.
7. Repeat the above test case if no Interface Identifier is present in
ASPIA message. The response should be same.
8. Execute the test case for both types of Interface Identifier
(Integer and Text).
Note: Interface Identifier is an optional parameter in the NTFY
message. In some implementation this parameter may not be present in
NTFY message. In that case NTFY message with status AS-Inactive/ AS-
Manish Sharma, HSS [Page 40]
Internet Draft M2UA Conformance Test Plan Oct 2003
Pending will be received at ASP and it means that it is for all AS for
which this ASP is configured.
Note: The Line 7 of the above Test is applicable only when SGP is
capable of identifying via Configuration Data, the Application Servers
to which the ASP belongs. In either case it is not applicable.
"ASPM messages"
+ TEST NUMBER : 4.2.16
+ TITLE : Traffic Handling Modes
+ SUBTITLE : Override Mode of Traffic Handling in ASPAC message
+ PURPOSE: To check that if an ASPAC message is received with Traffic
Mode Type field containing Override mode then all traffic is sent
to that ASP which sent ASPAC message.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1 and ASP2. ASP1 is Active and ASP2 is Inactive. Mode of
traffic handling for AS configured at SGP is Override.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1 is Active
ASP2 is Inactive
ASPAC(ASP2) --------------->
(Traffic Mode Type = Override)
Status Ind --------------->
(ASP Active)
(ASP2)<--------------ASPAC-Ack
Manish Sharma, HSS [Page 41]
Internet Draft M2UA Conformance Test Plan Oct 2003
(ASP1)<--------------NTFY
(Alternate ASP Active)
<-------- Data
(Interface Id = X)
(ASP2)<-------- DATA Msg
<-------- Data
(Interface Id = Y)
(ASP2)<-------- DATA Msg
TEST DESCRIPTION:
1. Send ASPAC message with Override mode in Traffic Mode Type field and
Interface Identifier X and Y from ASP2 to SGP.
2. Check A: SGP should send ASP-Active-Ack message for ASP2 also an
NTFY message with status "Alternate ASP Active" is sent to ASP1
which was previously active.
3. Check B: Also all traffic should go to ASP2 which has sent the
ASPAC. Check this by sending Data Send Primitives from NIF at SGP
containing Interface Identifier X and Y following which the M2UA of
SGP will send DATA messages to corresponding ASPs.
Check that DATA messages will be sent to ASP2 only.
"DATA Send Primitive from NIF in AS Inactive State"
+ TEST NUMBER :4.2.17
+ TITLE : AS management
+ SUBTITLE : Data Send Primitive from NIF in AS Inactive State
+ PURPOSE: To check that if AS is not active at SGP and NIF sends
Data Send Primitive to local M2UA to send Protocol Data to that AS
then it receives a send failure.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
Manish Sharma, HSS [Page 42]
Internet Draft M2UA Conformance Test Plan Oct 2003
and ASP. ASP is in Active state.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPIA --------------->
ASP State Ind --------------->
(ASP Inactive)
<-------------- ASP-Inactive-Ack
<-------------- NTFY (AS-Pending)
T(r) expires
AS State Ind ---------------->
(AS Inactive)
<-------------- NTFY (AS-Inactive)
<----------------- Data
Send Failure ------------->
TEST DESCRIPTION:
1. Send ASPIA Message from ASP to the SGP with Interface Identifier = X
and other valid parameters.
2. Check A: An ASPIA-Ack and a NTFY message with Status AS-Pending will
be received ASP. After the expiry of Timer T(r) a NTFY message with
Status AS-Inactive is received at ASP. The state of ASP and AS at
SGP becomes Inactive.
3. Check B: NTFY message is received on stream 0.
4. Send DATA Send Primitive containing Interface Identifier X and
Protocol Data to be sent to the ASP.
Manish Sharma, HSS [Page 43]
Internet Draft M2UA Conformance Test Plan Oct 2003
5. Check C: Send failure should be received at the NIF and DATA message
should not be sent to ASP.
6. Repeat the above test if instead of sending ASPIA message, SCTP
association between ASP and SGP is removed.
"DATA Send Primitive from NIF in AS Down State"
+ TEST NUMBER : 4.2.18
+ TITLE : AS management
+ SUBTITLE : DATA Send Primitive from NIF in AS Down State
+ PURPOSE: To check that if AS is in AS-Down State at SGP and NIF
sends DATA Send Primitive to send data to that AS then it receives
a send failure.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in Inactive state.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Inactive
ASPDN --------------->
ASP State Ind ---------->
(ASP Down)
AS-Status Ind ------->
(AS Down)
<-------------- ASP-Down-Ack
<----------------- Data
Send failure ------------->
Manish Sharma, HSS [Page 44]
Internet Draft M2UA Conformance Test Plan Oct 2003
TEST DESCRIPTION:
1. Send ASPDN Message from ASP to the SGP.
Check A: An ASPDN-Ack will be received ASP.
The state of ASP and AS at SGP becomes Down.
2. Send DATA Send Primitive containing Interface Identifier X and
Protocol Data to be sent to the ASP.
3. Check B: Send failure should be received at the NIF and DATA message
should not be sent to ASP.
4. Repeat the above test if instead of sending ASPDN message, SCTP
association between ASP and SGP is removed.
Note: When the AS transitions to the AS down state, all the SS7 link
(Interface Identifier) for this AS should be taken out of service.
4.3 MGMT Messages
4.3.1 NTFY Messages
"Notify Message with AS Status"
+ TEST NUMBER :4.3.1
+ TITLE : AS management
+ SUBTITLE : Notify Message with AS status
+ PURPOSE: To check that if ASPDN, ASPUP, ASPAC and ASPIA messages
are received in ASP-Active, ASP-Down, ASP-Up and ASP-Active states
respectively then NTFY message with correct status is sent to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. The ASPDN and ASPUP messages should be sent
on SCTP stream 0. The value of Interface Identifiers is X and Y in
all the messages where required and other parameters are having
Manish Sharma, HSS [Page 45]
Internet Draft M2UA Conformance Test Plan Oct 2003
valid values.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPDN --------------->
Status Ind ------------->
(ASP-Down)
<-------------- ASP-Down-Ack
AS Status Ind ---------->
(AS Pending)
| Timer T(r) Starts
|
Time = z sec
|
| Timer T(r) Expiry
AS Status Ind ----------->
(AS Down)
ASPUP --------------->
ASP-Status Ind ------------->
(ASP-Inactive)
AS Status Ind ---------->
(AS-Inactive)
<-------------- ASP-Up-Ack
<-------------- NTFY (AS-Inactive)
ASPAC --------------->
ASP-Status Ind ----------->
(ASP-Active)
Manish Sharma, HSS [Page 46]
Internet Draft M2UA Conformance Test Plan Oct 2003
AS Status Ind ---------->
(AS-Inactive)
<-------------- ASP-Active-Ack
<-------------- NTFY (AS-Active)
ASPIA --------------->
ASP-Status Ind ----------->
(ASP-Inactive)
AS Status Ind ---------->
(AS-Inactive)
<-------------- ASP-Inactive-Ack
<-------------- NTFY (AS-Pending)
TEST DESCRIPTION:
1. Send ASPDN message from ASP to the SGP.
2. Check A: ASPDN is acknowledged by ASP-Down-Ack message at the ASP.
3. Check B: No NTFY message is received at the ASP.
4. Send ASPUP message to SGP.
5. Check C: SGP responds with ASP-UP-Ack message and NTFY (AS-
Inactive).
6. Send ASPAC message with Interface Identifier parameter present.
7. Check D: SGP responds with ASP-Active-Ack and NTFY with status AS-
Active. Repeat the test case with Interface Identifier parameter not
present in ASPAC message.
8. Send ASPIA message from ASP to SGP.
9. Check E: SGP responds with ASP Inactive-Ack and NTFY with status AS-
Pending.
10. Check F: NTFY message is received on stream 0.
Manish Sharma, HSS [Page 47]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Notify Message with "Insufficient Resources Active" in AS"
+ TEST NUMBER :4.3.2
+ TITLE : AS management
+ SUBTITLE : Notify Message with Insufficient Resources Active in AS
+ PURPOSE: To check that if the number of Active ASPs in a Loadshare/
Broadcast AS goes below the minimum number of required ASPs then a
NTFY message for Insufficient Resources Active is sent to INACTIVE
ASPs.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1 and ASP2. ASP1 is Active for Interface Identifier X and
ASP2 is Inactive in SGP. The AS is in Loadshare mode and the
minimum number of Active ASPs required is two.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 SGP SM
ASP1 is Active
ASP2 is Inactive
ASPIA ------------------------------->
(ASP1)
Status Ind ------------------>
(ASP-Inactive)
<------------------ ASP-Inactive-Ack(to ASP1)
(ASP2)<----- NTFY (Insufficient Resources)
(ASP1)<--------------------- NTFY (Insufficient Resources)
TEST DESCRIPTION:
1. Send ASPIA message from ASP1 to the SGP with Interface Identifier X.
2. Check A: ASPIA is acknowledged by ASPIA-Ack message by the SGP to
ASP1.
3. Check B: SGP sends a NTFY Message with Insufficient Resources to
Manish Sharma, HSS [Page 48]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP2 and ASP1 both of which are in ASP-Inactive State.
4. Repeat the Test Case when the AS is in Broadcast Mode.
Note: This NTFY message might not be provisioned by some
implementations.
"Notify Message with Alternate ASP Active in AS"
+ TEST NUMBER : 4.3.3
+ TITLE : AS management
+ SUBTITLE : Notify Message with Alternate ASP Active in AS
+ PURPOSE: To check that if an Alternate ASP of the AS (in Override
Mode of Traffic Handling) becomes Active then a NTFY message for
Alternate ASP Active is sent to the previously Active ASP.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1 and ASP2. ASP1 is Active for Interface Identifier X and
ASP2 is Inactive in SGP. The AS is in Override mode.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 SGP SM
ASP1 is Active
ASP2 is Inactive
ASPAC --------------->
(ASP2)
(Interface Id = p)
Status Ind ---------->
(ASP-Active)
<------------------- ASPAC-Ack(to ASP2)
(ASP1)<-----------------------------NTY(Alter ASP Active)
TEST DESCRIPTION:
1. Send ASPAC with Traffic Mode Type parameter as "Override" message
Manish Sharma, HSS [Page 49]
Internet Draft M2UA Conformance Test Plan Oct 2003
from ASP2 to the SGP and Interface Identifier P.
2. Check A: ASPAC is acknowledged by ASPAC-Ack message by the SGP to
ASP2.
3. Check A: SGP sends a NTFY Message with Alternate ASP Active to ASP1
which was previously active in AS.
Note: This NTFY message might not be provisioned by some
implementations.
"Notify Message with ASP Failure in AS"
+ TEST NUMBER : 4.3.4
+ TITLE : AS management
+ SUBTITLE : Notify Message with ASP Failure in AS
+ PURPOSE: To check that if an ASP of the AS goes down then a NTFY
message for ASP Failure is sent to all the ASP(s) of the AS.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1 and ASP2. ASP1 is Active for Interface Identifier X and
ASP2 is Inactive in SGP. The AS is in Loadshare mode.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 SGP SM
ASP1 is Active
ASP2 is Inactive
ASPDN --------------->
(ASP2)
Status Ind ---------------->
(ASP-Down)
<-------------- ASP-Down-Ack(to ASP2)
Manish Sharma, HSS [Page 50]
Internet Draft M2UA Conformance Test Plan Oct 2003
(ASP1)<------------------------------ NTFY
(ASP Failure)
TEST DESCRIPTION:
1. Send ASPDN message from ASP2 to the SGP.
2. Check A: ASPDN is acknowledged by ASPDN-Ack message by the SGP to
ASP2.
3. Check B: SGP sends a NTFY Message with ASP Failure to ASP1 in AS.
4. Check C: No Notify message is received at ASP2.
Note: This NTFY message might not be provisioned by some
implementations.
"Timer T(r) Cancellation"
+ TEST NUMBER : 4.3.5
+ TITLE : AS management
+ SUBTITLE : Timer T(r) Cancellation
+ PURPOSE: To check that after last ASP becomes inactive then SGP
buffers the messages from NIF for time T(r) and if ASPAC comes
before its expiry then all buffered messages are sent to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP. ASP is active. ASPIA and ASPAC messages are sent with
Interface Identifiers X & Y and value of Traffic Mode Type
parameter equal to the traffic handling mode configured for AS at
the SGP. Let the value of Timer T(r) is z sec.
EXPECTED MESSAGE SEQUENCE :
Manish Sharma, HSS [Page 51]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP SGP NIF+SM
ASP is Active
ASPIA --------------->
Status Ind ---------->
(ASP-Inactive)
<-------------- ASP-Inactive-Ack
<-------------- NTFY (AS-Pending)
T(r) starts
<-------------- Data
<-------------- Data
(Data will be buffered)
ASPAC ---------------> (time < z)
Status Ind ---------->
(ASP-Active)
<-------------- ASP-active-Ack
<-------------- NTFY (AS-Active)
<----------------- DATA Msg
<----------------- DATA Msg
TEST DESCRIPTION:
1. Send ASPIA Message from ASP to the SGP. ASP will become Inactive at
the SG. While Timer T(r) is still running send Data Send Primitive
containing Protocol Data with Interface Identifier X to be sent to
ASP.
2. Check A: DATA message will not be received at ASP.
3. Send ASPAC message before Timer T(r) expires.
4. Check B: DATA messages buffered at the SG will be received at ASP.
5. Repeat the above test case using Test Configuration C where
Manish Sharma, HSS [Page 52]
Internet Draft M2UA Conformance Test Plan Oct 2003
initially ASP1 will be active and ASP2 will be inactive. Send ASPIA
message from ASP1 and then send DATA send primitive from NIF to M2UA
at SGP and Check that no DATA message is received at any of the
ASPs. Send ASPAC message from ASP2 and check that the buffered DATA
messages are received at ASP2 and not ASP1.
Note: This case is implementation specific. In some implementations
there may not be any Timer T(r) running.
In that case there is no need to run this test case.
"Timer T(r) Expiry"
+ TEST NUMBER :4.3.6
+ TITLE : AS management
+ SUBTITLE : Timer T(r) Expiry
+ PURPOSE: To check that AS-State changes after timer T(r) expires.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is active. Let the value of Timer T(r) is z sec.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPDN --------------->
Status Ind ---------------->
(ASP-Down)
<-------------- ASP-Down-Ack
<-------------- NTFY (AS-Pending)
T(r) starts
<-------------- Data
Manish Sharma, HSS [Page 53]
Internet Draft M2UA Conformance Test Plan Oct 2003
<-------------- Data
(Data will be buffered)
(time = z) T(r) expires
(Data will be discarded)
<--------------- NTFY (AS-Down)
<-------------- Data
Send Failure ---------->
TEST DESCRIPTION:
1. Send ASPDN Message from ASP to the SGP. The state of AS will become
AS-Pending at the SG. Send Data Send Primitive containing Protocol
Data from NIF to be sent to the ASP and Wait for z sec.
2. Check A: DATA message will not be received at ASP.
3. Check B: DATA messages buffered at the SG will be discarded.
4. Send Data Send primitives from NIF to M2UA at SGP with Interface
Identifier X.
5. Check C: A failure message will be sent to the NIF.
Note: This case is implementation specific. In some implementations
there may not be any Timer T(r) running.
In that case there is no need to run this test case.
"Notify Message is sent only for AS State change - A"
+ TEST NUMBER : 4.3.7
+ TITLE : AS management
+ SUBTITLE : Notify Message with AS Status is sent only for AS State
change
+ PURPOSE: To check that NTFY message is not sent if there is no
change in the state of the AS.
Manish Sharma, HSS [Page 54]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 and both are active. Traffic Mode Type parameter in ASPAC and
ASPIA message should be same as the traffic handling mode
configured For AS at SGP. Interface Identifier parameter should be
having values X and Y.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1,ASP2 are active
ASPIA(ASP2)--------------------->
Status Ind ---------->
(ASP-Inactive)
<--------------- ASPIA-Ack(to ASP2)
ASPDN(ASP2)------------>
Status Ind ---------->
(ASP-Down)
<--------------- ASPDN-Ack(to ASP2)
ASPUP(ASP2)------------>
Status Ind ---------->
(ASP-Up)
<--------------- ASPUP-Ack(to ASP2)
ASPAC(ASP2)------------>
Status Ind ---------->
(ASP-Active)
<--------------- ASPAC-Ack(to ASP2)
TEST DESCRIPTION:
1. Send ASPIA message for ASP2 from ASP to the SGP.
Manish Sharma, HSS [Page 55]
Internet Draft M2UA Conformance Test Plan Oct 2003
2. Check A: ASP-Inactive Ack will be received at the ASP and NTFY
message with status AS-Inactive is not received as AS is now Active.
3. Repeat the above test case for other messages like ASPAC, ASPUP and
ASPDN for ASP2 from ASP to SGP. NTFY message with AS status should
not be received in any case.
"Notify Message is sent only for AS State change- B"
+ TEST NUMBER :4.3.8
+ TITLE : AS management
+ SUBTITLE : Notify Message with AS Status is sent only for AS State
change
+ PURPOSE: To check that NTFY message is sent when there is change in
the state of the AS.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 and both are active. Traffic Mode Type parameter in ASPAC and
ASPIA message should be same as the traffic handling mode
configured for AS at SGP. Interface Identifier parameter should be
having values X and Y.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1, ASP2 are active
ASPIA (ASP1)---------------->
Status Ind ---------->
(ASP-Inactive)
<-------------- ASPIA-Ack(to ASP1)
ASPIA (ASP2)------------>
Status Ind ---------->
Manish Sharma, HSS [Page 56]
Internet Draft M2UA Conformance Test Plan Oct 2003
(ASP-Inactive)
<--------------- ASPIA-Ack(to ASP2)
<--------------- NTFY(AS-Pending) (to ASP1 and ASP2)
Timer T(r) expires
<--------------- NTFY(AS-Inactive) (to ASP1 and ASP2)
ASPDN (ASP1)------------>
Status Ind ---------->
(ASP-Down)
<------------ ASPDN-Ack(to ASP1)
ASPDN (ASP2)------------>
Status Ind ---------->
(ASP-Down)
AS state Ind --------->
(AS-Down)
<------------- ASPDN-Ack(to ASP2)
ASPUP (ASP1)------------>
Status Ind ---------->
(ASP-Up)
<--------------- ASPUP-Ack(to ASP1)
<--------------- NTFY(AS-Inactive) (to ASP1)
ASPAC (ASP1)------------>
Status Ind ---------->
(ASP-Active)
<--------------- ASPAC-Ack(to ASP1)
<--------------- NTFY(AS-Active) (to ASP1)
TEST DESCRIPTION:
1. Send ASPIA message for ASP1 from ASP to the SGP with Interface
Manish Sharma, HSS [Page 57]
Internet Draft M2UA Conformance Test Plan Oct 2003
Identifier X and Y and Traffic Mode Type parameter equal to the
Traffic Handling Mode configured for the AS.
2. Check A: NTFY message not sent to ASPs (ASP1 and ASP2), but
ASP-Inactive-Ack message is received at the ASP1.
3. Send ASPIA message for ASP2 from ASP to the SGP with Interface
Identifier X and Y and Traffic Mode Type parameter as in the ASP1
case.
4. Check B: ASP-Inactive-Ack and NTFY message with status AS-Pending
and after Timer T(r) expiry AS-Inactive is received at the ASPs.
5. Repeat the above test case for other messages like ASPDN, ASPUP and
ASPAC for ASP1 and ASP2 from ASP to SGP.
Note 1: A NTFY message should be sent to both ASP1 and ASP2 if they are
not in the ASP-Down state.
Note 2: When the AS transitions to the AS down state, all the SS7 link
(Interface Identifier) for this AS should be taken out of service.
4.3.2 ERROR Messages
"Error - Invalid Version"
+ TEST NUMBER :4.3.9
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Version Error
+ PURPOSE: To check that if any message with Invalid version is
received at the SGP then SGP responds with ERROR message containing
Cause "Invalid Version" and diagnostic information filled with the
version the SGP supports.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
Manish Sharma, HSS [Page 58]
Internet Draft M2UA Conformance Test Plan Oct 2003
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
ASPIA ---------------->
(Version = 2.0)
<--------------- ERROR
(Cause = Invalid Version)
TEST DESCRIPTION:
1. Send ASPIA message from ASP to SGP containing version 2.0 in the
Common Message Header.
2. Check A: ERROR message is received at the ASP containing cause
Invalid Version.
3. Check B: Diagnostic Field Parameter in ERROR is filled with
version 1.0 .
4. Repeat the above test cases for other messages from ASP to SGP like
ASPAC, ASPUP, ASPDN, RETRIEVAL REQUEST, ESTABLISH REQUEST,
RELEASE REQUEST, STATE REQUEST and DATA. In all these cases,
ERROR message will be received with the same cause.
Note: The Diagnostic information in the ERROR messages is an optional
parameter which contains information germane to error condition. In
case it is not included the Check in Line 3 above is not applicable.
"Error - Unsupported Message Class"
+ TEST NUMBER :4.3.10
+ TITLE : Unsupported Message Handling
+ SUBTITLE : Unsupported Message Class Error
+ PURPOSE: To check that if a message with Message Class not defined
Manish Sharma, HSS [Page 59]
Internet Draft M2UA Conformance Test Plan Oct 2003
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. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
Message ---------------->
(Message Class = 1)
<--------------- ERROR
(Cause = Unsupported Message Class)
DATA Msg ---------------->
(Interface Id = X)
Data Receive Ind ------->
TEST DESCRIPTION:
1. Send a message with message Class 1 or any other value which is not
defined from ASP to SGP and other valid parameters.
2. Check A: ERROR message will be received at the ASP containing Cause
"Unsupported Message Class".
3. Check B: State of ASP at SGP is not disturbed.
4. Send DATA message from ASP to SGP with Interface Identifier = X and
other required parameters with valid values including Message Class.
5. Check C: A DATA Receive Indication is sent to NIF by M2UA at SGP.
Manish Sharma, HSS [Page 60]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Error - Unsupported Message Type"
+ TEST NUMBER :4.3.11
+ TITLE : Unsupported Message Handling
+ SUBTITLE : Unsupported Message Type Error
+ 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. ASP is active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
Message ---------------->
(Message Type = 708)
<--------------- ERROR
(Cause = Unsupported Message Type)
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind ------->
TEST DESCRIPTION:
1. Send a message with message type 708 or any other value which is
not defined from ASP to SGP and other valid parameters.
2. Check A: ERROR message is received at the ASP containing cause
Unsupported Message Type.
3. Check B: State of ASP at SGP is not disturbed.
Manish Sharma, HSS [Page 61]
Internet Draft M2UA Conformance Test Plan Oct 2003
4. Send DATA message from ASP to SGP with Interface Identifier = X and
other required parameters with valid values.
5. Check C: A DATA Receive Indication is sent to NIF by M2UA at SGP.
6. Repeat the above test cases by sending ESTABLISH CONFIRMATION,
RELEASE CONFIRMATION, RELEASE INDICATION, STATE CONFIRM,
STATE INDICATION, RETRIEVAL CONFIRM and RETRIEVAL INDICATION ,
REG-RESP messages from ASP which the SGP is not expected to receive.
In this case Error will be reported to the SM and Message will be
discarded.
"Error - Invalid Interface Identifier "
+ TEST NUMBER : 4.3.12
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Interface Identifier in MAUP messages
+ PURPOSE: To check that if a message with invalid Interface
Identifier i.e. Interface Identifier not defined at SGP is received
then SGP responds with ERROR message containing cause
"Invalid Interface Identifier".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
DATA ---------------->
(Interface Id = P)
<--------------- ERROR
(Cause = Invalid Interface Identifier)
Manish Sharma, HSS [Page 62]
Internet Draft M2UA Conformance Test Plan Oct 2003
DATA ---------------->
(Interface Id = X)
Data receive Ind ------->
TEST DESCRIPTION:
1. Send DATA message with Interface Identifier P that is not defined at
SGP.
2. Check A: ERROR message will be received at ASP containing cause
"Invalid Interface Identifier".
3. Check B: State of ASP at SGP is not disturbed.
4. Send DATA message from ASP to SGP with Interface Identifier = X and
other required parameters with valid values.
5. Check C: A DATA Receive Indication is sent to NIF
6. Repeat the above test case for test configuration D. DATA message is
sent from ASP1 with Interface Identifier P that is defined at SGP
for ASP2. In this case also ERROR message should be received at ASP
with cause "Invalid Interface Identifier".
7. Repeat the above test case for other messages like RELEASE REQUEST,
ESTABLISH REQUEST, STATE REQUEST, RETRIEVAL REQUEST, NTFY and ERROR.
Other parameters in these messages should be having valid values.
Response will be same in all cases.
"Error - Invalid Interface Identifier"
+ TEST NUMBER :4.3.13
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Interface Identifier parameter in ASPTM messages
+ PURPOSE: To check that if ASPAC message with Invalid Interface
Identifier parameter is received then ASPAC message is discarded.
+ TEST CONFIGURATION: A
Manish Sharma, HSS [Page 63]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP and AS is in AS-Inactive state i.e. ASP is INACTIVE.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Inactive
ASPAC ---------------->
(Interface Id = P)
<--------------- ERROR
(Cause = Invalid Interface Identifier)
ASPAC ---------------->
(Interface Id =X,Q)
Status Ind ------->
(ASP-Active)
<--------------- ASPAC-Ack
<--------------- NTFY(AS-ACTIVE)
(Interface Identifier = X)
<--------------- ERROR
(Cause = Invalid Interface Identifier)
TEST DESCRIPTION:
1. Send ASPAC message with Interface Identifier P or any Interface
Identifier other than X and Y.
2. Check A: SGP will take no action and will discard the ASPAC message.
3. Check B: An Error message with Cause = Invalid Interface Identifier
is send to ASP.
4. Send ASPAC message with Interface Identifier X and Q.
5. Check C: An ASP-Active-Ack and a NTFY messages will be received at
the ASP with status AS-Active for Interface Identifier X.
6. Check D: An ERROR message with Cause "Invalid Interface Identifier"
is sent to ASP for Interface Identifier Q.
Manish Sharma, HSS [Page 64]
Internet Draft M2UA Conformance Test Plan Oct 2003
7. Repeat the above test case with ASPIA message in ASP Active state.
Response should be same.
Note: Interface Identifier is an optional parameter in ASPAC message.
In some implementations this field may not come in ASPAC and ASPIA
message. In those implementations this test case is not applicable.
"Error - Parameter Field Error"
+ TEST NUMBER :4.3.14
+ TITLE : Invalid Message Handling
+ SUBTITLE : Wrong Length Field of a Parameter in the Common Message
Header.
+ PURPOSE: To check that if an MAUP or MGMT message with wrong length
field of a Parameter in Common Message Header or M2UA Header is
sent to SGP then SGP responds with Error message with Cause
"Parameter Field Error".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP, ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
RELEASE REQUEST ---------------->
(Length in M2UA header = 7)
Message is discarded.
<--------------- ERROR
Manish Sharma, HSS [Page 65]
Internet Draft M2UA Conformance Test Plan Oct 2003
(Cause = Parameter Field Error)
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind ------->
TEST DESCRIPTION:
1. Send RELEASE REQUEST message with length in Interface ID Parameter
in M2UA Header less than 8 from ASP to the SGP.
2. Check A: RELEASE REQUEST message will be discarded and ERROR message
with Cause "Parameter Field Error" will be sent to the ASP.
3. Check B: State of ASP at SGP is not disturbed.
4. Send DATA message from ASP to SGP with Interface Identifier = X and
other required parameters with valid values including the Length
Field.
5. Check C: A Data Receive Indication is sent to NIF.
6. Repeat the above test case for other messages like STATE REQUEST,
RETRIEVAL REQUEST which include Parameters in the Common Message
Header or M2UA Header.
"Error - Unsupported Traffic Handling Mode - A"
+ TEST NUMBER : 4.3.15
+ TITLE : Unsupported Message Handling
+ SUBTITLE : Unsupported Traffic Handling Mode Error
+ PURPOSE: To check that if ASPAC or ASPIA message is received with
Traffic Mode Type parameter incompatible with the Traffic Handling
Mode currently used in AS at SGP, SGP responds with ERROR message
containing cause "Unsupported Traffic Handling Mode".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
Manish Sharma, HSS [Page 66]
Internet Draft M2UA Conformance Test Plan Oct 2003
and ASP. ASP is INACTIVE. Traffic Handling Mode defined at SGP for
AS is Override.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Inactive
ASPAC ---------------->
(Traffic Mode Type = Loadshare)
<--------------- ERROR
(Cause = Unsupported traffic Handling Mode)
TEST DESCRIPTION:
1. Send ASPAC message from ASP to SGP containing Traffic Mode Type
field Loadshare. Fill value X and Y in Interface Identifier
parameter and other fields will be having valid values.
2. Check A: ERROR message is received at the ASP containing cause
"Unsupported Traffic Handling Mode".
3. Repeat the above test cases for other values of Traffic Mode Type
field with Traffic Handling Mode for AS at SGP being different from
this Type field.
4. Repeat the test case with Traffic Mode Type field having value that
is not defined i.e. any value greater than 0x3. The Response will be
the same.
5. Repeat all the above tests for ASPIA message.
"Error - Unsupported Traffic Handling Mode - B"
+ TEST NUMBER : 4.3.17
+ TITLE : Unsupported Message Handling
+ SUBTITLE : Unsupported Traffic Handling Mode Error if there are two
ASPs in one AS.
Manish Sharma, HSS [Page 67]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ PURPOSE: To check that if ASPAC or ASPIA message is received with
Traffic Mode Type parameter incompatible with the traffic handling
mode currently used in AS at SGP, SGP responds with ERROR message
containing cause "Unsupported Traffic Handling Mode".
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and both ASPs and both ASP1 and ASP2 are INACTIVE. Traffic Handling
Mode defined at SGP for AS is Override Mode.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Inactive
(ASP1 and ASP2 are Inactive)
ASPAC (ASP1) ---------------->
(Traffic Mode Type = Override)
Status Ind ------->
(ASP-Active)
<--------------- ASP-Active-Ack(to ASP1)
ASPAC (ASP2)---------------->
(Traffic Mode Type = Override)
<--------------- ERROR
(Cause = Unsupported traffic Handling Mode)
TEST DESCRIPTION:
1. Send ASPAC message from ASP1 to SGP containing Traffic Mode Type
field Override. Fill value X and Y in Interface Identifier parameter
and other fields will be having valid values.
2. Check A: ASP-Active-Ack message is received at the ASP.
3. Send ASPAC message from ASP2 to SGP containing Traffic Mode Type
field Loadshare. Fill value X and Y in Interface Identifier
parameter and other fields will be having valid values.
4. Check B: ERROR message is received at the ASP containing cause
Manish Sharma, HSS [Page 68]
Internet Draft M2UA Conformance Test Plan Oct 2003
Invalid Traffic Handling Mode.
5. Repeat the above test cases for other values of Traffic Mode Type
field with Traffic Handling Mode for AS at SGP being different from
this Type.
6. Repeat the test case with Type field having value that is not
defined i.e. any value greater than 0x3.
7. Repeat all the above tests for ASPIA message.
"Error - Unsupported Interface Identifier Type"
+ TEST NUMBER : 4.3.16
+ TITLE : Unsupported Interface Identifier parameter Type
+ SUBTITLE : Unsupported Interface Identifier parameter in MAUP
message
+ PURPOSE: To check that if a message with unsupported Interface
Identifier i.e. Interface Identifier not supported at SGP is
received then SGP responds with ERROR message containing cause
"Unsupported Interface Identifier".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. Only Integer based Interface Identifiers
are supported at SGP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
DATA Msg ---------------->
(Text Interface Id = X)
<--------------- ERROR
Manish Sharma, HSS [Page 69]
Internet Draft M2UA Conformance Test Plan Oct 2003
(Cause = Unsupported Interface Identifier Type)
DATA Msg ---------------->
(Integer Interface Id = X)
Data Receive Ind ------->
TEST DESCRIPTION:
1. Send DATA message with Text based Interface Identifier X that is not
supported at SG.
2. Check A: ERROR message will be received at ASP containing cause
"Unsupported Interface Identifier Type".
3. Check B: State of ASP at SGP is not disturbed.
4. Now send Protocol Data with Integer based Interface Identifier X
from ASP to SGP.
5. Check C: No ERROR message will be received at ASP.
6. Check D: A Data Receive Indication is received at NIF.
7. Repeat the above test case for other messages like RELEASE REQUEST,
ESTABLISH REQUEST, STATE REQUEST, RETRIEVAL REQUEST, NTFY and ERROR.
Other parameters in these messages should be having valid values.
Response will be same in all cases.
"Error - Unexpected Message"
+ TEST NUMBER : 4.3.17
+ TITLE : Invalid Message Handling
+ SUBTITLE : DATA message from ASP in ASP-Inactive state
+ PURPOSE: To check that if DATA message is received at SGP from an
ASP which is in state ASP-Inactive at SGP then it is discarded and
an ERROR message is sent to peer.
+ TEST CONFIGURATION: A
Manish Sharma, HSS [Page 70]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Inactive
DATA Msg --------------->
(Interface Id = X)
<----------- Error
(Cause = Unexpected Message)
ASPAC ------------->
Status Ind --------------->
(ASP-Active)
<----------- ASPAC-Ack
<----------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send DATA message from ASP to SGP while ASP is in ASP-Inactive state
at SGP.
2. Check A: DATA message should be discarded and no message will be
received at the NIF in response to DATA message.
3. Check B: An ERROR message with Cause "Unexpected Message" is
received at ASP.
4. Check C: State of ASP at SGP is not disturbed. Send ASPAC message
and SGP will respond with ASPAC Ack and NTFY (AS-Active).
Note: Any DATA message in case of ASP-Down state MAY be silently
discarded. In that case Line 4 of the above Test Case will not be
applicable.
Manish Sharma, HSS [Page 71]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Error - Invalid Stream Identifier"
+ TEST NUMBER : 4.3.18
+ TITLE : Invalid Stream Identifier
+ SUBTITLE : Invalid Stream Identifier
+ PURPOSE: To check that if Management message is sent on an SCTP
Stream other than 0 an error message is sent to the peer.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in Inactive state.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Inactive
ASPDN ---------------->
(SCTP Stream other than 0)
Message discarded
<--------------- ERROR
(Cause = Invalid Stream Identifier)
ASPAC ---------------->
(Interface Id = X)
Status Ind ------->
(ASP-Active)
<--------------- ASPAC-Ack
<--------------- NTFY(AS-ACTIVE)
TEST DESCRIPTION:
1. Send ASPDN Message from ASP to the SGP on an SCTP stream other than
0.
2. Check A: An error message with reason as "Invalid Stream Identifier"
Manish Sharma, HSS [Page 72]
Internet Draft M2UA Conformance Test Plan Oct 2003
is received at ASP.
3. Check B: State of ASP at SGP is not disturbed.
4. Now send the ASPAC with Interface Identifier X.
5. Check C: ASP state changes to ACTIVE in SGP.
6. Check D: An ASPAC Ack is received at ASP.
7. Check E: A NTFY message with Status AS-Active is received at ASP.
8. Repeat the above Test for other ASPM messages (example- ASPUP,
ASPAC).
"Error - Invalid parameter value"
+ TEST NUMBER : 4.3.19
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid State Parameter in STATE REQUEST message
+ PURPOSE: To check that if STATE REQUEST message is received with
invalid value of State parameter then SGP will send an ERROR
message to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF
AS is Active
STATE REQUEST ---------------->
(State = 0xb)
Message Discarded
Manish Sharma, HSS [Page 73]
Internet Draft M2UA Conformance Test Plan Oct 2003
<--------------- Error
(Cause = Invalid parameter value)
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind --------->
TEST DESCRIPTION:
1. Send STATE REQUEST message with state value 0xb, which is invalid,
to the SGP.
2. Check A: STATE REQUEST message will be discarded and an Error
message will be received at ASP.
3. Check B: State of ASP at SGP is not disturbed.
4. Send DATA message with Interface Identifier = X and all other valid
values from ASP to SGP.
5. Check C: A DATA Receive Indication is received at NIF.
"Error - Invalid parameter value"
+ TEST NUMBER : 4.3.20
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Action Parameter in RETRIEVAL REQUEST message
+ PURPOSE: To check that if RETRIEVAL REQUEST message is received
with invalid value of Action parameter then SGP will send ERROR
message to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF
ASP is Active
Manish Sharma, HSS [Page 74]
Internet Draft M2UA Conformance Test Plan Oct 2003
RETRIEVAL REQUEST ---------------->
(Action = 0x4)
Message Discarded
<--------------- Error
(Cause = Invalid parameter value)
DATA Msg ---------------->
(Interface Id = X)
Data Receive Ind --------->
TEST DESCRIPTION:
1. Send RETRIEVAL REQUEST message with Action parameter value 0x4,
which is invalid, and a valid Sequence Number to the SGP.
2. Check A: RETRIEVAL REQUEST message will be discarded and an Error
message will be received at the ASP containing cause "Invalid
Parameter Value".
3. Check B: State of ASP at SGP is not disturbed.
4. Send DATA message with Interface Identifier = X and other required
parameters with valid values from ASP to SGP.
5. Check C: A DATA Receive Indication is sent to NIF.
6. Repeat the above test case for invalid value of Sequence Number
field like -2 etc. Response should be same.
Note: The Sequence Number parameter is optional, if it is not used Line
6 of the above Test case is not applicable.
Manish Sharma, HSS [Page 75]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Error - Protocol Error"
+ TEST NUMBER : 4.3.21
+ TITLE : Invalid Message Handling
+ SUBTITLE : Handling of Bogus messages.
+ PURPOSE: To check that if a message with no significance for SGP is
received at SGP it is discarded and an ERROR message is sent with
Cause "Protocol Error".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF
ASP is Active
NTFY ---------------->
(AS-Active)
<--------------- Error
(Cause = Protocol Error)
DATA Msg---------------->
(Interface Id = X)
Data Receive Ind --------->
TEST DESCRIPTION:
1. Send NTFY message with Status as AS-active from ASP to SGP.
2. Check A: SGP will send an Error message with Cause "Protocol Error".
The NTFY message will be discarded.
3. Check B: State of ASP at SGP is not disturbed.
4. Send DATA message with Interface Identifier = X and other required
parameters with valid values from ASP to SGP.
Manish Sharma, HSS [Page 76]
Internet Draft M2UA Conformance Test Plan Oct 2003
5. Check C: A DATA Receive indication is sent to the NIF.
6. Repeat the above test for other messages which are only meant to be
sent from SGP and not to be received (example- ASPAC-Ack, ASPIA-
Ack).
"Error - Refused - Management Blocking"
+ TEST NUMBER : 4.3.22
+ TITLE : Refused - Management Blocking
+ SUBTITLE : Refused - Management Blocking
+ PURPOSE: To check that if ASPUP or ASPAC messages are received at
SGP and Management is Locked out an ERROR message is sent to the
requesting ASP with Cause "Refused-Management Blocking".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in ASP-Down state and is "blocked" at SGP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Down
ASPUP ---------------->
<--------------- Error
(Cause = Refused - Management Blocking)
ASPAC ---------------->
<--------------- Error
(Cause = Refused - Management Blocking)
TEST DESCRIPTION:
Manish Sharma, HSS [Page 77]
Internet Draft M2UA Conformance Test Plan Oct 2003
1. Send ASPUP message from ASP to SGP.
2. Check A: Error should be sent from SGP with Cause
"Refused - Management Blocking" to ASP.
3. Check B: The state of ASP at SGP is not disturbed.
4. Send ASPAC message from ASP to SGP.
5. Check A: Error should be sent from SGP with Cause
"Refused - Management Blocking" to ASP.
6. Check B: The state of ASP at SGP is not disturbed.
"ERROR Message Handling"
+ TEST NUMBER : 4.3.23
+ TITLE : ERROR Handling
+ SUBTITLE : Handling of Received Error
+ PURPOSE: To check that if an ERROR message is received then that is
reported to the SM and no ERROR message is sent to peer which sent
the ERROR message in the first place.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
ERROR ---------------->
(Cause = Invalid version)
Error Ind --------->
TEST DESCRIPTION:
Manish Sharma, HSS [Page 78]
Internet Draft M2UA Conformance Test Plan Oct 2003
1. Send ERROR message with Cause "Invalid Version" from ASP to SGP.
2. Check A: Error should be reported to the SM.
3. Check B: No ERROR message must be received at the ASP.
4. Repeat the test case for other Cause values in ERROR message.
Note: Further action at the SGP are implementation dependent and ERROR-
Code dependent.
SM may tear down the connection or no action may be taken.
"Error - Unexpected Parameter"
+ TEST NUMBER :4.3.24
+ TITLE : Invalid Message Handling
+ SUBTITLE : Unexpected parameter in MAUP messages.
+ PURPOSE: To check that if a message containing an Invalid Parameter
is received at SGP then the SGP responds with an ERROR message
containing cause "Unexpected Parameter".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP, and ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
DATA Msg ---------------->
(Parameter Tag = 0x13
in place of 0x2 )
Manish Sharma, HSS [Page 79]
Internet Draft M2UA Conformance Test Plan Oct 2003
<--------------- ERROR
(Cause = Unexpected Parameter)
DATA Msg ---------------->
(Interface Id = X)
DATA Receive Ind --------->
TEST DESCRIPTION:
1. Send DATA message with a parameter other than Interface Identifier
from ASP to the SGP.
2. Check A: ERROR message will be received at ASP containing cause
"Unexpected Parameter".
3. Check B: State of ASP at SGP is not disturbed.
4. Send a DATA Message from ASP with valid parameters including
Interface Identifier = X.
5. Check C: A DATA Receive Indication is sent to NIF.
6. Repeat the above test case for other MAUP and ASPM messages.
"Error - ASP Identifier Required"
+ TEST NUMBER :4.3.25
+ TITLE : Invalid Message Handling
+ SUBTITLE : Absence of ASP Identifier in ASPUP message when
required.
+ PURPOSE: To check that if an ASPUP message is received at the SGP
without any ASP identifier and SGP cannot identify the ASP by pre-
configured address/port number information, SGP send an ERROR
message to the ASPUP message sending ASP with Cause "ASP Identifier
Required".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP, and ASP is Down. The Address/Port number information for
the ASP is not configured at the SGP.
Manish Sharma, HSS [Page 80]
Internet Draft M2UA Conformance Test Plan Oct 2003
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Down
ASPUP ---------------->
(No ASP ID)
<--------------- ERROR
(Cause = ASP Identifer Required)
TEST DESCRIPTION:
1. Send ASPUP message without ASP Identifier from ASP to SGP.
2. Check A: ERROR message will be received at ASP containing cause
"ASP Identifier Required".
"Error - Invalid ASP Identifier"
+ TEST NUMBER :4.3.26
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid ASP Identifier in ASPUP message.
+ PURPOSE: To check that if an ASPUP message is received at the SGP
with a non-unique ASP identifier, SGP sends an ERROR message
to the ASPUP message sending ASP with Cause "Invalid ASP
Identifier".
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and both ASPs (i.e. ASP1 and ASP2). ASP1 is in ASP-Inactive state
and the ASP-Identifier for ASP1 is 'T'. ASP2 is in ASP-Down State.
EXPECTED MESSAGE SEQUENCE :
Manish Sharma, HSS [Page 81]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP2 SGP SM + NIF
ASP1 is Inactive
ASP2 is Down
ASPUP (ASP2)---------------->
(ASP ID = 'T')
<--------------- ERROR (to ASP2)
(Cause = Invalid ASP Identifier)
TEST DESCRIPTION:
1. Send ASPUP message with ASP Identifier 'T' from ASP2 to SGP.
2. Check A: ERROR message will be received at ASP2 containing cause
"Invalid ASP Identifier". The ASPUP message is discarded.
3. Check B: No ERROR message is received at ASP1.
"Error - Missing Parameter"
+ TEST NUMBER :4.3.27
+ TITLE : Invalid Message Handling
+ SUBTITLE : Missing Mandatory Parameter
+ PURPOSE: To check that if a message is received at the SGP
not containing a Mandatory Parameters, SGP responds with an ERROR
message to the message sending ASP with Cause "Missing Parameter".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP, and ASP is Active.
EXPECTED MESSAGE SEQUENCE :
Manish Sharma, HSS [Page 82]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP SGP SM + NIF
ASP is Active
DATA Msg ---------------->
(No Interface Id)
<--------------- ERROR
(Cause = Missing Parameter)
DATA Msg ---------------->
(Interface Id = X)
DATA Receive Ind ---------->
TEST DESCRIPTION:
1. Send DATA message without any Interface Identifier in the M2UA
Header from ASP to SGP which is a mandatory parameter for MAUP
messages like the DATA message.
2. Check A: ERROR message will be received at ASP containing cause
"Missing Parameter".
3. Check B: State of the ASP at SGP is not disturbed.
4. Send a DATA Msg from ASP to SGP with valid parameters including
Interface Identifier = X.
5. Check C: A DATA Receive Indication is sent to SM.
6. Repeat the above Test case for other MAUP and ASPM messages
containing Mandatory Parameters.
4.4 MAUP Messages
4.4.1 Link Management Messages
"Link Management"
+ TEST NUMBER :4.4.1
Manish Sharma, HSS [Page 83]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ TITLE : Link Management
+ SUBTITLE : Link Establish and Release Request
+ PURPOSE: To check that if Establish Request is received from
ASP then NIF is indicated that establish request has been received.
Also a corresponding indication is sent to NIF in case a Release
Request is received.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ESTABLISH REQUEST ------------>
Establish Request Ind ---------->
RELEASE REQUEST -------------->
Release Request Ind------------>
TEST DESCRIPTION:
1. Send ESTABLISH REQUEST message from ASP to the SGP with Interface
Identifier X and Y.
2. Check A: Establish Request indication should be received at the NIF.
3. Repeat the above test case for RELEASE REQUEST message from ASP to
SG. Release Request indication should be sent to the NIF.
4. When ASP sends an Establish Request message, it starts a timer. This
Timer is stopped after receiving Establish Confirm message from the
other side.
Repeat the above test case arranging the data such that the Timer at
ASP expires and ASP resends the Establish Request message and
restart the Timer.
Manish Sharma, HSS [Page 84]
Internet Draft M2UA Conformance Test Plan Oct 2003
Note: The NIF maps the Establish Request Indication and the Release
Request Indication that reach the NIF to Start Req and Stop Req
Primitives respectively which are sent to the MTP2 at the SG side.
"Link Management"
+ TEST NUMBER :4.4.2
+ TITLE : Link Management
+ SUBTITLE : Establish and Release Confirmation and Indication
Primitive from NIF
+ PURPOSE: To check that if Establish and Release Confirm Primitive
is sent from NIF to M2UA at SGP then SGP sends ESTABLISH
CONFIRMATION and RELEASE CONFIRMATION message to the concerned ASP.
If Release Indication primitive is received from NIF then RELEASE
INDICATION is sent from SGP to ASP.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 in AS1 and AS2 respectively. Both ASPs are Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1, ASP2 are Active
<------Establish Confirmation
(Interface Id = X)
(ASP1)<-----------------ESTABLISH CONFIRMATION
<------Release Confirmation
Manish Sharma, HSS [Page 85]
Internet Draft M2UA Conformance Test Plan Oct 2003
(Interface Id = X)
(ASP1)<-----------------RELEASE CONFIRMATION
<------Release Indication
(Interface Id = X)
(ASP1)<-----------------RELEASE INDICATION
TEST DESCRIPTION:
1. Send Establish Confirmation Primitive from NIF to M2UA at SGP with
Interface Identifier = X.
2. Check A: ESTABLISH CONFIRMATION message will be received at ASP1
containing the Interface Identifier passed to it from NIF.
3. Check B: ESTABLISH CONFIRMATION message is received only at ASP1 and
not at ASP2.
4. Repeat the above test case for Release Confirmation Primitive and
Release Indication Primitive. In these cases RELEASE CONFIRAMTION
and RELEASE INDICATION messages will be received at ASP1 and not at
ASP2.
5. Repeat the above test case with Interface Identifier P.
In this case message will be received at ASP2 and not at ASP1.
Note: Here the NIF maps the "In Serv" Indication and "Out of Serv"
Indication sent by the MTP2 at the SG side to Estsblish Confirm and
Release Confirm Primitive respectively sent to the M2UA layer of the
SGP. Again, the NIF maps "Out of Serv" primitive to Release Indication
which is then sent to M2UA at SGP.
Manish Sharma, HSS [Page 86]
Internet Draft M2UA Conformance Test Plan Oct 2003
"State Request"
+ TEST NUMBER : 4.4.3
+ TITLE : STATE Request primitive
+ SUBTITLE : STATE Request primitive
+ PURPOSE: To check that if State request message is received from
ASP then NIF is sent State Request primitive.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
STATE REQUEST ------------>
(State = Status_LPO_Set)
State Request --------------->
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to SGP with state parameter
Status_LPO_Set and Interface Identifier X.
2. Check A: State Request primitive will be received at the NIF at SG
containing the Interface Identifier X and State received.
3. Repeat the above test case for other valid State parameter
values(example-STATUS_LPO_CLEAR).
Manish Sharma, HSS [Page 87]
Internet Draft M2UA Conformance Test Plan Oct 2003
"State Request(Audit)-1"
+ TEST NUMBER :4.4.4
+ TITLE : STATE Request primitive
+ SUBTITLE : Auditing of SS7 link state
+ PURPOSE: To check that if State Request message for auditing of the
Link state is received from ASP then it is processed appropriately.
(When the SS7 link is in-service ).
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. The state of SS7 link is In-Service.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
STATE REQUEST ------------>
(State = Status_Audit)
<--------------Establish Confirm
<--------------State Confirm
(State = Status_Audit)
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to SG with State parameter
Status_Audit for the link which is In-Service and with Interface
Identifier X.
2. Check A: State Confirm massage with state parameter is received at
ASP.
3. A message Establish Confirm is also received at ASP indicating
the link is in-service.
Manish Sharma, HSS [Page 88]
Internet Draft M2UA Conformance Test Plan Oct 2003
"State Request(Audit)-2"
+ TEST NUMBER :4.4.5
+ TITLE : STATE Request primitive
+ SUBTITLE : Auditing of SS7 link state
+ PURPOSE: To check that if State Request message for auditing of the
Link state is received from ASP then it is processed appropriately.
(When the state of SS7 link is In-Service, but congested).
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP. ASP is Active. The state of SS7 link is In-Service,
but congested.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
STATE REQUEST ------------>
(State = Status_Audit)
<--------------Establish confirm
<--------------Congestion Indication
<--------------State Confirm
(State = Status_Audit)
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to SG with State parameter
Status_Audit for the link which is In-Service but congested and with
Interface Identifier X.
2. Check A: State Confirm massage with state parameter is received at
Manish Sharma, HSS [Page 89]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP.
3. Check B: A Establish confirm message is received at ASP indicating
the link is In-Service.
4. Check C: A Congestion Indication message is received at ASP
indicating the level of congestion.
"State Request(Audit)-3"
+ TEST NUMBER : 4.4.6
+ TITLE : STATE Request primitive
+ SUBTITLE : Auditing of SS7 link state
+ PURPOSE: To check that if State Request message for auditing of the
Link state is received from ASP then it is processed appropriately.
(When the state of SS7 link is in-service, but in Remote Processor
Outage).
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. The state of SS7 link is in-service, but in
Remote Processor Outage.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
STATE REQUEST ------------>
(State = Status_Audit)
<--------------Establish confirm
<--------------State Indication
(Event = Event_RPO_Enter)
<--------------State Confirm
(State = Status_Audit)
Manish Sharma, HSS [Page 90]
Internet Draft M2UA Conformance Test Plan Oct 2003
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to SGP with state parameter
Status_Audit for the link which is in Remote Processor Outage and
with Interface Identifier X.
2. Check A: State Confirm massage with State parameter is received at
ASP.
3. Check B: An Establish confirm message is received at ASP indicating
the link is In-Service.
4. Check C: A State Indication message is received at ASP with the
Event field containing EVENT_RPO_ENTER.
"State Request(Audit)-4"
+ TEST NUMBER : 4.4.7
+ TITLE : STATE Request primitive
+ SUBTITLE : Auditing of SS7 link state
+ PURPOSE: To check that if State Request message for auditing of the
Link state is received from ASP then it is processed appropriately.
(When the state of SS7 link is Out-of-Service).
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. The state of SS7 link is Out-of-Service.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
STATE REQUEST ------------>
(State = Status_Audit)
<--------------Release Indication
Manish Sharma, HSS [Page 91]
Internet Draft M2UA Conformance Test Plan Oct 2003
<--------------State Confirm
(State = Status_Audit)
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to SGP with state parameter
Status_Audit for the link which is now Out-of-Service and with
Interface Identifier X.
2. Check A: State Confirm message with state parameter is received at
ASP.
3. Check B: A Release Indication message is also received at ASP
indicating the link is Out-of-Service.
"State Confirm"
+ TEST NUMBER : 4.4.8
+ TITLE : STATE Confirm primitive
+ SUBTITLE : STATE Confirm primitive
+ PURPOSE: To check that if State Confirm primitive is received from
Upper Layer Protocol (ULP) at SGP with interface identifier and
State then STATE CONFIRM message is sent from SGP to all the ASP
which are handling traffic for that Interface Identifier.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 in AS1 and AS2 respectively and both ASPs are active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1, ASP2 are Active
<--------------State Confirm
Manish Sharma, HSS [Page 92]
Internet Draft M2UA Conformance Test Plan Oct 2003
(State = Status_LPO_Set)
(ASP1)<--------------STATE CONFIRM
TEST DESCRIPTION:
1. Send State Confirm primitive from NIF at SGP with State
Status_LPO_Set and Interface Identifier X.
2. Check A: STATE CONFIRM message will be received at ASP1 with state
as Status_LPO_Set.
3. Check B: STATE CONFIRM message will not be received at ASP2.
4. Repeat the above test case for different valid values of State
Parameter. STATE CONFIRM message will be received at ASP1 with the
State parameter sent in State Confirm primitive from NIF at the SGP.
"Congestion Indication"
+ TEST NUMBER : 4.4.9
+ TITLE : Congestion Indication primitive
+ SUBTITLE : Congestion Indication primitive
+ PURPOSE: To check that if the MSU buffer fill increases above an
Onset threshold or decrease below an Abatement threshold or crosses
a Discard threshold ,the SGP sends a congestion indication message
to ASP which is handling traffic for that Interface Identifier.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SGP is having SCTP association with
ASP and the ASP is active.
The MSU buffer fill is above the threshold value.
EXPECTED MESSAGE SEQUENCE :
SU+SM ASP SGP NIF+SM
Manish Sharma, HSS [Page 93]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP is Active
<----------Cong. Indication
<--------Congestion Indication
(Congestion Status)
(Interface Id = X)
<--------Congestion Indication
<----------Congestion Cease Ind
<--------Congestion Indication
(Congestion Status = LEVEL_NONE)
(Interface Id = X)
<--------Congestion Cease Ind
TEST DESCRIPTION:
1. CHECK A: M2UA at SGP receives Congestion Indication primitive from
NIF with corresponding Congestion Status, Discard Status and with
Interface Identifier X.
2. CHECK B: Congestion Indication message is sent to peer M2UA at
ASP from M2UA at SGP with corresponding level of congestion and
Discard Status.
3. CHECK C: The M2UA at ASP sends a Congestion Indication primitive to
the ULP after it receives a Congestion Indication message from SGP.
4. Now, let MTP2 at SGP detect no Congestion.
CHECK D: M2UA at SGP receives Congestion Cease Indication from NIF.
5. CHECK E: Congestion Indication message with Congestion Status
LEVEL_NONE is sent to peer M2UA at ASP from M2UA at SGP.
6. CHECK F: The M2UA at ASP sends a Congestion Cease Indication to the
ULP after it receives a Congestion Indication message from SGP.
Note1: For networks that do not support multiple levels of congestion,
only the LEVEL_NONE and LEVEL_3 values will be used. For networks
that support multiple levels of congestion, it is possible for all
values to be used.
Manish Sharma, HSS [Page 94]
Internet Draft M2UA Conformance Test Plan Oct 2003
Note2: The Discard Status in the Congestion Indication is an optional
field and might not be supported in an implementation.
"State Indication"
+ TEST NUMBER : 4.4.10
+ TITLE : STATE Indication primitive
+ SUBTITLE : STATE Indication primitive
+ PURPOSE: To check that if State Indication primitive is received
from ULP at SGP with Interface Identifier then STATE INDICATION
message is sent from SGP to all the ASPs which are handling traffic
for that Interface Identifier.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 in AS1 and AS2 respectively and both ASPs are active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1, ASP2 are Active
<------------ State Indication
(State = Event_RPO_ENTER)
(Interface Id = X )
(ASP1)<-------------------STATE INDICATION
TEST DESCRIPTION:
1. Send State Indication primitive with Event field equal to
Even_RPO_ENTER from NIF at SGP with Interface Identifier X.
2. Check A: STATE INDICATION message will be received at ASP1 with
Event field as Event_RPO_Enter.
3. Check B: STATE INDICATION message will not be received at ASP2.
4. Repeat the above test case for different valid State Indications
from NIF(example - RPO Rcvr Indication). STATE INDICATION message
Manish Sharma, HSS [Page 95]
Internet Draft M2UA Conformance Test Plan Oct 2003
will be received at ASP1 with the Event parameter sent in State
Indication primitive from NIF at the SGP.
5. Repeat the above Test by sending the RPO Indication primitive with
Interface Identifier equal to P. The STATE INDICATION message will
be received at ASP2 and not ASP1.
"Retrieval Request "
+ TEST NUMBER : 4.4.11
+ TITLE : Retrieval Request message
+ SUBTITLE : Retrieval Request message
+ PURPOSE: To check that if RETRIEVAL REQUEST message is received
from ASP with Action parameter as Action_Rtrv_BSN then SGP sends
Retrieval Request primitive to the NIF.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
RETRIEVAL REQUEST ------------>
(Action = Action_Rtrv_BSN)
(Sequence Number = 0)
Retrieval Request --------------->
(Action = Action_Rtrv_BSN)
(Sequence Number = 0)
TEST DESCRIPTION:
1. Send RETRIEVAL REQUEST message from ASP to SGP with Action parameter
Manish Sharma, HSS [Page 96]
Internet Draft M2UA Conformance Test Plan Oct 2003
as Action_Rtrv_BSN, Interface Identifier X.
Sequence Number parameter should be 0 this case.
2. Check A: NIF at SGP will receive Retrieval Request primitive
with action field as Action_Rtrv_BSN.
3. Repeat the above test case with the other valid Action parameter
value i.e. Action_Rtrv_Msgs. In case of action parameter as
Action_Rtrv_Msgs Sequence Number field should contain the Forward
Sequence Number(FSN) of the far end.
"Retrieval Confirm, Indication and Complete Indication"
+ TEST NUMBER : 4.4.12
+ TITLE : Retrieval CONFIRM, INDICATION and COMLETE INDICATION
messages
+ SUBTITLE : Retrieval CONFIRM, INDICATION and COMLETE INDICATION
messages
+ PURPOSE: To check that if Retrieval Confirm Primitive is received
from NIF with Action as Action_Rtrv_BSN and BSN retrieved in
Sequence Number field then SGP sends RETRIEVAL CONFIRM message to
the concerned ASP with the Action and BSN number passed to it from
NIF.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 and both ASPs are Active. Let there be total of "n" number of
messages to be retrieved.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1, ASP2 are Active
RETRIEVAL REQUEST ------------>
(Action = Action_Rtrv_BSN)
(Sequence Number = 0)
Manish Sharma, HSS [Page 97]
Internet Draft M2UA Conformance Test Plan Oct 2003
Retrieval Request --------------->
(Action = Action_Rtrv_BSN)
(Sequence Number = 0)
<----------Retrieval Confirm
(Action = Action_Rtrv_BSN)
(Sequence Number = BSN)
(Interface Identifier = X)
(ASP1)<------------RETRIEVAL CONFIRM
(Action = Action_Rtrv_BSN)
(Sequence Number = BSN)
RETRIEVAL REQUEST ------------>
(Action = Action_Rtrv_MSGS)
(Sequence Number = FSN)
Retrieval Request --------------->
(Action = Action_Rtrv_MSGS)
(Sequence Number = FSN)
<----------Retrieval Indication
MSU from retransmit
queue and not last MSU
(Interface Id = X)
(ASP1)<---------------RETRIEVAL INDICATION
<----------Retrieval Indication
MSU from retransmit
queue and not last MSU
(Interface Id = X)
(ASP1)<---------------RETRIEVAL INDICATION
<----------Retrieval Indication
MSU from retransmit
queue and not last MSU
(Interface Id = X)
(ASP1)<---------------RETRIEVAL INDICATION
... n-1 RETRIEVAL INDICATIONs
Manish Sharma, HSS [Page 98]
Internet Draft M2UA Conformance Test Plan Oct 2003
<----------Retrieval Complete
Indication
MSU from retransmit
queue and last MSU
(Interface Id = X)
(ASP1)<------------RETRIEVAL COMPLETE INDICATION
TEST DESCRIPTION:
1. Send RETRIEVAL REQUEST from ASP to SGP with Action parameter as
Action_Rtrv_BSN and Sequence Number as 0.
SGP will receive retrieval request and send it to NIF.
Send Retrieval Confirm primitive from NIF at SGP with action
Action_Rtrv_BSN and BSN in the Sequence Number field.
2. Check A: RETRIEVAL CONFIRM message will be received at the ASP1.
3. Check B: RETRIEVAL CONFIRM message will not be received at the ASP2.
4. Check C: In the RETRIEVAL CONFIRM message, Action field is
Action_Rtrv_BSN and Sequence Number field is BSN.
Check the Result field for RESULT_SUCCESS.
5. Repeat the above test case if the Sequence Number field in Retrieval
Confirm primitive from NIF is not included, indicating BSN retreival
failure.
Check D: In the RETRIEVAL CONFIRM message, Action field is
Action_Rtrv_BSN and the Result field contains RESULT_FAILURE.
The Sequence Number field is not included.
6. Send RETRIEVAL REQUEST from ASP to SGP with Action field equal to
Action_Rtrv_MSGS and FSN in the Sequence Number field. SGP will
receive retrieval request and send it to NIF.
Send Retrieval Indication primitive containing MSU n-1 times from
NIF.
7. Check E: RETRIEVAL INDICATION is sent n-1 times to the ASP1 with the
PDU containing the MSU received from NIF.
8. Send Retrieval Complete Indication primitive containing MSU from NIF
and it is the last MSU.
Manish Sharma, HSS [Page 99]
Internet Draft M2UA Conformance Test Plan Oct 2003
9. Check F: RETRIEVAL COMPLETE INDICATION is received at the ASP1 with
the PDU containing the MSU received from NIF.
10. Repeat the above test cases for Interface Identifier P.
In this case messages will be received at ASP2 and not at ASP1.
4.4.2 Data Transfer Messages
"DATA Primitive"
+ TEST NUMBER : 4.4.13
+ TITLE : DATA Primitive at SGP
+ SUBTITLE : Handling of DATA Primitives in AS active state
+ PURPOSE: To check that on receiving DATA Send primitive from ULP,
DATA message is sent to the AS. Also on receiving DATA message from
ASP, NIF is sent Receive Data Indication from M2UA at SGP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP
NIF+SM
ASP is Active
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
DATA Msg--------------->
Data Receive Ind ------------->
TEST DESCRIPTION:
1. Send DATA Send Primitive from the NIF to M2UA at SGP side to send
Manish Sharma, HSS [Page 100]
Internet Draft M2UA Conformance Test Plan Oct 2003
Protocol Data to the ASP with Interface Identifier X.
2. Check A: DATA message is received at the ASP containing the data and
the Interface Identifier X passed by the NIF.
3. Send DATA message from ASP to SGP containing Protocol Data and
Interface Identifier X.
4. Check B: Data Receive Indication is received at the NIF.
"DATA Primitive"
+ TEST NUMBER : 4.4.14
+ TITLE : DATA Primitive at SGP
+ SUBTITLE : Handling of DATA Primitives in AS active state for
Override AS traffic mode type.
+ PURPOSE: To check that on receiving DATA Send primitive from ULP,
DATA message is sent to the ASP for Override AS traffic mode type.
+ TEST CONFIGURATION:C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASPs and ASP1 is active. The Traffic Handling Mode for the AS
is configured as Override at SGP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1 Active
ASP2 Inactive
<-------- Data
(Interface Id = X)
(ASP1)<----------------- DATA Msg
<-------- Data
(Interface Id = Y)
Manish Sharma, HSS [Page 101]
Internet Draft M2UA Conformance Test Plan Oct 2003
(ASP1)<----------------- DATA Msg
ASP2 Active
ASP1 Inactive
<-------- Data
(Interface Id = X)
(ASP2)<----------------- DATA Msg
<-------- Data
(Interface Id = Y)
(ASP2)<----------------- DATA Msg
TEST DESCRIPTION:
1. Send Data Send primitives from NIF to M2UA at SGP with Interface
Identifiers Xand Y following which SGP will send Protocol DATA to
ASP1.
2. CHECK A: Both the DATA messages are sent to ASP1.
3. Make ASP2 Active in Override mode in AS1.
Again send the Data Send Primitives from NIF to M2UA at SGP with
Interface Identifiers X and Y.
4. CHECK B: Both the DATA messages are sent to ASP2.
"DATA Primitive"
+ TEST NUMBER : 4.4.15
+ TITLE : DATA Primitive at SGP
+ SUBTITLE : Handling of DATA Primitive in AS active state, for
Loadshare AS traffic mode type.
+ PURPOSE: To check that on receiving DATA primitive from ULP, DATA
message is sent to appropriate ASP for Loadshare AS Traffic
Handling Mode.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and both ASPs and both ASPs are active. The Traffic Handling Mode
for the AS is configured as Loadshare at SGP.
Manish Sharma, HSS [Page 102]
Internet Draft M2UA Conformance Test Plan Oct 2003
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1, ASP2 are Active
<-------- Data
(Interface Id = X)
(ASP1)<----------------- DATA Msg
<-------- Data
(Interface Id = Y)
(ASP2)<----------------- DATA Msg
TEST DESCRIPTION:
1. Send Data Send primitives from NIF to M2UA at SGP with Interface
Identifiers X and Y following which SGP will send Protocol DATA to
ASP.
2. CHECK A: First DATA message is sent to ASP1 and the second is sent
to ASP2.
"DATA Primitive"
+ TEST NUMBER : 4.4.16
+ TITLE : DATA Primitive at SGP
+ SUBTITLE : Handling of DATA Primitive in AS active state, for
Broadcast AS traffic mode type.
+ PURPOSE: To check that on receiving DATA primitive from ULP, DATA
message is sent to the ASP for Broadcast AS traffic mode type.
+ TEST CONFIGURATION: C
Manish Sharma, HSS [Page 103]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and both ASPs and only ASP1 is Active. ASP2 is Inactive.The Traffic
Handling Mode for the AS is configured as Broadcast at SGP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP1 is Active
ASP2 is Inactive
<-------- Data
(Interface Id = X)
(ASP1)<----------------- DATA Msg
<-------- Data
(Interface Id = Y)
(ASP1)<----------------- DATA Msg
ASP2 Active
ASP1 Active
<-------- Data
(Interface Id = X)
(ASP1)<----------------- DATA Msg
(Corelation Id)
(ASP2)<----------------- DATA Msg
(Corelation Id)
DATA Ack (ASP1)------------->
(Correlation Id)
DATA Ack (ASP2)------------->
(Correlation Id)
<-------- Data
(Interface Id = Y)
(ASP1)<----------------- DATA Msg
(ASP2)<----------------- DATA Msg
Manish Sharma, HSS [Page 104]
Internet Draft M2UA Conformance Test Plan Oct 2003
TEST DESCRIPTION:
1. Send Data Send primitives from NIF to M2UA at SGP with Interface
Identifiers X and Y following which SGP will send Protocol DATA to
AS.
2. CHECK A: Both DATA messages are sent to ASP1.
3. Make ASP2 Active in Broadcast mode in AS1.
Again send Data Send primitives from NIF to M2UA at SGP with
Interface Identifiers X and Y.
4. CHECK B: Both the DATA messages are sent to all active ASP i.e.
ASP1, ASP2.
First DATA message after a new ASP Active contains Correlation Id.
5. CHECK C: The SGP will receive DATA Ack messages for the DATA
messages containing Correlation Ids sent.
CHECK D: The DATA Ack messages should have the same Correlation Ids
which were sent in the DATA messages.
"TTC DATA Primitive"
+ TEST NUMBER : 4.4.17
+ TITLE : TTC DATA Primitive
+ SUBTITLE : Handling of TTC DATA Primitive in AS active state.
+ PURPOSE: To check that on receiving TTC DATA Send primitive from
ULP, TTC DATA message is sent to the AS. Also, on receiving TTC
DATA message from ASP, NIF is sent Receive Data Indication.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is active.
EXPECTED MESSAGE SEQUENCE :
Manish Sharma, HSS [Page 105]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP SGP NIF+SM
ASP is Active
<-------- TTC Data
<----------------- TTC DATA Msg
TTC DATA Msg --------------->
TTC DATA Receive Ind ------------->
TEST DESCRIPTION:
1. Send TTC DATA Send Primitive from the NIF to M2UA at SGP side to
send Protocol Data to the ASP with Interface Identifier X.
2. Check A: TTC DATA message is received at the ASP containing the data
and the Interface Identifier X passed by the NIF.
3. Send TTC DATA message from ASP to SGP containing Protocol Data and
Interface Identifier X.
4. Check B: TTC DATA Receive Indication is received at the NIF.
"Message Routing"
+ TEST NUMBER : 4.4.18
+ TITLE : Message Routing
+ SUBTITLE : Message Routing towards ASP
+ PURPOSE: To check that if NIF sends a Data Send primitive
containing Protocol DATA to be send to the ASP then it is sent to
the correct ASP.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 in AS1 and AS2 respectively, and both ASPs are Active.
Manish Sharma, HSS [Page 106]
Internet Draft M2UA Conformance Test Plan Oct 2003
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 SGP NIF+SM
ASP1, ASP2 are Active
<-------- Data
(Interface Id = X)
<------------------------- DATA Msg
<-------- Data
(Interface Id = Y)
<------------------------- DATA Msg
<-------- Data
(Interface Id = P)
<------------ DATA Msg
TEST DESCRIPTION:
1. Send Data Send primitive from NIF to M2UA in the SGP containing
Protocol Data to be sent to the ASP with Interface Identifier X.
2. Check A: DATA message will be received at the ASP1.
3. Repeat the above test case for Data Send primitive containing
Protocol Data and Interface Identifier Y. Data message should be
received at ASP1.
4. Repeat the above test case for Data Send primitive containing
Protocol Data and Interface Identifier P. Data message should be
received at ASP2.
"Message Routing"
+ TEST NUMBER :4.4.19
+ TITLE : Message Routing
+ SUBTITLE : Routing for DATA not matching any Interface Identifier
+ PURPOSE: To check that if NIF sends a Data Send primitive
Manish Sharma, HSS [Page 107]
Internet Draft M2UA Conformance Test Plan Oct 2003
containing Protocol DATA and Interface Identifier not defined at
the SGP then Error Message should be returned or some default
routing is given to this message.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
ASP2 and both ASPs are Active. Interface Identifier Z, is not
defined at SGP.
EXPECTED MESSAGE SEQUENCE :
ASP1 ASP2 SGP NIF+SM
ASP1, ASP2 are Active
<-------- Data
(Interface Id = Z)
Error ------------------>
TEST DESCRIPTION:
1. Send Data Send primitive from NIF in the SGP with Interface
Identifier Z.
2. Check A: Error should be returned or some default routing will be
given to this protocol data.
"SCTP Stream Management"
+ TEST NUMBER : 4.4.20
+ TITLE : SCTP Stream Management
+ SUBTITLE : Same Stream selection for same Interface Identifier
+ PURPOSE: To check that all the messages for the same Interface
Manish Sharma, HSS [Page 108]
Internet Draft M2UA Conformance Test Plan Oct 2003
Identifier are sent on the same SCTP stream.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP with two streams and ASP is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
TEST DESCRIPTION:
1. Send three or more DATA Send Primitives with same Interface
Identifier value X from the NIF to M2UA at SGP side to send Protocol
Data to the ASP.
2. Check A: DATA messages are received at the ASP containing the same
Stream Id.
3. Repeat the above test with other Interface Identifier Y.
4. Repeat the above case if number of streams between ASP and SGP is
more than two but AS is handling only two Interface Identifiers. One
or more streams may not be used for sending DATA message.
5. Repeat the above case if number of streams between ASP and SGP is
two but AS is handling four Interface Identifiers. Send DATA
messages for all Interface Identifier. DATA messages should be sent
Manish Sharma, HSS [Page 109]
Internet Draft M2UA Conformance Test Plan Oct 2003
on both the streams and DATA messages for the same Interface
Identifier are sent on the same stream.
Note: The method to distribute messages on different SCTP streams is
implementation specific.
5. Test Cases for Testing M2UA at ASP
5.1 Layer Management Messages
5.1.1 SCTP Connection Management Messages
"SCTP Connection Management"
+ TEST NUMBER : 5.1.1
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Establishment
+ PURPOSE: To check that on receiving M-SCTP-Establish primitive from
SM, ASP M2UA initiates and establishes an SCTP association with
SGP.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is not established between
SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
<--------M-SCTP-Establish
Request
SCTP_ASSOCIATE request issued to SCTP from M2UA at ASP.
SCTP Association will be established between ASP with SGP.
Manish Sharma, HSS [Page 110]
Internet Draft M2UA Conformance Test Plan Oct 2003
M2UA at ASP will receive
SCTP-COMMUNICATION_Up Primitive from SCTP.
M-SCTP-Establish Confirm--------->
TEST DESCRIPTION:
1. Send M-SCTP-Establish Request Primitive with required parameters
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
confirm will be received at the SM.
"SCTP Connection Management"
+ TEST NUMBER : 5.1.2
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Status
+ PURPOSE: To check on receiving M-SCTP_STATUS request from SM, M2UA
will send the M-SCTP_STATUS Indication primitive to SM.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
Manish Sharma, HSS [Page 111]
Internet Draft M2UA Conformance Test Plan Oct 2003
<--------- M-SCTP_STATUS request
M-SCTP_STATUS Indication ---------->
TEST DESCRIPTION:
1. Let the SM at ASP send M-SCTP_STATUS request to M2UA at ASP.
2. Check A: M-SCTP_STATUS Indication will be received at SM.
"SCTP Connection Management"
+ TEST NUMBER :5.1.3
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Termination
+ PURPOSE: To check that on receiving SCTP-Communication Down
Indication (SCTP CDI) primitive from SCTP, M2UA at ASP will send
the M-SCTP Status primitive to the SM.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in Active state. Let the SM at SGP send M-
SCTP_RELEASE to M2UA at SGP. The M2UA then sends a SCTP-SHUTDOWN
primitive to the local SCTP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
<----------M-SCTP_RELEASE
Request
M2UA at ASP sends SCTP-SHUTDOWN primitive to SCTP Layer.
Manish Sharma, HSS [Page 112]
Internet Draft M2UA Conformance Test Plan Oct 2003
SCTP association between ASP and SGP is terminated.
M2UA at ASP will receive SCTP CDI Primitive from SCTP.
M-SCTP_RELEASE Confirm ------>
M-SCTP_Status Ind--------->
<-------- Data
Send Failure --------------->
TEST DESCRIPTION:
1. Terminate the association between SGP and ASP by sending
M-SCTP_RELEASE Request from SU to M2UA at ASP.
2. Check A: SCTP association will be down and on receiving
Communication Down Indication primitive from SCTP, M-SCTP_Status
indication will be received at SM.
3. Check B: State of ASP will be down. Send DATA Send primitive from
the SU to M2UA at ASP to send Protocol DATA. ASP will report send
failure.
4. Repeat the above Test case when SCTP Shutdown is initiated by SGP
side. In that case M-SCTP_RELEASE Indication primitive will be
received at SU as compared to M-SCTP_RELEASE Confirm primitive in
this case.
5. Repeat the above Test Case when SCTP CDI indicating COMMUNICATION-
LOST is received in case of an ungraceful SCTP Shutdown.
5.2 ASPM Messages
5.2.1 ASPSM and ASPTM Messages
Manish Sharma, HSS [Page 113]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Timer T(ack) Cancellation"
+ TEST NUMBER :5.2.1
+ TITLE : AS Management
+ SUBTITLE : Timer T(ack) Cancellation
+ PURPOSE: To check that T(ack) at ASP is cancelled on receiving
ASPIA-Ack from SGP before T(ack) expires.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active. Let value of Timer T(ack) be z seconds.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF+SM
ASP is Active
ASPIA --------------->
Time = z seconds
(T(ack) expires)
ASPIA --------------->
Status Ind.----------------->
(ASP Inactive)
Time < z seconds
T(ack) is running
<-------- ASPIA-Ack
TEST DESCRIPTION:
1. Send ASPIA message from ASP to SGP and restrict the ASPIA-Ack at
SGP.
2. Check A: After T(ack) expires i.e. after z seconds ASP resends ASPIA
message to SGP.
3. Don't restrict the ASPIA-Ack for the next ASPIA message from ASP.
Manish Sharma, HSS [Page 114]
Internet Draft M2UA Conformance Test Plan Oct 2003
4. Check B: Before Timer T(ack) expires ASPIA-Ack is received at ASP
and retransmission of ASPIA messages is stopped.
5. Repeat the above Test for other similar messages for which
acknowledgement is expected(example- ASPUP, ASPDN, ASPAC).
Note: The retransmission of ASP Inactive messages and other such
messages is implementation specific, in some implementations the
retransmission may be put under the control of Layer Management.
"ASPM messages"
+ TEST NUMBER :5.2.2
+ TITLE : AS management
+ SUBTITLE : ASP-Up-Ack message is not received in response to ASPUP
message
+ PURPOSE: To check that if ASP-Up-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 specified time will
report the SM.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in Down State.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Down
<--------------- ASP-Up
<--------------------- ASPUP
Manish Sharma, HSS [Page 115]
Internet Draft M2UA Conformance Test Plan Oct 2003
Timer T(ack) expires
<--------------------- ASPUP
Timer T(ack) expires
.
.
.
<---------------------- ASPUP
Timer T(ack) expires
<---------------------- ASPUP
Timer T(ack) expires
<---------------------- ASPUP
n tries
Status Ind --------------->
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to M2UA at ASP. ASP will send ASPUP
message to the SGP. Restrict the ASPUP-Ack message at the SGP.
2. Check A: ASPUP message will be retransmitted to the SGP.
3. Check B: After n tries M2UA at ASP sends Status Indication to SM.
4. Repeat the above test case for similar messages i.e. that expect an
acknowledgement from the peer M2UA(example-ASPDN, ASPAC, ASPIA).
Note: T(ack) is provisionable, with a default of 2 seconds. The value
of n is also implementation dependent.
Manish Sharma, HSS [Page 116]
Internet Draft M2UA Conformance Test Plan Oct 2003
"ASPM messages"
+ TEST NUMBER :5.2.3
+ TITLE : AS management
+ SUBTITLE : ASP-Down-Ack message is received in response to ASPUP
message
+ PURPOSE: To check that if ASP-Down-Ack message is received in
response to the ASPUP message then ASP sends the ASPUP message
again.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in Down State.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Down
<--------------- ASP-Up
<--------------------- ASPUP
ASP-Dn-Ack --------------->
<---------------------- ASPUP
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to M2UA at ASP. ASP will send ASPUP
message to the SGP. Send ASP-Down-Ack message from the SGP in
response to the ASPUP message before Timer T(ack) expires.
2. Check A: ASPUP message can be retransmitted to the SGP.
3. Check B: The ASP-Dn-Ack message from SGP is discarded.
4. Repeat the above test case using ASP-Active-Ack, ASP-Inactive-Ack
being sent in place of ASP-Dn-Ack message.
Manish Sharma, HSS [Page 117]
Internet Draft M2UA Conformance Test Plan Oct 2003
Note: This case is implementation specific. Every time an Ack message
Is received when one is expected the T(ack) timer is cancelled. But in
Case of Invalid Ack message the Request is sent again and the Timer
T(ack) is started again. The default time for T(ack) is 2 seconds but
it is provisional. The number of trials before the ASP gives up is
again implementation dependent.
"ASPM messages"
+ TEST NUMBER :5.2.4
+ TITLE : ASP Management messages towards SGP
+ SUBTITLE : ASP Management messages towards SGP
+ PURPOSE: To check that if SM sends primitive to send ASP management
messages to M2UA at ASP then the corresponding message is sent to
the SGP.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Active
<-------- ASP-
Inactive
<--------------------- ASPIA
ASPIA-Ack --------------->
NTFY(AS-Pending) --------->
Timer T(r) expires
NTFY(AS-Inactive) -------->
Status Ind------------------>
Manish Sharma, HSS [Page 118]
Internet Draft M2UA Conformance Test Plan Oct 2003
<------------- ASP-Down
<--------------------- ASPDN
ASPDN-Ack -------------->
Status Ind------------------>
<--------------- ASP-Up
<--------------------- ASPUP
ASPUP-Ack -------------->
NTFY(AS-Inactive) ------->
Status Ind------------------>
<-------- ASP-Active
<--------------------- ASPAC
ASPAC-Ack -------------->
NTFY(AS-active) --------->
Status Ind------------------>
TEST DESCRIPTION:
1. Send ASP-Inactive Primitive from SM to M2UA at ASP.
2. Check A: ASPIA message will be received at the SGP.
3. Check B: Corresponding ASP-Inactive-Ack and NTFY message with status
AS-Pending in response to the ASPIA message will be received at ASP.
After the expiry of Timer T(r) a NTFY message with Status AS-
Inactive will be received at ASP.
4. Check C: A Status Indication is sent to the SM by M2UA at ASP.
5. Check D: ASPM messages are received on stream 0.
6. Repeat the test case for other primitives from SM to M2UA like
ASP-Down, ASP-Up and ASP-Active. Corresponding Ack and NTFY messages
will be sent from SGP to ASP.
Manish Sharma, HSS [Page 119]
Internet Draft M2UA Conformance Test Plan Oct 2003
Note: All messages which should be sent on Stream 0 include all ASPM
messages with the exception of ASPTM, BEAT and BEAT Ack messages.
Thus, for the ASPTM messages Check in Line 5 above is not applicable.
Note: The ASPM messages at the ASP may be initiated by the Layer
Management by sending corresponding Primitives to M2UA or may be
initiated automatically by an M2UA management function.
"ASPM messages"
+ TEST NUMBER :5.2.5
+ TITLE : Invalid message processing
+ SUBTITLE : ASP-Up-Ack is received in response to ASPDN message
+ PURPOSE: To check that if ASP-Up-Ack message is received in
response to the ASPDN then the ASP-Up-Ack message is discarded and
ASPDN is sent again.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Active
<-------- ASP-
Down
<--------------------- ASPDN
ASP-Up-Ack --------------->
<--------------------- ASPDN
TEST DESCRIPTION:
Manish Sharma, HSS [Page 120]
Internet Draft M2UA Conformance Test Plan Oct 2003
1. Send ASP-Down Primitive from SM to M2UA at ASP. ASPDN message will
be sent to the SGP. Send ASP-Up-Ack in response to the ASPDN message
before Timer T(ack) expires.
2. Check A: ASPDN message is retransmitted to the SGP.
3. Check B: The ASP-Up-Ack message from SGP is discarded.
4. Repeat the above test case using ASP-Active-Ack, ASP-Inactive-Ack
being sent in place of ASP-Up-Ack message.
Note: Every time an Ack message is received when one is expected the
T(ack) timer is cancelled. But in case of Invalid Ack message the
Request is sent again and the Timer T(ack) is started again. The
Default time for T(ack) is 2 seconds but it is provisionable. The
number of trials before the ASP gives up is again implementation
dependent.
"ASPM messages"
+ TEST NUMBER :5.2.6
+ TITLE : Invalid message processing
+ SUBTITLE : ASP-Active-Ack is received in response to ASPIA message
+ PURPOSE: To check that if ASP-Active-Ack message is received in
response to the ASPIA then the ASP-Active-Ack message is discarded
and ASPIA is sent again.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Active
Manish Sharma, HSS [Page 121]
Internet Draft M2UA Conformance Test Plan Oct 2003
<-------------- ASP-Inactive
<--------------------- ASPIA
ASPAC-Ack --------------->
<--------------------- ASPIA
TEST DESCRIPTION:
1. Send ASP-Inactive Primitive from SM to M2UA at ASP. ASPIA message
will be sent to the SGP. Send ASP-Active-Ack in response to the
ASPIA message before Timer T(ack) expires.
2. Check A: ASPIA message is received again at the SGP.
3. Check B: The ASP-Active-Ack message from SGP is discarded.
4. Repeat the above test case using ASP-Up-Ack, ASP-Dn-Ack being sent
in response to the ASPIA message in place of ASP-Active-Ack.
5. Repeat the above test case using ASPAC in place of ASPIA message and
using ASP-Inactive-Ack, ASP-Up-Ack, ASP-Dn-Ack being sent in
response to the ASPAC message from the ASP.
Note: Every time an Ack message is received when one is expected the
T(ack) timer is cancelled. But in case of Invalid Ack message the
Request is sent again and the Timer T(ack) is started again. The
Default time for T(ack) is 2 seconds but it is provisionable. The
number of trials before the ASP gives up is again implementation
dependent.
"ASPM messages"
+ TEST NUMBER :5.2.7
+ TITLE : ACK messages at ASP are not acknowledged.
+ SUBTITLE : ACK messages at ASP are not acknowledged.
+ PURPOSE: To check that ACK messages at ASP are not acknowledged.
Manish Sharma, HSS [Page 122]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Down.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM
ASP is Down
<--------------- ASP-Up
<--------------------- ASPUP
ASPUP-Ack --------------->
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to ASP. ASPUP message will be sent
from ASP to SGP. Send ASP-Up-Ack from the SGP.
2. Check A: ASPUP-ACK message at ASP is not acknowledged.
3. Repeat the above test case for ASPAC, ASPIA, ASPDN messages.
The result should be same in all the cases.
5.3 MGMT Messages
5.3.1 ERROR Messages
"Error - Invalid Version"
+ TEST NUMBER : 5.3.1
Manish Sharma, HSS [Page 123]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Version Error
+ PURPOSE: To check that if any message with Invalid version is
received at the ASP then ASP responds with ERROR message containing
cause "Invalid Version" and diagnostic information filled with the
version the ASP supports.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM + SU
ASP is active
DATA Msg---------------->
(Version = 2.0)
<--------------- ERROR
(Cause = Invalid Version)
TEST DESCRIPTION:
1. Send DATA message from SGP to ASP containing version 2.0 in the
Common Message Header and other valid parameters.
2. Check A: ERROR message is received at the SGP containing cause
Invalid Version.
3. Check B: Diagnostic Field Parameter in ERROR is filled with version
1.0 .
4. Repeat the above test cases for other messages from SGP to ASP like
ESTABLISH CONFIRM, RELEASE CONFIRM, RELEASE INDICATION, STATE
CONFIRM, STATE INDICATION, DATA RETRIEVAL CONFIRM, DATA RETRIEVAL
INDICATION and DATA RETRIEVAL COMPLETE INDICATION.
Note: The Diagnostic information in the ERROR messages is an optional
parameter which contains information germane to error condition. In
case it is not included the Check in Line 3 above is not applicable.
Manish Sharma, HSS [Page 124]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Error - Unsupported Message Class"
+ TEST NUMBER :5.3.2
+ TITLE : Unsupported Message Handling
+ SUBTITLE : Unsupported Message Class Error
+ PURPOSE: To check that if a message with message class not defined
is received at ASP, ASP responds with ERROR message containing
cause "Unsupported Message Class".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM + SU
ASP is Active
Message ---------------->
(Message Class = 1)
<--------------- ERROR
(Cause = Unsupported Message Class)
DATA ---------------->
(Interface Id = X)
Data receive Ind ------->
TEST DESCRIPTION:
1. Send a message with Message Class 1 or any other value which is not
defined from SGP to ASP with other valid parameters.
2. Check A: ERROR message will be received at the SGP containing cause
"Unsupported Message Class".
3. Check B: State of ASP is not disturbed.
Manish Sharma, HSS [Page 125]
Internet Draft M2UA Conformance Test Plan Oct 2003
4. Send DATA message from SGP to ASP with Interface Identifier = X and
other required parameters with valid values.
5. Check C: A DATA Receive Indication is sent to SU by M2UA at ASP.
"Error - Unsupported Message Type"
+ TEST NUMBER :5.3.3
+ TITLE : Unsupported Message Handling
+ SUBTITLE : Unsupported Message Type Error
+ PURPOSE: To check that if a message with message type not defined
is received at ASP, ASP responds with ERROR message containing
cause "Unsupported Message Type".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP1 is active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM + SU
ASP is Active
Message ---------------->
(Message Type = 0x610)
<--------------- ERROR
(Cause = Unsupported Message Type)
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind ------->
TEST DESCRIPTION:
1. Send a message with message type 0x610 or any other value which is
not defined from SGP to ASP with other valid parameters.
Manish Sharma, HSS [Page 126]
Internet Draft M2UA Conformance Test Plan Oct 2003
2. Check A: ERROR message is received at the SGP containing Cause
Unsupported Message Type and the Message is discarded.
3. Check B: State of ASP is not disturbed.
4. Send DATA message from SGP to ASP with Interface Identifier = X and
other required parameters with valid values.
5. Check C: A DATA Receive Indication is sent to SU by M2UA at ASP.
6. Repeat the above test cases by sending ASPUP, ASPDN, ASPAC, ASPIA
messages from AS which the ASP is not expected to receive. In this
case error will be reported to the SM and message will be discarded.
"Error - Invalid Interface Identifier "
+ TEST NUMBER :5.3.4
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Interface Identifier in MAUP messages
+ PURPOSE: To check that if a message with invalid Interface
Identifier i.e. Interface Identifier not defined at ASP is received
then ASP responds with ERROR message containing Cause
"Invalid Interface Identifier".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM + SU
ASP is Active
DATA Msg ---------------->
(Interface Id = P)
<--------------- ERROR
Manish Sharma, HSS [Page 127]
Internet Draft M2UA Conformance Test Plan Oct 2003
(Cause = Invalid Interface Identifier)
DATA Msg---------------->
(Interface Id = X)
Data receive Ind ------->
TEST DESCRIPTION:
1. Send DATA message with Interface Identifier P that is not defined at
ASP.
2. Check A: ERROR message will be received at SGP containing cause
"Invalid Interface Identifier".
3. Check B: State of ASP is not disturbed.
4. Send DATA message from SGP to ASP with Interface Identifier = X and
other required parameters with valid values.
5. Check C: A DATA Receive Indication is sent to SM.
6. Repeat the above test case for other MAUP messages.
"Error - Parameter Field Error"
+ TEST NUMBER : 5.3.5
+ TITLE : Invalid Message Handling
+ SUBTITLE : Wrong Length Field of a Parameter in the Common Message
Header.
+ PURPOSE: To check that if an MAUP or MGMT message with wrong length
field of a Parameter in Common Message Header or M2UA Header is
sent to ASP then ASP responds with Error message with Cause
"Parameter Field Error".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
Manish Sharma, HSS [Page 128]
Internet Draft M2UA Conformance Test Plan Oct 2003
SGP ASP SM+SU
ASP is Active
RELEASE INDICATION --------------------->
(Length in Interface Id Parameter = 7)
<--------------------Error
(Cause = Parameter Field Error)
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind --------->
TEST DESCRIPTION:
1. Send RELEASE INDICATION message with length in Interface Id
Parameter in M2UA Header less than 8 from SGP to ASP.
2. Check A: RELEASE INDICATION message will be discarded and ERROR
message with Cause "Parameter Field Error" will be sent to the ASP.
3. Check B: State of ASP is not disturbed.
4. Send DATA message from SGP to ASP with Interface Identifier = X and
other required parameters with valid values including the Length
Field.
5. Check C: A Data Receive Indication is sent to SM.
6. Repeat the above test case for other messages like STATE INDICATION,
RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, which include
Parameters in the Common Message Header or M2UA Header.
"Error - Invalid Stream Identifier"
+ TEST NUMBER : 5.3.6
+ TITLE : Invalid stream Identifier
+ SUBTITLE : MGMT messages on SCTP stream other than 0
Manish Sharma, HSS [Page 129]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ PURPOSE: To check that if a MGMT message is received on a stream
other than 0, then an error message is sent to the peer with Cause
"Invalid stream Identifier" .
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Active
<-------------------ASPIA
ASPIA-Ack ----------------->
NTFY(AS-Inactive)---------->
(SCTP Stream other than 0)
<--------------------Error
(Cause = Invalid Stream Identifier)
<-------------------ASPAC
ASPAC-Ack ----------------->
NTFY(AS-active)---------->
TEST DESCRIPTION:
1. Send an ASPIA message from ASP to SGP with valid parameters.
2. An ASPIA-Ack message and a NTFY message with state AS-Pending will
be received at ASP. After the expiry of Timer T(r) SGP will send a
NTFY message with State AS-Inactive. Send this NTFY message on an
SCTP Stream other than 1.
2. Check A: ERROR message with Cause "Invalid Stream Identifier" will
be sent to SGP.
4. Check B: The state of ASP remains Inactive.
5. Now send an ASPAC message from ASP to SGP. A corresponding ASPAC-Ack
Manish Sharma, HSS [Page 130]
Internet Draft M2UA Conformance Test Plan Oct 2003
and NTFY with Status AS-Active are received at ASP. Ensure that
these messages are sent with all valid parameter values including
SCTP Stream.
6. Check C: No ERROR message is sent to SGP.
7. Check D: The State of ASP is Active now.
8. Repeat the above test for other messages which are expected to
come on SCTP Stream 0 at ASP(example- ASP-Up-Ack, ASP-Dn-Ack).
Note: In case an expected Ack message is received on an SCTP Stream
other than 0 at ASP, in addition to the ERROR message the corresponding
message for which the Ack is expected will be again sent and this
process will continue unless a valid Ack message arrives or ASP gives
up.
"Error - Unexpected message"
+ TEST NUMBER : 5.3.7
+ TITLE : Unexpected message
+ SUBTITLE : MAUP message received at ASP when it is not active
+ PURPOSE: To check that if a MAUP message is received on an ASP when
it is not active, then a error message to the peer is sent with
Cause "Unexpected message".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Inactive. Arrange the data in SGP such that
ESTABLISH REQUEST message is sent to ASP.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Inactive
Manish Sharma, HSS [Page 131]
Internet Draft M2UA Conformance Test Plan Oct 2003
ESTABLISH REQUEST---------->
<--------------------Error
(Cause = Unexpected Message)
<------------------- ASPAC
ESTABLISH REQUEST---------->
<--------------------ERROR
(Cause = Unexpected Message)
<----------Data
Send Failure--------->
ASPAC-ACK---------------->
NTFY(AS-Active)---------->
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind --------->
TEST DESCRIPTION:
1. Send DATA message to ASP from SGP while ASP is in Inactive State.
2. Check A: ERROR message with Cause "Unexpected Message" will be
received at SGP.
3. Check B: The State of ASP is not disturbed.
4. Now send ASPAC from ASP side to SGP & before sending the ASPAC-ACK,
send DATA Msg to ASP from SGP.
5. Check C: ERROR message with Cause "Unexpected Message" will be
received at SGP.
6. Send DATA Send Primitive from SU to M2UA at ASP.
7. Check C: Send Failure Indication is sent to the SU by M2UA at ASP.
8. Now send ASPAC-ACK & NTFY(AS-Active) to ASP from SGP.
9. Check: State of ASP is now active.
10. Repeat the above test case for other MAUP messages.
Manish Sharma, HSS [Page 132]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Error - Invalid parameter value"
+ TEST NUMBER : 5.3.8
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid State Parameter in STATE CONFIRM message
+ PURPOSE: To check that if STATE CONFIRM message with Invalid State
Parameter is received at ASP then the message is discarded and an
ERROR message is sent to SGP.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Active
<---------------State Request
<----------------------- STATE REQUEST
STATE CONFIRM ---------------->
(State = 0xb)
message discarded
<--------------- Error
(Cause = Invalid Parameter Value)
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind --------->
TEST DESCRIPTION:
1. The SU at ASP sends an State Request Primitive to M2UA at ASP
corresponding to which M2UA sends STATE REQUEST message to M2UA at
SGP.
Manish Sharma, HSS [Page 133]
Internet Draft M2UA Conformance Test Plan Oct 2003
2. Send STATE CONFIRM message with State Parameter 0Xb from SGP to ASP
which is invalid.
3. Check A: The message is discarded at ASP and an ERROR message with
Cause "Invalid Parameter Value" is sent to SGP.
4. Check B: State of ASP is undisturbed.
5. Send DATA message with Interface Identifier = X and all other valid
values from ASP to SGP.
6. Check C: A DATA Receive Indication is received at SM.
"Error - Invalid parameter value"
+ TEST NUMBER :5.3.9
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Action Parameter in RETRIEVAL CONFIRM message
+ PURPOSE: To check that if RETRIEVAL CONFIRM message with Invalid
Action Parameter is received at ASP then message is discarded and
an ERROR message is sent to the peer.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Active
<---------------Retrieval
Request
(Action = 0x1)
Manish Sharma, HSS [Page 134]
Internet Draft M2UA Conformance Test Plan Oct 2003
<--------------------RETRIEVAL REQUEST
RETRIEVAL CONFIRM ---------------->
(Action = 0x4)
message discarded
<--------------- ERROR
(Cause = Invalid Parameter Value)
DATA Msg---------------->
(Interface Id = X)
Data receive Ind --------->
TEST DESCRIPTION:
1. Send RETRIEVAL REQUEST message with Action parameter value 0x1 from
ASP to SGP with Sequence Number = 0.
Send RETRIEVAL CONFIRM message with Action Parameter 0X4 which is
invalid from SGP to ASP.
2. Check A: The message is discarded and an ERROR message with
Cause "Invalid Parameter Value" is sent to SGP.
3. Check B: State of ASP is undisturbed.
4. Send DATA message with Interface Identifier = X and other required
parameters with valid values from SGP to ASP.
5. Check C: A DATA Receive Indication is sent to SM.
6. Repeat the above test case for invalid value of Sequence Number
field like -2 etc. Response should be same.
Note: The Sequence Number parameter is optional, if it is not used Line
6 of the above Test case is not applicable.
"Error - Invalid parameter value"
Manish Sharma, HSS [Page 135]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ TEST NUMBER :5.3.10
+ TITLE : Invalid Message Handling
+ SUBTITLE : ERROR message with invalid Error Code
+ PURPOSE: To check that if ERROR message with Invalid Error Code
parameter is received then M2UA at ASP doesn't take any action but
discard the message.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Active
<---------------STATE Request
<---------------------STATE REQUEST
ERROR --------------------->
(Error Code = 0x14)
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to the SGP. In response to this
message, send ERROR message with Error Code 0x14 which is invalid
from SGP to the ASP.
2. Check A: This ERROR message is discarded.
3. Further actions are implementation dependent.
Note: The M2UA at ASP may notify to SM about receipt of an invalid
ERROR message from SGP depending upon implementation. Depending on
implementation it may even close the SCTP Association with the peer.
Manish Sharma, HSS [Page 136]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Error - Missing Parameter"
+ TEST NUMBER :5.3.11
+ TITLE : Invalid Message Handling
+ SUBTITLE : Missing Mandatory Parameters
+ PURPOSE: To check that if a message is received at the ASP not
containing a Mandatory Parameter, ASP responds with an ERROR
message to the message sending SGP with Cause "Missing Parameter".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Active
DATA Msg ---------------->
(No Interface Id)
<--------------- ERROR
(Cause = Missing Parameter)
DATA Msg ---------------->
(Interface Id = X)
Data Receive Ind --------->
TEST DESCRIPTION:
1. Send DATA message without any Interface Identifier from SGP to ASP
which is a mandatory parameter in M2UA Header for MAUP messages .
2. Check A: ERROR message will be received at ASP containing cause
"Missing Parameter".
3. Check B: State of the ASP is not disturbed.
Manish Sharma, HSS [Page 137]
Internet Draft M2UA Conformance Test Plan Oct 2003
4. Send a DATA Msg from SGP to ASP with valid parameters including
Interface Identifier = X.
5. Check C: A DATA Receive Indication is sent to SM.
6. Repeat the above Test case for other MAUP and ASPM messages
containing Mandatory Parameters.
"Error - Unexpected Parameter"
+ TEST NUMBER :5.3.12
+ TITLE : Invalid Message Handling
+ SUBTITLE : Unexpected Parameter in MAUP messages
+ PURPOSE: To check that if a message containing an invalid parameter
is received at ASP then the ASP responds with an ERROR message
containing cause "Unexpected Parameter".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Active
DATA Msg --------------------->
(Parameter Tag = 0x13
in place of 0x2 )
<--------------------ERROR
(Cause = Unexpected Parameter)
DATA Msg ---------------->
(Interface Id = X)
Data receive Ind --------->
Manish Sharma, HSS [Page 138]
Internet Draft M2UA Conformance Test Plan Oct 2003
TEST DESCRIPTION:
1. Send DATA message with a parameter other than Interface Identifier
from SGP to ASP.
2. Check A: ERROR message will be received at ASP containing Cause
"Unexpected Parameter".
3. Check B: State of ASP is not disturbed.
4. Send a DATA Msg from SGP to ASP with valid parameters including
Interface Identifier = X.
5. Check C: A DATA Receive Indication is sent to SM.
6. Repeat the above test case for other MAUP and ASPM messages.
" ERROR Message Handling "
+ TEST NUMBER :5.3.13
+ TITLE : ERROR Handling
+ SUBTITLE : Handling of Received Error.
+ PURPOSE: To check that if an ERROR message is received then that is
reported to the SM and no ERROR message is sent to peer which sent
the ERROR message in the first place.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in Active state.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SM+SU
ASP is Active
ERROR --------------------->
Manish Sharma, HSS [Page 139]
Internet Draft M2UA Conformance Test Plan Oct 2003
(Cause = Invalid Version)
Error Ind------------->
TEST DESCRIPTION:
1. Send ERROR message with Cause "Invalid Version" from SGP to ASP.
2. Check A: M2UA at ASP should report the error to its SM.
3. Check B: No ERROR message must be received at the SGP.
4. Repeat the test case for other Cause values in ERROR message.
Note: Further action at the SGP are implementation dependent and ERROR-
Code dependent.
SM may tear down the connection or no action may be taken.
5.4 MAUP Messages
5.4.1 Link Management Messages
"Link Management"
+ TEST NUMBER :5.4.1
+ TITLE : Link Management
+ SUBTITLE : Link Establish and Release Confirmation
+ PURPOSE: To check that if Establish Request Primitive is received
from SU at ASP then M2UA at ASP sends ESTABLISH REQUEST message to
SGP and if ESTABLISH CONFIRMATION is received from SGP then SU is
indicated by M2UA that Establish Confirmation has been received.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
Manish Sharma, HSS [Page 140]
Internet Draft M2UA Conformance Test Plan Oct 2003
SGP ASP SU+SM
ASP is Active
<-----------Establish Request
<------------------ ESTABLISH REQUEST
ESTABLISH CONFIRMATION---->
Establish Confirmation-------->
<------------Release request
<------------------ RELEASE REQUEST
RELEASE CONFIRMATION--------->
Release Confirmation--------->
TEST DESCRIPTION:
1. Send Establish Request primitive from the SU at the ASP to M2UA.
2. Check A: ESTABLISH REQUEST message should be sent to the SGP.
3. Send ESTABLISH CONFIRMATION message to the ASP in response to the
received ESTABLISH REQUEST message with Interface Identifier X.
4. Check B: Establish Confirmation indication should be sent to SU from
M2UA at ASP.
5. Repeat the above test case for Release Request primitive from SU
at ASP to M2UA. RELASE REQUEST message should be received at SGP.
Send RELEASE CONFIRMATION message in response to the received
message.
Check C: Release Confirmation indication should be sent to the SU
from M2UA at ASP.
Manish Sharma, HSS [Page 141]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Link Management"
+ TEST NUMBER :5.4.2
+ TITLE : Link Management
+ SUBTITLE : Release Indication message
+ PURPOSE: To check that if RELEASE INDICATION message is received at
ASP then SU is reported of it.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
RELEASE INDICATION------------>
Release Indication-------->
TEST DESCRIPTION:
1. Send RELEASE INDICATION message from SGP to ASP with Interface
Identifier X.
2. Check A: Release Indication primitive will be sent to SU from M2UA
at ASP.
Manish Sharma, HSS [Page 142]
Internet Draft M2UA Conformance Test Plan Oct 2003
"Link Management"
+ TEST NUMBER :5.4.3
+ TITLE : Link Management
+ SUBTITLE : STATE REQUEST and CONFIRMATION message
+ PURPOSE: To check that if State request primitive is received from
SU at ASP then STATE REQUEST message is sent from ASP to the SGP
with state received from SU and if STATE CONFIRM message is
received from SGP then SU is indicated of that.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
<-------State
Request
(State =STATUS_EMER_SET)
<------------------- STATE REQUEST
(State = STATUS_EMER_SET)
STATE CONFIRM----------->
(State = STATUS_EMER_SET)
State Confirm------------->
TEST DESCRIPTION:
1. Send State Request primitive with State parameter STATUS_EMER_SET
from the SU at the ASP to M2UA and Interface Identifier X.
2. Check A: STATE REQUEST message is sent to the SGP with the State
Manish Sharma, HSS [Page 143]
Internet Draft M2UA Conformance Test Plan Oct 2003
parameter STATUS_EMER_SET.
3. Send STATE CONFIRM message to the ASP in response to the received
message with Interface Identifier X.
4. Check B: State Confirmation indication should be received at the SU.
5. Repeat the above test case for other valid State parameter
values(example - STATUS_LPO_CLEAR).
6. Repeat the above test case for STATE INDICATION message from SGP to
ASP. State Indication primitive should be received at the SU with
the State received in STATE INDICATION message.
"Link Management"
+ TEST NUMBER : 5.4.4
+ TITLE : Link Management
+ SUBTITLE : Retrieval Request and Retrieval Confirm
+ PURPOSE: To check that if Retrieval Request primitive is received
from SU at ASP with specified parameter values then RETRIEVAL
REQUEST message is sent to SGP and if RETRIEVAL CONFIRM message is
Received from SGP, the SU is indicated of that.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
<-------Retrieval request
(Action = Action_Rtrv_BSN)
<------------------ RETRIEVAL REQUEST
Manish Sharma, HSS [Page 144]
Internet Draft M2UA Conformance Test Plan Oct 2003
RETRIEVAL CONFIRM----------->
(Action = Action_Rtrv_BSN)
Retrieval Confirm------------->
TEST DESCRIPTION:
1. Send Retrieval Request primitive from SU at ASP with Action
parameter as Action_Rtrv_BSN and Interface Identifier X.
2. Check A: RETRIEVAL REQUEST message will be received at SGP with
Action parameter Action_Rtrv_BSN.
3. Send RETRIEVAL CONFIRM message from SGP to ASP with Action parameter
Action_Rtrv_BSN from SGP to ASP and with BSN as the value of
Sequence Number field .
4. Check B: Retrieval Confirm Indication primitive will be received at
SU.
5. Repeat the above test case for other value of Action Parameter i.e.
ACTION_RTRV_MSGS. The results should be same.
"Link Management"
+ TEST NUMBER :5.4.5
+ TITLE : Link Management
+ SUBTITLE : Retrieval Indication and Retrieval Complete Indication
+ PURPOSE: To check that if RETRIEVAL INDICATION and RETRIEVAL
COMPLETE INDICATION messages are received from SGP then SU are
indicated of that.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
Manish Sharma, HSS [Page 145]
Internet Draft M2UA Conformance Test Plan Oct 2003
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
<-----------Retrieval request
(Action=Action_Rtrv_BSN)
(Sequence Number = 0)
<--------------- RETRIEVAL REQUEST
(Action=Action_Rtrv_BSN)
(Sequence Number = 0)
RETRIEVAL CONFIRM--------------->
(Action = Action_Rtrv_BSN)
(Sequence Number = BSN)
Retrieval Confirm------------->
<-----------Retrieval request
(Action=Action_Rtrv_MSGS)
(Sequence Number = FSN)
<--------------- RETRIEVAL REQUEST
(Action=Action_Rtrv_MSGS)
(Sequence Number = FSN)
RETRIEVAL CONFIRM--------------->
(Action = Action_Rtrv_MSGS)
(Sequence Number = 0)
Retrieval Confirm------------->
RETRIEVAL INDICATION ---------->
(MSU from retransmit
queue and not last MSU)
Retrieval Indication---------->
RETRIEVAL COMPLETE INDICATION--->
Manish Sharma, HSS [Page 146]
Internet Draft M2UA Conformance Test Plan Oct 2003
(MSU from retransmit
queue and last MSU)
(Interface Identifier = X)
Retrieval Complete Indication------------>
TEST DESCRIPTION:
1. Send Retrieval Request primitive from SU to M2UA at ASP with Action
Action_Rtrv_BSN, no Sequence Number and Interface Identifier X.
RETRIEVAL REQUEST message will be sent to SGP. In response to it
send a RETRIEVAL CONFIRM message from SGP to ASP containing BSN as
the Sequence Number.
2. CHECK A: A Retrieval Confirm Indication primitive is sent to SU at
ASP.
3. Send Retrieval Request primitive from SU to M2UA at ASP with Action
Action_Rtrv_MSGS, FSN as Sequence Number and Interface Identifier X.
RETRIEVAL REQUEST message will be sent to SGP. In response to it
send a RETRIEVAL CONFIRM message from SGP to ASP containing no
Sequence Number.
4. CHECK B: A Retrieval Confirm Indication primitive is sent to SU at
ASP.
5. Send RETRIEVAL INDICATION and RETRIEVAL COMPLETE INDICATION messages
containing the MSUs to be retransmitted with the MSU in RETRIEVAL
COMPLETE INDICATION to be last from the retransmission queue.
6. CHECK C: Retrieval Indication and Retrieval Complete Indication
primitive will be received at SU sent by M2UA at ASP.
5.4.2 Data Transfer Messages
"DATA Transfer Primitive"
+ TEST NUMBER : 5.4.6
+ TITLE : DATA Primitive at ASP
Manish Sharma, HSS [Page 147]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ SUBTITLE : Handling of DATA Primitive in AS active state
+ PURPOSE: To check that on receiving DATA Send primitive from SU,
DATA message is sent to the SGP. Also on receiving DATA message
from SGP, SU is given Receive Data Indication.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
DATA Msg --------------->
Data Receive Ind ------------->
TEST DESCRIPTION:
1. Send DATA Send Primitive from the SU at ASP side to send Protocol
Data to the SGP with Interface Identifier = X.
2. Check A: DATA message is received at the SGP containing the data and
the Interface Identifier X passed by the SU at ASP.
3. Send DATA message from SGP containing Protocol Data and Interface
Identifier X to ASP.
4. Check B: DATA Receive Indication is sent to SU.
"TTC DATA Primitive"
+ TEST NUMBER : 5.4.7
+ TITLE : TTC DATA Primitive
Manish Sharma, HSS [Page 148]
Internet Draft M2UA Conformance Test Plan Oct 2003
+ SUBTITLE : Handling of TTC DATA Primitive in AS active state
+ PURPOSE: To check that on receiving TTC DATA primitive from SU,
TTC DATA message is sent to the SGP. Also on receiving TTC DATA
message from SGP, SU is sent Receive Data Indication.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
<------------- TTC Data
<----------------- TTC DATA Msg
TTC DATA Msg --------------->
TTC Data Receive Ind ------------->
TEST DESCRIPTION:
1. Send TTC DATA Send Primitive from SU to M2UA at ASP side to send
Protocol Data to the SGP with Interface Identifier = X.
2. Check A: TTC DATA message is received at the SGP containing the data
and the Interface Identifier X passed by the SU at ASP.
3. Send TTC DATA message from SGP containing Protocol Data and
Interface Identifier X to ASP.
3. Check B: TTC DATA Receive Indication primitive is sent to SU with
the Protocol Data and Interface Identifier X.
Manish Sharma, HSS [Page 149]
Internet Draft M2UA Conformance Test Plan Oct 2003
"SCTP Stream Management"
+ TEST NUMBER :5.4.8
+ TITLE : SCTP Stream Management
+ SUBTITLE : Stream Selection
+ PURPOSE: To check that all the messages for the same Interface
Identifier are sent on the same SCTP stream.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP with two streams. ASP is Active.
EXPECTED MESSAGE SEQUENCE :
SGP ASP SU+SM
ASP is Active
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
<-------- Data
(Interface Id = X)
<----------------- DATA Msg
TEST DESCRIPTION:
1. Send three or more DATA Send Primitives with same Interface
Identifier value X from the SU to M2UA at ASP side to send Protocol
Data to the SGP.
2. Check A: DATA messages are received at the SGP containing the same
Stream Id.
3. Repeat the above test with other Interface Identifier Y.
Manish Sharma, HSS [Page 150]
Internet Draft M2UA Conformance Test Plan Oct 2003
4. Repeat the above case if number of streams between ASP and SGP is
more than two but AS is handling only two Interface Identifiers. One
or more streams may not be used for sending DATA message.
4. Repeat the above case if number of streams between ASP and SGP is
two but AS is handling four Interface Identifier. Send DATA messages
for all Interface Identifier. DATA messages should be sent on both
the streams and DATA messages for the same Interface Identifier are
sent on the same stream.
Note: How the messages will be distributed on different SCTP streams is
implementation specific.
6. Interface Identifier Management Messages
"Dynamic Registration"
+ TEST NUMBER :6.1
+ TITLE : Dynamic Registration
+ SUBTITLE : Dynamic Registration.
+ PURPOSE: To check that Dynamic Registration request and response
messages are sent and received.
+ TEST CONFIGURATION: A (Both SGP and ASP under test)
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP in Active State. SGP supports Dynamic Registration.
EXPECTED MESSAGE SEQUENCE :
SM+SU ASP SGP SM + NIF
Manish Sharma, HSS [Page 151]
Internet Draft M2UA Conformance Test Plan Oct 2003
ASP is Active
Reg Req------->
(Single valid
Link Key LK1)
REG REQ---------->
(Link Key = LK1)
REG Ind -------->
<----------------- REG RSP
(Reg. Status = SUCCESS
Associated Interface Id)
<-------- Reg Confirm
<----------------- REG RSP
(Reg. Status = SUCCESS
Associated Interface Id)
Error ------------>
(Cause = Unexpected message)
Reg Req ------->
(single valid
link key LK1)
REG REQ---------->
(Link Key = LK1)
<----------------- REG RSP
(Reg. Status = Error-Overlapping Link Key
Interface Id = 0)
Reg Req ------->
(Multiple(n) Valid Link Keys)
REG REQ---------->
(Link Key = LK2,
Link Key = LK3,
.....)
<----------------- REG RSP
(Reg. Status = SUCCESS
Manish Sharma, HSS [Page 152]
Internet Draft M2UA Conformance Test Plan Oct 2003
Associated Interface Id)
.
.
1 or more
<----------------- REG RSP
(Reg. Status = SUCCESS
Associated Interface Id)
TEST DESCRIPTION:
1. Send Reg Req primitive from SM to M2UA at ASP for single and valid
link key LK1.
2. CHECK A: REG REQ message for LK1 is sent to SGP from ASP.
REG Indication is sent to the SM at SGP on receiving REG REQ.
3. REG RES is sent to the ASP with result status SUCCESS, and
corresponding associated Interface Identifier.
Now again send an REG RES message from SGP to ASP with parameters
same as the previous REG RES message sent to ASP.
4. CHECK B: ASP sends an ERROR message with Cause "Unexpected message".
5. Again send an Reg Req primitive from SM to M2UA at ASP for single
and valid Link Key LK1 which has already been registered.
6. CHECK C: REG RESP is sent to the ASP from SGP with Registration
Status field containing "Error - Overlapping Link Key".
The Interface Identifier field is set to 0.
7. Send Reg Req primitive from SM to M2UA at ASP for multiple and valid
Link Key LK2, LK3, etc.
8. CHECK D: One or more REG RESP is sent to the ASP from SGP with
appropriate result status. And all the REG RES messages are having
same Local-LK-Identifier.
Note: The response of ASP to a duplicate REG RES message from SGP is
implementation specific. The ASP may silently discard such messages. In
Manish Sharma, HSS [Page 153]
Internet Draft M2UA Conformance Test Plan Oct 2003
that case the CHECK in Line 4 above is inapplicable.
Note: The multiplicity of REG RES messages in response to a single REG
REQ message containing multiple Link Keys depends on implementation.
"Dynamic Registration"
+ TEST NUMBER : 6.2
+ TITLE : Dynamic Registration.
+ SUBTITLE : Registration of a Link Key at SGP.
+ PURPOSE: To check that on receiving a Link Key Registration Request
for a valid and existing Link key from an ASP, the SGP adds it and
confirms the registration to the ASP.
Also if the SGP determines that the received Link Key data is
Invalid or contains invalid parameters, the SGP returns a
Registration Response message containing a Registration Result as
appropriate.
+ TEST CONFIGURATION: D (SGP and ASPs under test)
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP1 and ASP2. ASP1 is in Inactive and ASP2 is in Active State.
Link Key LK2 is configured at the SGP side and it is for AS2.
AS1 and AS2 have Interface Identifier as X and Y respectively.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP1 is Inactive
ASP2 is Active
<-------- Data
(Interface Id = X)
Send Failure --------->
<-------- Data
Manish Sharma, HSS [Page 154]
Internet Draft M2UA Conformance Test Plan Oct 2003
(Interface Id = Y)
(To ASP2)<-----------------DATA Msg
REG REQ(ASP1) ----------------->
(Link Key = LK2)
Reg Ind -------->
<----------------- REG RSP
(Reg Status = SUCCESS,
Interface Id = Y)
Reg Confirm Primitive is sent to SM from M2UA at ASP
ASPIA(ASP2) ---------------->
(Interface Id = Y)
Status Ind ------->
(To ASP2)<-------------- ASP-Inactive-Ack
(To ASP2)<-------------- NTFY(AS-Pending)
Timer T(r) Expires
(To ASP2)<-------------- NTFY(AS-Inactive)
<-------- Data
(Interface Id = Y)
Send Failure --------->
ASPAC(ASP1) ---------------->
(Interface Id = Y)
Status Ind ------->
(To ASP1)<------------ ASP-Active-Ack
(To ASP1)<------------ NTFY(AS-Active)
<-------- Data
(Interface Id = Y)
(To ASP1)<----------------DATA Msg
TEST DESCRIPTION:
Manish Sharma, HSS [Page 155]
Internet Draft M2UA Conformance Test Plan Oct 2003
1. Send DATA Send primitive from NIF to M2UA at SGP with Interface Id =
X. As it is for AS1 and AS1 has only one ASP, ASP1, which is in
INACTIVE state now, DATA send will fail at SGP and a Failure
Indication will be sent to NIF.
2. Send DATA Send primitive from NIF at SGP with Interface Id = Y. As
It is for AS2 and AS2 has only one ASP, ASP2, which is in ACTIVE
state now, DATA Msg will be send to ASP2.
3. Send REG REQ for Link Key LK2 from ASP1 to SGP.
4. Check-A: M2UA at SGP will send REG Indication to SM and REG RSP with
result (SUCCESS, Interface Identifier = Y) will be sent to ASP.
And Reg Confirm primitive will be sent to SM at ASP.
6. Send ASPIA from ASP2 to SGP for Interface Identifier = Y. Now AS2
and ASP2 will be inactive. Send DATA Send primitive from NIF at SGP
for Interface Identifier = Y, this will Fail as AS2 is Inactive now.
6. Send ASPAC from ASP1 to SGP for Interface Identifier = Y.
7. Check-B: AS2 and ASP1 becomes active.
8. Send DATA Send primitive from NIF to M2UA at SGP for Interafce Id Y.
9. Check C: DATA Msg will be sent to ASP1 from SGP.
In addition to the above Tests perform the following DOs and CHECKs for
the mentioned results.
DO-1: Send REG REQ from ASP to SGP with a Link Key such that, the sent
Link Key is already configured at the SGP, the sending ASP is not
within the list of ASPs of the corresponding AS, but addition of ASP is
not allowed(REG REQ is not authorized) at SGP.
CHECK-1: REG RES with Registration Status "Error - Permission Denied"
is sent to ASP.
DO-2: Send REG REQ from ASP to SGP with a link key such that, the sent
Link key is already configured at the SGP, the sending ASP is already
within the list of ASPs of the corresponding AS, and addition of ASP is
allowed(REG REQ is supported) at SGP.
CHECK-2:REG RES with Registration Status "Error - Overlapping Link Key"
Manish Sharma, HSS [Page 156]
Internet Draft M2UA Conformance Test Plan Oct 2003
is sent to ASP.
DO-3: Send REG REQ from ASP to SGP with a Link Key such that, the sent
Link Key is valid but not configured at the SGP, the sending ASP is not
within the list of ASPs of the corresponding AS, and dynamic
configuration of ASP is supported at SGP.
CHECK-3: M2UA at SGP will send REG Indication to SM and REG RSP with
result (SUCCESS, Associated Interface Id) will be sent to ASP.
Also check that the Interface Identifier sent is unique.
DO-4: Send REG REQ from ASP to SGP with a Link Key such that, the sent
Link Key is valid but not configured at the SGP, the sending ASP is not
within the list of ASPs of the corresponding AS, and dynamic
configuration of ASP is not supported at SGP.
CHECK-4:REG RES with Registration Status "Error - Link Key not
Provisioned" is sent to ASP.
DO-5: Send REG REQ from ASP to SGP with a Link Key such that, the sent
Link Key is invalid.
CHECK-5:REG RES with Registration Status "Error - Invalid Link Key" is
sent to ASP.
DO-6: Send REG REQ from ASP to SGP with a Link Key such that, the sent
Link Key has invalid Signaling Data Link Identifier(SDLI).
CHECK-6: REG RES with Registration Status "Error - Invalid SDLI" is
sent to ASP.
DO-7: Send REG REQ from ASP to SGP with a Link Key such that, the sent
Link Key has invalid Signaling Data Terminal Identifier (SDTI).
CHECK-7: REG RES with Registration Status "Error - Invalid SDTI" is
Sent to ASP.
DO-8: Send REG REQ from ASP to SGP with a Link Key such that the sent
Link key is valid but not configured at the SGP, the sending ASP is not
Within the list of Asps of the corresponding AS, dynamic configuration
Of ASP is supported at SGP, and SGP has no more capacity to add new
Link Key entry or AS entry.
CHECK-8: REG RES with Registration Status "Error - Insufficient
Manish Sharma, HSS [Page 157]
Internet Draft M2UA Conformance Test Plan Oct 2003
Resources" is sent to ASP.
"Dynamic De-Registration"
+ TEST NUMBER: 6.3
+ TITLE: Dynamic De-Registration
+ SUBTITLE: Dynamic De-Registration.
+ PURPOSE: To check that Dynamic De-Registration request and
response messages are sent and received.
+ TEST CONFIGURATION: A (Both SGP and ASP under test)
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. ASP is in Inactive State.
EXPECTED MESSAGE SEQUENCE:
SM+SU ASP SGP SM + NIF
ASP is Inactive
DeReg req------->
(Single valid
Interface Id = X)
DEREG REQ---------->
(Interface Id = X)
DeReg Ind -------->
<----------------- DEREG RSP
(Interface Id = X
De-Reg Status = SUCCESS)
<----------------- DEREG RSP
(Interface Id = X
De-Reg Status = SUCCESS)
Error ----------->
Manish Sharma, HSS [Page 158]
Internet Draft M2UA Conformance Test Plan Oct 2003
(Cause = Unexpected Message)
DeReg req------->
(Single valid
Interface Id = X)
DEREG REQ---------->
(Interface Id = X)
<--------------- DEREG RSP
(Interface Id = X
De-Reg Status = Error - Not Registered)
De-Reg req------->
(Multiple(n) valid Interface Identifier)
DEREG REQ---------->
(Interface Identifier = ID1,
Interface Identifier = ID2,
.....)
<----------------- DE-REG RSP
(Interface Id = ID1
De-Reg Status )
(Interface Id = ID2
De-Reg Status )
.
.
.
(Interface Id = IDn
De-Reg Status )
TEST DESCRIPTION:
Do the following and check for the mentioned results.
1. Send DeReg Req primitive from SM to M2UA at ASP for single and
valid Interface Identifier X.
2. CHECK A: DEREG REQ messages for Interface ID X is sent to SGP from
ASP.
Manish Sharma, HSS [Page 159]
Internet Draft M2UA Conformance Test Plan Oct 2003
3. M2UA at SGP sends DEREG Indication to the SM on receiving DEREG REQ
message from ASP.
DEREG RES is sent to the ASP with De-Registration Status SUCCESS,
and corresponding Interface Identifier as in the DEREG REQ message.
Now again send DEREG RES message from SGP to ASP with parameters
same as the previous DE-REG RESP message sent to ASP.
4. CHECK B: ASP sends an ERROR message with Cause "Unexpected message".
5. Send DeReg Req primitive from SM to M2UA at ASP for single and valid
Interface Identifier X when the ASP is no more registered in AS.
6. CHECK C: DEREG RES is sent to ASP from SGP with De-Registration
Status "Error - Not Registered".
7. Send DeReg Req primitive from SM to M2UA at ASP with multiple and
valid Interface Identifiers ID1, ID2, etc for which the ASP is
registered.
8. CHECK D: One DEREG RES is sent to the ASP from SGP with appropriate
De-Registration Status for all Interface Identifiers in the DEREG
REQ message. Also check that De-Reg Result for each Interface
Identifier in DEREG REQ message also includes that Interface
Identifier.
In addition to the above Tests perform the following DOs and CHECKs for
the results as mentioned:
DO-1:Send DEREG REQ from ASP to SGP for single and invalid Interface
Identifier.
CHECK-1:DEREG RES is sent to the ASP from SGP with De-Registration
Status "Invalid Interface Identifier".
Note: The de-registration procedure does not necessarily imply the
Deletion of Link Key and Application Server configuration data at the
SG. Other ASPs may continue to be associated with the Application
Server, in which case the Link Key data CANNOT be deleted. If a De-
registration results in no more ASPs in an Application Server, an SG
MAY delete the Link Key data.
Manish Sharma, HSS [Page 160]
Internet Draft M2UA Conformance Test Plan Oct 2003
7. Acknowledgements
The author would like to thank puneet dhal who has done
a great job and completed this test spec effectively,
Dipak Bash, Satyendra Kumar Varshney, Yogesh Gahlaut and Sandeep
Mahajan for their insightful comments and suggestions.
8. Authors' Addresses
Manish Sharma
Hughes Software Systems
Electronic City, Plot 17,
Sector 18, Gurgaon - 122015.
Harayana, India
EMail: sharmam@hss.hns.com
9. References
[M2UA] : SS7 MTP2-User Adaptation Layer (M2UA)
RFC 3331
[2960] : RFC 2960 "Stream Control Transport Protocol"
R. Stewart, et al, November 2000.
[ITU-MTP] : ITU-T Recommendations Q.701-Q.705, 'Signaling
System No. 7 (SS7) - Message Transfer Part (MTP)'