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