INTERNET-DRAFT Anjali Gurmukhani (Editor) Dipak Aggarwal Hughes Software Systems (HSS) Issued: Aug 2003 Expires: Feb 2004 SS7 SCCP-User Adaptation Layer (SUA) Conformance Test plan Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft expires in Feb 2004. Anjali Gurmukhani, HSS [Page 1] Internet Draft SUA Conformance Test Plan Aug 2003 Abstract This document presents the test specification for SUA(SCCP User Adaptation layer )protocol, which can be used to test SUA implementations for conformance to the protocol definition. The list of tests is exhaustive and covers almost all the categories of test. This draft can also be used in conjunction with SUA specification by implementers of protocol as implementers guide, as the pictorial representation of various scenarios help easy understanding of the protocol. Abstract.............................................................2 1. Introduction......................................................3 1.1 Scope............................................................3 1.2 Terminology......................................................3 2 General Principles of SUA Tests....................................5 2.1 Presentation of test descriptions................................6 3 Test Configurations................................................6 3.1 Configurations for IUT at SGP....................................7 3.2 Configurations for IUT at ASP...................................11 4 Test Cases - SUA at SGP...........................................16 4.1 ASPSM...........................................................16 4.2 ASPTM...........................................................22 4.3 SSNM............................................................45 4.4 Dynamic Routing Key Management..................................56 4.5 Management......................................................68 5 Test Cases - SUA at ASP...........................................78 5.1 ASPSM...........................................................78 5.2 ASPTM...........................................................85 5.3 SSNM............................................................93 5.4 Dynamic Routing Key Management.................................101 5.5 Management.....................................................104 6 Test Cases - SUA at SGP/ASP......................................108 6.1 Connectionless Procedures.................................... 108 6.2 Routing Procedures.............................................116 6.3 Reassembly Procedures ...................................124 6.4 Relay Functionality............................................129 6.5 Connection Oriented Procedures ................................132 6.6 SCTP Connection Management.....................................168 7 Acknowledgements.................................................174 8 Authors' Addresses...............................................175 9 References.......................................................175 Copyright Statement................................................176 Anjali Gurmukhani, HSS [Page 2] Internet Draft SUA Conformance Test Plan Aug 2003 1. Introduction 1.1 Scope This document details the Conformance of the SUA( SCCP User Adaptation Layer) Protocol as per The next version of the draft will cover any additions done to Protocol revision and any subsequent RFC published by IETF. 1.2 Terms Used Signaling Gateway (SG) - Network element that terminates SCN Signaling and transports SCCP-User signaling over IP to an IP Signaling endpoint. A Signaling Gateway could be modeled as one Or more Signaling Gateway Processes, which are located at the Border of the SS7 and IP networks. Where an SG contains more than one SGP, the SG is a logical entity and the contained SGPs are assumed to be coordinated into a single management view to the SS7 network and to the supported Application Servers. Application Server (AS) - A logical entity serving a specific Routing Key. An example of an Application Server is a virtual IP Database element handling all requests for an SCCP-user. The AS Contains a set of one or more unique Application Server Processes, Of which one or more is normally actively processing traffic. Application Server Process (ASP) - An Application Server Process Serves as an active or backup process of an Application Server (e.g., part of a distributed signaling node or database element). Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs. An ASP Contains an SCTP end-point and may be configured to process traffic Within more than one Application Server. IP Server Process (IPSP) - A process instance of an IP-based Application. An IPSP is essentially the same as an ASP, except that It uses SUA in a peer-to-peer fashion. Conceptually, an IPSP does Not use the services of a Signaling Gateway. Anjali Gurmukhani, HSS [Page 3] Internet Draft SUA Conformance Test Plan Aug 2003 Signaling Gateway Process (SGP) - A process instance of a Signaling Gateway. It serves as an active, load-sharing or Broadcast process of a Signaling Gateway. Signaling Process - A process instance that uses SUA to communicate With other signaling process. An ASP, a SGP and an IPSP are all Signaling processes. Association - An association refers to an SCTP association. The Association provides the transport for the delivery of SCCP-User Protocol data units and SUA layer peer messages. Routing Key - The Routing Key describes a set of SS7 parameters And/or parameter-ranges that uniquely defines the range of Signaling traffic configured to be handled by a particular Application Server. An example would be where a Routing Key consists Of a particular SS7 SCCP SSN plus an identifier to uniquely mark the network that the SSN belongs to, for which all traffic would be Directed to a particular Application Server. Routing Keys are mutually exclusive in the sense that a received SS7 signaling Message cannot be directed to more than one Routing Key. Routing Keys can be provisioned, for example, by a MIB or registered using SUA's dynamic registration procedures. Routing Context - An Application Server Process may be configured to Process traffic within more than one Application Server. In this Case, the Routing Context parameter is exchanged between the SGP and the ASP (or between two ASPs), identifying the relevant Application Server. From the perspective of an SGP/ASP, the Routing Context Uniquely identifies the range of traffic associated with a Particular Application Server, which the ASP is configured to receive. There is a 1:1 relationship between a Routing Context values and a Routing Key within an AS. Therefore the Routing Context can be viewed as an index into an AS Table containing the AS Routing Keys. The Routing Context also uniquely identifies an SS7 entity (Point code) into a SS7 network, as presented by the SGP. Address Mapping Function (AMF) - The AMF is an implementation Dependent function that is responsible for resolving the address Presented in the incoming SCCP/SUA message to correct SCTP Association for the desired endpoint. The AMF MAY use routing Context / rouging key information as selection criteria for the Appropriate SCTP association. Anjali Gurmukhani, HSS [Page 4] Internet Draft SUA Conformance Test Plan Aug 2003 Fail-over - The capability to re-route signaling traffic as Required to an alternate Application Server Process, or group of ASPs, within an Application Server in the event of failure or Unavailability of a currently used Application Server Process. Fail-over may apply upon the return to service of a previously Unavailable Application Server Process. Network Byte Order - Most significant byte first, a.k.a. Big Endian. Layer Management - Layer Management is a nodal function that Handles the inputs and outputs between the SUA layer and a local Management Entity. Host - The computing platform that the SGP or ASP process is running On. Stream - A stream refers to an SCTP stream; a uni-directional Logical channel established from one SCTP endpoint to another Associated SCTP endpoint, within which all user messages are Delivered in-sequence except for those submitted to the un-ordered Delivery service. Transport address - an address that serves as a source or Destination for the unreliable packet transport service used by SCTP. In IP networks, a transport address is defined by the Combination of an IP address and an SCTP port number. Note, only One SCTP port may be defined for each endpoint, but each SCTP Endpoint may have multiple IP addresses. 2 General Principles of SUA Tests These tests aim to verify a given implementation of a protocol in Accordance with the relevant draft. The specification is independent Of a given implementation and does not generally imply any modification of The endpoint under test. However, it is recognized that certain tests Require capabilities of the system that are not explicitly defined in The draft, and these capabilities may not be present in all Implementations. As a consequence, certain tests may not be possible in All implementations. Anjali Gurmukhani, HSS [Page 5] Internet Draft SUA Conformance Test Plan Aug 2003 2.1 Presentation of test descriptions Each test description includes the environment in which the implementation under test must be inserted in order to pass the test. Nine test Configurations are defined (named A, B, C, D, G, H and I, Relay); they are presented in clause 3. Each test is precisely described. Nevertheless, some events not Directly concerning the point under test, or without direct link With the test nature, are not explicitly described. In order to preserve the Test description implementation independence, certain flexibility has been left in the test descriptions. This is particularly the case when it is necessary to terminate the SCTP association (where it is only mentioned, "Terminate" with no more precision). The operator will choose according to the implementation particularities and the events expected in the test description, the appropriate Termination means (MML- Man Machine Language, provoked failure, etc.). 2.1.1 Pre Test Condition Before starting the test we need to get the setup into a condition From where test can be started. These conditions are specified in Pre- Test condition in each test. Note: Where NIF has been written, it means that NIF+SM. In some implementation these may be two entities and in some, they may be implemented in single entity. 3 Test Configurations: The set of tests described in this Recommendation assumes that the Point under test is inserted in a test environment called "test Configuration". Anjali Gurmukhani, HSS [Page 6] Internet Draft SUA Conformance Test Plan Aug 2003 3.1 Configuration A: For Testing the IUT at SGP Configuration A : This simple configuration is used for all the procedures of tests Concerning only one AS. Configuration A is shown in figure 1. AS is Handling the traffic for routing context P and N/w Appearance A. AS is having only one ASP ASP1.SG routes data to Point code Z and SGP serves SG. Routing Context P may Be based on the following information: 1. DPC. 2. DPC+SSN. 3. IP Address. 4. IP Address + SSN. 5. Hostname SG ------------- -------------- | SGP/IPSP | | AS DPC = X | | under Test | | ------- | | DPC = Z |-------------------------------|--| ASP1 | | | | | ------- | ------------- -------------- Fig 1: Configuration A Anjali Gurmukhani, HSS [Page 7] Internet Draft SUA Conformance Test Plan Aug 2003 Configuration B: This configuration is used for all the procedures of tests concerning one ASP in two AS which are handling traffic for both AS. Configuration B is shown in figure 2. AS1 is handling the traffic for routing context P and N/w Appearance A. AS2 is handling the traffic for routing context Q and N/w Appearance A. ASP1 is in both AS. Point Code of SGP/IPSP is Z. Routing Context P and Q may be based on the following information: 1. DPC. 2. DPC+SSN. 3. IP Address. 4. IP Address + SSN 5. hostname. -------------- SG | AS1 DPC X | ------------- | ------- | | |-------------------------------| | ASP1 | | | SGP/IPSP | | ------- | | Under Test | -------------- | DPC Z | -------------- | |-------------------------------| AS2 DPC Y | ------------- | ------- | | | ASP1 | | | ------- | -------------- Fig 2: Configuration B Anjali Gurmukhani, HSS [Page 8] Internet Draft SUA Conformance Test Plan Aug 2003 Configuration C : This configuration is used for all the procedures of tests concerning two or more ASP in one AS. Configuration C is shown in figure 3. AS is handling the traffic for routing context P and N/w Appearance A. ASP1 and ASP2 can be in FAIL-OVER /LOADSHARE/BROADCAST mode of traffic handling. Point Code of SGP/IPSP is Z. Routing Context P may be based on the following information: 1. DPC. 2. DPC+SSN. 3. IP Address. 4. hostname. 5. IP Address + SSN -------------- SG | AS DPC X | ------------- | ------- | | |-------------------------------|-| ASP1 | | | SGP/IPSP | | ------- | | Under Test | | ------- | | DPC Z | | | ASP2 | | | |-------------------------------|- ------- | ------------- -------------- Fig 3: Configuration C Anjali Gurmukhani, HSS [Page 9] Internet Draft SUA Conformance Test Plan Aug 2003 Configuration D : This configuration is used for all the procedures of tests concerning two or more AS which are handling traffic for different network appearance and different routing context. Configuration D is shown in figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and AS3 is handling traffic for N/w appearance B. AS1 is handling traffic for Routing Context P, AS2 is handling traffic for Routing Context Q and AS3 is handling traffic for Routing Context R. 1. DPC. 2. DPC+SSN. 3. IP Address. 4. IP Address + SSN. 5. Hostname -------------- SG | AS1 DPC X | ------------- | ------- | | |-------------------------------| | ASP1 | | | SGP/IPSP | | ------- | | Under Test | -------------- | DPC Z | -------------- | |-------------------------------| AS2 DPC Y | ------------- -------+ | ------- | | | | ASP2 | | | | ------- | | -------------- | -------------- | | AS3 DPC z | +-----------------------|- ------- | | | ASP 3 | | | ------- | -------------- Fig 4: Configuration D Anjali Gurmukhani, HSS [Page 10] Internet Draft SUA Conformance Test Plan Aug 2003 3.2 Configurations for Testing the IUT at ASP Configuration G : This simple configuration is used for all the procedures of tests concerning only one SGP/IPSP. Configuration G is shown in figure 7. Point Code of SGP is Z. ASP is handling the traffic for routing context P. Routing Context P may be based on the following information: 1. DPC. 2. DPC+SSN. 3. Hostname 4. IP Address 5. IP Address + SSN. ------------- -------------- | ASP1 | | SGP/IPSP | | Under Test | | DPC = Z | | DPC = X |-------------------------------| SG | | | | | ------------- -------------- Fig 7: Configuration G Anjali Gurmukhani, HSS [Page 11] Internet Draft SUA Conformance Test Plan Aug 2003 Configuration H: This configuration is used for all the procedures of tests concerning Two SGPs/IPSPs connected to the same ASP and handling traffic for the same DPC In the SEP network. Configuration H is shown in figure 8. SG1/IPSP1 and SG2/IPSP2 are handling the traffic for N/w Appearance A.Point Code of SG1/IPSP1 is Y and of SG2/IPSP2 is Z. Routing Context P may be based on the following information: 1. DPC. 2. DPC+SSN. 3. IP Address 4. Hostname. 5. IP Address + SSN -------------- | SG1/IPSP1 | ------------- | DPC Y | | |-------------------------------| | | ASP1 | | SG1 | | Under Test | -------------- | DPC X | -------------- | |-------------------------------| SG2/IPSP2 | ------------- | DPC Z | | SG2 | | | -------------- Fig 8: Configuration H Anjali Gurmukhani, HSS [Page 12] Internet Draft SUA Conformance Test Plan Aug 2003 Configuration I: This simple configuration is used for all the procedures of tests Concerning one ASP in two AS. Configuration I is shown in figure 9. Point Code of SGP/IPSP is Z. ASP1 is in two AS, AS1 and AS2. AS1 is handling Traffic for routing context P and AS2 is handling traffic for routing Context Q. Routing Context P and Q may be based on the following Information: 1. DPC. 2. DPC+SSN. 3. IP Address/IP Address + SSN. 4. Hostname. +--------------+ | Under Test | | AS1 DPC X | | ------- | +----------------+ | | ASP1 | | ---------------------| | | ------- | | SGP / IPSP | +--------------+ | | +--------------+ | DPC Z | | AS2 DPC Y | | SG | | ------- | ---------------------| | | | ASP1 | | +----------------+ | ------- | | Under Test | +--------------+ Fig 9: Configuration I Configuration Note: The SG can have same Point Code as one of The AS in the SEP mode of operation. Anjali Gurmukhani, HSS [Page 13] Internet Draft SUA Conformance Test Plan Aug 2003 Configuration J: This configuration is used for all the procedures of tests concerning two SGPs in an SG connected to the same ASP. SG is handling traffic for Point Code Y and SGP1 and SGP2 are serving the SG. The ASP is handling Traffic for Routing Context P. Configuration J is shown in figure 10. The SG can be in Broadcast, Loadshare or Override Mode. Routing Context P may be based on the following information: 1. DPC. 2. DPC+SSN. 3. Global Title GT. 4. Hostname. 5. IP Address 6. IP Address + SSN. +--------------+ | SGP1 | +-------------+ | DPC Y | | |-------------------------------| SG | | ASP1 | | | | Under Test | +--------------+ | DPC X | +--------------+ | |-------------------------------| SGP2 | +-------------+ | DPC Y | | SG | | | +--------------+ Fig 10 : Configuration J Anjali Gurmukhani, HSS [Page 14] Internet Draft SUA Conformance Test Plan Aug 2003 Configuration RELAY: This configuration is used for all the procedures of tests concerning Relay functionality of SUA. Here IPSP1 is connected to IPSP2 which is connected to another IPSP3. Routing Context P may be based on the following information: 1. DPC. 2. DPC+SSN. 3. Global Title GT. 4. IP Address 5. IP Address + SSN Configuration RELAY is shown in figure 11. +-------------+ +-------------+ +--------------+ | | | | | | | +-------+ | | +--------+ | | +---------+ | | | | ----------| | | --------- | | | | | | IPSP1| | | | IPSP2 | | | | IPSP3 | | | +-------+ | | +--------+ | | +---------+ | +-------------+ +-------------+ +--------------+ DPC X AS1 AS2 DPC=Y Fig 11: Configuration Relay Anjali Gurmukhani, HSS [Page 15] Internet Draft SUA Conformance Test Plan Aug 2003 4.Test Cases for Testing SUA at SGP 4.1 ASPSM "Heartbeat and Heartbeat Ack" + TEST NUMBER: ASPSM_1 + PURPOSE:: To check that an ASP sends Heartbeat messages (to ensure that the SUA peers are still available to each other) and receives a Heartbeat Ack from the remote peer. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is active. Also arrange the data in ASP such that BEAT message is sent from ASP to SGP. EXPECTED MESSAGE SEQUENCE: ASP SGP SM ASP is Active a) BEAT (ASP1) -----------------> Timer 2*T(beat) | is started | <---------------- BEAT ACK b) BEAT (ASP1) -----------------> Timer 2*T(beat) | is started | | Timer 2*T(beat) is expired and no BEAT ACK is from SGP. TEST DESCRIPTION: 1. Send BEAT Message from ASP to the SGP. 2. The beat message should be acknowledge by BEAT ACK before the Timer expires. 3. Send the Beat message again. 4. The timer expires and no beat Ack message is received, the ASP will Anjali Gurmukhani, HSS [Page 16] Internet Draft SUA Conformance Test Plan Aug 2003 consider remote SUA peer as unavailable. Transmission of Heartbeat messages is stopped and the signalling process SHOULD attempt to re- establish communication if it is configured as the client for the disconnected SUA peer. Note: The recommended value of Heartbeat timer is 30sec. Anjali Gurmukhani, HSS [Page 17] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPUP_ACK message wait state" + TEST NUMBER : ASPSM_2 + PURPOSE: To check that if ASPUP message is sent to the SGP, then the ASP should discard any other message, till an ASPUP_ACK message is received . + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in ASP such that ASPUP message is sent to the SGP two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Down ASPUP ----------------> Status Ind -------> REG_REQ ----------------> <------------ ERROR to SM TEST DESCRIPTION: 1. Send ASPUP message to the SGP in ASP-Down state. 2. send a REG_REQ message from the ASP, before it gets an ASPUP_ACK message from the SGP. Check A: The ASP should discard the message and may indicate SM with Error Indication. The above test case should be applicable to all the SUA MGMT messages The ASP Should not send any Messages across unless until an ASPUP_ACK message is received, after sending an ASPUP message. Anjali Gurmukhani, HSS [Page 18] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPUP message in ASP-Up state" + TEST NUMBER : ASPSM_3 + PURPOSE: To check that if ASPUP message is received in ASP-Up state then ASP-Up-Ack message is sent to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and AS is in AS-Down state. Arrange the data in ASP such that ASPUP message is sent to the SGP two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Down ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(ASP-InActive) ASPUP ----------------> <--------------- ASP-Up-Ack TEST DESCRIPTION: 1. Send ASPUP message to the SGP in ASP-Down state. Check A: ASP-Up-Ack is received at ASP. Check B: NTFY (AS-Inactive) message will come from the SGP. 2.Send ASPUP message again from the ASP on the same association. Check A: ASP-Up-Ack message should be received at ASP. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the Up state. Anjali Gurmukhani, HSS [Page 19] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPUP message in ASP-ACTIVE state" + TEST NUMBER: ASPSM_4 + PURPOSE: To check that if ASPUP message is received in ASP-ACTIVE state then message ASP-Up-Ack is sent to the ASP, and the ASP state is changed in all the relevant AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and AS is in AS-Active state i.e. ASP is ACTIVE. EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF ASP is Active ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- ERR(Unexpected message) (ASP State Changes to INACTIVE in all the AS it belongs to) TEST DESCRIPTION: 1. Send ASPUP message to the SGP in ASP-Active state. Check A: ASP-Up-Ack message should be received at ASP. Check B: State of ASP at SGP Should change to ASP-INACTIVE. Check C: An ERR message with error code "Unexpected message" should be received at the ASP. Anjali Gurmukhani, HSS [Page 20] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPDN message in ASP-Down state" + TEST NUMBER : ASPSM_5 + PURPOSE: To check that if ASPDN message is received in ASP-Down state then ASP-Down-Ack message is sent to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is in Up state. Arrange the data in ASP such that ASPDN message is sent to the SGP two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Up ASPDN ----------------> Status Ind -------> <--------------- ASP-Down-Ack ASPDN ----------------> <--------------- ASP-Down-Ack ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-InActive) TEST DESCRIPTION: 1. Send ASPDN message to the SGP in ASP-Up state. Check A: ASP-Down-Ack message will come from the SGP. 2. Send ASPDN message again from the ASP1. Check A: ASP-Down-Ack message should be received at ASP. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the Down state. 3. Send ASPUP message for the ASP.ASP-Up-Ack and NTFY with status AS- Inactive should be received at ASP. Anjali Gurmukhani, HSS [Page 21] Internet Draft SUA Conformance Test Plan Aug 2003 4.2 ASPTM "Invalid Routing Context in ASP-Active Message" + TEST NUMBER: ASPTM_1 + PURPOSE: To check that if ASPAC message carries multiple Routing Contexts, and the SGP cannot Activate One of the Routing Context, then the SGP MUST Send ERROR Message for each Routing Context value that cannot be successfully activated. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is INACTIVE ASPAC ----------------> (RC1, RC2, RC3) <--------------- ASPAC-Ack (RC1) <--------------- NTFY(AS-Active) <--------------- ERR(Invalid Routing Context RC2) <------------ ERROR <--------------- ERR(Invalid Routing Context RC3) <------------ ERROR TEST DESCRIPTION: Anjali Gurmukhani, HSS [Page 22] Internet Draft SUA Conformance Test Plan Aug 2003 1. Send ASPAC message(With 3 Routing Contexts Routing Context RC1 should be a valid value Routing Context RC2 should be a INVALID value Routing Context RC3 should be a INVALID value) to the SGP in ASP-Inactive state. Check A: The SGP Should send ASPAC-ACK Message in response to the ASPAC message(For Routing Context RC1). Check B: ASP Should move to ASP-Active State. Check C: The SGP MUST Send individual ERROR messages for the Routing Context RC2 and RC3. Note: Repeat the above test case for ASPIA message also. Anjali Gurmukhani, HSS [Page 23] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPAC Message Out-Of-The-Blue" + TEST NUMBER : ASPTM_2 + PURPOSE: To check that if ASPAC message is received at the SGP end, for an ASP that is not registered with the SGP and also SGP has no knowledge of ASP through static configuration, SGP MAY Discard this message silently. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Not Registered with SGP ASPAC ----------------> (No reaction) TEST DESCRIPTION: 1. Send ASPAC message to the SGP from the ASP which has not been registered with SGP . Check A: ASP Should discard this message silently. Anjali Gurmukhani, HSS [Page 24] Internet Draft SUA Conformance Test Plan Aug 2003 "Validation of AS pending Behavior: recovery case" + TEST NUMBER: ASPTM_3 + PURPOSE: To check that if ASP Inactive is received when AS is active and if the AS has a single ASP, AS moves to Pending state which changes to Active when Active message is received from Asp. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP is active and is the only ASP serving the AS EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is Active ASPIA ----------------> Status Ind ------->ASP-inact (Since this is the only Active ASP in the AS the AS moves to pending state) Status Ind ------->AS-pending <--------------- NTFY(AS-Pending) (timer tr=2 seconds starts) <> <--------- N-CONNECT REQ <> <--------- N-UNITDATA REQ ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) N-CONNECT IND <------------- CORE (Source ref. number "A") N-UNITDATA IND <------------- CLDT COAK ------------> Anjali Gurmukhani, HSS [Page 25] Internet Draft SUA Conformance Test Plan Aug 2003 (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> ---------> N-DATA IND (ref. number "A") <--------- N-DATA REQ N-DATA IND<------------- CODT TEST DESCRIPTION: 1. Send ASPIA message to the SGP in ASP-active state. Check A: Since this is the only ASP in the AS, the AS should move to AS Pending State. 2. Send N-CONNECT REQ destined to the ASP. Check A: The CORE Message should not be sent to the ASP. 3. Send N-UNITDATA REQ destined to the ASP. Check A: The CLDT Message should not be sent to the ASP. 4. Send ASPAC Message to the SGP, before the timer t(r)=2 Seconds expires. Check A: The CORE and the CLDT Messages should now reach the ASP. 5. Send COAK Message to the SGP. Check A: The COAK Message should reach the SGP, and the connection should be established. 6. Send CODT Messages in both directions. Check A: The CODT Messages should reach the both ends. Anjali Gurmukhani, HSS [Page 26] Internet Draft SUA Conformance Test Plan Aug 2003 "Validation of AS pending Behavior: recovery Failure" + TEST NUMBER: ASPTM_4 + PURPOSE: To check that if ASP Down is received when AS is active and if the AS has a single ASP, AS moves to Pending state which changes to Down if no Up message is received from ASP when the Pending timer is running. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP is active and this is the only ASP serving the AS. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is Active ASPDN ----------------> Status Ind ------->ASP-down (Since this is the only Active ASP in the AS the AS moves to pending state) Status Ind ------->AS-pending <--------------- NTFY(AS-Pending) (timer tr=2 seconds starts) <> <--------- N-CONNECT REQ <> <--------- N-UNITDATA REQ (timer tr=2 seconds Expires) Status Ind ------->AS-down TEST DESCRIPTION: 1. Send ASPIA message to the SGP in ASP-active state. Check A: Since this is the only ASP in the AS, the AS should move to AS Pending State. Anjali Gurmukhani, HSS [Page 27] Internet Draft SUA Conformance Test Plan Aug 2003 2. send N-CONNECT REQ destined to the ASP. Check A: The CORE Message should not be sent to the ASP. 3. Send N-UNITDATA REQ destined to the ASP. Check A: The CLDT Message should not be sent to the ASP. Check B: The Timer T(r) will expire on the SGP Side. Check C: The AS Should move to AS-Down state . The above test case MUST be carried out for both AS-INACTIVE and AS-DOWN Transitions. Anjali Gurmukhani, HSS [Page 28] Internet Draft SUA Conformance Test Plan Aug 2003 "Alternative ASP-ACTIVE in Override Mode" + TEST NUMBER: ASPTM_5 + PURPOSE: To check that if ASPAC message is sent to an SGP which carries an already active ASP for that AS, then all the new traffic should be directed to this ASP and the SGP MUST send a NTFY message with code "Alternate ASP Active " to the other ASP. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1,ASP2. The AS to which the ASPs belong is configured at the SGP with mode as OVERIDE. ASP1 is active and handling Traffic. EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF ASP1 is ACTIVE and Handling traffic (ASP 2 Sends ASPAC) ASPAC ----------------> <--------------- ASPAC-Ack <--------------- NTFY(Alternate ASP Active) to ASP1 TEST DESCRIPTION: 1. Send ASPAC message for ASP2 to the SGP. Check A: All the Traffic henceforth MUST be routed to ASP2, and the ASP1 should be moved to INACTIVE in the AS, and a NTFY Message MUST be generated to the Previous ACTIVE ASP, with status "Alternate ASP Active ". Anjali Gurmukhani, HSS [Page 29] Internet Draft SUA Conformance Test Plan Aug 2003 "Loadshare Mode for AS" + TEST NUMBER: ASPTM_6 + PURPOSE: To verify that if an AS is configured to operate in Loadshare mode, then any data should be distributed amongst all the ASPs present in that AS. + TEST CONFIGURATION: C(with three ASPs) + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASPs. The AS to which the ASP1, ASP2, ASP3 belongs is configured at the SGP with mode as LOADSHARE. EXPECTED MESSAGE SEQUENCE : ASP3 ASP2 ASP1 SGP NIF (AS is in Loadshare Mode with ASP1, ASP2 and ASP3 as the ACTIVE ASPs ) <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP1 <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP2 <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP3 TEST DESCRIPTION: 1. Send Several N-UNITDATA Req. from the SGP. Check A: The Data MUST be distributed amongst the Three ACTIVE ASPs(the mechanism for Distribution is implementation dependent). Anjali Gurmukhani, HSS [Page 30] Internet Draft SUA Conformance Test Plan Aug 2003 Repeat the Above test case after moving one of the ACTIVE ASPs to INACTIVE State(An Additional NTFY Message MAY be generated with status "Insufficient ASP resources active in AS", to inactive ASP/ASPs if number of ASPs actually active in AS goes less than the required value). Anjali Gurmukhani, HSS [Page 31] Internet Draft SUA Conformance Test Plan Aug 2003 "Loadshare Mode for AS: ASP Inactive-Active Transition" + TEST NUMBER: ASPTM_7 + PURPOSE: To verify behavior of AS with Loadshare Traffic mode when one/more ASPs in it move to Inactive . + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASPs. The AS to which the ASP1, ASP2, ASP3 belongs is configured at the SGP with mode as LOADSHARE. The minimum number ASPs required to be Active in AS is 1. EXPECTED MESSAGE SEQUENCE : ASP3 ASP2 ASP1 SGP (AS is in Loadshare Mode with ASP1, ASP2 and ASP3 as the ACTIVE ASPs ) <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP1 <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP2 <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP3 ASPIA ----------> ASPIA-ack to ASP3 <-------- <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP1 Anjali Gurmukhani, HSS [Page 32] Internet Draft SUA Conformance Test Plan Aug 2003 <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP2 ASPIA(ASP2) ----------> ASPIA-ack to ASP2 <-------- <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP1 only <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP1 only <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT ASP1 only ASPAC ---------> ASPAC-ack to ASP2 <-------- <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT To ASP1 <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT To ASP2 TEST DESCRIPTION: 1. Send Several N-UNITDATA Req. from the SGP. Anjali Gurmukhani, HSS [Page 33] Internet Draft SUA Conformance Test Plan Aug 2003 Check A: The Data MUST be distributed amongst the Three ACTIVE ASPs(the mechanism for Distribution is implementation Dependent, can be e.g. SLS basis). 2. Send ASPIA from ASP3. Check A: ASPIA-ack is received at ASP3 Check B: State of AS at SGP is not disturbed. 3. Now SEND SEVERAL N-Unitdata Req. from SGP. Check A: Data MUST be Loadshared amongst Two ASPs , ASP1 and ASP2. 4. Send ASPIA from ASP2. Check A: ASPIA-ack is received at ASP. Check B: State of AS is not disturbed since the minimum number of ASP active is 1. 5. Send several Unitdata Req from SGP. Check A: All Data goes to ASP1. Repeat Active procedure (both ASPs coming back to Active). Data should be Loadshared again amongst the three ASPs. Anjali Gurmukhani, HSS [Page 34] Internet Draft SUA Conformance Test Plan Aug 2003 "Broadcast Mode for AS" + TEST NUMBER: ASPTM_8 + PURPOSE: To verify that if ASPs are operating in Broadcast mode all the Data MUST be sent to all the Active ASPs. + TEST CONFIGURATION: C (AS has three ASPs) + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASPs. The AS to which the ASP1, ASP2, ASP3 belongs is configured at the SGP with mode as BROADCAST. EXPECTED MESSAGE SEQUENCE : ASP SGP NIF (AS is in BROADCAST Mode with ASP1, ASP2 and ASP3 as the ACTIVE ASPs ) <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT (ASP1) N-UNITDATA IND <------------- CLDT (ASP2) N-UNITDATA IND <------------- CLDT (ASP3) <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT (ASP1) N-UNITDATA IND <------------- CLDT (ASP2) N-UNITDATA IND <------------- CLDT (ASP3) TEST DESCRIPTION: 1. Send Several N-UNITDATA REQs from the SGP. Check A: The Data MUST be sent to ALL the ACTIVE ASPs (ASP1, ASP2 and ASP3). Repeat the Above test case after moving one of the ACTIVE ASPs to INACTIVE State(An Additional NTFY Message MAY be generated Anjali Gurmukhani, HSS [Page 35] Internet Draft SUA Conformance Test Plan Aug 2003 with status code "Insufficient ASP resources active in AS", to inactive ASPs) . Anjali Gurmukhani, HSS [Page 36] Internet Draft SUA Conformance Test Plan Aug 2003 "Broadcast Mode for ASP, Unique Correlation ID" + TEST NUMBER: ASPTM_9 + PURPOSE: To verify that if ASPs are operating in Broadcast mode the SGP MUST tag the first DATA message broadcast in each SCTP stream with a unique Correlation Id parameter. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASPs. The AS to which the ASP1, ASP2 belongs is configured at the SGP with traffic handling mode as BROADCAST. EXPECTED MESSAGE SEQUENCE : ASP2 ASP1 SGP NIF (AS is in BROADCAST Mode with ASP1, ASP2 as the ACTIVE ASPs ) <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT (ASP1) N-UNITDATA IND <------------- CLDT (ASP2) ASPIA (ASP2) -------------> ASPIA-ack to ASP2 <-------------------- <--------- N-UNITDATA REQ N-UNITDATA IND <---- CLDT (ASP1) ASPAC (ASP2) -------------> Anjali Gurmukhani, HSS [Page 37] Internet Draft SUA Conformance Test Plan Aug 2003 ASPAC-ack to ASP2 <------------------ <--------- N-UNITDATA REQ N-UNITDATA IND <-------- CLDT (ASP1, Correlation ID) N-UNITDATA IND <------------- CLDT (ASP2, Correlation ID) TEST DESCRIPTION: 1. Send Several N-UNITDATA Req. from the SGP. Check A: The Data MUST be sent to both the ASPs. 2. Now send ASPIA from ASP2. Check A: ASPIA-ack should be received at ASP2. Check B: State of AS is not disturbed at SGP. 3. Send Unitdata-Req from SGP. Check A: Data must be received at ASP1 only. 4. Send ASPAC from ASP2. Check A: ASPAC -ack is received at ASP2. Check B: State of the AS at SGP is same ACTIVE. 5. Send Unitdata-Req from SGP. Check A: Data is received at ASP1, ASP2 with a unique correlation Id. Anjali Gurmukhani, HSS [Page 38] Internet Draft SUA Conformance Test Plan Aug 2003 "Last ASP Transition to INACTIVE state" + TEST NUMBER: ASPTM_10 + PURPOSE: To check that if an AS has only 1 ASP in the ACTIVE state, and it moves to ASP-INACTIVE state, SGP MUST send a Notify message ("AS-Pending") to all the ASPs in the AS which are in the state ASP- INACTIVE. + TEST CONFIGURATION: C (with three ASPs in AS) + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASPs.AS has three ASPs, ASP1 is in ACTIVE State, ASP2 is in INACTIVE State and ASP3 is in DOWN State. EXPECTED MESSAGE SEQUENCE : ASP2 ASP1 SGP SM + NIF ASPIA ----------------> Status Ind -------> <--------------- ASPIA-Ack <--------------- NTFY(AS-Pending) ASP1,ASP2 TEST DESCRIPTION: 1. Send ASPIA message to the SGP from ASP1in ASP-Active state. Check A: ASP Should move to ASP-INACTIVE State. Check B: The AS Should now move to AS PENDING State and a NTFY message with AS-Pending should be sent to ASP2 and ASP1. Check C: The NTFY Message MUST not be sent to ASP3, since it is in DOWN State. Anjali Gurmukhani, HSS [Page 39] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPAC message in ASP-Active State" + TEST NUMBER: ASPTM_11 + PURPOSE: To check that if ASPAC message is received in ASP-Active state then ASP-Active-Ack message is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and AS is in AS-Inactive state. Arrange the data in AS such that ASPAC message with correct Traffic Mode and routing context P is sent to the SGP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Inactive ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <-------------- Ntfy(AS-active) ASPAC ----------------> <--------------- ASP-Active-Ack CLDT ----------------> N-Unitdata Ind -------> TEST DESCRIPTION: 1. Send ASPAC message to the SGP in AS-inactive state. This ASPAC message should contain RC parameter. Check A: ASP-Active-Ack message comes from the SGP. Check B: This Ack message MUST contain RC parameter. 2. Send ASPAC message again from the ASP for the same AS. Check A: ASP-Active-Ack message should be received at ASP. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the Active state. Send DATA message for the ASP, SGP should send N-DATA indication to the NIF. Anjali Gurmukhani, HSS [Page 40] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPIA message in ASP-Inactive state" + TEST NUMBER: ASPTM_12 + PURPOSE: To check that if ASPIA message is received in ASP-Up state then ASP-Inactive-Ack message is sent to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and AS is in AS-Active state i.e. ASP1 is active. Arrange the data in AS such that ASPIA message and Routing Context P is sent to the SGP two times. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Active ASPIA ----------------> Status Ind -------> <--------------- ASP-Inactive-Ack <------------ NTFY(AS-pending) Pending timer expiry .------------ NTFY(AS-Inactive) ASPIA ----------------> <--------------- ASP-Inactive-Ack ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) TEST DESCRIPTION: 1. Send ASPIA message to the SGP in ASP-Active state. ASP-Inactive-Ack and NTFY (AS-Pending) messages will come from the SGP. Let the pending timer expire. 2. Send ASPIA message again from the AS for the same ASP. Anjali Gurmukhani, HSS [Page 41] Internet Draft SUA Conformance Test Plan Aug 2003 Check A: ASP-Inactive-Ack message will come from SGP. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the Inactive state. Send ASPAC message with correct traffic mode (traffic mode defined at SGP for the AS) for the ASP1 and SGP should respond with ASP-Active-Ack message. Anjali Gurmukhani, HSS [Page 42] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPAC message in ASP-Down state" + TEST NUMBER : ASPTM_13 + PURPOSE: To check that if ASPAC message is received in ASP-Down state then message is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is down. Arrange the data in ASP such that ASPAC is sent to SGP . EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF AS is Down ASPAC ----------------> Message silently discarded ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-InActive) TEST DESCRIPTION: 1. Send ASPAC message to the SGP in ASP-Down state. Check A: State of ASP at SGP is not disturbed i.e. ASP remains in the Down state. 2. Send ASPUP message for the ASP and SGP . Check B: SGP should respond with ASP-Up-Ack and NTFY message with status AS Inactive. 3. Repeat the above test case for ASPIA message. Anjali Gurmukhani, HSS [Page 43] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPAC message without any Routing Context" + TEST NUMBER: ASPTM_14 + PURPOSE: To check that if ASPAC message is received without any Routing Context then status of ASP is active in all the AS which this ASP serves. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is Inactive in both the AS at the SGP. Arrange data in ASP such that ASPAC messages is sent to the SGP from ASP. Don't fill any routing context parameter in ASPAC. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS1 & AS2 are Inactive ASPAC ------------------> No Routing Context Status Ind ---------> <----------------- ASP-Active-Ack <----------------- NTFY (AS Active) TEST DESCRIPTION: 1. Send ASPAC Message without any Routing context to the SGP. 2. Check A: ASP-Active-Ack and NTFY message with status AS-Active should be received at ASP without any routing context. 3. Check B: Check that state of ASP is active using configuration Data present at the SGP. Note: If there is no Configuration Data present at the SGP and the ASP has not dynamically registered for any Routing Context, then the ASP Active Message is silently discarded at the SGP. No Ack or NTFY as shown above is sent in that case. Anjali Gurmukhani, HSS [Page 44] Internet Draft SUA Conformance Test Plan Aug 2003 4.3 SSNM "Point Code Unavailability" + TEST NUMBER: SSNM_1 + PURPOSE: To check that if N-PCState indication primitive is received (with Point code status as Unavailable)from NIF at SGP then SGP sends DUNA message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 ASP3 SGP NIF All AS are active <---------- N-PCState Affected DPC M <---------------------------- DUNA <----------------- DUNA <---------- N-PCState Affected DPC M <--------- DUNA TEST DESCRIPTION: 1. Send N-PCState indication Primitive message from NIF in the SGP containing Affected Point code M and Point code status as Unavailable. 2. Check A: DUNA message will be received at the ASP1 and ASP2 containing the RC A and RC B and Affected DPC M. 3. Check B: DUNA message is sent on the Stream number 0. 4. Repeat the above test case with Affected Point code as M but with nw appearance for AS3. In this case DUNA message should be sent to ASP3. Anjali Gurmukhani, HSS [Page 45] Internet Draft SUA Conformance Test Plan Aug 2003 Note: Repeat the above test case when there are multiple point codes in SSNM Message. Note: Also if the Indication from the NIF is N-Status which includes Affected Subsystem also, then DUNA message being sent SHOULD include SSN parameter also. Anjali Gurmukhani, HSS [Page 46] Internet Draft SUA Conformance Test Plan Aug 2003 "Point Code Availability" + TEST NUMBER: SSNM_2 + PURPOSE: To check that if N-PCState indication primitive is received (with Point code status as Available)from NIF at SGP then SGP sends DAVA message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. EXPECTED MESSAGE SEQUENCE: ASP1 ASP2 ASP3 SGP NIF All AS are active <---------- N-PCState Affected DPC M <---------------------------- DAVA <----------------- DAVA <---------- N-PCState Affected DPC M <--------- DAVA TEST DESCRIPTION: 1. Send N-PCState indication Primitive from NIF in the SGP containing the Affected DPC M and Point code status as "Available" Check A: DAVA message is received at ASP1 and ASP2 containing the Corresponding RCs and Affected DPC M. Check B: DAVA message is sent on the Stream number 0. 2. Repeat the test case for N/w appearance B and affected destination any value. Check that message is being sent to ASP3. Note: Repeat the above test case when there are multiple point codes in SSNM Message. Anjali Gurmukhani, HSS [Page 47] Internet Draft SUA Conformance Test Plan Aug 2003 Note: Also if the Indication from the NIF is N-Status which includes Affected Subsystem also, then DAVA message being sent SHOULD include SSN parameter also. Anjali Gurmukhani, HSS [Page 48] Internet Draft SUA Conformance Test Plan Aug 2003 "Route Congestion Indication" + TEST NUMBER : SSNM_3 + PURPOSE: To check that if N-PCState indication primitive with point code status as congested is received from NIF at SGP then SGP sends SCON message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. EXPECTED MESSAGE SEQUENCE : AS1 AS2 AS3 SGP NIF All AS are active <---------- N-PCState DPC M remote sccp status 2 <---------------------------- SCON <----------------- SCON <---------- N-PCState DPC M remote sccp status 2 <--------- SCON TEST DESCRIPTION: 1. Send N-PCState indication Primitive from NIF in the SGP containing the Affected DPC M and network info as corresponding to network appearance and Sccp status as 2. Check A: SCON message is received at the ASP1 and ASP2 containing the corresponding RC values, Affected DPC M, Congestion Level 2 Anjali Gurmukhani, HSS [Page 49] Internet Draft SUA Conformance Test Plan Aug 2003 from NIF. Check B: SCON message is received on the Stream number 0. 2. Repeat the above test case for all congestion level 0, 1, 2 and 3. SCON message will be received from NIF. 3. Repeat the above test case with different congestion level for different affected DPC. SCON message should contain the correct congestion level for each affected destination. Note: If SSN is included in the SCON message, it should be 1. This corresponds to the N-PCSTATE primitive used to convey the Restricted Importance Level to the SCCP user Anjali Gurmukhani, HSS [Page 50] Internet Draft SUA Conformance Test Plan Aug 2003 "User Part Unavailable" + TEST NUMBER : SSNM_4 + PURPOSE: To check that if N-PCState indication primitive with cause User Part Unavailable is received from NIF at SGP then SGP sends DUPU message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 ASP3 SGP NIF All AS are active <---------- N-PCState DPC M <---------------------------- DUPU <----------------- DUPU <---------- N-PCState DPC M <--------- DUPU TEST DESCRIPTION: 1. Send N-PCState indication Primitive from NIF in the SGP containing Affected DPC M and Remote SCCP status as User Part Unavailability. Check A: SGP SHOULD send DUPU message containing corresponding RCs Anjali Gurmukhani, HSS [Page 51] Internet Draft SUA Conformance Test Plan Aug 2003 for AS Affected DPC M, cause as received from NIF. Check B: DUPU message is received at ASP1 and ASP2. Check C: DUPU message is sent on the Stream number 0. 2. Repeat the above test case with cause values Unequipped Remote User and Inaccessible Remote User and other parameters being the same as in the above tests. DUPU message will be received with these cause values. Also try the test case without sending anything in User/Cause parameter. This should result in an Error with Mandatory Parameter missing error cause. Anjali Gurmukhani, HSS [Page 52] Internet Draft SUA Conformance Test Plan Aug 2003 "Route Restricted" + TEST NUMBER: SSNM_5 + PURPOSE: To check that if N-PCState indication primitive with status as Restricted is received from NIF at SGP then SUA at SGP sends DRST Message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 ASP3 SGP NIF All AS are active <---------- N-PCState status Restricted <---------------------------- DRST <----------------- DRST <---------- N-PCState Cause Restricted <--------- DRST TEST DESCRIPTION: 1.Send N-PCState indication Primitive message from NIF in the SGP containing Affected DPC M and cause restricted. Check A: DRST message will be received at the ASP1 and ASP2 containing the corresponding RCs and Affected DPC M. Check C: DRST message is sent on the Stream number 0. 2.Repeat the above test case by sending the N-PCState indication with the affected Point code belonging to the network corresponding to the network appearance being served by AS3. Then the DRST should go to ASP3. Anjali Gurmukhani, HSS [Page 53] Internet Draft SUA Conformance Test Plan Aug 2003 Note: When SSN is included in the message parameter, the DRST message corresponds to the SCCP N-COORD primitive. If the SMI parameter is also included in the message, the DRST message corresponds to the N- COORD Request and N-COORD Indication primitives, otherwise, the DRST message corresponds to the N-COORD Response and N-COORD Confirm primitives. The Affected Point Code can only contain one point code when SSN is present. Anjali Gurmukhani, HSS [Page 54] Internet Draft SUA Conformance Test Plan Aug 2003 "DAUD without Mandatory Parameter" + TEST NUMBER : SSNM_6 + PURPOSE: To verify that DAUD received at SGP without Mandatory parameter is rejected. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1. AS1 is in Active state. Also arrange the data in ASP such that DAUD is sent to SGP without Affected Point code parameter. EXPECTED MESSAGE SEQUENCE : ASP1 SGP NIF AS1 is active Daud without Mandatory param -------------------------> ----------------- >Received Rejected <---------- Error sent Mandatory param missing TEST DESCRIPTION: 1. Send DAUD message from ASP1 to SGP without "Affected Point code" param. Check A: DAUD message is received at SGP and rejected. Check B: Error message with "Mandatory Parameter Missing" error cause is sent to ASP. Anjali Gurmukhani, HSS [Page 55] Internet Draft SUA Conformance Test Plan Aug 2003 4.4 DYNAMIC ROUTING KEY MANAGEMENT "Routing Key Registration" + TEST NUMBER: DRKM_1 + PURPOSE: To check that on receiving a Routing Key Registration Request for a new valid RK from an ASP, the SGP adds a RK and confirms the registration to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. The ASP is in Inactive state. The Routing Key RK1 is not configured at the SGP side. Arrange Data in ASP such that a Routing Key Registration request is sent from ASP to SGP on stream 0. EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF ASP is Inactive <-------- UNITDATA (For RK1) Send Failure ---------> REG REQ(RK1) -----------------> RK REG Ind --------> <----------------- REG RSP (SUCCESS, RC1) <---------------- NTFY(AS - InActive) ASPAC(RC1) ----------------> Status Ind -------> To ASP <---------------- ASP-Active-Ack <-------- UNITDATA(For RK1) To ASP <--------------- DATA Anjali Gurmukhani, HSS [Page 56] Internet Draft SUA Conformance Test Plan Aug 2003 TEST DESCRIPTION: 1. Select a valid RK1 (Eg. DPC = Z, SSN = 5) that is not already configured at the SGP. Send Data for RK1 from SGP side. Check A: A Send Failure would be reported at the SGP Side. 2. Send a valid Reg Req message from ASP to SGP Stack. Check B: A REG_IND would be received at the NIF(SM) and a REG_RSP message would be received at the ASP side with RC value and a Success Status for REG_RSP. Check that the AS to which ASP has been added has the same configuration as requested in the Dynamic Registration. Check C: Ntfy (AS-inactive) is sent to ASP. 3. Send a ASPAC from ASP to SGP for RC1. Check C: A Status Ind for ASP Active for RC1 is received at the NIF(SM). Active-Ack with RC1 is received at ASP and Notify with State AS Active for RC1 is received at the SGP. 4. Send Data for RK1 from SGP. Check D: Data Message is received at the ASP side. Note: In some implementations, when Data is sent for an unconfigured RK then instead of giving a Send Failure the Stack may route the Data through a Default AS . Anjali Gurmukhani, HSS [Page 57] Internet Draft SUA Conformance Test Plan Aug 2003 "Routing Key Deregistration" + TEST NUMBER: DRKM_2 + PURPOSE: To check that on receiving a Routing Key Deregistration Request for a existing RK from an ASP, the SGP removes the requesting ASP from the List of ASPs serving that RK. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. The Routing Key RK1 is configured at the SGP side. The ASP is in Active State for RK1 at the SGP. Arrange Data in ASP such that a Routing Key Deregistration request for RK1 is sent from ASP to SGP on stream 0. EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF ASP is Active in AS with RK1. ASPIA(RC1) ----------------> Status Ind -------> To ASP <---------------- ASP-Inactive-Ack <---------------- NTFY(AS - Pending) <---------------- NTFY(AS - Inactive)[after timer expiry] DEREG REQ(RC1) -----------------> RK DEREG Ind --------> <----------------- DEREG RSP (SUCCESS, RC1) TEST DESCRIPTION: 1. Send an ASPIA message to the SGP from ASP with the RC as the RC with which RK1 is configured at the SGP. Check A: A Status Ind is received at the NIF. ASPIA-Ack is received at the ASP and NTFY with RC1 and Status AS-Inactive is received at the ASP After pending timer expiry. Anjali Gurmukhani, HSS [Page 58] Internet Draft SUA Conformance Test Plan Aug 2003 2. Send DeReg Req message with RC as RC1 from ASP to SGP. Check B: A DEREG_IND would be received at the NIF(SM) and a DEREG_RSP message would be received at the ASP side with RC value as RC1 and a Success Status for DEREG_REQ. Anjali Gurmukhani, HSS [Page 59] Internet Draft SUA Conformance Test Plan Aug 2003 ôRegistration in an existing AS at SGP." + TEST NUMBER : DRKM_3 + PURPOSE: To check that on receiving a Routing Key Registration Request for a existing RK from an ASP, the SGP adds the requesting ASP to the List of ASPs serving that RK. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1 .ASP2. The Routing Key RK1 is configured at the SGP side. The ASP1 is in Inactive State at the SGP and ASP2 is actively handling Traffic for RK1 with RC value as RC1. The AS for RK1 is in Traffic handling Mode Override. Arrange Data in ASP such that a valid Routing Key Registration request with Traffic Mode consistent with mode at SG for RK1 is sent from ASP1 to SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP1 is Inactive <-------- UNITDATA(For RK1) To ASP2 <--------------- DATA From ASP1 REG REQ(RK1) -----------------> RK REG Ind --------> <----------------- REG RSP (SUCCESS, RC1) From ASP1 ASPAC(RC1) ----------------> Status Ind -------> To ASP1 <---------------- ASP-Active-Ack To ASP2 <---------------- Ntfy(Alternate ASP-Act) Anjali Gurmukhani, HSS [Page 60] Internet Draft SUA Conformance Test Plan Aug 2003 <-------- UNITDATA(For RK1) To ASP1 <--------------- DATA TEST DESCRIPTION: 1. Send a Data Message from SGP for RK1. Check A: Data would be received at ASP2. 2. Send a valid Registration Req message for RK1 from ASP1 to SGP Stack. Check B: A REG_IND would be received at the NIF(SM) and a REG_RSP message would be received at the ASP1 with RC value as RC1 and a Success Status for REG_REQ. 3. Send a ASPAC with Traffic Mode Override from ASP1 to SGP for RC1. Check C: A Status Ind for ASP Active for RC1 is received at the NIF(SM). Active-Ack with RC1 is received at ASP1 and Notify with Alt-ASP Act is received at the ASP2. 4. Send a Data Message from SGP for RK1. Check D: Data would be received at ASP1. Anjali Gurmukhani, HSS [Page 61] Internet Draft SUA Conformance Test Plan Aug 2003 " RK Registration Fails when ASP is Active for the RK " + TEST NUMBER: DRKM_4 + PURPOSE: To check that on receiving a Routing Key Registration Request for an existing RK from an ASP that is already active for the RK, the Registration Fails and a Negative Response Message is sent to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. The Routing Key RK1 is configured at the SGP side. The ASP is in Active State for RK1 at the SGP. Arrange Data in ASP such that a Routing Key Registration request for RK1 is sent from ASP to SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active for RK1 REG REQ(RK1) -----------------> <----------------- REG RSP (FAILURE) <-------- UNITDATA(For RK1) To ASP <--------------- DATA TEST DESCRIPTION: 1. Send a valid Reg Req message for RK1 from ASP to SGP Stack. 2. Check A: REG_RSP message would be received at the ASP side with Failure Response. 3. Send a Data Message from SGP for RK1. 4. Check C: Data would be received at ASP. Anjali Gurmukhani, HSS [Page 62] Internet Draft SUA Conformance Test Plan Aug 2003 " RK Deregistration Fails when ASP is Active for the RK " + TEST NUMBER: DRKM_5 + PURPOSE: To check that on receiving a Routing Key Deregistration Request for an existing RK from an ASP which is active for the RK, the Deregistration Fails and a Failure Response Message is sent to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. The Routing Key RK1 is configured at the SGP side. The ASP is in Active State for RK1 at the SGP. Arrange Data in ASP such that a Routing Key Deregistration request for RK1 is sent from ASP to SGP on stream 0. EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF ASP is Active for RK1 DEREG REQ(RC1) -----------------> <----------------- DEREG RSP (FAILURE) Err Code: ASP Currently Active for RC TEST DESCRIPTION: 1. Send a valid DeReg Req message for RK1 from ASP to SGP Stack. 2. Check A: A DEREG_RSP would be received at the ASP side with Registration Status as Failed and Error Code as "ASP Currently Active for Routing Context". Anjali Gurmukhani, HSS [Page 63] Internet Draft SUA Conformance Test Plan Aug 2003 " Unique RC Value for a given RK " + TEST NUMBER : DRKM_6 + PURPOSE: To check that on receiving a Routing Key Registration Request from two different ASPs at the SGP Stack, the SGP allocates the same RC ID to both of these. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1 , ASP2. Both ASP1 and ASP2 are in Inactive State at the SGP. Arrange Data in ASP1 and ASP2 such that a valid Routing Key Registration request for RK1 is sent from ASP to SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP1 and ASP2 are Inactive From ASP1 REG REQ(RK1) -----------------> RK REG Ind --------> <----------------- REG RSP (SUCCESS, RC1) From ASP2 REG REQ(RK1) -----------------> RK REG Ind --------> <----------------- REG RSP (SUCCESS, RC1) TEST DESCRIPTION: 1. Send a valid Reg Req message for RK1 from ASP1 to SGP Stack. Check A: A REG_IND would be received at the NIF(SM) and a REG_RSP message would be received at the ASP1 with RC value as RC1 and a Success Status for REG_REQ. Anjali Gurmukhani, HSS [Page 64] Internet Draft SUA Conformance Test Plan Aug 2003 2. Send a valid Reg Req message for RK1 from ASP2 to SGP Stack. Check B: A REG_IND would be received at the NIF(SM) and a REG_RSP message would be received at the ASP2 with RC value again as RC1 and a Success Status for REG_REQ. Anjali Gurmukhani, HSS [Page 65] Internet Draft SUA Conformance Test Plan Aug 2003 "AS does not Loadshare the data to ASP that has deregistered from the AS" + TEST NUMBER: DRKM_7 + PURPOSE: To verify that after an ASP has successfully deregistered from the AS, data is not routed to that ASP. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2. Both ASP1 and ASP2 have been added dynamically to AS.AS is routing data to both the ASPs on Loadshare basis. EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 SGP SM + NIF ASPs are active <-------- UNITDATA (For RK1) <-------CLDT ASP1 receives data <-------- UNITDATA (For RK1) <-------CLDT ASP2 receives data ASP1 ASPIA--------------------> ASPIA-ack <------------ Indication to SM <---------------- DEREG REQ(RK1) -----------------> <------------ DEREG RSP (SUCCESS, RC1) ASP1 Anjali Gurmukhani, HSS [Page 66] Internet Draft SUA Conformance Test Plan Aug 2003 <------- Dereg Indication <-------- UNITDATA(For RK1) To ASP2 <---------------CLDT <-------- UNITDATA(For RK1) To ASP2 <---------------CLDT TEST DESCRIPTION: 1. Send ASPIA from ASP1. Check A: SGP receives ASPIA and sends back ASPIA-ack Check B: ASP indicates Inactive to SM. The state of AS is Active if the minimum number of ASPs that can be Active in the AS is 1. 2. Send a valid DeReg Req message from ASP1 to SGP Stack. Check B: A DEREG_IND would be received at the NIF(SM) and a DEREG_RSP message would be received at the ASP1 side with RC value and a Success Status for DEREG_REQ. Check that ASP1 is removed from the AS. 3. Send CLDT from SGP. Check C: Data should go to only ASP2 4. Send another CLDT from SGP, it should again go to ASP2. Anjali Gurmukhani, HSS [Page 67] Internet Draft SUA Conformance Test Plan Aug 2003 4.5 MANAGEMENT "Handling of Invalid messages at SGP" + TEST NUMBER: MGMT_1 + PURPOSE: To check that if the SGP receives an ASP-UPACK message it discards the message. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams.) EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ---------------> ASP-UPAck <------------ ERROR TEST DESCRIPTION: 1. Generate an ASP-UPAck Message to be destined to the SGP. Check A: The SGP Should discard this message and report an error to SM. Also it sends Error message back to ASP with error code "Protocol Error". The Above test case MUST be carried out for the following combinations Anjali Gurmukhani, HSS [Page 68] Internet Draft SUA Conformance Test Plan Aug 2003 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ SGP DUNA DAVA DUPU ASPUP_ACK ASPDN_ACK ASPAC_ACK ASPIA_ACK REG_RSP DEREG_RSP ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Anjali Gurmukhani, HSS [Page 69] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPUP message for an ASP which is in LOCKED state" + TEST NUMBER: MGMT_2 + PURPOSE: To check that if ASPUP message is received for an ASP, which has been marked as LOCKED for MGMT purposes, the SGP sends an error message with error code "Refused - Management Blocking". + TEST CONFIGURATION: The Following test cases MUST be executed at SGP/IPSP. The example listed below covers the IUT running at the SGP. + PRE-TEST CONDITIONS: SCTP association is established between SGP and AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in AS such that ASPUP message is sent to the SGP two times on stream 0. EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF AS is Down <--------- LOCK ASP ASPUP ----------------> <--------------- ERR(Refused - Management Blocking) <------------ ERROR TEST DESCRIPTION: 1. Lock the ASP on the SGP side for MGMT purposes. 2. Send ASPUP message to the SGP in ASP-Down state. Check A: No ASP-Up-Ack and NTFY message will come from the SGP. 3. Send ASPUP message again from same ASP. Check A: an ERROR Message should be sent in response to the ASPUP message with error code "Refused - Management Blocking". Anjali Gurmukhani, HSS [Page 70] Internet Draft SUA Conformance Test Plan Aug 2003 "Invalid Traffic mode in ASP-Active Message" + TEST NUMBER: MGMT_3 + PURPOSE: To check that if ASPAC message carries a Traffic mode which is incompatible at the SGP, then an error message with code "Unsupported / Invalid Traffic Handling Mode" MUST be sent. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. The AS to which the ASP belongs MUST be configured at the SGP with traffic handling mode OVERIDE. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is INACTIVE ASPAC ----------------> (Traffic mode = Loadshare) <--------------- ERR(Unsupported / Invalid Traffic Handling Mode) <------------ ERROR TEST DESCRIPTION: 1. Send ASPAC message(With Traffic mode as Loadshare) to the ASP in ASP-Inactive state. Check A: SGP Should send an error message with error code "Unsupported / Invalid Traffic Handling Mode". Anjali Gurmukhani, HSS [Page 71] Internet Draft SUA Conformance Test Plan Aug 2003 "Unrecognized Message Type" + TEST NUMBER : MGMT_4 + PURPOSE: To check that if a message with message type not defined is received at SGP, SGP responds with ERROR message containing cause "Unsupported Message Type". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP1 is active. Arrange the data in ASP such that a message with Message type not defined is sent to SGP. Let the other parameters in the message be like any other message. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active Message ----------------> Message Type=0x408 <--------------- ERROR Cause = Unsupported Message Type TEST DESCRIPTION: 1. Send a message with message type 0x408 or any other value which is not defined for SUA protocol. Check A: ERROR message is received at the ASP containing cause Invalid Message Type. 2. Check B: State of AS at SGP is not disturbed. Anjali Gurmukhani, HSS [Page 72] Internet Draft SUA Conformance Test Plan Aug 2003 "Unrecognized Message Class" + TEST NUMBER : MGMT_5 + PURPOSE: To check that if a message with message Class not defined is received at SGP, SGP responds with ERROR message containing cause "Unsupported Message Class". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP1 is active. Arrange the data in ASP such that a message with Message class not defined is sent to SGP. Let the other parameters in the message be like any other message. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active Message ----------------> Message CLASS=0x408 <--------------- ERROR Cause = Unsupported Message CLASS TEST DESCRIPTION: 1. Send a message with message class 0x408 or any other value which is not defined for SUA protocol. Check A: ERROR message is received at the ASP containing cause Unsupported Message Class. Check B: State of AS at SGP is not disturbed. Anjali Gurmukhani, HSS [Page 73] Internet Draft SUA Conformance Test Plan Aug 2003 "Invalid Stream Identifier" + TEST NUMBER : MGMT_6 + PURPOSE: To check that if ASPSM(except BEAT/BEAT-ack) is received on an unexpected SCTP stream, error containing error code "Invalid Stream Identifier" is sent back. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established (with multiple streams)between SGP and ASP and ASP1 is down. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is down ASPUP ----------------> Stream Identifier 2 <--------------- ERROR Cause = Invalid Stream Identifier TEST DESCRIPTION: 1. Send ASPUP on SCTP stream Id 2. 2. Check A: ERROR message is received at the ASP containing cause Invalid Stream Identifier. 3. Check B: State of AS at SGP is not disturbed. Note: The above test case can be repeated for SUA MGMT,RKM messages also. Anjali Gurmukhani, HSS [Page 74] Internet Draft SUA Conformance Test Plan Aug 2003 "Message length less than the length of mandatory Parameters" + TEST NUMBER: MGMT_7 + PURPOSE: To check that if a message with value of length parameter less than length of mandatory parameters is received then message is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and AS is in AS-Active state. Arrange the data in ASP such that Error message with length parameter filled with value less than the length of error code parameter is sent. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF AS is Active Error ----------------> Message Length = 2 <--------------- Error (Protocol Error) TEST DESCRIPTION: 1. Send Error message with length parameter filled with value less than the length of error code field to the SGP. Check A: SGP will send an Error message . Check B: State of AS at SGP is not disturbed. Anjali Gurmukhani, HSS [Page 75] Internet Draft SUA Conformance Test Plan Aug 2003 "ERROR Message Handling" + TEST NUMBER : MGMT_8 + PURPOSE: To check that if an error is received then that is reported to the SM and no action is taken against that. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is active. Arrange data in ASP such that ERROR with cause invalid version is sent to the SGP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active ERROR ----------------> cause=Invalid version Error -------> TEST DESCRIPTION: 1. Send ERROR message with cause invalid version from ASP to SGP. Check A: Error should be reported to the SM. Check B: Further action at the SGP is implementation dependent. 2. Repeat the test case for other cause values in ERROR message. Anjali Gurmukhani, HSS [Page 76] Internet Draft SUA Conformance Test Plan Aug 2003 "Reception of Unpadded Message" + TEST NUMBER : MGMT_9 + PURPOSE: If the SGP receives a Message from the ASP which is not padded, then also the Message should be Processed. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is in ASP-Down state. Arrange data in ASP such that ASPUP is sent to SGP with size of Info String such that the Total Message Length is 35 Bytes and this Message should not be padded. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Down ASPUP ----------------> (Length is 35 Bytes) <---------------- ASPUP-Ack <---------------- Ntfy (AS-Inactive) TEST DESCRIPTION: 1. Send the ASPUP message as described from ASP to SGP on Stream 0. 2. Check A: The Message should not be rejected at the SGP. 3. Check B: ASP UP Ack and NTFY should be sent from the SGP side. Anjali Gurmukhani, HSS [Page 77] Internet Draft SUA Conformance Test Plan Aug 2003 5.Test Cases for Testing SUA at ASP 5.1 ASPSM "ASPDN-ACK message in ASP-INACTIVE state" + TEST NUMBER: ASPSM_1 + PURPOSE: To check that if ASPDN-ACK message is received in ASP-INACTIVE state then the ASP Should move to ASP-Down, and the Procedure to bring the ASP into ASP-INACTIVE State may be initiated by ASP itself. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. EXPECTED MESSAGE SEQUENCE: ASP SGP SM + NIF ASP is INACTIVE <--------------- ASPDN-Ack (ASP SHOULD Move to Down State) <<<< ASP may Initiate the procedures to bring itself to it's previous State >>>> ASPUP ----------------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) TEST DESCRIPTION: 1. Send ASPDN-ACK message to the ASP in ASP-InActive state. Check A: ASP MUST move to ASP-Down State. Check B: The ASP may Now initiate Procedures to bring itself to it's previous state. 2. The ASP Sends ASPUP message to the SGP in ASP-Down state. Check A: ASP-Up-Ack and NTFY (AS-Inactive) messages will come from the SGP. Check B: ASP notifies SM about the ASP becoming Up. Anjali Gurmukhani, HSS [Page 78] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPDN-ACK message in ASP-Active state" + TEST NUMBER : ASPSM_2 + PURPOSE: To check that if ASPDN-ACK message is received in ASP- Active state then the ASP Should move to ASP-Down, and the procedure to bring the ASP into ASP-ACTIVE state may be initiated by the ASP itself. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active <--------------- ASPDN-Ack (ASP SHOULD Move to Down State) <<<< ASP may Initiate the procedures to bring itself to it's previous State >>>> ASPUP ----------------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-InActive) ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) TEST DESCRIPTION: 1. Send ASPDN-ACK message to the ASP in ASP-Active state. Check A: ASP Should move to ASP-Down State. Anjali Gurmukhani, HSS [Page 79] Internet Draft SUA Conformance Test Plan Aug 2003 Check B: The ASP may Now initiate Procedures to bring itself to it's previous state. 2. ASP Sends ASPUP message to the SGP in ASP-Down state. Check A: ASP-Up-Ack and NTFY (AS-Inactive) are received at ASP. 3. The ASP Sends ASPAC message to the same ASP. Check A: ASP-Act-Ack message should be received at ASP. Check B: State of ASP at SGP is now ASP-ACTIVE. Check C: NTFY(AS-Active) is received at ASP. Anjali Gurmukhani, HSS [Page 80] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPUP-Ack message is not received in response to ASPUP message" + TEST NUMBER: ASPSM_4 + PURPOSE: To check that if Ack message is not received in response to the ASPUP message then ASP keeps on sending ASPUP message at an interval for some time and after some tries will report the SM. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. Also arrange the data in ASP such that SM sends ASP Up primitive to the SUA. Arrange data in SGP such that Ack message is not sent in response to the ASPUP message. EXPECTED MESSAGE SEQUENCE : SGP ASP SM <----------- ASP-Up <------------ ASPUP | |time t1 <------------ ASPUP | |time t1 <------------ ASPUP . . n tries . Status Ind ----------> TEST DESCRIPTION: 1. Send ASP-Up primitive from SM at ASP. ASP will send ASPUP message to the SGP. Don't send Ack message from the SGP. Check A: ASPUP message will be retransmitted to the SGP. Check B: The ASPUP Message will be retransmitted as many times as has been configured in the implementation Check C: After Maximum number of retries as configured by the implementation, the ASP Down Ind would be received at SM. Anjali Gurmukhani, HSS [Page 81] Internet Draft SUA Conformance Test Plan Aug 2003 2. Repeat the above test case for ASPDN message also i.e. Ack message is not sent in response to ASPDN message. Anjali Gurmukhani, HSS [Page 82] Internet Draft SUA Conformance Test Plan Aug 2003 "ASP-Up-Ack is received in response to ASPDN message" + TEST NUMBER : ASPSM_5 + PURPOSE: To check that if ASP-Up-Ack message is received in response to the ASPDN then the Ack message is rejected and ASPDN is sent again. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is Up. Arrange data in SGP such that ASP-Up-Ack is sent to ASP in response to ASPDN message on stream 0. EXPECTED MESSAGE SEQUENCE : SGP ASP SM ASP is Inactive <--------- ASP-Down <----------- ASPDN ASP-Up-Ack ------------> <----------- ASPDN -------->Status Ind (Down) TEST DESCRIPTION: 1. Send ASP-Down Primitive to the ASP. ASPDN message will be sent to the SGP. 2. Send ASP-Up-Ack message in response to the ASPDN message. Check A: ASPDN message is received again at the SGP and ASP keeps retransmitting ASPDN message till it gets ASPDN-ack. Check B: After n number of retries as configured by implementation ASP down indication is given to SM. 3. Repeat the above test case if Ack message is sent. Note: The above test holds true for ASPIA/ASPAC acks in response to ASPDN message Anjali Gurmukhani, HSS [Page 83] Internet Draft SUA Conformance Test Plan Aug 2003 "ASP-Up-Ack is received in response to ASPAC message" + TEST NUMBER: ASPSM_6 + PURPOSE: To check that if ASP-Up-Ack message is received in response to the ASPAC then the Ack message is accepted and ASPAC retransmission is stopped. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is Up. Arrange data in SGP such that ASP-Up-Ack is sent to ASP in response to ASPAC message . EXPECTED MESSAGE SEQUENCE : SGP ASP SM ASP is Inactive <--------- ASP-Active <----------- ASPAC ASP-Up-Ack ------------> Accepted and Inactive indicated to SM TEST DESCRIPTION: 1. Send ASP-Active Primitive to the ASP. ASPAC message will be sent to SGP. 2. Send ASP-Up-Ack message in response to the ASPAC message. Check A: ASPAC retransmission is stopped and status indication indicating Inactive is sent to SM. Note: The above test can be run when ASPIA-Ack is received in response to ASPAC. Anjali Gurmukhani, HSS [Page 84] Internet Draft SUA Conformance Test Plan Aug 2003 5.2 ASPTM "ASPDN-ack received in response to ASPAC" + TEST NUMBER: ASPTM_1 + PURPOSE: To Check that if ASPDN-ack is received in response to ASPAC, ASPAC retransmissions are stopped. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is inactive. EXPECTED MESSAGE SEQUENCE: SM ASP SGP NIF ASPAC ----------------> <----------------ASPDN-ack <---------------- Accepted and indicated DN to SM. TEST DESCRIPTION: 1. Send ASPAC message to the SGP in ASP-Inactive state. 2. Send ASPDN-ack from the peer SGP. Check A: ASPAC retransmissions are stopped . Check B: ASP informs the SM with Down indication. Anjali Gurmukhani, HSS [Page 85] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPIA -Ack received in response to ASPAC" + TEST NUMBER: ASPTM_2 + PURPOSE: To check that if ASPIA-ack is received in response to ASPAC, ASPAC retransmissions are stopped. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is inactive. EXPECTED MESSAGE SEQUENCE: SM ASP SGP NIF ASPAC ----------------> <----------------ASPIA-ack <---------------- Accepted and indicated Inactive to SM TEST DESCRIPTION: 1. Send ASPAC message to the SGP in ASP-Inactive state. 2. Send ASPIA-ack from the peer SGP. Check A: ASPAC retransmissions are stopped. Check B: ASP informs the SM about Inactive state of ASP. Anjali Gurmukhani, HSS [Page 86] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPAC-ack with multiple duplicate Routing contexts" + TEST NUMBER : ASPTM_3 + PURPOSE: To Check that if ASPAC-ack with multiple duplicate Routing contexts is sent, the message is accepted at ASP and ASPAC retransmissions stop. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is inactive. AS has been added with RC value P. EXPECTED MESSAGE SEQUENCE: SM ASP SGP NIF ASPAC ----------------> <----------------ASPAC-ack <---------------- Accepted and indicated Active SM. TEST DESCRIPTION: 1. Send ASPAC message to the SGP in ASP-Inactive state. 2. SGP sends the ack for ASPAC with multiple duplicate Routing context values . Check A: ASPAC retransmissions are stopped as ASPAC-ack is accepted by ASP. Check B: ASP informs the SM about ASP active for AS with RC value P. Anjali Gurmukhani, HSS [Page 87] Internet Draft SUA Conformance Test Plan Aug 2003 "ASP-Active-Ack is received in response to ASPIA message" + TEST NUMBER: ASPTM_4 + PURPOSE: To check that if ASP-Active-Ack message is received in response to the ASPIA then the Ack message is discarded and ASPIA is sent again. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is active. Arrange the data in SGP such that ASP-Active-Ack with routing context P is sent to ASP. EXPECTED MESSAGE SEQUENCE : SGP ASP SM ASP is active <--------- ASP-Inactive <----------- ASPIA ASP-Active-Ack ------------> <----------- ASPIA TEST DESCRIPTION: 1. Send ASP-Inactive Primitive to the ASP. ASPIA message will be sent to the SGP. 2. Send ASP-Active-Ack message in response to the ASPIA message. Check A: ASPIA message is received again at the SGP. Anjali Gurmukhani, HSS [Page 88] Internet Draft SUA Conformance Test Plan Aug 2003 "ASP-Down-Ack is received in ASP Active/Inactive State" + TEST NUMBER: ASPTM_5 + PURPOSE: To check that if ASP-Down-Ack message is received in any state, the state of the ASP changes to Down. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is Active/Inactive. Arrange the data in SGP such that ASP-Down-Ack is sent to ASP on stream 0. EXPECTED MESSAGE SEQUENCE: SGP ASP SM ASP is Active/Inactive ASP-Down-Ack ------------> Status Ind ---------> ASP is Down TEST DESCRIPTION: 1. Send ASP-Down-Ack Message from SGP. 2. Check A: Status Ind with ASP State Down is received at ASP. Anjali Gurmukhani, HSS [Page 89] Internet Draft SUA Conformance Test Plan Aug 2003 "Multiple ASP-Active-Ack are received in response to ASP Active" + TEST NUMBER : ASPTM_6 + PURPOSE: To Check that ASP successfully processes RCs spread over Multiple ASP Active Ack Messages. + TEST CONFIGURATION: I + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP is Inactive. Arrange the data in SGP such that ASP-Active-Ack with RC value P or Q are sent to ASP. EXPECTED MESSAGE SEQUENCE : SGP ASP SM ASP is Inactive <--------- ASP-Active <------------ ASPAC (RC P, RC Q) ASP-Active-Ack ------------> (RC P) NTFY (AS-Active) ------------> (RC P) | Status Ind ---------> | | Timer Expires <------------ ASPAC (only RC Q) ASP-Active-Ack ------------> (RC Q) NTFY (AS-Active) ------------> (RC Q) Status Ind ---------> TEST DESCRIPTION: 1. Invoke ASP Active Primitive from ASP with RC value as P and Q. Check A: ASPAC is received at SGP with Routing Contexts P and Q. 2. Send ASP Active Ack and NTFY from SGP with only one RC value P. Check B: Status Ind for RC P is received at ASP and after time-out ASPAC is retransmitted with just one RC = Q. 3. Send ASP Active Ack and NTFY from SGP with only one RC value Q. Check C: Status Ind for RC Q is indicated at ASP. Anjali Gurmukhani, HSS [Page 90] Internet Draft SUA Conformance Test Plan Aug 2003 Note: In some Implementations Retransmission is not done. Here a negative Indication to the SM would be given regarding RC Q and ASPAC will not be resent. Anjali Gurmukhani, HSS [Page 91] Internet Draft SUA Conformance Test Plan Aug 2003 "ASPIA-ACK message in ASP-Active state" + TEST NUMBER : ASPTM_7 + PURPOSE: To check that if ASPIA-ACK message is received in ASP-Active state then the ASP Should move to ASP-INACTIVE, and the procedure to bring the ASP into ASP-ACTIVE state should be initiated by the ASP itself. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active <--------------- ASPIA-Ack (ASP SHOULD Move to INACTIVE State) <<<< ASP may Initiate the procedures to bring itself to it's previous State >>>> ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) TEST DESCRIPTION: 1. Send ASPIA-ACK message to the ASP in ASP-Active state. Check A: ASP Should move to ASP-INACTIVE State. Check B: The ASP may Now initiate Procedures to bring itself to it's previous state. 2. ASP Sends ASPAC message for the same ASP. Check A: ASP-Act-Ack message should be received at ASP. Check B: State of ASP at SGP is now ASP-ACTIVE. Anjali Gurmukhani, HSS [Page 92] Internet Draft SUA Conformance Test Plan Aug 2003 5.3 SSNM "Reception of SSNM messages" + TEST NUMBER: SSNM_1 + PURPOSE: To check that if SSNM message is received at the ASP then it is reported to the ULP. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is Active. Also arrange the data in SGP such that DUNA, DAVA, DUPU, DRST and SCON messages are sent from the SGP to the ASP with valid parameters and they are sent on stream number 0. EXPECTED MESSAGE SEQUENCE : SGP ASP SU AS is active a) DUNA ---------------> N-Pcstate-Ind--------> b) DAVA ---------------> N-Pcstate-Ind --------> c) SCON ---------------> N-Pcstate-Ind --------> d) DUPU ---------------> N-Pcstate-Ind --------> e) DRST ---------------> Anjali Gurmukhani, HSS [Page 93] Internet Draft SUA Conformance Test Plan Aug 2003 N-Pcstate-Ind --------> TEST DESCRIPTION: 1. Send DUNA message from SGP to ASP containing Routing Context Value P and Affected DPC any value. Check A: N-PCState indication primitive will be received at the SU. 2. Repeat the above test case for other messages like DAVA, SCON, DRST and DUPU messages. 3. Repeat the above test case for multiple Point Codes. Note: If in the SSNM messages , only Point code is included, the message should result in N-Pcstate indication and if SSN is included ,SSNM message results in N-State indication being given to SU. Anjali Gurmukhani, HSS [Page 94] Internet Draft SUA Conformance Test Plan Aug 2003 "Selection of Route to Point Code: Routes Restricted & Unavailable " + TEST NUMBER: SSNM_2 + PURPOSE: To check that when a Restricted and unavailable Routes are available for a Point code, ASP routes through RESTRICTED Route. + TEST CONFIGURATION: H + PRE-TEST CONDITIONS: SCTP association is established between SG1, and ASP and SG2 and ASP. SGP1 serves SG1 and SGP2 serves SG2. ASP is Active for RC P in all SGPs. Also arrange the data in ASP such that SU sends Unitdata Indication primitive to SUA containing the RC value P. Also arrange Data at SGPs to send SSNM for PC Y. Route to PC Y is available from both SG1 and SG2. The routes through both the SGs are equi-priority routes and ASP loadshares between two SGs. EXPECTED MESSAGE SEQUENCE: SGP ASP SU ASP is Active in all SGPs. <----------- CLDT DPC Y To SGP1 <--------------- DATA <----------- CLDT DPC Y To SGP2 <--------------- DATA From SGP1 DUNA ---------------> (for PC Y) <----------- CLDT DPC Y To SGP2 <--------------- DATA Anjali Gurmukhani, HSS [Page 95] Internet Draft SUA Conformance Test Plan Aug 2003 <----------- CLDT DPC Y To SGP2 <--------------- DATA From SGP1 DAVA ---------------> (for PC Y) From SGP2 DRST ---------------> (for PC Y) <----------- CLDT DPC Y To SGP1 <--------------- DATA <----------- CLDT DPC Y To SGP1 <--------------- DATA From SGP1 DUNA ---------------> (for PC Y) <----------- CLDT DPC Y To SGP2 <--------------- DATA TEST DESCRIPTION: 1. Send two Unitdata Request Primitive from the SU at ASP side. Check A: DATA message 1 reaches SGP1, and Data Message 2 reaches SGP2. 2. Send a DUNA from SGP1 to ASP with Affected Point Code as Y. 2. Repeat the Step1 with appropriate Seq control (S,T) for Loadsharing. Check B: Data Message 1 as well as Data Message 2 are both received SGP1 as well as SGP2. 4. Send a DAVA from SGP1 to ASP with Affected Point Code as Y and a DRST from SGP2 to ASP with Affected Point Code as Y. 5. Repeat the Step1 with appropriate Sequence ctrl (S,T) for Loadsharing. Check C: DATA message 1 reaches SGP1, and Data Message 2 reaches SGP2. Anjali Gurmukhani, HSS [Page 96] Internet Draft SUA Conformance Test Plan Aug 2003 6. Send a DUNA from SGP1 to ASP with Affected Point Code as Y. 7. Send Data for Point Code Y. Check B: Data Message will be received at SGP2. Note: Corresponding to the different SSNM messages received at ASP i.e DUNA,DAVA verify that proper N-PCState/N-state indications are received at ASP. Anjali Gurmukhani, HSS [Page 97] Internet Draft SUA Conformance Test Plan Aug 2003 " Selection of Route to Point Code: Routes Congested & Restricted " + TEST NUMBER: SSNM_3 + PURPOSE: To check that when a Restricted and Congested Routes are available for a Point code, ASP routes through Congested Route. + TEST CONFIGURATION: H + PRE-TEST CONDITIONS: SCTP association is established between SGP1, SGP2 and ASP. ASP is Active for RC P in all SGPs. Also arrange the data in ASP such that SU sends a Unitdata Indication primitive to SUA containing the RC value P. Also arrange Data at SGPs to send SSNM for PC Y. Route to PC Y is available from both SG1 and SG2. SG mode for ASP is Loadshare. EXPECTED MESSAGE SEQUENCE: SGP ASP SU ASP is Active in all SGPs. <----------- CLDT DPC Y & Seq. ctrl S To SGP1 <--------------- DATA <----------- CLDT DPC Y & Seq ctrl T To SGP2 <--------------- DATA From SGP1 DRST ---------------> (for PC Y) <----------- CLDT DPC Y & Seq ctrl S To SGP2 <--------------- DATA From SGP2 SCON -------------------> Anjali Gurmukhani, HSS [Page 98] Internet Draft SUA Conformance Test Plan Aug 2003 <----------- CLDT DPC Y & Seq ctrl T To SGP2 <--------------- DATA From SGP1 DAVA ---------------> (For PC Y) From SGP2 DRST ---------------> (for PC Y) <----------- CLDT DPC Y & Seq ctrl S To SGP1 <--------------- DATA <----------- CLDT DPC Y & Seq ctrl T To SGP1 <--------------- DATA From SGP1 DUNA ---------------> (for PC Y) <----------- CLDT DPC Y To SGP2 <--------------- DATA TEST DESCRIPTION: 1. Send two Unitdata Primitive from the SU at ASP side with Seq. ctrl values S and T respectively. Check A: DATA message 1 reaches SGP1, and Data Message 2 reaches SGP2. 2. Send a DRST from SGP1 to ASP with Affected Point Code as Y. 3. Repeat the Step1 with appropriate Seq. ctrl values (S,T) for Loadsharing . Check B: Data Message 1 as well as Data Message 2 are both received SGP2. 4. Send a SCON from SGP2 to ASP with Affected Point Code as Y . 5. Repeat the step1 with appropriate Seq ctrl values for loadsharing. Check A: Data message should be routed through the Congested route. Anjali Gurmukhani, HSS [Page 99] Internet Draft SUA Conformance Test Plan Aug 2003 Note: Corresponding to the different SSNM messages received at ASP i.e DUNA,DAVA,SCON, verify that proper N-PCState/N-state indications are received at ASP. Anjali Gurmukhani, HSS [Page 100] Internet Draft SUA Conformance Test Plan Aug 2003 5.4 Dynamic Routing Key Procedures "RK Registration Request" + TEST NUMBER: DRKM_1 + PURPOSE: To check that when SM invokes Registration Request a valid REG_REQ message is sent to the SGP. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is Inactive in SGP. Also arrange the data in ASP such that Layer Mgmt sends a Reg. Req Primitive to SUA containing a valid Routing Key (Indicator). Also arrange Data at SGPs to send REG RESP with a RC value. EXPECTED MESSAGE SEQUENCE : SGP ASP LM ASP is Inactive in SGP. <----------- REG REQ (RK = RK1) To SGP <--------------- REG_REQ (RK1) REG_RSP ---------------> (RC1) REG RESPONSE -----------> TEST DESCRIPTION: 1. Invoke RK Registration Request from LM with a valid Routing Key. Check A: A REG_REQ Message with RK1 packed is sent from the ASP to SGP. 3. Send a REG_RSP with SUCCESS and RC Value RC1 from the SGP to the ASP. Check B: A Registration Success Response is sent to the SM at ASP and this is indicated to SM. Anjali Gurmukhani, HSS [Page 101] Internet Draft SUA Conformance Test Plan Aug 2003 "RK Deregistration Request" + TEST NUMBER: DRKM_2 + PURPOSE: To check that when SM invokes Deregistration Request a valid DEREG_REQ message is sent to the SGP. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is Inactive in SGP. Also arrange the data in ASP such that Layer Mgmt sends a DeReg Req Primitive to SUA containing a valid Routing Context. Also arrange Data at SGPs to send DEREG RESP with a RC value. EXPECTED MESSAGE SEQUENCE : SGP ASP LM ASP is Inactive in SGP. <----------- DEREG REQ (RC = RC1) To SGP <--------------- DEREG_REQ (RC1) DEREG_RSP ---------------> (RC1) DEREG RESPONSE -----------> TEST DESCRIPTION: 1. Invoke RK Deregistration Request from LM with a valid Routing Context. Check A: A DEREG_REQ Message with RC1 is sent from the ASP to SGP. 2. Send a DEREG_RSP with SUCCESS and RC Value RC1 from the SGP to the ASP. Check B: A Deregistration Success Response is indicated to SM at ASP. Anjali Gurmukhani, HSS [Page 102] Internet Draft SUA Conformance Test Plan Aug 2003 "RK Registration Response with Invalid LRK Identifier" + TEST NUMBER : DRKM_3 + PURPOSE: To check that for a sent Registration Request, if the ASP receives response with Invalid/Non-Matching LRK, it is rejected. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is Inactive in SGP. Also arrange the data in ASP such that SU sends a Reg. Req. Primitive to SUA containing a valid Routing Context. Also arrange Data at SGP to send Reg RESP with Invalid Local Routing Key identifier. EXPECTED MESSAGE SEQUENCE : ASP SGP SM+NIF -----------> REG REQ (RK1,LRK1) <--------------- REG_RESP (Invalid LRK) REG_RESP rejected TEST DESCRIPTION: 1. Invoke RK Registration Request from LM with a valid Routing Key. Check A: A REG_REQ Message with valid Routing key is sent from the ASP to SGP and LRK Id as 1. 2. Send Registration response from SGP with Invalid LRK Id from SGP to ASP. Check B: Registration Response is rejected at the ASP. Anjali Gurmukhani, HSS [Page 103] Internet Draft SUA Conformance Test Plan Aug 2003 5.5 MANAGEMENT "Handling of Invalid messages at ASP" + TEST NUMBER: MGMT_1 + PURPOSE: To check that if the ASP receives an ASP-UP message ,it discards the message. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams.) EXPECTED MESSAGE SEQUENCE: ASP SGP NIF <--------------- ASP-UP ------------> ERROR (error code = Protocol Error) TEST DESCRIPTION: 1. Generate an ASP-UP Message to be destined to the ASP. Check A: The ASP should discard this message and report an error to SM. A Check B: Error message is sent back to SGP with error code "Protocol Error" The Above test case MUST be carried out for the following combinations +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ASP DAUD ASPUP ASPDN ASPAC ASPIA REG_REQ DEREG_REQ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Anjali Gurmukhani, HSS [Page 104] Internet Draft SUA Conformance Test Plan Aug 2003 "Message length less than the length of mandatory Parameters" + TEST NUMBER : MGMT_2 + PURPOSE: To check that if a message with value of length parameter less than length of mandatory parameters is received then message is discarded. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP, and ASP is Down. Arrange the data in SGP such that ASPUP-Ack message with length parameter filled with value less than the length of Common Message Header. EXPECTED MESSAGE SEQUENCE : SGP ASP SM <--------- ASP-Up <----------- ASPUP ASP-Up-Ack ------------> <----------- ERROR <----------- ASPUP(sent after T(ack)) TEST DESCRIPTION: 1. Send ASP-Up primitive from SM to the SUA at the ASP. ASPUP message will be sent to the SGP. 2. Send ASP-Up-Ack message with length field less than the length of Common Message Header from the SGP. Check A: ASP will send an ERROR message to the SGP and discard the Message. Check B: ASPUP message will be sent again after ASPSM Timer Expiry. Note: Resending of ASPUP is implementation Dependent. Anjali Gurmukhani, HSS [Page 105] Internet Draft SUA Conformance Test Plan Aug 2003 "Invalid MASK Value in DUPU message" + TEST NUMBER : MGMT_3 + PURPOSE: To check that if DUPU message with MASK value other than 0 is received ,an error is sent back to SGP. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is active. Arrange the data in SGP such that DUPU message with mask value not equal to 0 is sent to the ASP. EXPECTED MESSAGE SEQUENCE : SGP ASP SM ASP is active DUPU ---------------> Mask not equal to 0 <-------------- ERROR Cause = Invalid Parameter value CLDT ---------------> RC-A Unitdata-Ind ---------> TEST DESCRIPTION: 1. Send DUPU message with Mask not equal to 0. Check A: ASP will send an ERROR Message with Invalid Parameter Value to SGP. 2. Send a CLDT Message to the ASP. Check B: Unitdata Indication will be given to the SU at ASP and State of ASP is not disturbed. Anjali Gurmukhani, HSS [Page 106] Internet Draft SUA Conformance Test Plan Aug 2003 "Parameter Field Error" + TEST NUMBER: MGMT_4 + PURPOSE: To check that if a message is sent with the length of one of its parameter incorrect, ASP responds with Error message + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is UP. Arrange the data in SGP such that DUNA with Affected point code as Z and length of this parameter as 0xa is sent. EXPECTED MESSAGE SEQUENCE: SGP ASP SM ASP is active DUNA ---------------> (Single PC=Z) <-------------- ERROR Cause = Parameter Field Error CLDT ---------------> RC-A Unitdata-Ind ---------> TEST DESCRIPTION: 1. Send DUNA message with Affected point code as Z and length of the point code field as 0xa. Check A: ASP will send an ERROR Message with Parameter Field Error. 2. Send a CLDT Message to the ASP. Check B: Unitdata Indication will be given to the SU at ASP and State of ASP is not disturbed. Anjali Gurmukhani, HSS [Page 107] Internet Draft SUA Conformance Test Plan Aug 2003 6. Test cases for testing SUA at ASP and SGP. The following section lists test cases that can be executed by both ASP and SGP implementations. 6.1 Connectionless Data Transfer "Connectionless Data Transfer for Protocol Class 0" + TEST NUMBER: CL_1 + PURPOSE: To check that successful Connectionless Data transfer occurs from one PC to another. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY (AS-InActive) ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY (AS-Active) <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT Anjali Gurmukhani, HSS [Page 108] Internet Draft SUA Conformance Test Plan Aug 2003 N-UNITDATA REQ CLDT -------------> ---------> N-UNITDATA IND <--------- N-UNITDATA REQ N-UNITDATA IND <------------- CLDT TEST DESCRIPTION: 1. Send ASPUP message to the SGP in ASP-DOWN state. Check A: ASPUP-Ack message will come from SGP. 2. Send ASPAC message to the SGP in ASP-UP state. Check A: ASPAC-Ack message will come from SGP. Check B: NTFY message will come from SGP. 3. Send N-UNITDATA Primitive from the NIF at SGP to send to ASP. Check A: CLDT message should be received at the ASP containing data passed by the SCCP. Check B: Check the protocol class field in the message received. It should be class 0. 4. Send CLDT message from ASP containing Protocol Data and Protocol Class 0. Check C: N-UNITDATA Ind. Primitive is received at the NIF with Protocol Data and protocol class as 0. Check D: Check the protocol class field in message received. It should be class 0. Send different CLDT messages from both the directions several times. The Above Test case should be carried out for Protocol Class "0" and "1". Anjali Gurmukhani, HSS [Page 109] Internet Draft SUA Conformance Test Plan Aug 2003 "CL Data response message generation " + TEST NUMBER: CL_2 + PURPOSE: To check that in case a CLDT Message is sent and at the peer the SSN is not present for which Unitdata is meant, CLDR is returned if the return on error option is set. + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. Also arrange the data at SGP such that Unitdata primitive is sent to SUA with return option set as "1"(Bit 8 in the protocol class parameter should be set to 1)to be sent to DPC X. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <------------- CLDT (DPC=X, SSN=Y) (No user with SSN=Y) CLDR -------------> ---------> N-NOTICE IND TEST DESCRIPTION: 1. Send Unitdata primitive from SGP with Address parameters with Point code X and SSN as Y. 2. SSN Y is not registered as user at ASP. Check A: Check that a CLDR Message is sent in response to this CLDT Message with Reason for return as "Unequipped User". Check B: This CLDR is indicated at ASP as Notice Indication. Anjali Gurmukhani, HSS [Page 110] Internet Draft SUA Conformance Test Plan Aug 2003 "Connectionless Data response message not generated if return option is not set " + TEST NUMBER: CL_3 + PURPOSE: To check that in case CLDT Message is sent and at the peer the SSN is not present for which Unitdata is meant, CLDR is NOT returned if return on error option is not set. + TEST CONFIGURATION: G + PRE-TEST CONDITIONSSCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. Also arrange the data at SGP such that Unitdata primitive is sent to SUA with return option set as "0"(Bit 8 in the protocol class parameter should be set to 0)to be sent to DPC X EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <------------- CLDT (DPC=X,SSN=Y) (No user with SSN=Y) (Discard message) <------ Error TEST DESCRIPTION: 1 Send Unitdata primitive from SGP with Address parameters with Point code X and SSN as Y. SSN Y is not registered as user at ASP. Check A: No CLDR Message is generated. Check B: Error may be generated locally. Anjali Gurmukhani, HSS [Page 111] Internet Draft SUA Conformance Test Plan Aug 2003 "Ordered Delivery for CLDT for Protocol Class 1" + TEST NUMBER: CL_4 + PURPOSE: To check that CLDT Messages with Protocol class 1 are delivered in order. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with more than two streams). ASP1 is active. Also arrange the data in SGP such that NIF sends Unitdata primitive to SUA containing protocol class "1" and sequence control parameter set to "1", to be sent to DPC X. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active N-UNITDATA IND <------------- CLDT Data=abc (Seq. Control 1)(data=abc) N-UNITDATA IND <------------- CLDT Data=xyz (Seq. Control 1)(data=xyz) N-UNITDATA IND <------------- CLDT Data=mno (Seq. Control 1)(data=mno) TEST DESCRIPTION: 1. Send 3 CLDT (with Seq. Control 1) to the ASP. Check A: CLDT messages should be received at the ASP1 in the same order as was sent by the originating side. Check B: Check the stream identifier in each of above cases. It should be same. Anjali Gurmukhani, HSS [Page 112] Internet Draft SUA Conformance Test Plan Aug 2003 "Loadsharing of CL messagesö + TEST NUMBER: CL_5 + PURPOSE: To check that Loadsharing of CLDT Messages . + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 and ASP2 both are active. Also arrange the data such that Unitdata primitive is sent to SUA containing protocol class "0" and with different sequence control values. EXPECTED MESSAGE SEQUENCE: ASP1 ASP2 SGP NIF ASPs are active <------- Unitdata(Seq. ctrl=X) N-Unitdata-Ind <------ .------- Unitdata (Seq_ctrl = Y) N-Unitdata-Ind <------ TEST DESCRIPTION: 1.Send CLDT from SGP varying the sequence control 0. Check A: CLDT message should be received at ASP1. 2.Send CLDT from SGP with sequence control as 1. Check B: CLDT message should be sent to ASP2. Repeat the above with different values of sequence control. The data should be Loadshared . 3. Now send ASP-inactive from ASP1. 4. Send CLDT from SGP with different seq. ctrl. All messages should go to ASP2. Repeat the Above Test case for Protocol Class "1" with different values for the message length field. Anjali Gurmukhani, HSS [Page 113] Internet Draft SUA Conformance Test Plan Aug 2003 "CLDT received with Optional parameters before Mandatory parameters" + TEST NUMBER: CL_6 + PURPOSE: To check that CLDT Message received with optional parameters before Mandatory parameters is not rejected at IUT. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. Also arrange the data such that Unitdata primitive is sent to SUA containing protocol class "0" to be sent to DPC X. EXPECTED MESSAGE SEQUENCE: SGP ASP ASP is active CLDT ------------> ------------>N-unitdata Ind TEST DESCRIPTION: 1. Send CLDT to the SGP with Hop counter before any of the mandatory parameters. Check A: CLDT message received at SGP is not rejected Check B: Data is Indicated to the user at the ASP. Repeat the Above Test case for different combinations and reordering of Mandatory and optional parameters. Anjali Gurmukhani, HSS [Page 114] Internet Draft SUA Conformance Test Plan Aug 2003 "CL Data Transfer (Different Seq. Control values)" + TEST NUMBER: CL_7 + PURPOSE: To check that CLDT Messages with different value of sequence control parameter are sent on different SCTP streams. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with more than two streams). ASP1 is active. Also arrange the data such that Unitdata primitives are sent to SUA containing protocol class "0" to be sent to DPC X. EXPECTED MESSAGE SEQUENCE: SGP ASP ASP is active CLDT ------------> Seq ctrl X ------------>N-unitdata Ind CLDT -------------> Seq ctrl Y ------------>N-unitdata Ind CLDT -------------> Seq ctrl Z ------------>N-unitdata Ind TEST DESCRIPTION: 1. Send CLDT to the SGP with different values of Sequence control parameter. Check A: CLDT message is sent on different SCTP non-zero streams. Check B: CLDT Data is received and indicated to user at SGP. Anjali Gurmukhani, HSS [Page 115] Internet Draft SUA Conformance Test Plan Aug 2003 6.2 Routing Procedures "CL Data Transfer, Route on GT" + TEST NUMBER: RP_1 + PURPOSE: To check that successful GT Translation takes place and Connectionless Data transfer occurs from one PC to another. + TEST CONFIGURATION: A. + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. Also arrange the data In SGP such that NIF sends UNITDATA primitive to SUA containing protocol class "0" to be sent to GT "X". Configure the SCCP Routing control route GT "X" to DPC of ASP and SSN available at ASP. Set the Routing Indicator in called address as Route on GT. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-UNITDATA REQ (Route on GT) <------------- CLDT (Route on GT) <------------ N-UNITDATA IND (GT Translated to local PC and SSN) TEST DESCRIPTION: 1. Send N-UNITDATA Primitive from the NIF at SGP to send to GT "X". Check A: GT translation at SGP gives point code X being served by ASP1.Proper Routing and address indicators are filled in CLDT message. Check B: CLDT message should be received at the ASP1 containing data passed by the SCCP. Check C: At ASP1 GT translation occurs and gives SSN available on ASP and hence Unitdata Indication is given. Anjali Gurmukhani, HSS [Page 116] Internet Draft SUA Conformance Test Plan Aug 2003 "CL Data Transfer for Protocol Class 0, Route on GT Failure, with return Option set" + TEST NUMBER: RP_2 + PURPOSE: To check that if GT Translation fails and return option is set Connectionless Data response is sent back. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP . ASP1 is active. Also arrange the data in SGP such that NIF sends UNITDATA primitive to SUA containing protocol class "0" to be sent to GT "X". Configure the SCCP Routing control route GT "X" to DPC of ASP and SSN that is NOT AVAILABLE at ASP. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <------------- CLDT (Route on GT) (return option set) <------------ ERROR CLDR -------------> (Route on GT FAILURE) ---------> N-NOTICE IND TEST DESCRIPTION: 1. Send N-UNITDATA Primitive from the NIF at SGP to send to GT "X". Check A: GT translation at SGP gives point code X being served by ASP1.Proper Routing and address indicators are filled in CLDT message. Check B: CLDT message should be received at the ASP1 containing data passed by the SCCP. Check C: At ASP1 GT translation occurs and gives SSN unavailable on ASP and hence CLDR is sent back to SGP. Anjali Gurmukhani, HSS [Page 117] Internet Draft SUA Conformance Test Plan Aug 2003 "CL Data Transfer for Protocol Class 0, Route on DPC+SSN " + TEST NUMBER: RP_3 + PURPOSE: To check that Connectionless Data transfer occurs from one PC to another, when routing is DPC+SSN based. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP1 is active. Also arrange the data in SGP such that NIF sends UNITDATA primitive to SUA with protocol class "0" to be sent to DPC "X" and SSN "Y". EXPECTED MESSAGE SEQUENCE: ASP SGP NIF (DPC = X) ASP is active <--------- N-UNITDATA REQ (Route on DPC+SSN) <------------- CLDT (Route on DPC+SSN) <------------ N-UNITDATA IND (IND is given to user with SSN "Y") TEST DESCRIPTION: 1. Send N-UNITDATA Primitive from the NIF at SGP to send to DPC "X" and SSN "Y". Check A: CLDT message should be received at the ASP1 containing the data passed by the SCCP. The Above Test case should be carried out for Protocol Class "0" and "1". Anjali Gurmukhani, HSS [Page 118] Internet Draft SUA Conformance Test Plan Aug 2003 "CL Data Transfer for Protocol Class 0, Route on DPC+SSN FAILURE with return option set" + TEST NUMBER: RP_4 + PURPOSE: To check that when routing is DPC+SSN based, and the peer fails to locate a user, a CLDR message is sent back if return option is set. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. Also arrange the data in SGP such that NIF sends UNITDATA primitive to SUA containing protocol class "0" to be sent to DPC "X" and SSN "Y". No user should be registered with the SSN "Y" on the ASP side. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF (DPC = X) ASP is active <--------- N-UNITDATA REQ (Route on DPC+SSN) (Return option set) <------------- CLDT (Route on DPC+SSN) <------------ ERROR(no SSN found) CLDR -------------> (Route on DPC+SSN FAILURE)---------> N-NOTICE IND TEST DESCRIPTION: 1. Send N-UNITDATA Primitive from the NIF at SGP to send to DPC "X" and SSN "Y". Check A: CLDT message should be received at the ASP1 containing the data passed by the SCCP. Check B: A CLDR Message should be sent back with appropriate error code, indicating no user with the desired SSN exists. Anjali Gurmukhani, HSS [Page 119] Internet Draft SUA Conformance Test Plan Aug 2003 Note: Check the behavior when return option is not set. No CLDR is sent in that case. Anjali Gurmukhani, HSS [Page 120] Internet Draft SUA Conformance Test Plan Aug 2003 "CL Data Transfer, Route on IP " + TEST NUMBER: RP_5 + PURPOSE: To check that successful Connectionless Data transfer occurs from one PC to another, when routing is based on IP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. Also arrange the data in SGP such that NIF sends UNITDATA primitive to SUA containing protocol Class "0ö, to be sent to the ASP serving the AS with Routing Key as A.B.C.D EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-UNITDATA REQ (To be sent to ASP handling traffic AS with routing key as IP=A.B.C.D, RC A) <------------- CLDT (containing RC A) <------------ N-UNITDATA IND TEST DESCRIPTION: 1. Send N-UNITDATA Primitive from the NIF at SGP to be sent to the ASP serving the AS with Routing Key as IP/IP+SSN. Check A: CLDT message should be received at the ASP1 Note: The above test case should be repeated for Routing key IP(v6) based. Anjali Gurmukhani, HSS [Page 121] Internet Draft SUA Conformance Test Plan Aug 2003 "Successful connection establishment and termination Route on GT" + TEST NUMBER: RP_6 + PURPOSE: To check connection establishment and termination Route on GT . + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ (Route on GT) N-CONNECT IND <------------- CORE (Source ref. number "A") N-CONNECT RESPONSE --------> COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND N-DATA REQ --------> CODT ------------> ---------> N-DATA IND (ref. number "A") <--------- N-DATA REQ N-DATA IND<------------- CODT <--------- N-DISCONNECT REQ N-DISCONNECT IND<------------- RELRE (Source ref. number "A") RELCO------------> (Dest ref. number "A") ---------> N-DISCONNECT IND N-DATA REQ --------> Anjali Gurmukhani, HSS [Page 122] Internet Draft SUA Conformance Test Plan Aug 2003 <--------- ERROR (Connection Does not exist) TEST DESCRIPTION: 1. Send N-CONNECT REQ(Dest Address should be in GT form ) Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send N-DATA REQ Primitive from the ASP to send to SGP. Check A: CODT message should be received at the SGP. Check B: CODT message should be received for Dest Ref. number "A". 4. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: RELRE message should be received at the ASP. Check B: RELCO message should be received at the SGP. 5. Send N-DATA REQ Primitive from the ASP to send to SGP. Check A: Should result in error. Anjali Gurmukhani, HSS [Page 123] Internet Draft SUA Conformance Test Plan Aug 2003 6.3 Reassembly Procedures "Successful Reassembly of segmented messages" + TEST NUMBER: SR_1 + PURPOSE: To check that if segmented messages (CLDT) are received , Reassembly is done and reassembled data indicated to user. + TEST CONFIGURATION: A/G + PRE-TEST CONDITIONS: SCTP association is established between ASP and SGP. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-UNITDATA REQ <------------- CLDT (Segmentation param ,bit 8 =1,remain=1) CLDT <---------- T(reass) start <------------- CLDT (Segmented Data, Bit 8 =0,remain=0) CLDT <---------- N-Unitdata-Ind <---- TEST DESCRIPTION: 1.Send segmented CLDT messages from SGP such that the message has Segmentation parameter with bit 8 of ôfirstö field set. Also the number of remaining segments as 1. Check A: CLDT is received at ASP. Check B: ASP starts Reassembly timer. Anjali Gurmukhani, HSS [Page 124] Internet Draft SUA Conformance Test Plan Aug 2003 3. Send another segmented CLDT from SGP such that Bit 8 of the ôfirst/remainö field is not set but the remaining segments is 0. Check A: CLDT is received at ASP. Check B: Reassembly timer is stopped Check C: The two segmented messages are reassembled and indicated to SU. Anjali Gurmukhani, HSS [Page 125] Internet Draft SUA Conformance Test Plan Aug 2003 "Reassembly Timer Expiry" + TEST NUMBER: SR_2 + PURPOSE: To check that if segmented messages (CLDT) are received , but if remaining segments are not received during reassembly timer.Reassembly procedure is stopped and messages discarded. + TEST CONFIGURATION: A/G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP1 is active. Also arrange the data in SGP such segmented messages are sent to ASP. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF <------------- CLDT (Segmentation param ,bit 8 =1,remain=1) CLDT <---------- T (reass) start - - - \/Timer expires Message Discarded TEST DESCRIPTION: 1.Send segmented CLDT messages from SGP such that the message has Segmentation parameter with bit 8 of ôfirstö field set. Also the number of remaining segments as 1. Check A: CLDT is received at ASP. Check B: ASP starts Reassembly timer. 2. Do not send any other segment. Let the Reassembly timer expire at ASP. Check A: Segmented message sent earlier is discarded Check B: Any other message sent from peer for the earlier segmented reference is discarded. Anjali Gurmukhani, HSS [Page 126] Internet Draft SUA Conformance Test Plan Aug 2003 "CLDR message sent back if Reassembly of segmented message cannot be done" + TEST NUMBER: SR_3 + PURPOSE: To check that if segmented message (CLDT) is received and Reassembly cannot be done, CLDR is sent back with appropriate SCCP cause. + TEST CONFIGURATION: A/G + PRE-TEST CONDITIONS: SCTP association is established between ASP and SGP. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-UNITDATA REQ <------------- CLDT (Segmentation param ,bit 8 =1,remain=4) CLDT <---------- T(reass) start <------------- CLDT (Segmented Data, Bit 8 =0,remain=0) CLDT <---------- CLDR-------------> SCCP cause "cannot perform Reassembly" TEST DESCRIPTION: 1.Send segmented CLDT messages from SGP such that the message has Segmentation parameter with bit 8 of ôfirstö field set. Also the number of remaining segments as 4.This CLDT has return on error set. Anjali Gurmukhani, HSS [Page 127] Internet Draft SUA Conformance Test Plan Aug 2003 Check A: CLDT is received at ASP. Check B: ASP starts Reassembly timer. 2. Send another segmented CLDT from SGP such that Bit 8 of the ôfirst/remainö field is not set but the remaining segments is 0.The return on error is set in Protocol class. Check A: CLDT is received at ASP. Check B: Reassembly timer is stopped Check C: CLDR is received and indicated to user as N-Notice indication. Anjali Gurmukhani, HSS [Page 128] Internet Draft SUA Conformance Test Plan Aug 2003 6.4 Relay Functionality "Relay mode operation (Connectionless)" + TEST NUMBER: RE_1 + PURPOSE: To check the Relay node functionality. + TEST CONFIGURATION: RELAY + PRE-TEST CONDITIONS: SCTP association is established between ASP1 and ASP2 AND ASP2 and ASP3. Also both the associations (ASP1-ASP2) (ASP2-ASP3) are Active. EXPECTED MESSAGE SEQUENCE: IPSP1 IPSP2 IPSP3 ----. CLDT (Called_addr=Y) ----. ------.N-UnitdataInd <--------- CLDT(Called_addr=X) <------- N-UnitdataInd <---------- TEST DESCRIPTION: 1. Send CLDT from IPSP1 to IPSP2 with called address as Y. Check A: CLDT message should be received at the IPSP2. Check B: CLDT is received at IPSP3 and indicated to user. 2. Send CLDT from IPSP3 with called address with point code = X. Check A: CLDT message should be received at IPSP2. Check B: CLDT message is sent from IPSP2 to IPSP1 and indicated to SU. Anjali Gurmukhani, HSS [Page 129] Internet Draft SUA Conformance Test Plan Aug 2003 "Relay mode operation (Connection-oriented)" + TEST NUMBER: RE_2 + PURPOSE: To check the Relay node functionality. + TEST CONFIGURATION: RELAY + PRE-TEST CONDITIONS: SCTP association is established between ASP1 and ASP2 AND ASP2 and ASP3. Also both the associations (ASP1-ASP2) (ASP2-ASP3) are Active. EXPECTED MESSAGE SEQUENCE: IPSP1 IPSP2 IPSP3 ----. CORE (Called_addr=Y) ----. ------.N-connectInd <--------- COAK <------- N-Connect ConfirmInd <---------- --------. CODT(Y) ----. -----.n-DATA iND TEST DESCRIPTION: 1. Send CORE from IPSP1 to IPSP2 with called address as Y. Check A: CORE message should be received at the IPSP2. Check B: CORE is received at IPSP3 and indicated to user. Check C: IPSP3 sends back COAK and two connection sections are established. Anjali Gurmukhani, HSS [Page 130] Internet Draft SUA Conformance Test Plan Aug 2003 2.Send CODT from IPSP1 with called address with point code = y. Check A: CODT message should be received at IPSP2. Check B: CODT message is sent from IPSP2 to IPSP3 and indicated to as Data-Ind. Anjali Gurmukhani, HSS [Page 131] Internet Draft SUA Conformance Test Plan Aug 2003 6.5 Connection Oriented Procedures "Successful connection establishment and termination" + TEST NUMBER: CO_1 + PURPOSE: To check connection establishment and termination. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") N-CONNECT RESPONSE --------> COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND N-DATA REQ --------> CODT ------------> ---------> N-DATA IND (Ref. number "A") <--------- N-DATA REQ N-DATA IND<------------- CODT <--------- N-DISCONNECT REQ N-DISCONNECT IND<------------- RELRE (Source ref. number "A") Anjali Gurmukhani, HSS [Page 132] Internet Draft SUA Conformance Test Plan Aug 2003 RELCO------------> (Dest ref. number "A") ---------> N-DISCONNECT IND N-DATA REQ --------> <--------- ERROR (Connection Does not exist) TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send N-DATA REQ Primitive from the ASP to send to SGP. Check A: CODT message should be received at the SGP. Check B: CODT message should be received for Dest Ref. number "A". 4. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: RELRE message should be received at the ASP. Check B: RELCO message should be received at the SGP. 5. Send N-DATA REQ Primitive from the ASP to send to SGP. Check A: Should result in error. Anjali Gurmukhani, HSS [Page 133] Internet Draft SUA Conformance Test Plan Aug 2003 "Connection release during Connection Establishment" + TEST NUMBER: CO_2 + PURPOSE: To check if the CORE message is responded with a COREF Message the connection is not established. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") N-DISCONNECT REQ --------> COREF------------> (Dest ref. number "A") ---------> N-DISCONNECT IND <--------- N-DATA REQ ------------> ERROR TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send N-DISCONNECT REQ Primitive from the SU to SGP. Check A: COREF message should be received at the ASP, with refusal cause value. The Above Test case should be carried out for Protocol Class "2" and "3". Anjali Gurmukhani, HSS [Page 134] Internet Draft SUA Conformance Test Plan Aug 2003 "Connection oriented Data with mandatory parameter missing" + TEST NUMBER: CO_3 + PURPOSE: To check if the CODT message is received with a mandatory parameter missing it is responded with an COERR Message. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. SCCP connection exists between ASP and SGP. Arrange the CODT message so that it does not contain the mandatory parameter Routing Context. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-DATA REQ <------------- CODT (Routing Context missing) COERR------------> (Error cause) ------------> ERROR TEST DESCRIPTION: 1. Send N-DATA REQ (without protocol class parameter )Primitive from the NIF at SGP to send to ASP. Check A: CODT message should be received at the ASP. Check B: COERR message should be received at the SGP, with error cause value. Anjali Gurmukhani, HSS [Page 135] Internet Draft SUA Conformance Test Plan Aug 2003 The Above Test case should be carried out for Protocol Class "2" and "3". The above Test case should also be carried for the messages listed below ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message parameters to be checked for ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CODT Routing Context Sequence Number(NOT in case of N-EXPED.DATA REQ) Destination Reference Number Data ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CODA Routing Context Destination Reference Number Receive Sequence number[mandatory in case of data ack] Credit ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CORE Routing Context Protocol Class Source Reference Number Destination Address Sequence Control Sequence Number[in case of class 3] Credit(in case of Protocol class 3) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ COAK Routing Context Protocol Class Destination Reference Number Source Reference Number Sequence Control Destination address [Mandatory when CORE contains src addr] Credit(in case of Protocol class 3) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ COREF Routing Context Anjali Gurmukhani, HSS [Page 136] Internet Draft SUA Conformance Test Plan Aug 2003 Destination Reference Number SCCP Cause ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RELRE Routing Context Destination Reference Number Source Reference Number SCCP Cause ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RELCO Routing Context Destination Reference Number Source Reference Number ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RESRE Routing Context Destination Reference Number Source Reference Number SCCP Cause ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RESCO Routing Context Destination Reference Number Source Reference Number ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ COERR Routing Context Destination Reference Number SCCP Cause ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ COIT Routing Context Protocol Class Source Reference Number Destination Reference number Sequence Number Credit Anjali Gurmukhani, HSS [Page 137] Internet Draft SUA Conformance Test Plan Aug 2003 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Anjali Gurmukhani, HSS [Page 138] Internet Draft SUA Conformance Test Plan Aug 2003 "Connection response message parameter validation" + TEST NUMBER: CO_4 + PURPOSE: To check that if the CORE Message carries the Source address then the COAK Message also carries the Destination address parameter. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (With Source Address parameter present) (Source ref. number "A") N-CONNECT RESPONSE --------> COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND (Contains Dest. Address parameter) TEST DESCRIPTION: 1. Send N-CONNECT REQ(with Source address parameter present) Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP. Check A: COAK message should be received at the SGP. Check A: COAK message should contain the Destination Address parameter. Anjali Gurmukhani, HSS [Page 139] Internet Draft SUA Conformance Test Plan Aug 2003 The Above Test case should be carried out for Protocol Class "2" and "3". "Connection response message parameter validation" + TEST NUMBER: CO_5 + PURPOSE: To check that if the CORE Message carries the Source address then the COREF Message also carries the Destination address parameter. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (With Source Address parameter present) (Source ref. number "A") COREF ------------> (Dest ref. number "A") ---------> oes not Contains Dest. Address parameter, Message is rejected) TEST DESCRIPTION: 1.Send N-CONNECT REQ(with Source address parameter present) Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COREF message from the ASP to SGP without source address parameter. Anjali Gurmukhani, HSS [Page 140] Internet Draft SUA Conformance Test Plan Aug 2003 Check A: COREF message should be received at the SGP. Check B: COREF message received is rejected due to absence of Destination address parameter. The Above Test case should be carried out for Protocol Class "2" and "3". Anjali Gurmukhani, HSS [Page 141] Internet Draft SUA Conformance Test Plan Aug 2003 "RELRE retransmissions" + TEST NUMBER: CO_6 + PURPOSE: To check that if RELRE message is sent and it is not responded with either RELRE/RELCO RELRE is retransmitted. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active.Also ASP and SGP have a SCCP connection between them. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-DISCONNECT REQ N-DISCONNECT IND <------------- RELRE (Source ref. number "A", Dest ref number "B" ) TEST DESCRIPTION: 1. Send N-DISCONNECT REQ primitive from the NIF at SGP to send to ASP. Check A: RELRE message should be received at the ASP. 2. Do not send any RELRE/RELCO message from ASP. Check A: SGP should keep retransmitting RELRE. Check B: Reference numbers are freed after maximum number of retransmissions. Anjali Gurmukhani, HSS [Page 142] Internet Draft SUA Conformance Test Plan Aug 2003 "Connection Oriented Data Ack. Received in response to CODT with Protocol Class 3, when the receive window becomes full" + TEST NUMBER: CO_7 + PURPOSE: To check that a CODA message is received in response to a CODT message in case of Protocol Class 3, when the receive window becomes full. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) (credit 3) N-CONNECT RESPONSE --------> COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND (credit 3) N-DATA REQ --------> CODT ------------> ---------> N-DATA IND (seq number "A") N-DATA REQ --------> CODT ------------> ---------> N-DATA IND (seq. number "A + 1") Anjali Gurmukhani, HSS [Page 143] Internet Draft SUA Conformance Test Plan Aug 2003 N-DATA REQ --------> CODT ------------> ---------> N-DATA IND (seq. number "A + 2") <------------- CODA (Recv Seq number "A + 2") TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send 3 N-DATA REQ Primitive from the ASP to send to SGP. Check A: 3 CODT messages should be received at the SGP. Check B: CODA message should be received at ASP with sequence Ref. number "A + 2". Anjali Gurmukhani, HSS [Page 144] Internet Draft SUA Conformance Test Plan Aug 2003 "Missequencing in Protocol Class 3 for send Seq. Number" + TEST NUMBER: CO_8 + PURPOSE: To check that in case of protocol class 3 if mis- sequencing Occurs, for send Seq. Number, then the connection is reset by peer. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> (Send Seq. Number 1) ---------> N-DATA IND (recv Seq. Number 0) (Ref. number "A") CODT ------------> (Send Seq. Number 2) ---------> N-DATA IND (recv Seq. Number 0) (Ref. number "A") CODT ------------> (Send Seq. Number 4) ---------> N-DATA IND (recv Seq. Number 0) (Ref. number "A") ---------> Error Anjali Gurmukhani, HSS [Page 145] Internet Draft SUA Conformance Test Plan Aug 2003 N-RESET IND <------------- RESRE TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send CODT message with Seq. number 1 to the SGP Side. 4. Send CODT message with Seq. number 2 to the SGP Side. Check A: CODT message should be received at the SGP. 5. Send CODT message with Seq. number 4 to the SGP Side. Check A: CODT message should be received at the SGP. Check B: RESRE Message should be received at the ASP side. Check C: Reset Indication is given to SU. Anjali Gurmukhani, HSS [Page 146] Internet Draft SUA Conformance Test Plan Aug 2003 "Missequencing in Protocol Class 3 for Recv Seq. Number" + TEST NUMBER: CO_9 + PURPOSE: To check that in case of protocol class 3 if mis- sequencing occurs, for receive Seq. Number, then the connection is reset by peer. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> (Send Seq. Number 0) ---------> N-DATA IND (recv Seq. Number 0) (Ref. number "A") CODT ------------> (Send Seq. Number 1) ---------> N-DATA IND (recv Seq. Number 0) (Ref. number "A") N-DATA IND<------------- CODT (Send Seq. Number 0) (recv Seq. Number 2) Anjali Gurmukhani, HSS [Page 147] Internet Draft SUA Conformance Test Plan Aug 2003 CODT ------------> (Send Seq. Number 2) ---------> N-DATA IND (recv Seq. Number 1) (Ref. number "A") CODT ------------> (Send Seq. Number 3) ---------> N-DATA IND (recv Seq. Number 1) (Ref. number "A") N-DATA IND<------------- CODT (Send Seq. Number 1) (recv Seq. Number 1) ERROR<----- RESRE------------> ---------> N-RESET IND N-RESET CONFIRM<------------- RESCO TEST DESCRIPTION: 1. Send CORE message from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send CODT message with Seq. number 0 to the SGP Side. 4. Send CODT message with Seq. number 1 to the SGP Side. 5. Send CODT message to the ASP Side. Check A: CODT message should be received at the SGP. Check B: Send Seq Number should be 0 and Recv. Seq. Number should be 2. 6. Send CODT message with Seq. number 2 to the SGP Side. 7. Send CODT message with Seq. number 3 to the SGP Side. 8. Send CODT message to the ASP Side, with RECV SEQ NUMBER AS 1. Check A: peer should reset Connection. Anjali Gurmukhani, HSS [Page 148] Internet Draft SUA Conformance Test Plan Aug 2003 "Credit parameter negotiation in Protocol Class 3" + TEST NUMBER: CO_10 + PURPOSE: To check the credit parameter negotiation in case of protocol class 3. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) (credit size 110) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND (credit size 100) (credit size 100) CODT ------------> (Seq. Number 1) ---------> N-DATA IND (ref. number "A") TEST DESCRIPTION: 1. Send N-CONNECT REQ(with credit size as 110) Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK(with a different credit value than what is received, credit = 100) message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. Anjali Gurmukhani, HSS [Page 149] Internet Draft SUA Conformance Test Plan Aug 2003 2. Send CODT(with Sequence number 1) message from the ASP to send to SGP. Check A: CODT message should be received at the SGP. Note: Repeat the above test case when the size of credit as sent by the SGP is less and as returned by the peer is more. Anjali Gurmukhani, HSS [Page 150] Internet Draft SUA Conformance Test Plan Aug 2003 "Connection Oriented Inactivity test in Protocol Class 3" + TEST NUMBER: CO_11 + PURPOSE: To check the Connection Oriented Inactivity test procedures in Protocol Class 3. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> (Seq. Number 1) ---------> N-DATA IND (ref. number "A") <<<< No Data transfer for "T(ias),Inactivity Send timer= 7 minutes" >>>>> <------------- COIT TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message to the SGP. Check A: COAK message should be received at the SGP. Anjali Gurmukhani, HSS [Page 151] Internet Draft SUA Conformance Test Plan Aug 2003 3. Send CODT message to the SGP. Check A: CODT message should be received at the SGP. 4. Send No Data for the inactivity Send Timer interval = 7 Minutes. Check A: COIT message should flow from the SGP to the ASP. Anjali Gurmukhani, HSS [Page 152] Internet Draft SUA Conformance Test Plan Aug 2003 "Connection Oriented Inactivity test invalid parameters in Protocol Class 3" + TEST NUMBER: CO_12 + PURPOSE: To check the Invalid Connection Oriented Inactivity test procedures in Protocol Class 3. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> (Seq. Number 1) ---------> N-DATA IND (ref. number "A") COIT ------------> (Source ref. number "B") ---------> Error N-RELEASE IND<------------- RELRE TEST DESCRIPTION: Anjali Gurmukhani, HSS [Page 153] Internet Draft SUA Conformance Test Plan Aug 2003 1. Send N-CONNECT REQ(with credit size as 100) Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send CODT message from the ASP to send to SGP. Check A: CODT message should be received at the SGP. 4. Send a COIT message with an invalid value of Dest. ref. number (ref. number B). Check A: peer should Release Connection. A RELCO Message should be received. The above Test case should be carried for Protocol class "2" and "3" for the following parameters ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ parameter Behavior to be observed ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Source Reference Number Connection Released by Peer. Protocol Class Connection Released by Peer. Sequence Number(only in protocol class 3)Connection Reset by Peer. Credit(only in protocol class 3) Connection Reset by Peer. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Anjali Gurmukhani, HSS [Page 154] Internet Draft SUA Conformance Test Plan Aug 2003 "No Response to RELRE Message" + TEST NUMBER: CO_13 + PURPOSE: To check that if a RELRE message is sent and is not responded with, it will retry a number of times and then release the connection. + TEST CONFIGURATION: A. + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> ---------> N-DATA IND (ref. number "A") <--------- N-DATA REQ N-DATA IND<------------- CODT <--------- N-DISCONNECT REQ N-DISCONNECT IND<------------- RELRE (Source ref. number "A") Anjali Gurmukhani, HSS [Page 155] Internet Draft SUA Conformance Test Plan Aug 2003 N-DISCONNECT IND<------------- RELRE (Source ref. number "A") N-DISCONNECT IND<------------- RELRE (Source ref. number "A") N-DISCONNECT IND<------------- RELCO (Source ref. number "A") TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send CODT message from the ASP to send to SGP. Check A: CODT message should be received at the SGP for Source Ref. number "A". 3. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: RELRE message should be received at the ASP. Check B: No RELCO message MUST be sent to the SGP. Check C: The RELRE message is retransmitted a number of times, till the inactivity timer expires and a RELCO message is sent. Anjali Gurmukhani, HSS [Page 156] Internet Draft SUA Conformance Test Plan Aug 2003 "Protocol Class negotiation" + TEST NUMBER: CO_14 + PURPOSE: To check the protocol Class negotiation procedures in SUA. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND (Protocol Class 2) (Protocol Class 2) CODT ------------> (Seq. Number 1) ---------> N-DATA IND (ref. number "A") <------------- CODA TEST DESCRIPTION: 1. Send N-CONNECT REQ(with protocol class 3) Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message(with protocol class 2) from the ASP to send to SGP. Anjali Gurmukhani, HSS [Page 157] Internet Draft SUA Conformance Test Plan Aug 2003 Check A: COAK message with protocol class 2, should be received at the SGP. 3. Send CODT message from the ASP to send to SGP. Check A: CODT message should be received at the SGP. Check B: CODA message should be received at ASP. Anjali Gurmukhani, HSS [Page 158] Internet Draft SUA Conformance Test Plan Aug 2003 "Connection refusal due to Route on DPC+SSN FAILURE, no SSN available" + TEST NUMBER: CO_15 + PURPOSE: To check that when routing is DPC+SSN based, and the peer fails to locate a user, a COREF message is sent back. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active.Also arrange the data in SGP such that NIF sends Connect- Req primitive to SUA with Routing Context A, containing protocol class "2/3" to be sent to DPC "X" and SSN "Y". No user should be registered with the SSN "Y" on the ASP side. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF (DPC = X) ASP is active <--------- N-CONNECT REQ (Route on DPC+SSN) <------------- CORE (Route on DPC+SSN) <------------ ERROR(no SSN found) COREF -------------> (Route on DPC+SSN FAILURE)---------> N-DISCONNECT IND TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to DPC "X" and SSN "Y". Check A: CORE message should be received at the ASP1 containing the data passed by the SCCP. Check B: A COREF Message should be sent back with appropriate error code, indicating no user with the desired SSN exists. Anjali Gurmukhani, HSS [Page 159] Internet Draft SUA Conformance Test Plan Aug 2003 "Reset Connection procedures in Protocol Class 3" + TEST NUMBER: CO_16 + PURPOSE: To check that in case of protocol class 3, Connection can be reset by the user. + TEST CONFIGURATION: A. + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams). ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> (Seq. Number 1) ---------> N-DATA IND (ref. number "A") <------------- CODA <--------- N-RESET REQ N-RESET IND <------------- RESRE (Source ref. number "A") (Protocol Class 3) RESCO------------> (Dest ref. number "A") ---------> N-RESET CONFIRM IND TEST DESCRIPTION: Anjali Gurmukhani, HSS [Page 160] Internet Draft SUA Conformance Test Plan Aug 2003 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send N-DATA REQ(with Sequence number 1) Primitive from the ASP to send to SGP. Check A: CODT message should be received at the SGP. Check B: CODA message should be received at ASP with Source Ref. number "A". 4. Send N-RESET REQ Primitive from the SGP to send to ASP. Check A: RESRE message should be received at the ASP. 5. Send RESCO message from the ASP to send to SGP. Check B: RESCO Message should be received at the SGP side. Anjali Gurmukhani, HSS [Page 161] Internet Draft SUA Conformance Test Plan Aug 2003 "Missequencing in Protocol Class 3 for Recv Seq. Number" + TEST NUMBER: CO_17 + PURPOSE: To check that in case of protocol class 3 if mis- sequencing occurs, for recv Seq. Number, then the connection is reset by peer. + TEST CONFIGURATION: The Following test cases MUST be executed at SGP, ASP and IPSP. The example listed below covers the test case at the ASP. The IUT is running at the ASP. However the same MUST be executed at IPSP and SGP also. + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND CODT ------------> (Send Seq. Number 0) ---------> N-DATA IND (recv Seq. Number 0) (Ref. number "A") CODT ------------> (Send Seq. Number 1) ---------> N-DATA IND (recv Seq. Number 0) (Ref. number "A") N-DATA IND<------------- CODT (Send Seq. Number 0) (recv Seq. Number 2) Anjali Gurmukhani, HSS [Page 162] Internet Draft SUA Conformance Test Plan Aug 2003 CODT ------------> (Send Seq. Number 2) ---------> N-DATA IND (recv Seq. Number 1) (Ref. number "A") CODT ------------> (Send Seq. Number 3) ---------> N-DATA IND (recv Seq. Number 1) (Ref. number "A") N-DATA IND<------------- CODT (Send Seq. Number 1) (recv Seq. Number 1) ERROR<----- RESRE------------> ---------> N-RESET IND N-RESET Ind<------------- RESRE RESCO ------------------> Reset Confirm Indication TEST DESCRIPTION: 1. Send CORE message from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send CODT message with Seq. number 0 to the SGP Side. 4. Send CODT message with Seq. number 1 to the SGP Side. 5. Send CODT message to the ASP Side. Check A: CODT message should be received at the SGP. Check B: Send Seq Number should be 0 and Recv. Seq. Number should be 2. 6. Send CODT message with Seq. number 0 to the SGP Side. 7. Send CODT message with Seq. number 1 to the SGP Side. 8. Send CODT message to the ASP Side, with RECV SEQ NUMBER AS 1. Check A: peer should reset Connection. Anjali Gurmukhani, HSS [Page 163] Internet Draft SUA Conformance Test Plan Aug 2003 "Missequencing in Protocol Class 3 for Recv Seq. Number, in CODA message" + TEST NUMBER: CO_18 + PURPOSE: To check that in case of protocol class 3 if mis- sequencing occurs, for recv Seq. Number, then the connection is reset by peer. + TEST CONFIGURATION: The Following test cases MUST be executed at SGP, ASP and IPSP. The example listed below covers the test case at the ASP. The IUT is running at the ASP. However the same MUST be executed at IPSP and SGP also. + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) (Credit 2) N-CONNECT RESPONSE --------> COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND (Credit 2) N-DATA REQ --------> CODT ------------> (Send Seq. Number 0) ---------> N-DATA IND (recv Seq. Number 0) (ref. number "A") N-DATA REQ --------> CODT ------------> (Send Seq. Number 1) ---------> N-DATA IND (recv Seq. Number 0) (ref. number "A") Anjali Gurmukhani, HSS [Page 164] Internet Draft SUA Conformance Test Plan Aug 2003 <------------- CODA (Send Seq. Number 0) (recv Seq. Number 1) <------------- CODA (Send Seq. Number 1) (recv Seq. Number 1) ERROR<----- RESRE------------> ---------> N-RESET IND N-RESET CONFIRM<------------- RESCO TEST DESCRIPTION: 1. Send CORE message from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send CODT message with Seq. number 0 to the SGP Side. 4. Send CODT message with Seq. number 1 to the SGP Side. Check A: CODA Message with Send Seq. Number 0 and recv Seq number 1 should be received. 5. Send CODA message to the ASP Side, with Send Seq. Number as 1 and recv Seq. number as 1. Check A: Connection should be reset by peer. Anjali Gurmukhani, HSS [Page 165] Internet Draft SUA Conformance Test Plan Aug 2003 "Missequencing in Protocol Class 3 for Send Seq. Number, Outside Rx Window" + TEST NUMBER: CO_19 + PURPOSE: To check that in case of protocol class 3 if mis- sequencing occurs, for send Seq. Number, then the connection is reset by peer. + TEST CONFIGURATION: A. + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP (with two or more streams. ASP1 is active. EXPECTED MESSAGE SEQUENCE: ASP SGP NIF ASP is active <--------- N-CONNECT REQ N-CONNECT IND <------------- CORE (Source ref. number "A") (Protocol Class 3) (Credit 3) COAK ------------> (Dest ref. number "A") ---------> N-CONNECT CONFIRM IND (Credit 3) CODT ------------> (Send Seq. Number 0) ---------> N-DATA IND (recv Seq. Number 0) (ref. number "A") CODT ------------> (Send Seq. Number 1) ---------> N-DATA IND (recv Seq. Number 0) (ref. number "A") CODT ------------> (Send Seq. Number 10) ---------> Error (recv Seq. Number 0) N-RESET IND<------------- RESRE (Source ref. number "A") Anjali Gurmukhani, HSS [Page 166] Internet Draft SUA Conformance Test Plan Aug 2003 RESCO------------> ---------> N-RESET CONFIRM IND TEST DESCRIPTION: 1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP. Check A: CORE message should be received at the ASP. 2. Send COAK message from the ASP to send to SGP. Check A: COAK message should be received at the SGP. 3. Send CODT message with Seq. number 0 to the SGP Side. 4. Send CODT message with Seq. number 1 to the SGP Side. 5. Send CODT message with Seq. number 10 to the SGP Side. Check A: The Connection is reset by peer. Anjali Gurmukhani, HSS [Page 167] Internet Draft SUA Conformance Test Plan Aug 2003 6.6 SCTP Connection Management "SCTP Connection Establishment" + TEST NUMBER : SCM_1 + PURPOSE: To check that on receiving M-SCTP-Establish primitive from SM, ASP initiates and establishes an SCTP association with the SGP. + TEST CONFIGURATION: A/G + PRE-TEST CONDITIONS: SCTP association is not established between SGP and ASP. Also arrange the data in ASP such that SM sends M-SCTP-Establish primitive to SUA with the SGP id to which the connection is to be established. EXPECTED MESSAGE SEQUENCE: SGP ASP SU + SM <--------- M-SCTP-Establish Request <-------------------> SCTP association will be established by SCTP ASP will receive Communication-Up primitive from SCTP M-SCTP-Establish Ind-------> TEST DESCRIPTION: 1. Send M-SCTP-Establish Request Primitive from the SM at ASP side to establish an SCTP association with the SGP. 2. Check A: SCTP association will be established and M-SCTP-Establish indication will be received at the SM. Anjali Gurmukhani, HSS [Page 168] Internet Draft SUA Conformance Test Plan Aug 2003 "SCTP Connection Termination" + TEST NUMBER: SCM_2 + PURPOSE: To check that on receiving SCTP-Communication Down indication primitive from SCTP, ASP will send the M-SCTP Status primitive to the upper layer. + TEST CONFIGURATION: A/G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is in Inactive state. Also arrange the data in SGP such that SCTP association is terminated between SGP and ASP. EXPECTED MESSAGE SEQUENCE : SGP ASP SM + SU ASP is Inactive <-------------- ASPDN ASP-Down-Ack --------------> SCTP association is terminated ASP will receive Communication-Down primitive from SCTP M-SCTP Status --------> <-------- Unitdata Send Failure ---------> TEST DESCRIPTION: 1. Terminate the association between SGP and ASP. Check A: SCTP association will be down and on receiving Communication Down primitive from SCTP, M-SCTP Status indication will be received at the SM. Check B: State of ASP will be down. Send Unitdata primitive from the SU to send some Protocol DATA. ASP will report send failure. Anjali Gurmukhani, HSS [Page 169] Internet Draft SUA Conformance Test Plan Aug 2003 Note: It may be possible that SCTP connection is terminated without exchanging the ASPDN message. Anjali Gurmukhani, HSS [Page 170] Internet Draft SUA Conformance Test Plan Aug 2003 "SCTP Connection Restart" + TEST NUMBER : SCM_3 + PURPOSE: To check that on receiving SCTP-Communication Restart Indication primitive from SCTP, ASP will send the M-SCTP Status primitive to the upper layer. + TEST CONFIGURATION: A/G + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is in active state. Also arrange in SGP such that SCTP association is restarted between SGP and ASP. EXPECTED MESSAGE SEQUENCE : SGP ASP SM + SU ASP is active ASP will receive Communication-Restart Primitive from SCTP M-SCTP Status --------> Status Ind --------> ASP Down N-PCState Ind --------> (PC Z) <-------- Unitdata Send Failure ---------> TEST DESCRIPTION: 1. Invoke a Connection Restart on the association between SGP and ASP. Check A: SCTP association will be restarted and on receiving Communication Restart primitive from SCTP, M-SCTP Status indication and an ASP Status Ind will be received at the SM. Check B: State of ASP will be Down. Send Unitdata primitive from the SU to send some Protocol DATA. ASP will report send failure. Anjali Gurmukhani, HSS [Page 171] Internet Draft SUA Conformance Test Plan Aug 2003 "SCTP Connection Establishment" + TEST NUMBER : SCM_4 + PURPOSE: To check that on receiving Communication Up primitive from SCTP, SG SUA will send M-SCTP-Establish indication to the SM. + TEST CONFIGURATION: A/G + PRE-TEST CONDITIONS: SCTP association is not established between SGP and ASP1. Also arrange the data in ASP such that SCTP association is established between ASP1 and SGP. EXPECTED MESSAGE SEQUENCE : SGP ASP SM SCTP Establish request to SCTP SCTP association will be established by SCTP ASP will receive Communication-Up primitive from SCTP M-SCTP-Establish Ind -------> <--------- ASP-UP <------------------ ASPUP ASP-Up-Ack ------------------> NTFY ------------------> (AS-Inactive) Status Ind ---------> Anjali Gurmukhani, HSS [Page 172] Internet Draft SUA Conformance Test Plan Aug 2003 TEST DESCRIPTION: 1. Make an SCTP association between SGP and ASP. ASP will receive Communication Up primitive from SCTP. 2. Check A: SM receives M-SCTP-Establish indication. 3. Send ASPUP message from ASP to SGP. 4. Send ASP-Up-Ack and NTFY message with status ASP-Inactive from the SGP. 5. Check B: Status Ind for ASP State as Inactive is received at SM. Anjali Gurmukhani, HSS [Page 173] Internet Draft SUA Conformance Test Plan Aug 2003 7 Acknowledgements The authors would like to thank Anshoo Sharma, Akhtar Iqbal,Kamesh Kaul, Yogesh Gahlaut, Manish Rajpal, Sandeep Mahajan for their insightful comments and suggestions. Funding for the RFC editor function is currently provided by the Internet Society. Anjali Gurmukhani, HSS [Page 174] Internet Draft SUA Conformance Test Plan Aug 2003 8 Authors' Addresses Anjali Gurmukhani Plot-17,Hughes Software Systems Electronic city,Gurgaon. India. Email_id:agurmukhani@hss.hns.com anj_gur@yahoo.com Dipak Aggarwal Hughes Software Systems Electronic City,Gurgaon India Email_id:diaggarwal@hss.hns.com 9 References [2960] RFC 2960 "Stream Control Transmission Protocol" R. Stewart, et al, November 2000. [ITU SCCP] ITU-T Recommendations Q.711-714, 'Signaling System No. 7 (SS7) - Signaling Connection Control Part (SCCP)' [SUA] SCCP-User Adaptation Layer [SUA-CONF] Test Specification for SUA [M3UA-CONF] Test Specification for MTP3 User Adaptation Anjali Gurmukhani, HSS [Page 175] Internet Draft SUA Conformance Test Plan Aug 2003 Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not Be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Anjali Gurmukhani, HSS [Page 176]