INTERNET-DRAFT                                         Manish Sharma
                                                    Hughes Software Systems



       Issued:  Oct 2003

       Expires: May 2004



                     Test Specification for MTP2 User Adaptation
                         <draft-sharmam-test-spec-m2ua-00.txt>


       Status of this Memo

       This document is an Internet-Draft and is in full conformance with all
       provisions of Section 10 of RFC 2026. Internet-Drafts are working
       documents of the Internet Engineering Task Force (IETF), its areas, and
       its working groups. Note that other groups may also distribute working
       documents as Internet-Drafts.

       Internet-Drafts are draft documents valid for a maximum of six months
       and may be updated, replaced, or obsolete by other documents at any
       time. It is inappropriate to use Internet-Drafts as reference material
       or to cite them other than as 'work in progress'.

       The list of current Internet-Drafts can be accessed at
       http://www.ietf.org/ietf/1id-abstracts.txt

       The list of Internet-Draft Shadow Directories can be accessed at
       http://www.ietf.org/shadow.html.



       Abstract

       This document presents the test specifications for M2UA (MTP2 User
       Adaptation) protocol (RFC 3331), which can be used to test M2UA
       implementations for conformance to the protocol definition. The list of
       test is exhaustive and covers almost all the categories of test.
       This draft can also be used in conjunction with M2UA specification by
       implementers of protocol as implementers guide, as the pictorial
       representation of various scenarios help easy understanding of the

    Manish Sharma, HSS                                            [Page 1]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       protocol. Next revision of the draft will cover the additions done to
       the protocol revision and any subsequent RFC published by IETF.




       Table of Contents

       1.  Introduction...................................................3
         1.1 Terms Used...................................................3

       2.  General Principles of M2UA Tests...............................5
         2.1 Presentation of test descriptions............................5

       3.  Test Configurations............................................6
         3.1 Presentation of test Configurations..........................6
         3.2 Configuration for testing the M2UA at SGP....................6
         3.3 Configuration for testing the M2UA at ASP....................9

       4.  Test Cases for Testing M2UA at SGP...........................  9
         4.1 Layer Management Messages................................... 9
         4.2 ASPM Messages...............................................15
         4.3 MGMT Messages...............................................45
         4.4 MAUP Messages.............................................. 83

       5.  Test Cases for Testing M2UA at ASP...........................110
         5.1 Layer Management Messages .................................110
         5.2 ASPM Messages..............................................113
         5.3 MGMT Messages..............................................123
         5.4 MAUP Messages..............................................140

       6.  Interface Identifier Management Messages.....................151
       7.  Acknowledgements.............................................160
       8.  Authors' Addresses...........................................161
       9.  References...................................................161












    Manish Sharma, HSS                                          [Page 2]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003




       1. Introduction

       The M2UA is a protocol for the transport of any SS7 MTP2-User signaling
       (e.g. MTP3 messages) over IP using the Stream Control Transport
       protocol(SCTP) or any other suitable transport protocol. This protocol
       would be used between a Signaling Gateway (SG) and an Application
       server process(ASP)(e.g. Media Gateway Controller - MGC) or IP-resident
       Database.

       1.1 Terms Used

       Application Server (AS) - A logical entity serving a specific
       application instance. An example of an Application Server is a MGC
       handling the MTP Level 3 and call processing for SS7 links terminated
       by the Signaling Gateways.  Practically speaking, an AS is modeled at
       the SG as an ordered list of one or more related Application Server
       Processes (e.g., primary, secondary, tertiary,..).

       Application Server Process (ASP) - A process instance of an Application
       Server.  Examples of Application Server Processes are primary or backup
       MGC instances.


       Association - An association refers to a SCTP association. The
       association will provide the transport for the delivery of protocol
       data units for one or more interfaces.

       Backhaul - Refers to the transport of signaling from the point of
       interface for the associated data stream (i.e., SG function in the MGU)
       back to the point of call processing (i.e., the MGCU), if this is not
       local.

       Fail-over - The capability to re-route signaling traffic as required to
       an alternate Application Server Process within an Application Server in
       the event of failure or unavailability of a currently used

       Application Server Process.  Fail-back MAY apply upon the return to
       service of a previously unavailable Application Server Process.
       Host - The computing platform that the ASP process is running on.




    Manish Sharma, HSS                                          [Page 3]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       Interface - For the purposes of this document, an interface is a SS7
       signaling link.

       Interface Identifier - The Interface Identifier identifies the physical
       interface at the SG for which the signaling messages are sent/received.
       The format of the Interface Identifier parameter can be text or
       integer, the values of which are assigned according to network operator
       policy. The values used are of local significance only, coordinated
       between the SG and ASP.


       Layer Management (LM)- Layer Management is a nodal function in an SG or
       ASP that handles the inputs and outputs between the M2UA layer and a
       local management entity.

       Link Key - The link key is a locally unique (between ASP and SG) value
       that identifies a registration request for a particular Signaling Data
       Link and Signaling Terminal pair.

       MTP - The Message Transfer Part of the SS7 protocol.

       MTP2 - MTP Level 2, the signaling datalink layer of SS7

       MTP3 - MTP Level 3, the signaling network layer of SS7.

       MTP2-User - A protocol that uses the services of MTP Level 2(i.e.
       MTP3).

       Network Byte Order: Most significant byte first, a.k.a. Big Endian.

       Signaling Link Terminal (SLT) - Refers to the means of performing all
       of the functions defined at MTP level 2 regardless of their
       implementation[2].

       Stream - A stream refers to an SCTP stream; a uni-directional logical
       channel established from one SCTP endpoint to another associated SCTP
       endpoint, within which all user messages are delivered in-sequence
       except for those submitted to the unordered delivery service.

       Signaling Gateway Process (SGP) - A process instance of a Signaling
       Gateway.  It serves as an active, backup, load-sharing or broadcast



    Manish Sharma, HSS                                          [Page 4]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       process of a Signaling Gateway.

       Signaling Gateway - An SG is a signaling agent that receives/sends SCN
       native signaling at the edge of the IP network [1]. An SG appears to
       the SS7 network as an SS7 Signaling Point. An SG contains a set of one
       or more unique Signaling Gateway Processes, of which one or more is
       normally actively processing traffic.  Where an SG contains more than
       one SGP, the SG is a logical entity and the contained SGPs are assumed
       to be coordinated into a single management view to the SS7 network and
       to the supported Application Servers.

       ASPSM, ASPTM, SSNM - ASP State Maintenance Messages, ASP Traffic
       Maintenance Messages, Signaling System Network Management Messages.


       2. General Principles of M2UA Tests

       These tests aim to verify a given implementation of a protocol in
       accordance with the relevant draft. The specification is independent of
       a given implementation and does not generally imply any modification of
       the endpoint under test.
       However, it is recognized that certain tests require capabilities of
       the system that are not explicitly defined in the draft, and these
       capabilities may not be present in all implementations. As a
       consequence, certain tests may not be possible in all implementations.

       2.1 Presentation of test descriptions

       Each test description includes the environment in which the point under
       test must be inserted in order to pass the test. The test
       configurations are defined (named A, B, C, D, E); they are presented in
       clause 3. Each test is precisely described. Nevertheless, some events
       not directly concerning the point under test, or without direct link
       with the test nature, are not explicitly described. In order to
       preserve the test description implementation independence, certain
       flexibility has been left in the test descriptions. This is
       particularly the case when it is necessary to terminate the SCTP
       association (where it is only mentioned "Terminate" with no more
       precision). The operator will choose according to the implementation
       particularities and the events expected in the test description, the




    Manish Sharma, HSS                                          [Page 5]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       appropriate Termination means (MML- Man machine Language, provoked
       failure, etc.).


       2.1.1 Pre Test Condition

       Before starting the test we need to get the setup into a condition from
       where test can be started. These conditions are specified in Pre-Test
       condition in each test.

       Note: Where NIF has been written, it means that NIF+SM. In some
       implementation these may be two entities and in some, they may be
       implemented in single entity. And where SM is written, it means LM+SM.
       In some implementation these may be two entities and in some, they may
       be implemented in single entity.


       3. Test Configurations:

       The set of tests described in this Recommendation assumes that the
       Point under test is inserted in a test environment called "test
       configuration".


       3.1 Presentation of test configurations:

       There are different configurations for testing the M2UA protocol. These
       configurations and hence test cases have been divided on the basis of
       M2UA at SG and M2UA at ASP.

       3.2 Configuration for testing the M2UA at SGP:

       3.2.1 Configuration A:

       This simple configuration is used for all the procedures of tests
       concerning only one AS. Configuration A is shown in figure 1.
       AS is handling the traffic for Interface Identifier X and Y.
       AS is having only one ASP ASP1.







    Manish Sharma, HSS                                          [Page 6]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



                SG

            +-------------+                               +--------------+
            | SGP         |                               | AS           |
            | under Test  |                               |  --------    |
            |             |-------------------------------|--| ASP1 |    |
            |             |                               |  --------    |
            +-------------+                               +--------------+
                                Fig 1: Configuration A



       3.2.2 Configuration B:

       This configuration is used for all the procedures of tests concerning
       one ASP in two AS which are handling traffic for different interface
       identifiers. Configuration B is shown in figure 2. AS1 is handling the
       traffic for Interface Identifier X and Y. AS2 is handling the traffic
       for Interface Identifier P and Q. ASP1 is in both AS.

                                                   +----------------------+
                                                   |      AS1             |
            SG                                     |                      |
          +-------------+                          |  +----------------+  |
          |             |                          |  |   -------      |  |
          |             |--------------------------|--|--| ASP1  |     |  |
          | SGP         |                          |  |   -------      |  |
          | Under Test  |                          +--|----------------|--+
          |             |                             |     AS2        |
          +-------------+                             +----------------+

                                    Fig 2: Configuration B






       3.2.3 Configuration C:

       This configuration is used for all the procedures of tests concerning
       two or more ASP in one AS. Configuration C is shown in figure 3. AS is



    Manish Sharma, HSS                                          [Page 7]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       handling the traffic for Interface Identifier X and Y. ASP1 and ASP2
       are in Over-ride mode of traffic handling.

                                                          +--------------+
              SG                                          | AS           |
            +-------------+                               |  -------     |
            |             |-------------------------------|-| ASP1  |    |
            | SGP         |                               |  -------     |
            | Under Test  |                               |  -------     |
            |             |                               | | ASP2  |    |
            |             |-------------------------------|- -------     |
            +-------------+                               +--------------+
                               Fig 3: Configuration C



       3.2.4 Configuration D:

       This configuration is used for all the procedures of tests concerning
       two or more AS which are handling traffic for different interface
       identifiers. Configuration D is shown in figure 4. AS1 is handling the
       traffic for Interface Identifier X and Y. AS2 is handling the traffic
       for Interface Identifier P and Q. AS3 for Interface Identifier S, T.
       ASP1 is in AS1 and ASP2 is in AS2 and ASP3 in AS3.

                                                          +--------------+
              SG                                          | AS1          |
            +-------------+                               |  -------     |
            |             |-------------------------------| | ASP1  |    |
            | SGP         |                               |  -------     |
            | Under Test  |                               +--------------+
            |             |                               +--------------+
            |             |-------------------------------| AS2          |
            |             |-------+                       |   -------    |
            +-------------+       |                       |  | ASP2  |   |
                                  |                       |   -------    |
                                  |                       +--------------+
                                  |                       +--------------+
                                  |                       | AS3          |
                                  +-----------------------|-  -------    |
                                                          |  | ASP3  |   |
                                                          |   -------    |
                                                          +--------------+
                               Fig 4: Configuration D

    Manish Sharma, HSS                                          [Page 8]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003






       3.3 Configuration for testing the M2UA at ASP

       3.3.1 Configuration E:

       This simple configuration is used for all the procedures of tests
       concerning only one SG. Configuration E is shown in figure 5. ASP1 is
       handling the traffic for Interface Identifier X and Y.

             +-------------+                               +--------------+
             | ASP1        |                               | SGP          |
             | under Test  |                               |              |
             |             |-------------------------------| SG           |
             |             |                               |              |
             +-------------+                               +--------------+

                                Fig 5: Configuration E
       The above conditions with each Test Configuration are meant only to be
       the Default conditions in case no specific conditions are mentioned.




       4.  Test Cases for Testing M2UA at SGP

       4.1 Layer Management Messages

         4.1.1 SCTP Connection Management

         "SCTP Connection Management"

         + TEST NUMBER : 4.1.1

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Establishment

         + PURPOSE: To check that on receiving Communication Up primitive
           from SCTP, SGP-M2UA will send M-SCTP-Establish indication to the
           SM.


    Manish Sharma, HSS                                          [Page 9]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is not established between
           SGP and ASP. ASP is acting as client and SGP as server.
           Let the SM at ASP send M-SCTP-ESTABLISH request to M2UA at ASP.


         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

         SCTP_ASSOCIATE request sent to SCTP from M2UA at ASP.

         SCTP association established between ASP and SGP.

         SGP M2UA will receive SCTP-Communication_Up Primitive from SCTP.

                              M-SCTP_Establish Indication--------->
         ASPUP  --------------->
                                 State Ind  --------------->
                                 (ASP-Up)

            <-------------------- ASPUP-Ack
            <-------------------- NTFY(AS-Inactive)

       TEST DESCRIPTION:

       1. Make an SCTP association between ASP and SGP.
          SGP M2UA will receive Communication Up primitive from SCTP.

       2. Check A: M-SCTP-Establish indication will be sent to the SM.

       3. To check association is established correctly, send ASPUP message
          from ASP to SGP.

       4. Check B: ASP-Up-Ack and NTFY message with status AS-Inactive should
          be received at the ASP.









    Manish Sharma, HSS                                          [Page 10]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         "SCTP Connection Management"

         + TEST NUMBER : 4.1.2

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Status

         + PURPOSE: To check on receiving M-SCTP_STATUS request from SM,
           M2UA will send the M-SCTP_STATUS Indication primitive to SM at SGP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between
           SGP and ASP. ASP is active.


         EXPECTED MESSAGE SEQUENCE :

         ASP                            SGP                             NIF+SM


                                   ASP is Active


                                         <-------------- M-SCTP_STATUS Request

                                    M-SCTP_STATUS Ind ------------------->


       TEST DESCRIPTION:

       1. Let the SM at SGP send M-SCTP_STATUS request to M2UA at SGP.

       2. Check A: M-SCTP_STATUS Indication will be received at SM indicating
          the SCTP Status.









    Manish Sharma, HSS                                          [Page 11]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         "SCTP Connection Management"

         + TEST NUMBER : 4.1.3

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Termination

         + PURPOSE: To check that on receiving SCTP-Communication Down
           Indication (SCTP CDI) primitive from SCTP in case of a graceful
           -shutdown, the SGP will send the M-SCTP Status primitive to the SM.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between
           SGP and ASP and ASP is active. Let the SM at ASP send
           M-SCTP_RELEASE request to M2UA at ASP. M2UA will send SCTP_SHUTDOWN
           primitive to local SCTP.


           EXPECTED MESSAGE SEQUENCE :

           ASP                        SGP                        NIF+SM

                                  ASP is Active

                 SCTP association terminated.

          M2UA at SGP will receive SCTP CDI(SCTP-SHUTDOWN_COMPLETE) from SCTP
          at SGP.

                             M-SCTP release Indication(to SM) ------>

                                M-SCTP_Status Ind--------->

                                M-ASP_Status Ind------------>
                               (ASP Down)
                                M-AS_Status Ind------------->
                               (AS-Pending)
                                                      <-------- Data

                                 Send Failure --------------->


    Manish Sharma, HSS                                          [Page 12]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



     TEST DESCRIPTION:

       1. Terminate the association between SGP and ASP.

       2. Check A: SCTP association will be down and on receiving
          SCTP-SHUTDOWN_COMPLETE(Communication Down Indication)from SCTP,
          M-SCTP Status indication will be received at SM.

       3. Check B: State of AS will be pending for T(r) time and will become
          AS-Down after the expiry of the timer T(r).

       4. Check C: State of ASP will be down at the SG. Send data primitive
          from the NIF to send some Protocol DATA. SGP will report send
          failure.

       5. Repeat the test for Inactive state of ASP including only Check A and
          Check C.



         "SCTP Connection Management"

         + TEST NUMBER : 4.1.4

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Termination

         + PURPOSE: To check that on receiving SCTP-Communication Down
           Indication (SCTP CDI) primitive from SCTP for an ungraceful
           shutdown, M2UA at SGP will change the state of ASP to ASP-DOWN.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between
           SGP and ASP. ASP is Active.


         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                  ASP is Active

    Manish Sharma, HSS                                          [Page 13]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


               SCTP at SGP detects loss of Communication with peer SCTP

         M2UA at SGP will receive SCTP CDI(SCTP-COMMUNICATION_LOST)from SCTP
         At SGP
                               M-SCTP-Release Ind---------------->

                                 M-ASP-Status--------->
                                 (ASP Down)

                                M-AS-Status---------->
                                (AS-Pending )

                                          <------------------- Data

                                 Send Failure --------------->

       TEST DESCRIPTION:


       1. Make SCTP at SGP send SCTP CDI to M2UA at SGP by letting it detect
          loss of Communication with peer SCTP.

       2. Check A: M-SCTP_Status indication will be received at SM.

       3. Check B: State of AS will be pending for T(r) time and will become
          AS-Down after the expiry of the timer T(r).

       4. Check C: State of ASP will be down at the SG. Send data primitive
          from the NIF to send some Protocol DATA.SGP will report send
          failure.

       5. Repeat the test for ASP in Inactive state including only Check A and
          Check C.




         "SCTP Connection Management"

         + TEST NUMBER : 4.1.5

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Restart

    Manish Sharma, HSS                                          [Page 14]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         + PURPOSE: To check that on receiving SCTP-RI indication primitive
           from SCTP, M2UA at SG will change the state of ASP to ASP-DOWN.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SG and
           ASP. ASP is active.


          EXPECTED MESSAGE SEQUENCE :

           ASP                        SGP                        NIF+SM

                                    ASP is Active

               SCTP at SGP detects a restart from ASP's peer SCTP Layer

               SCTP at SGP sends an SCTP RI to M2UA at SGP

                                  ASP Status Ind--------->
                                 (ASP Down)

                                AS Status Ind --------->
                                (AS-Pending)

                               Timer T(r) expires

                                AS Status Ind --------->
                                (AS-Down)

                                                       <-------- Data

                                  Send Failure --------------->

       TEST DESCRIPTION:

       1. Make the SCTP at SGP send an SCTP RI to M2UA at SGP by letting it
          detect a restart from Asp's peer SCTP Layer.

       2. Check A: ASP Down Status indication will be received at SM. AS-
          Pending Status Indication will be received at SM and after the
          expiry of Timer T(r) AS-Down Status indication will be received at
          SM.

    Manish Sharma, HSS                                          [Page 15]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       3. Check B: State of ASP will be down at the SGP. Send data primitive
          from the NIF to send some Protocol DATA.
          SGP will report send  failure.

       4. Repeat the test for ASP in Inactive state including Check A and
          Check B. There will not be any Timer expiry in this case, the state
          of AS will be directly changed to AS-Down.




       4.2 ASPM Messages

       4.2.1 ASPSM and ASPTM Messages

         "Heartbeat and Heartbeat Ack"

         + TEST NUMBER :4.2.1

         + TITLE :  Heartbeat Message

         + SUBTITLE : Heartbeat Message

         + PURPOSE: To check that if an ASP sends Heartbeat Messages (to
           ensure that the M2UA peers are still available to each other) , SGP
           sends Heartbeat Ack to the ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. ASP is configured as the Client.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                  ASP is Active

         BEAT  ----------------->

                 Timer 2*T(beat) is Started
                   |
                   |
                   |
           <------------------   BEAT Ack
    Manish Sharma, HSS                                          [Page 16]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         BEAT  ----------------->

                 Timer 2*T(beat) is Started
                   |
                   |
                   |

               Timer 2*T(beat) expires


       TEST DESCRIPTION:

       1. Send BEAT message from ASP to SGP.

       2. Check A: A BEAT Ack will be receive at the ASP before the Timer
          T(beat) expires.

       3. Send BEAT message again from ASP to SGP and restrict the BEAT Ack
          from SGP.

       4. Check B: No BEAT Ack is received while Timer T(beat) is running.

       5. Check C: After Timer T(beat) expires Transmission of BEAT message
          stops and the Signaling Process will attempt to re-establish
          communication.

       6. Repeat the above Test case when the BEAT message is sent by SGP.
          Results will be analogous.


       Note: The Signaling Process at an M2UA peer will attempt re-
       establishment of communication only if it is configured as the Client
       for the disconnected M2UA peer.



         "ASPM messages"

         + TEST NUMBER :4.2.1

         + TITLE :  ASPUP messages

         + SUBTITLE : ASPUP messages when SGP has locked the ASP for

    Manish Sharma, HSS                                          [Page 17]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                      Management reasons.

         + PURPOSE: To check that if ASPUP message is received when SGP has
           locked the ASP for management reason then error
           (Refused-Management Blocking) is sent to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Down.


         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Down

                                                   <-------- Lock AS

         ASPUP  --------------->

                         <-------- Error
                           (Cause - Refused-Management Blocking)


                                                 <-------- UnLock ASP

         ASPUP  --------------->

                                Status Ind.----------------->
                                (ASP Inactive)

                       <-------- ASPUP-Ack
                       <-------- NTFY(AS-Inactive)

       TEST DESCRIPTION:

       1. Lock out the ASP at the SGP by sending primitive for locking ASP
          from SM. Now send ASPUP message with valid parameters from ASP to
          SGP on SCTP Stream 0.
       2. Check A: Error(Cause = Refused-Management Blocking)is received at
          ASP.
       3. UnLock out the ASP at the SGP by sending primitive for un-locking
          ASP from SM. Now send ASPUP message with valid parameters from ASP

    Manish Sharma, HSS                                          [Page 18]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          to SGP on SCTP Stream 0.

       4. Check B: ASPUP-Ack will be received at ASP.

       5. Check C: A NTFY message with Status AS-Inactive is received at ASP.




         "ASPM messages"

         + TEST NUMBER : 4.2.2

         + TITLE :  ASPUP messages

         + SUBTITLE : ASPUP messages when SGP doesn't send ASPUP-Ack.

         + PURPOSE: To check that if ASPUP message is received at SGP
           and it does not send the ASPUP-Ack, then ASP re-tries it.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Down.

         EXPECTED MESSAGE SEQUENCE :

          ASP                        SGP                        NIF+SM

                                    ASP is Down

          ASPUP  --------------->

                                  T(ack) expires

          ASPUP  --------------->

                                  T(ack) expires


                            n-1 tries....

          ASPUP  --------------->


    Manish Sharma, HSS                                          [Page 19]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                               ASP State Ind---------->
                               AS State Ind----------->

                <----------------ASPUP-Ack
                <----------------NTFY(AS-Inactive)


       TEST DESCRIPTION:

       1. Send ASPUP message with valid parameters from ASP to SGP on SCTP
          Stream 0 and restrict ASPUP-Ack from SGP to ASP.

       2. Check A: ASPUP message is received at SGP repeatedly.

       3. Don't restrict ASPUP-Ack from SGP to ASP for the next ASPUP message
          from ASP.

       4. Check B: ASPUP-Ack, NTFY(AS-Inactive), will be received at ASP.

       5. Check C: ASP State Ind, AS-State Ind will be received at SM of SGP.


       Note: Number of repetitions are implementation dependent.


























    Manish Sharma, HSS                                          [Page 20]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         "Duplicate Message Handling"

         + TEST NUMBER :4.2.3

         + TITLE :  ASPUP messages

         + SUBTITLE : ASPUP message when ASP is in ASP-Inactive state at SGP

         + PURPOSE: To check that if ASPUP message is received when ASP is in
           ASP-Inactive state at SGP then ASP-Up-Ack message is sent to the
           ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
          and ASP. ASP is Down.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Down

         ASPUP --------------->

                                Status Ind --------------->
                              (ASP Inactive)

                  <--------------ASPUP-Ack
                  <--------------NTFY(AS-Inactive)

         ASPUP --------------->

                  <--------------ASPUP-Ack

         ASPAC --------------->

                               Status Ind --------------->
                              (ASP Active)

                 <--------------ASPAC-Ack

                              <--------------NTFY(AS-active)


    Manish Sharma, HSS                                          [Page 21]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       TEST DESCRIPTION:

       1. Send ASPUP message to the SGP with ASP in ASP-Down state.

       2. Check A: ASP-Up-Ack and NTFY  message will come from the SGP with
          status AS-Inactive.

       3. Send ASPUP message again from the ASP.

       4. Check B: ASP-Up-Ack message will be received at the ASP.

       5. Check C: State of ASP at SGP is not disturbed i.e. ASP remains in
          the Inactive state. Send ASPAC message for the ASP, ASP-Active-Ack
          and NTFY with AS-Active should come.




         "Different Message Handling"

         + TEST NUMBER : 4.2.4

         + TITLE :  ASPUP messages

         + SUBTITLE : ASPUP message when ASP is in ASP-Active state at SGP

         + PURPOSE: To check that if ASPUP message is received when ASP is in
           ASP-Active state at SGP then ASPUP-Ack is sent to ASP and Error
           message also sent to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Active

         ASPUP --------------->

                    <--------------Error
                            (Cause = Unexpected Message)
    Manish Sharma, HSS                                          [Page 22]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



                   <--------------ASPUP-Ack

                                ASP state Ind --------------->
                                (ASP Inactive)

       TEST DESCRIPTION:

       1. Send ASPUP message to the SGP when ASP is in ASP-Active state.

       2. Check A: Error message with Cause "Unexpected Message" should be
          received at the ASP.

       3. Check B: ASPAC-Ack message should be received at the ASP.

       4. Check C: State of ASP at SGP changes to ASP-Inactive.





         "ASPM messages"

         + TEST NUMBER : 4.2.5

         + TITLE :  ASPDN messages

         + SUBTITLE : ASPDN messages when SGP doesn't send ASPDN-Ack.

         + PURPOSE: To check that if ASPDN message is received at SGP and it
           does not send the ASPDN-Ack, then ASP re-tries it.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Inactive.


         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                ASP is Inactive


    Manish Sharma, HSS                                          [Page 23]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         ASPDN  --------------->

                            T(ack) expires
         ASPDN  --------------->

                            T(ack) expires


                            n-1 tries....

         ASPDN  --------------->

                                 ASP State Ind---------->
                                 AS State Ind----------->

               <----------------ASPDN-Ack
               <----------------NTFY(AS-Down)

       TEST DESCRIPTION:

       1. Send ASPDN message with valid parameters from ASP to SGP and dont
          send(restrict) ASPDN-Ack from SGP to ASP.

       2. Check A: ASPDN message is received at SGP repeatedly.

       3. Don't restrict ASPDN-Ack from SGP to ASP for the next ASPDN message.

       4. Check B: ASPDN-Ack, NTFY(AS-Down), will be received at ASP.

       5. Check C: ASP State Ind, AS-State Ind will be received at SM of SGP.

       6. Check D: A NTFY message with Status AS-Down is receivd at the ASP.



       Note 1: Number of repetition is Implementation dependent.

       Note 2: When the AS transitions to the AS down state, all the SS7 link
       (Interface Identifier) for this AS should be taken out of service.








    Manish Sharma, HSS                                          [Page 24]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



        "Duplicate Message Handling"

         + TEST NUMBER : 4.2.6

         + TITLE :  ASPDN message

         + SUBTITLE : ASPDN message when ASP is in ASP-Down state at SGP

         + PURPOSE: To check that if ASPDN message is received when ASP is in
           ASP-Down state at SGP then SGP sends an ASP-DN-Ack message to the
           ASP and no further action is taken at SGP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Down.


         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                  ASP is Down

          ASPDN --------------->

                    <--------------ASPDN-Ack

          ASPUP --------------->

                               Status Ind. ------------>

                   <--------------ASPUP-Ack
                   <--------------NTFY(AS-Inactive)

       TEST DESCRIPTION:

       1. Send ASPDN message to the SGP when ASP is in ASP-Down state.

       2. Check A: ASPDN-Ack will come from the SGP to ASP and no further
          action will be taken.

       3. Check B: The State of the ASP at SGP is not disturbed.

    Manish Sharma, HSS                                          [Page 25]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       4. Now send ASPUP message from the ASP.

       5. Check B: ASP-Up-Ack message and a NTFY message with Status AS-
          Inactive will be received at the ASP.






         "Different Message Handling"

         + TEST NUMBER : 4.2.7

         + TITLE :  ASPDN message

         + SUBTITLE : ASPDN message when ASP is in ASP-Active state at SGP

         + PURPOSE: To check that if ASPDN message is received when ASP is in
           ASP-Active state at SGP then ASPDN-Ack is sent to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Active

         ASPDN --------------->

                                  ASP state Ind --------------->
                                 (ASP Down)

                                 AS  state Ind --------------->
                                 (AS-Pending)

                  <--------------ASPDN-Ack
                  <--------------NTFY(AS-Pending)

                          T(r) expires

                               AS State Ind --------------->
    Manish Sharma, HSS                                          [Page 26]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                             (AS-Down)

         DATA --------------->

                   <--------------Error
                          (Unexpected Message)


       TEST DESCRIPTION:

       1. Send ASPDN message to the SGP with ASP is in ASP-Active state.

       2. Check A: ASPDN-Ack, NTFY(AS-Pending) is received at ASP.

       3. Check B: ASP State Ind, AS State Ind is received at SGP.

       4. Send DATA from ASP to SGP after Timer T(r) expires.

       5. Error message with parameter Unexpected message should be received
          at the ASP.


       Note: When the AS transitions to the AS down state, all the SS7 link
       (Interface Identifier) for this AS should be taken out of service.







         "ASPM messages"

         + TEST NUMBER : 4.2.8

         + TITLE :  ASPAC messages

         + SUBTITLE : ASPAC message when ASP is in ASP-Inactive state at SGP

         + PURPOSE: To check that if ASPAC message is received at SGP with ASP
                    in ASP-Inactive state then ASPAC-Ack is sent to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP

    Manish Sharma, HSS                                          [Page 27]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                                and ASP. ASP is Inactive.


         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                ASP is Inactive

         ASPAC --------------->

                                  ASP State Ind --------------->
                                  (ASP-active)

                                  AS State Ind --------------->
                                  (AS-active)

                   <--------------ASPAC-Ack
                   <--------------NTFY(AS-active)


       TEST DESCRIPTION:

       1. Send ASPAC message with Interface Identifiers X and Y to the SGP
          with ASP in ASP-Inactive state.

       2. Check A: ASPAC-Ack, NTFY(AS-active)message is received at the ASP.

       3. Check B: State of ASP, AS at SGP is changed to active.




         "ASPM messages"

         + TEST NUMBER : 4.2.9

         + TITLE :  ASPAC messages

         + SUBTITLE : ASPAC messages when SGP doesn't send ASPAC-Ack.

         + PURPOSE: To check that if ASPAC message is received at SGP and it
                    does not send the ASPAC-Ack, then ASP re-tries it.

         + TEST CONFIGURATION: A

    Manish Sharma, HSS                                          [Page 28]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + PRE-TEST CONDITIONS: SCTP association is established between SGP
                               and ASP. ASP is Inactive.


         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Inactive

         ASPAC --------------->

                          T(ack) expires

         ASPAC --------------->

                          T(ack) expires

                           n-1 tries....

         ASPAC --------------->

                              ASP State Ind---------->

                              AS State Ind----------->

                <--------------- ASPAC -Ack
                <----------------NTFY(AS-Active)


       TEST DESCRIPTION:

       1. Send ASPAC message with valid parameters from ASP to SGP and dont
          send(restrict) ASPAC-Ack from SGP to ASP.

       2. Check A: ASPAC message is received at SGP repeatedly.

       3. Don't restrict ASPAC -Ack from SGP to ASP for the next ASPAC
          message.

       4. Check B: ASPAC-Ack, NTFY(AS-active), will be received at ASP.

       5. Check C: ASP State Ind, AS-State Ind will be received at SM of SGP.


    Manish Sharma, HSS                                          [Page 29]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       Note: Number of repetitions is implementation dependent.




         "Duplicate Message Handling"

         + TEST NUMBER : 4.2.10

         + TITLE :  ASPAC message

         + SUBTITLE : ASPAC message when ASP is in ASP-Active state at SGP

         + PURPOSE: To check that if ASPAC message is received when ASP is in
                    ASP-Active state at SGP then ASPAC-Ack message is sent to
                    the ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Active

         ASPAC --------------->

                    <--------------ASPAC-Ack

         ASPAC --------------->

                    <--------------ASPAC-Ack

         DATA Msg-------------->

                               Data Receive Ind --------->

       TEST DESCRIPTION:

       1. Send ASPAC message from ASP to the SGP with ASP in ASP-Active state.
          ASPAC-Ack message will be sent from the SGP .
    Manish Sharma, HSS                                          [Page 30]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       2. Send ASPAC message again from the ASP.

       3. Check A: ASPAC-Ack message will be received at the ASP.

       4. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
          Active state. Send DATA message from ASP, Data Receive Indication
          Will be received at NIF at SGP.







         "Different Message Handling"

         + TEST NUMBER : 4.2.11

         + TITLE :  ASPAC message

         + SUBTITLE : ASPAC message when ASP is in ASP-Down state at SGP

         + PURPOSE: To check that if ASPAC message is received when ASP is in
           ASP-Down state at SGP then it is discarded and ASPDN-Ack is sent to
           ASP and optionally Error (Unexpected message) is sent to the ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Down.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Down

         ASPAC --------------->

                     <------------ASPDN-Ack

                     <--------------ERROR
                       (Cause = Unexpected Message)


    Manish Sharma, HSS                                          [Page 31]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         ASPUP --------------->

                                 State Ind --------------->
                              (ASP Inactive)

                   <--------------ASPUP-Ack
                   <--------------NTFY(AS-Inactive)


       TEST DESCRIPTION:

       1. Send ASPAC message with Interface Identifiers X, Y to the SGP with
          ASP in ASP-Down state.

       2. Check A:  ASPDN-Ack is received at the ASP.
          ERROR message with Cause Unexpected message should be received at
          the ASP.

       3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
          Down state. Send ASPUP message for the ASP and SGP should respond
          with ASP-Up-Ack and NTFY message with status AS-Inactive.

       4. Repeat the above test case for ASPIA message i.e. ASPIA message is
          received in ASP-Down state with the same parameters as were in the
          ASPAC message. Response should be same.

       Note: The above ERROR message with Cause Unexpected Message is optional
       depending upon the implementation.



         "ASPAC message with no Interface Identifier"

         + TEST NUMBER : 4.2.12

         + TITLE :  ASPAC message

         + SUBTITLE : ASPAC message with no Interface Identifier

         + PURPOSE: To check that if ASPAC message is received with no
           Interface Identifier then status of ASP is made Active for all the
           Interface Identifier of the AS to which ASP belongs at SGP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between
    Manish Sharma, HSS                                          [Page 32]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                SGP and ASP. ASP is Inactive.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                ASP is Inactive

         ASPAC   --------------->
         (No Interface Id)

                                  Status Ind ---------->

              <---------------    ASPAC-Ack
              <---------------    ASPAC-Ack

              <---------------    NTFY (AS-active)
              <---------------    NTFY (AS-active)

         DATA Msg--------------->
         (Interface Id = X)

                              Data Receive Ind ---------->

         DATA Msg--------------->
         (Interface Id = Y)

                              Data Receive Ind ---------->


       TEST DESCRIPTION:

       1. Send ASPAC Message containing no Interface Identifier from ASP to
          the SGP with ASP in ASP-Inactive state.

       2. Check A: ASP-Active-Ack and  NTFY(AS-Active) messages should be
          received at ASP with Interface Identifiers X, Y.

       3. Check B: NTFY message is received on stream 0.

       4. Check C: Check that state of ASP is active in all the Interface
          Identifier of the AS to which this ASP belongs. This can be checked
          by sending DATA message with Interface Identifier X and Y.


    Manish Sharma, HSS                                          [Page 33]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       5. Execute the test case for both types of Interface Identifiers
          (Integer and Text).

       6. Repeat the above test for other ASPTM messages. Response should be
          as per the above rule.




       Note: Usage of multiple ASP Active Ack messages in response to an ASP
       Active message containing multiple Interface Identifier allowing the
       SGP to independently acknowledge the ASP Active messages for different
       (sets of) Interface Identifier is implementation dependent. A single
       ASPAC-Ack message can also be sent for all the Interface Identifiers.



         "ASPAC message with subset of Interface Identifier"

         + TEST NUMBER : 4.2.13

         + TITLE :  ASPAC message

         + SUBTITLE : ASPAC message with subset of Interface Identifiers

         + PURPOSE: To check that if ASPAC message is received with subset of
           Interface Identifiers at SGP then status of ASP is made Active in
           all the Interface Identifiers of the corresponding AS at SGP.

         + TEST CONFIGURATION: B

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Inactive. Traffic handling mode in AS1 and AS2
           configured at SG is Over-ride and ASPAC messages will use the
           Over-ride mode in Traffic Mode Type parameter.

          EXPECTED MESSAGE SEQUENCE :

          ASP                        SGP                        NIF+SM

                                 ASP is Inactive

          ASPAC   --------------->
          (Interface Id = X,P)

                                   Status Ind ---------->
    Manish Sharma, HSS                                          [Page 34]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                   (ASP Active)

              <---------------    ASPAC-Ack(for AS1)
              <---------------    ASPAC-Ack(for AS2)

              <---------------    NTFY (AS-active)(for AS1)
              <---------------    NTFY (AS-active)(for AS2)

          DATA Msg --------------->
          (Interface Id = X)
                                Data Receive Ind --------------->

          DATA Msg --------------->
          (Interface Id = P)
                                Data Receive Ind --------------->

          DATA Msg--------------->
          (Interface Id = Y)
                                Data Receive Ind ---------->


          DATA Msg--------------->
          (Interface Id = Q)
                                Data Receive Ind ---------->


       TEST DESCRIPTION:

       1. Send ASPAC Message containing Interface Identifier X, P from ASP to
          the SGP.

       2. Check A: ASP-Active-Ack and  NTFY(AS-Active) messages should be
          received at ASP  with Interface Identifier X, Y, P and Q  both for
          AS1 and AS2.

       3. Check B: NTFY messages are received on stream 0.

       4. Check C: Check that state of ASP is active in all the AS to which
          this ASP belongs and for all the Interface Ids of the ASs. This can
          be checked by sending DATA messages with Interface Identifier Y, P,
          X and Q respectively.

       5. Execute the test case for both types of Interface Identifier
          (Integer and Text).

    Manish Sharma, HSS                                          [Page 35]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       6. Do this for ASPIA message also.
          Response(Inactive) will be as per the above rule .




         "Duplicate Message Handling"

         + TEST NUMBER : 4.2.14

         + TITLE :  ASPIA message

         + SUBTITLE : ASPIA message when ASP is in ASP-Inactive state at SGP

         + PURPOSE: To check that if ASPIA message is received when ASP is in
           ASP-Inactive state at SGP then ASPIA-Ack message is sent to the
           ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
                                and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                ASP is Active

         ASPIA --------------->

                                  Status Ind --------------->
                                (ASP Inactive)

                   <--------------ASPIA-Ack
                   <--------------NTFY(AS-Pending)

                      Timer T(r) expires

                   <--------------NTFY(AS-Inactive)

          ASPIA --------------->

                   <--------------ASPIA-Ack

    Manish Sharma, HSS                                          [Page 36]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          ASPAC --------------->

                                  Status Ind --------------->
                                 (ASP Active)

                   <--------------ASPAC-Ack
                   <--------------NTFY(AS-active)

                                ASP is active
         ASPIA --------------->



                       T(ack) expires

         ASPIA --------------->

                            |
                            |
                            |

                   T(ack) expires...n-1 times

         ASPIA --------------->

                                 Status Ind ---------------->
                               (ASP Inactive)

                 <--------------ASPIA-Ack
                 <--------------NTFY(AS-Pending)

                      Timer T(r) expires

                 <--------------NTFY(AS-Inactive)

         ASPDN --------------->

                               ASP State Ind --------------->
                               (ASP Down)

                               AS State Ind ---------------->
                               (AS Down)

                 <--------------ASPDN-Ack

    Manish Sharma, HSS                                          [Page 37]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         ASPIA --------------->

                 <--------------ASPDN-Ack

                 <--------------ERROR
                       (Cause = Unexpected Message)


       TEST DESCRIPTION:

       1. Send ASPIA message from ASP to SGP with ASP in ASP-Active state.

       2. Check A: ASPIA-Ack and NTFY message will be sent from the SGP with
          status AS-Pending. After the expiry of Timer T(r) a NTFY message
          with Status AS-Inactive will be sent by the SGP to ASP.

       3. Send ASPIA message again from the ASP.

       4. Check A: ASPIA-Ack message will be received at the ASP.

       5. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in
          the Inactive state. Send ASPAC message from ASP, ASPAC-Ack, NTFY(AS-
          Active)will be received at ASP and State of ASP at SGP will be
          changed to ASP-Active.

       6. Send ASPIA message from ASP to SGP and restrict SGP from sending
          ASPIA-Ack to ASP.

       7. Check C: SGP repeatedly receives ASPIA messages from ASP.

       8. Don't restrict ASPIA-Ack from SGP for the next ASPIA message from
          ASP.

       9. Check D: ASPIA-Ack and NTFY  message will come from the SGP with
          status AS-Pending. After the expiry of Timer T(r) SGP will send a
          NTFY message with Status AS-Inactive to the ASP.

       10. Send ASPDN message to SGP from ASP.

       11. Check E: ASPDN-Ack and NTFY  message will come from the SGP with
           status AS-Pending.

       12. Send ASPIA message from ASP to SGP.

       13. Check F: ASPDN-Ack is received by the ASP sent by SGP.
    Manish Sharma, HSS                                          [Page 38]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       14. Check G: SGP sends error message with cause "Unexpected Message" to
           ASP.

       Note: Number of re-tries are implementation dependent. The above Error
       message with cause "Unexpected Message" is optional depending upon the
       implementation.






         "ASPIA message with a subset of Interface Identifiers"

         + TEST NUMBER : 4.2.15

         + TITLE :  AS management

         + SUBTITLE : ASPIA message with a Subset of Interface Identifiers

         + PURPOSE: To check that if ASPIA message is received with 0 or more
           Interface Identifiers at SGP then status of ASP is set to Inactive
           in all the AS to which this ASP belongs at SGP.

         + TEST CONFIGURATION: B

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. Traffic handling mode in AS1 and AS2
           configured at SG is Over-ride and ASPAC messages will use the Over-
           ride mode in Traffic Mode Type parameter.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                ASP is Active

         ASPIA   --------------->
         (Interface Id = X,P)

                                Status Ind ---------->
                               (ASP Inactive)

             <---------------    ASPIA-Ack(for AS1)

    Manish Sharma, HSS                                          [Page 39]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

             <---------------    ASPIA-Ack(for AS2)

             <---------------    NTFY (AS-Inactive)(for AS1)
             <---------------    NTFY (AS-Inactive)(for AS2)


                                                <---------------Data

                                Send Failure ---------->

                                                <---------------Data

                                Send Failure ---------->


       TEST DESCRIPTION:
       1. Send ASPAC Message containing Interface Identifiers X and P from ASP
          to the SGP.

       2. Check A: ASP-Active-Ack and  NTFY(AS-Active) messages should be
          received at ASP with Interface Identifier X, Y, P and Q  both for
          AS1 and AS2.

       3. Check B: NTFY message is received on stream 0.

       4. Check C: Check that state of ASP is inactive in all the AS to which
          this ASP belongs.

       5. Send DATA Send Primitives with Interface Identifiers X, P, Y and Q
          respectively from NIF to M2UA at SGP.

       6. Check D: A failure message will be received by NIF for all Interface
          Identifiers.

       7. Repeat the above test case if no Interface Identifier is present in
          ASPIA message. The response should be same.

       8. Execute the test case for both types of Interface Identifier
          (Integer and Text).


       Note: Interface Identifier is an optional parameter in the NTFY
       message. In some implementation this parameter may not be present in
       NTFY message. In that case NTFY message with status AS-Inactive/ AS-


    Manish Sharma, HSS                                          [Page 40]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       Pending will be received at ASP and it means that it is for all AS for
       which this ASP is configured.

       Note: The Line 7 of the above Test is applicable only when SGP is
       capable of identifying via Configuration Data, the Application Servers
       to which the ASP belongs. In either case it is not applicable.




         "ASPM messages"

         + TEST NUMBER : 4.2.16

         + TITLE : Traffic Handling Modes

         + SUBTITLE : Override Mode of Traffic Handling in ASPAC message

         + PURPOSE: To check that if an ASPAC message is received with Traffic
           Mode Type field containing Override mode then all traffic is sent
           to that ASP which sent ASPAC message.

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP1 and ASP2. ASP1 is Active and ASP2 is Inactive. Mode of
           traffic handling for AS configured at SGP is Override.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP1 is Active
                                 ASP2 is Inactive

         ASPAC(ASP2)  --------------->
         (Traffic Mode Type = Override)

                                 Status Ind --------------->
                                (ASP Active)

             (ASP2)<--------------ASPAC-Ack


    Manish Sharma, HSS                                          [Page 41]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

             (ASP1)<--------------NTFY
                            (Alternate ASP Active)

                                                    <-------- Data
                                                    (Interface Id = X)

                 (ASP2)<-------- DATA Msg

                                                    <-------- Data
                                                    (Interface Id = Y)
                (ASP2)<-------- DATA Msg

       TEST DESCRIPTION:

       1. Send ASPAC message with Override mode in Traffic Mode Type field and
          Interface Identifier X and Y from ASP2 to SGP.

       2. Check A: SGP should send ASP-Active-Ack message for ASP2 also an
          NTFY message with status "Alternate ASP Active" is sent to ASP1
          which was previously active.

       3. Check B: Also all traffic should go to ASP2 which has sent the
          ASPAC. Check this by sending Data Send Primitives from NIF at SGP
          containing Interface Identifier X and Y following which the M2UA of
          SGP will send DATA messages to corresponding ASPs.
          Check that DATA messages will be sent to ASP2 only.






         "DATA Send Primitive from NIF in AS Inactive State"

         + TEST NUMBER :4.2.17

         + TITLE :  AS management

         + SUBTITLE : Data Send Primitive from NIF in AS Inactive State

         + PURPOSE: To check that if AS is not active at SGP and NIF sends
           Data Send Primitive to local M2UA to send Protocol Data to that AS
           then it receives a send failure.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
    Manish Sharma, HSS                                          [Page 42]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


           and ASP. ASP is in Active state.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Active

         ASPIA   --------------->

                                  ASP State Ind --------------->
                                (ASP Inactive)

             <--------------    ASP-Inactive-Ack
             <--------------    NTFY (AS-Pending)

                                T(r) expires

                                  AS State Ind ---------------->
                                  (AS Inactive)

               <--------------   NTFY (AS-Inactive)

                                              <----------------- Data

                              Send Failure ------------->


       TEST DESCRIPTION:

       1. Send ASPIA Message from ASP to the SGP with Interface Identifier = X
          and other valid parameters.

       2. Check A: An ASPIA-Ack and a NTFY message with Status AS-Pending will
          be received ASP. After the expiry of Timer T(r) a NTFY message with
          Status AS-Inactive is received at ASP. The state of ASP and AS at
          SGP becomes Inactive.

       3. Check B: NTFY message is received on stream 0.

       4. Send DATA Send Primitive containing Interface Identifier X and
          Protocol Data to be sent to the ASP.



    Manish Sharma, HSS                                          [Page 43]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       5. Check C: Send failure should be received at the NIF and DATA message
          should not be sent to ASP.

       6. Repeat the above test if instead of sending ASPIA message, SCTP
          association between ASP and SGP is removed.





         "DATA Send Primitive from NIF in AS Down State"

         + TEST NUMBER : 4.2.18

         + TITLE :  AS management

         + SUBTITLE : DATA Send Primitive from NIF in AS Down State

         + PURPOSE: To check that if AS is in AS-Down State at SGP and NIF
           sends DATA Send Primitive to send data to that AS then it receives
           a send failure.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in Inactive state.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                               ASP is Inactive

         ASPDN   --------------->

                                 ASP State Ind ---------->
                               (ASP Down)

                                 AS-Status Ind ------->
                                 (AS Down)

              <--------------    ASP-Down-Ack

                                              <----------------- Data
                                 Send failure ------------->
    Manish Sharma, HSS                                          [Page 44]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       TEST DESCRIPTION:

       1. Send ASPDN Message from ASP to the SGP.
          Check A: An ASPDN-Ack will be received ASP.
          The state of ASP and AS at SGP becomes Down.

       2. Send DATA Send Primitive containing Interface Identifier X and
          Protocol Data to be sent to the ASP.

       3. Check B: Send failure should be received at the NIF and DATA message
          should not be sent to ASP.

       4. Repeat the above test if instead of sending ASPDN message, SCTP
          association between ASP and SGP is removed.


       Note: When the AS transitions to the AS down state, all the SS7 link
       (Interface Identifier) for this AS should be taken out of service.



       4.3 MGMT Messages

         4.3.1 NTFY Messages

         "Notify Message with AS Status"

         + TEST NUMBER :4.3.1

         + TITLE :  AS management

         + SUBTITLE : Notify Message with AS status

         + PURPOSE: To check that if ASPDN, ASPUP, ASPAC and ASPIA messages
           are received in ASP-Active, ASP-Down, ASP-Up and ASP-Active states
           respectively then NTFY message with correct status is sent to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. The ASPDN and ASPUP messages should be sent
           on SCTP stream 0. The value of Interface Identifiers is X and Y in
           all the messages where required and other parameters are having

    Manish Sharma, HSS                                          [Page 45]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

           valid values.

         EXPECTED MESSAGE SEQUENCE :

         ASP                              SGP                   NIF+SM

                                      ASP is Active

         ASPDN   --------------->
                                     Status Ind ------------->
                                    (ASP-Down)

              <--------------        ASP-Down-Ack

                                     AS Status Ind ---------->
                                    (AS Pending)

                            | Timer T(r) Starts

                            |
                   Time = z sec
                            |

                            | Timer T(r) Expiry

                                   AS Status Ind ----------->
                                  (AS Down)




         ASPUP   --------------->

                                   ASP-Status Ind ------------->
                                 (ASP-Inactive)

                                 AS Status Ind ---------->
                                 (AS-Inactive)

               <--------------    ASP-Up-Ack
               <--------------    NTFY (AS-Inactive)

         ASPAC   --------------->

                                  ASP-Status Ind ----------->
                                 (ASP-Active)
    Manish Sharma, HSS                                          [Page 46]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



                                 AS Status Ind ---------->
                                 (AS-Inactive)

               <--------------    ASP-Active-Ack
               <--------------    NTFY (AS-Active)

         ASPIA   --------------->
                                  ASP-Status Ind ----------->
                                 (ASP-Inactive)

                                 AS Status Ind ---------->
                                 (AS-Inactive)

               <--------------    ASP-Inactive-Ack
               <--------------    NTFY (AS-Pending)

       TEST DESCRIPTION:

       1. Send ASPDN message from ASP to the SGP.

       2. Check A: ASPDN is acknowledged by ASP-Down-Ack message at the ASP.

       3. Check B: No NTFY message is received at the ASP.

       4. Send ASPUP message to SGP.

       5. Check C: SGP responds with ASP-UP-Ack message and NTFY (AS-
          Inactive).

       6. Send ASPAC message with Interface Identifier parameter present.

       7. Check D: SGP responds with ASP-Active-Ack and NTFY with status AS-
          Active. Repeat the test case with Interface Identifier parameter not
          present in ASPAC message.

       8. Send ASPIA message from ASP to SGP.

       9. Check E: SGP responds with ASP Inactive-Ack and NTFY with status AS-
          Pending.

       10. Check F: NTFY message is received on stream 0.



    Manish Sharma, HSS                                          [Page 47]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         "Notify Message with "Insufficient Resources Active" in AS"

         + TEST NUMBER :4.3.2

         + TITLE :  AS management

         + SUBTITLE : Notify Message with Insufficient Resources Active in AS

         + PURPOSE: To check that if the number of Active ASPs in a Loadshare/
           Broadcast AS goes below the minimum number of required ASPs then a
           NTFY message for Insufficient Resources Active is sent to INACTIVE
           ASPs.

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP1 and ASP2. ASP1 is Active for Interface Identifier X and
           ASP2 is Inactive in SGP. The AS is in Loadshare mode and the
           minimum number of Active ASPs required is two.

         EXPECTED MESSAGE SEQUENCE :

         ASP1              ASP2                   SGP                       SM

                                   ASP1 is Active
                                   ASP2 is Inactive

         ASPIA   ------------------------------->
         (ASP1)
                                             Status Ind ------------------>
                                            (ASP-Inactive)

                  <------------------    ASP-Inactive-Ack(to ASP1)

                          (ASP2)<-----  NTFY (Insufficient Resources)
          (ASP1)<---------------------  NTFY (Insufficient Resources)

       TEST DESCRIPTION:

       1. Send ASPIA message from ASP1 to the SGP with Interface Identifier X.

       2. Check A: ASPIA is acknowledged by ASPIA-Ack message by the SGP to
          ASP1.

       3. Check B: SGP sends a NTFY Message with Insufficient Resources to

    Manish Sharma, HSS                                          [Page 48]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


             ASP2 and ASP1 both of which are in ASP-Inactive State.

       4. Repeat the Test Case when the AS is in Broadcast Mode.


       Note: This NTFY message might not be provisioned by some
       implementations.
         "Notify Message with Alternate ASP Active in AS"

         + TEST NUMBER : 4.3.3

         + TITLE :  AS management

         + SUBTITLE : Notify Message with Alternate ASP Active in AS

         + PURPOSE: To check that if an Alternate ASP of the AS (in Override
           Mode of Traffic Handling) becomes Active then a NTFY message for
           Alternate ASP Active is sent to the previously Active ASP.

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP1 and ASP2. ASP1 is Active for Interface Identifier X and
           ASP2 is Inactive in SGP. The AS is in Override mode.

         EXPECTED MESSAGE SEQUENCE :

         ASP1             ASP2              SGP                   SM

                                   ASP1 is Active
                                   ASP2 is Inactive

                           ASPAC   --------------->
                          (ASP2)
                    (Interface Id = p)
                                             Status Ind ---------->
                                             (ASP-Active)

                           <------------------- ASPAC-Ack(to ASP2)
         (ASP1)<-----------------------------NTY(Alter ASP Active)

       TEST DESCRIPTION:

       1. Send ASPAC with Traffic Mode Type parameter as "Override" message

    Manish Sharma, HSS                                          [Page 49]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

          from ASP2 to the SGP and Interface Identifier P.

       2. Check A: ASPAC is acknowledged by ASPAC-Ack message by the SGP to
          ASP2.

       3. Check A: SGP sends a NTFY Message with Alternate ASP Active to ASP1
          which was previously active in AS.


       Note: This NTFY message might not be provisioned by some
       implementations.






         "Notify Message with ASP Failure in AS"

         + TEST NUMBER : 4.3.4

         + TITLE :  AS management

         + SUBTITLE : Notify Message with ASP Failure in AS

         + PURPOSE: To check that if an ASP of the AS goes down then a NTFY
           message for ASP Failure is sent to all the ASP(s) of the AS.

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP1 and ASP2. ASP1 is Active for Interface Identifier X and
           ASP2 is Inactive in SGP. The AS is in Loadshare mode.

         EXPECTED MESSAGE SEQUENCE :

         ASP1              ASP2                   SGP                       SM

                                    ASP1 is Active
                                    ASP2 is Inactive

                           ASPDN   --------------->
                           (ASP2)
                                             Status Ind ---------------->
                                              (ASP-Down)

                           <--------------      ASP-Down-Ack(to ASP2)
    Manish Sharma, HSS                                          [Page 50]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          (ASP1)<------------------------------ NTFY
                                            (ASP Failure)


       TEST DESCRIPTION:

       1. Send ASPDN message from ASP2 to the SGP.

       2. Check A: ASPDN is acknowledged by ASPDN-Ack message by the SGP to
          ASP2.

       3. Check B: SGP sends a NTFY Message with ASP Failure to ASP1 in AS.

       4. Check C: No Notify message is received at ASP2.

       Note: This NTFY message might not be provisioned by some
       implementations.






         "Timer T(r) Cancellation"

         + TEST NUMBER : 4.3.5

         + TITLE :  AS management

         + SUBTITLE : Timer T(r) Cancellation

         + PURPOSE: To check that after last ASP becomes inactive then SGP
           buffers the messages from NIF for time T(r) and if ASPAC comes
           before its expiry then all buffered messages are sent to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between
           SGP and ASP. ASP is active.  ASPIA and ASPAC messages are sent with
           Interface Identifiers X & Y and value of Traffic Mode Type
           parameter equal to the traffic handling mode configured for AS at
           the SGP. Let the value of Timer T(r) is z sec.

         EXPECTED MESSAGE SEQUENCE :


    Manish Sharma, HSS                                          [Page 51]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         ASP                        SGP                        NIF+SM

                                   ASP is Active

         ASPIA   --------------->
                                Status Ind ---------->
                               (ASP-Inactive)

             <--------------    ASP-Inactive-Ack
             <--------------    NTFY (AS-Pending)

                                 T(r) starts

                                              <-------------- Data
                                              <-------------- Data
                                               (Data will be buffered)

         ASPAC   ---------------> (time < z)

                                Status Ind ---------->
                               (ASP-Active)

             <--------------    ASP-active-Ack
             <--------------    NTFY (AS-Active)

             <----------------- DATA Msg
             <----------------- DATA Msg




       TEST DESCRIPTION:

       1. Send ASPIA Message from ASP to the SGP. ASP will become Inactive at
          the SG. While Timer T(r) is still running send Data Send Primitive
          containing Protocol Data with Interface Identifier X to be sent to
          ASP.

       2. Check A: DATA message will not be received at ASP.

       3. Send ASPAC message before Timer T(r) expires.

       4. Check B: DATA messages buffered at the SG will be received at ASP.

       5. Repeat the above test case using Test Configuration C where

    Manish Sharma, HSS                                          [Page 52]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



          initially ASP1 will be active and ASP2 will be inactive. Send ASPIA
          message from ASP1 and then send DATA send primitive from NIF to M2UA
          at SGP and Check that no DATA message is received at any of the
          ASPs. Send ASPAC message from ASP2 and check that the buffered DATA
          messages are received at ASP2 and not ASP1.

       Note: This case is implementation specific. In some implementations
       there may not be any Timer T(r) running.
       In that case there is no need to run this test case.



         "Timer T(r) Expiry"

         + TEST NUMBER :4.3.6

         + TITLE :  AS management

         + SUBTITLE : Timer T(r) Expiry

         + PURPOSE: To check that AS-State changes after timer T(r) expires.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is active. Let the value of Timer T(r) is z sec.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                  ASP is Active

         ASPDN   --------------->
                                 Status Ind ---------------->
                                (ASP-Down)

              <--------------    ASP-Down-Ack
              <--------------    NTFY (AS-Pending)

                                   T(r) starts

                                               <-------------- Data

    Manish Sharma, HSS                                          [Page 53]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                                               <-------------- Data
                                                (Data will be buffered)

                             (time = z) T(r) expires

                                                (Data will be discarded)

                        <---------------    NTFY (AS-Down)

                                               <-------------- Data
                                 Send Failure ---------->

       TEST DESCRIPTION:

       1. Send ASPDN Message from ASP to the SGP. The state of AS will become
          AS-Pending at the SG. Send Data Send Primitive containing Protocol
          Data from NIF to be sent to the ASP and Wait for z sec.

       2. Check A: DATA message will not be received at ASP.

       3. Check B: DATA messages buffered at the SG will be discarded.

       4. Send Data Send primitives from NIF to M2UA at SGP with Interface
          Identifier X.

       5. Check C: A failure message will be sent to the NIF.


       Note: This case is implementation specific. In some implementations
       there may not be any Timer T(r) running.
       In that case there is no need to run this test case.




         "Notify Message is sent only for AS State change - A"

         + TEST NUMBER : 4.3.7

         + TITLE :  AS management

         + SUBTITLE : Notify Message with AS Status is sent only for AS State
                      change

         + PURPOSE: To check that NTFY message is not sent if there is no
                    change in the state of the AS.
    Manish Sharma, HSS                                          [Page 54]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 and both are active. Traffic Mode Type parameter in ASPAC and
           ASPIA message should be same as the traffic handling mode
           configured For AS at SGP. Interface Identifier parameter should be
           having values X and Y.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                ASP1,ASP2 are active

         ASPIA(ASP2)--------------------->
                                    Status Ind ---------->
                                (ASP-Inactive)

            <---------------    ASPIA-Ack(to ASP2)

         ASPDN(ASP2)------------>
                                  Status Ind ---------->
                                (ASP-Down)

           <---------------    ASPDN-Ack(to ASP2)

         ASPUP(ASP2)------------>
                                 Status Ind ---------->
                                (ASP-Up)

           <---------------    ASPUP-Ack(to ASP2)

         ASPAC(ASP2)------------>
                                 Status Ind ---------->
                                (ASP-Active)

           <---------------    ASPAC-Ack(to ASP2)


       TEST DESCRIPTION:

       1. Send ASPIA message for ASP2 from ASP to the SGP.


    Manish Sharma, HSS                                          [Page 55]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       2. Check A: ASP-Inactive Ack will be received at the ASP and NTFY
          message with status AS-Inactive is not received as AS is now Active.

       3. Repeat the above test case for other messages like ASPAC, ASPUP and
          ASPDN for ASP2 from ASP to SGP. NTFY message with AS status should
          not be received in any case.







         "Notify Message is sent only for AS State change- B"

         + TEST NUMBER :4.3.8

         + TITLE :  AS management

         + SUBTITLE : Notify Message with AS Status is sent only for AS State
                      change

         + PURPOSE: To check that NTFY message is sent when there is change in
                    the state of the AS.

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 and both are active. Traffic Mode Type parameter in ASPAC and
           ASPIA message should be same as the traffic handling mode
           configured for AS at SGP. Interface Identifier parameter should be
           having values X and Y.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                               ASP1, ASP2 are active

         ASPIA (ASP1)---------------->
                                  Status Ind ---------->
                                 (ASP-Inactive)

                 <--------------  ASPIA-Ack(to ASP1)

         ASPIA (ASP2)------------>
                                  Status Ind ---------->
    Manish Sharma, HSS                                          [Page 56]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                 (ASP-Inactive)

                 <--------------- ASPIA-Ack(to ASP2)

                 <--------------- NTFY(AS-Pending) (to ASP1 and ASP2)

                         Timer T(r) expires

                 <--------------- NTFY(AS-Inactive) (to ASP1 and ASP2)

         ASPDN (ASP1)------------>
                                  Status Ind ---------->
                                (ASP-Down)

                <------------    ASPDN-Ack(to ASP1)



         ASPDN (ASP2)------------>
                                 Status Ind ---------->
                                (ASP-Down)

                                AS state Ind --------->
                                (AS-Down)

              <-------------     ASPDN-Ack(to ASP2)

         ASPUP (ASP1)------------>
                                 Status Ind ---------->
                               (ASP-Up)

              <---------------   ASPUP-Ack(to ASP1)
              <---------------   NTFY(AS-Inactive) (to ASP1)

         ASPAC (ASP1)------------>
                                 Status Ind ---------->
                                (ASP-Active)

             <---------------    ASPAC-Ack(to ASP1)
             <---------------    NTFY(AS-Active) (to ASP1)

       TEST DESCRIPTION:

       1. Send ASPIA message for ASP1 from ASP to the SGP with Interface

    Manish Sharma, HSS                                          [Page 57]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

          Identifier X and Y and Traffic Mode Type parameter equal to the
          Traffic Handling Mode configured for the AS.

       2. Check A: NTFY message not sent to ASPs (ASP1 and ASP2), but
          ASP-Inactive-Ack message is received at the ASP1.

       3. Send ASPIA message for ASP2 from ASP to the SGP with Interface
          Identifier X and Y and Traffic Mode Type parameter as in the ASP1
          case.

       4. Check B: ASP-Inactive-Ack and NTFY message with status AS-Pending
          and after Timer T(r) expiry AS-Inactive is received at the ASPs.

       5. Repeat the above test case for other messages like ASPDN, ASPUP and
          ASPAC for ASP1 and ASP2 from ASP to SGP.


       Note 1: A NTFY message should be sent to both ASP1 and ASP2 if they are
       not in the ASP-Down state.

       Note 2: When the AS transitions to the AS down state, all the SS7 link
       (Interface Identifier) for this AS should be taken out of service.




       4.3.2 ERROR Messages

         "Error - Invalid Version"

         + TEST NUMBER :4.3.9

         + TITLE :  Invalid Message Handling

         + SUBTITLE : Invalid Version Error

         + PURPOSE: To check that if any message with Invalid version is
           received at the SGP then SGP responds with ERROR message containing
           Cause "Invalid Version" and diagnostic information filled with the
           version the SGP supports.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

    Manish Sharma, HSS                                          [Page 58]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                       SM + NIF

                                  ASP is Active

         ASPIA   ---------------->
        (Version = 2.0)

                  <---------------    ERROR
                             (Cause = Invalid Version)

       TEST DESCRIPTION:

       1. Send ASPIA message from ASP to SGP containing version 2.0 in the
          Common Message Header.

       2. Check A: ERROR message is received at the ASP containing cause
          Invalid Version.

       3. Check B: Diagnostic Field Parameter in ERROR is filled with
          version 1.0 .

       4. Repeat the above test cases for other messages from ASP to SGP like
          ASPAC, ASPUP, ASPDN, RETRIEVAL REQUEST, ESTABLISH REQUEST,
          RELEASE REQUEST, STATE REQUEST  and DATA. In all these cases,
          ERROR message will be received with the same cause.


       Note: The Diagnostic information in the ERROR messages is an optional
       parameter which contains information germane to error condition. In
       case it is not included the Check in Line 3 above is not applicable.



         "Error - Unsupported Message Class"

         + TEST NUMBER :4.3.10

         + TITLE : Unsupported Message Handling

         + SUBTITLE : Unsupported Message Class Error

         + PURPOSE: To check that if a message with Message Class not defined

    Manish Sharma, HSS                                          [Page 59]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

           is received at SGP, SGP responds with ERROR message containing
           cause "Unsupported Message Class".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                     SM + NIF

                                   ASP is Active

         Message ---------------->
         (Message Class = 1)

                  <---------------    ERROR
                      (Cause = Unsupported Message Class)

         DATA Msg ---------------->
         (Interface Id = X)
                                 Data Receive Ind ------->

       TEST DESCRIPTION:

       1. Send a message with message Class 1 or any other value which is not
          defined from ASP to SGP and other valid parameters.

       2. Check A: ERROR message will be received at the ASP containing Cause
          "Unsupported Message Class".

       3. Check B: State of ASP at SGP is not disturbed.

       4. Send DATA message from ASP to SGP with Interface Identifier = X and
          other required parameters with valid values including Message Class.

       5. Check C: A DATA Receive Indication is sent to NIF by M2UA at SGP.









    Manish Sharma, HSS                                          [Page 60]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         "Error - Unsupported Message Type"

         + TEST NUMBER :4.3.11

         + TITLE : Unsupported Message Handling

         + SUBTITLE : Unsupported Message Type Error

         + PURPOSE: To check that if a message with Message Type not defined
           is received at SGP, SGP responds with ERROR message containing
           cause "Unsupported Message Type".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                           SM + NIF

                                   ASP is Active

         Message ---------------->
         (Message Type = 708)

                  <---------------    ERROR
                         (Cause = Unsupported Message Type)

         DATA Msg ---------------->
         (Interface Id = X)
                                Data receive Ind ------->

       TEST DESCRIPTION:

       1. Send a message with message type 708 or any other value which is
          not defined from ASP to SGP and other valid parameters.

       2. Check A: ERROR message is received at the ASP containing cause
          Unsupported Message Type.

       3. Check B: State of ASP at SGP is not disturbed.


    Manish Sharma, HSS                                          [Page 61]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       4. Send DATA message from ASP to SGP with Interface Identifier = X and
          other required parameters with valid values.

       5. Check C: A DATA Receive Indication is sent to NIF by M2UA at SGP.

       6. Repeat the above test cases by sending ESTABLISH CONFIRMATION,


          RELEASE CONFIRMATION, RELEASE INDICATION, STATE CONFIRM,
          STATE INDICATION, RETRIEVAL CONFIRM and RETRIEVAL INDICATION ,
          REG-RESP messages from ASP which the SGP is not expected to receive.
          In this case Error will be reported to the SM and Message will be
          discarded.



         "Error - Invalid Interface Identifier "

         + TEST NUMBER : 4.3.12

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid Interface Identifier in MAUP messages

         + PURPOSE: To check that if a message with invalid Interface
           Identifier i.e. Interface Identifier not defined at SGP is received
           then SGP responds with ERROR message containing cause
           "Invalid Interface Identifier".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                        SM + NIF

                                 ASP is Active

         DATA    ---------------->
         (Interface Id = P)

                  <---------------    ERROR
                         (Cause = Invalid Interface Identifier)

    Manish Sharma, HSS                                          [Page 62]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         DATA    ---------------->
         (Interface Id = X)

                                Data receive Ind ------->

       TEST DESCRIPTION:

       1. Send DATA message with Interface Identifier P that is not defined at
          SGP.

       2. Check A: ERROR message will be received at ASP containing cause
          "Invalid Interface Identifier".

       3. Check B: State of ASP at SGP is not disturbed.

       4. Send DATA message from ASP to SGP with Interface Identifier = X and
          other required parameters with valid values.

       5. Check C: A DATA Receive Indication is sent to NIF

       6. Repeat the above test case for test configuration D. DATA message is
          sent from ASP1 with Interface Identifier P that is defined at SGP
          for ASP2. In this case also ERROR message should be received at ASP
          with cause "Invalid Interface Identifier".

       7. Repeat the above test case for other messages like RELEASE REQUEST,
          ESTABLISH REQUEST, STATE REQUEST, RETRIEVAL REQUEST, NTFY and ERROR.
          Other parameters in these messages should be having valid values.
          Response will be same in all cases.



         "Error - Invalid Interface Identifier"

         + TEST NUMBER :4.3.13

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid Interface Identifier parameter in ASPTM messages

         + PURPOSE: To check that if ASPAC message with Invalid Interface
           Identifier parameter is received then ASPAC message is discarded.

         + TEST CONFIGURATION: A

    Manish Sharma, HSS                                          [Page 63]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP and AS is in AS-Inactive state i.e. ASP is INACTIVE.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                        SM + NIF

                                   ASP is Inactive

         ASPAC    ---------------->
         (Interface Id = P)

                  <---------------    ERROR
                        (Cause = Invalid Interface Identifier)

         ASPAC    ---------------->
         (Interface Id =X,Q)
                                   Status Ind ------->
                                 (ASP-Active)

                 <---------------    ASPAC-Ack
                 <---------------    NTFY(AS-ACTIVE)
                            (Interface Identifier = X)

                 <---------------    ERROR
                         (Cause = Invalid Interface Identifier)

       TEST DESCRIPTION:

       1. Send ASPAC message with Interface Identifier P or any Interface
          Identifier other than X and Y.

       2. Check A: SGP will take no action and will discard the ASPAC message.

       3. Check B: An Error message with Cause = Invalid Interface Identifier
          is send to ASP.

       4. Send ASPAC message with Interface Identifier X and Q.

       5. Check C: An ASP-Active-Ack and a NTFY messages will be received at
          the ASP with status AS-Active for Interface Identifier X.

       6. Check D: An ERROR message with Cause "Invalid Interface Identifier"
          is sent to ASP for Interface Identifier Q.

    Manish Sharma, HSS                                          [Page 64]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       7. Repeat the above test case with ASPIA message in ASP Active state.
          Response should be same.


       Note: Interface Identifier is an optional parameter in ASPAC message.
       In some implementations this field may not come in ASPAC and ASPIA
       message. In those implementations this test case is not applicable.






         "Error - Parameter Field Error"


         + TEST NUMBER :4.3.14

         + TITLE : Invalid Message Handling

         + SUBTITLE : Wrong Length Field of a Parameter in the Common Message
                      Header.

         + PURPOSE: To check that if an MAUP or MGMT message with wrong length
           field of a Parameter in Common Message Header or M2UA Header is
           sent to SGP then SGP responds with Error message with Cause
           "Parameter Field Error".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP, ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                         SM + NIF

                                  ASP is Active

         RELEASE REQUEST ---------------->
         (Length in M2UA header = 7)

                                Message is discarded.

                 <---------------    ERROR

    Manish Sharma, HSS                                          [Page 65]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                         (Cause = Parameter Field Error)

         DATA Msg    ---------------->
         (Interface Id = X)
                                 Data receive Ind ------->

       TEST DESCRIPTION:

       1. Send RELEASE REQUEST message with length in Interface ID Parameter
          in M2UA Header less than 8 from ASP to the SGP.

       2. Check A: RELEASE REQUEST message will be discarded and ERROR message
          with Cause "Parameter Field Error" will be sent to the ASP.

       3. Check B: State of ASP at SGP is not disturbed.

       4. Send DATA message from ASP to SGP with Interface Identifier = X and
          other required parameters with valid values including the Length
          Field.

       5. Check C: A Data Receive Indication is sent to NIF.

       6. Repeat the above test case for other messages like STATE REQUEST,
          RETRIEVAL REQUEST which include Parameters in the Common Message
          Header or M2UA Header.






         "Error - Unsupported Traffic Handling Mode - A"

         + TEST NUMBER : 4.3.15

         + TITLE : Unsupported Message Handling

         + SUBTITLE : Unsupported Traffic Handling Mode Error

         + PURPOSE: To check that if ASPAC or ASPIA message is received with
           Traffic Mode Type parameter incompatible with the Traffic Handling
           Mode currently used in AS at SGP, SGP responds with ERROR message
           containing cause "Unsupported Traffic Handling Mode".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
    Manish Sharma, HSS                                          [Page 66]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


           and ASP. ASP is INACTIVE. Traffic Handling Mode defined at SGP for
           AS is Override.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                         SM + NIF

                                   ASP is Inactive

         ASPAC   ---------------->
         (Traffic Mode Type = Loadshare)

                   <---------------    ERROR
                        (Cause = Unsupported traffic Handling Mode)

       TEST DESCRIPTION:

       1. Send ASPAC message from ASP to SGP containing Traffic Mode Type
          field Loadshare. Fill value X and Y in Interface Identifier
          parameter and other fields will be having valid values.

       2. Check A: ERROR message is received at the ASP containing cause
          "Unsupported Traffic Handling Mode".

       3. Repeat the above test cases for other values of Traffic Mode Type
          field with Traffic Handling Mode for AS at SGP being different from
          this Type field.

       4. Repeat the test case with Traffic Mode Type field having value that
          is not defined i.e. any value greater than 0x3. The Response will be
          the same.

       5. Repeat all the above tests for ASPIA message.


         "Error - Unsupported Traffic Handling Mode - B"

         + TEST NUMBER : 4.3.17

         + TITLE : Unsupported Message Handling

         + SUBTITLE : Unsupported Traffic Handling Mode Error if there are two
                      ASPs in one AS.


    Manish Sharma, HSS                                          [Page 67]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         + PURPOSE: To check that if ASPAC or ASPIA message is received with
           Traffic Mode Type parameter incompatible with the traffic handling
           mode currently used in AS at SGP, SGP responds with ERROR message
           containing cause "Unsupported Traffic Handling Mode".

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and both ASPs and both ASP1 and ASP2 are INACTIVE. Traffic Handling
           Mode defined at SGP for AS is Override Mode.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                        SM + NIF

                                  ASP is Inactive
                         (ASP1 and ASP2 are Inactive)

         ASPAC (ASP1) ---------------->
         (Traffic Mode Type = Override)

                                     Status Ind ------->
                                   (ASP-Active)

                <---------------  ASP-Active-Ack(to ASP1)

         ASPAC (ASP2)---------------->
         (Traffic Mode Type = Override)

                 <---------------    ERROR
                  (Cause = Unsupported traffic Handling Mode)

       TEST DESCRIPTION:

       1. Send ASPAC message from ASP1 to SGP containing Traffic Mode Type
          field Override. Fill value X and Y in Interface Identifier parameter
          and other fields will be having valid values.

       2. Check A: ASP-Active-Ack message is received at the ASP.


       3. Send ASPAC message from ASP2 to SGP containing Traffic Mode Type
          field Loadshare. Fill value X and Y in Interface Identifier
          parameter and other fields will be having valid values.

       4. Check B: ERROR message is received at the ASP containing cause
    Manish Sharma, HSS                                          [Page 68]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          Invalid Traffic Handling Mode.

       5. Repeat the above test cases for other values of Traffic Mode Type
          field with Traffic Handling Mode for AS at SGP being different from
          this Type.

       6. Repeat the test case with Type field having value that is not
          defined i.e. any value greater than 0x3.

       7. Repeat all the above tests for ASPIA message.




         "Error - Unsupported Interface Identifier Type"

         + TEST NUMBER : 4.3.16

         + TITLE : Unsupported Interface Identifier parameter Type

         + SUBTITLE : Unsupported Interface Identifier parameter in MAUP
                      message

         + PURPOSE: To check that if a message with unsupported Interface
           Identifier i.e. Interface Identifier not supported at SGP is
           received then SGP responds with ERROR message containing cause
           "Unsupported Interface Identifier".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. Only Integer based Interface Identifiers
           are supported at SGP.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                        SM + NIF

                                  ASP is Active

         DATA Msg   ---------------->
         (Text Interface Id = X)

                  <---------------    ERROR

    Manish Sharma, HSS                                          [Page 69]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

               (Cause = Unsupported Interface Identifier Type)

         DATA Msg  ---------------->
         (Integer Interface Id = X)

                                Data Receive Ind ------->

       TEST DESCRIPTION:

       1. Send DATA message with Text based Interface Identifier X that is not
          supported at SG.

       2. Check A: ERROR message will be received at ASP containing cause
          "Unsupported Interface Identifier Type".

       3. Check B: State of ASP at SGP is not disturbed.

       4. Now send Protocol Data with Integer based Interface Identifier X
          from ASP to SGP.

       5. Check C: No ERROR message will be received at ASP.

       6. Check D: A Data Receive Indication is received at NIF.

       7. Repeat the above test case for other messages like RELEASE REQUEST,
          ESTABLISH REQUEST, STATE REQUEST, RETRIEVAL REQUEST, NTFY and ERROR.
          Other parameters in these messages should be having valid values.
          Response will be same in all cases.




         "Error - Unexpected Message"

         + TEST NUMBER : 4.3.17

         + TITLE :  Invalid Message Handling

         + SUBTITLE : DATA message from ASP in ASP-Inactive state

         + PURPOSE: To check that if DATA message is received at SGP from an
           ASP which is in state ASP-Inactive at SGP then it is discarded and
           an ERROR message is sent to peer.

         + TEST CONFIGURATION: A

    Manish Sharma, HSS                                          [Page 70]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Inactive.

         EXPECTED MESSAGE SEQUENCE :

         ASP                          SGP                           NIF+SM

                                 ASP is Inactive

         DATA Msg --------------->
         (Interface Id = X)

                        <----------- Error
                          (Cause = Unexpected Message)
         ASPAC ------------->

                                  Status Ind  --------------->
                                (ASP-Active)

                     <----------- ASPAC-Ack
                     <----------- NTFY(AS-Active)

       TEST DESCRIPTION:

       1. Send DATA message from ASP to SGP while ASP is in ASP-Inactive state
          at SGP.

       2. Check A: DATA message should be discarded and no message will be
          received at the NIF in response to DATA message.

       3. Check B: An ERROR message with Cause "Unexpected Message" is
          received at ASP.

       4. Check C: State of ASP at SGP is not disturbed. Send ASPAC message
          and SGP will respond with ASPAC Ack and NTFY (AS-Active).

       Note: Any DATA message in case of ASP-Down state MAY be silently
       discarded. In that case Line 4 of the above Test Case will not be
       applicable.







    Manish Sharma, HSS                                          [Page 71]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         "Error - Invalid Stream Identifier"

         + TEST NUMBER : 4.3.18

         + TITLE :    Invalid Stream Identifier

         + SUBTITLE : Invalid Stream Identifier

         + PURPOSE: To check that if Management message is sent on an SCTP
           Stream other than 0 an error message is sent to the peer.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in Inactive state.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                           SM + NIF

                                   ASP is Inactive

         ASPDN    ---------------->
         (SCTP Stream other than 0)

                                  Message discarded

                 <---------------    ERROR
                       (Cause = Invalid Stream Identifier)

         ASPAC    ---------------->
         (Interface Id = X)
                                   Status Ind ------->
                                  (ASP-Active)

               <---------------    ASPAC-Ack
               <---------------    NTFY(AS-ACTIVE)

       TEST DESCRIPTION:

       1. Send ASPDN Message from ASP to the SGP on an SCTP stream other than
          0.

       2. Check A: An error message with reason as "Invalid Stream Identifier"
    Manish Sharma, HSS                                          [Page 72]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          is received at ASP.

       3. Check B: State of ASP at SGP is not disturbed.

       4. Now send the ASPAC with Interface Identifier X.

       5. Check C: ASP state changes to ACTIVE in SGP.

       6. Check D: An ASPAC Ack is received at ASP.

       7. Check E: A NTFY message with Status AS-Active is received at ASP.

       8. Repeat the above Test for other ASPM messages (example- ASPUP,
          ASPAC).




         "Error - Invalid parameter value"

         + TEST NUMBER : 4.3.19

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid State Parameter in STATE REQUEST message

         + PURPOSE: To check that if STATE REQUEST message is received with
           invalid value of State parameter then SGP will send an ERROR
           message to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                            NIF

                                   AS is Active

         STATE REQUEST    ---------------->
         (State = 0xb)
                                 Message Discarded

    Manish Sharma, HSS                                          [Page 73]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                   <---------------    Error
                           (Cause = Invalid parameter value)

         DATA Msg   ---------------->
         (Interface Id = X)
                               Data receive Ind  --------->

       TEST DESCRIPTION:

       1. Send STATE REQUEST message with state value 0xb, which is invalid,
          to the SGP.

       2. Check A: STATE REQUEST message will be discarded and an Error
          message will be received at ASP.

       3. Check B: State of ASP at SGP is not disturbed.

       4. Send DATA message with Interface Identifier = X and all other valid
          values from ASP to SGP.

       5. Check C: A DATA Receive Indication is received at NIF.


         "Error - Invalid parameter value"

         + TEST NUMBER : 4.3.20

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid Action Parameter in RETRIEVAL REQUEST message

         + PURPOSE: To check that if RETRIEVAL REQUEST message is received
           with invalid value of Action parameter then SGP will send ERROR
           message to ASP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                         NIF

                                   ASP is Active
    Manish Sharma, HSS                                          [Page 74]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         RETRIEVAL REQUEST    ---------------->
         (Action = 0x4)

                                 Message Discarded

                    <---------------  Error
                           (Cause = Invalid parameter value)

         DATA Msg  ---------------->
         (Interface Id = X)
                                  Data Receive Ind   --------->

       TEST DESCRIPTION:

       1. Send RETRIEVAL REQUEST message with Action parameter value 0x4,
          which is invalid, and a valid Sequence Number to the SGP.

       2. Check A: RETRIEVAL REQUEST message will be discarded and an Error
          message will be received at the ASP containing cause "Invalid
          Parameter Value".

       3. Check B: State of ASP at SGP is not disturbed.

       4. Send DATA message with Interface Identifier = X and other required
          parameters with valid values from ASP to SGP.

       5. Check C: A DATA Receive Indication is sent to NIF.

       6. Repeat the above test case for invalid value of Sequence Number
          field like -2 etc. Response should be same.


       Note: The Sequence Number parameter is optional, if it is not used Line
       6 of the above Test case is not applicable.











    Manish Sharma, HSS                                          [Page 75]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         "Error - Protocol Error"

         + TEST NUMBER : 4.3.21

         + TITLE : Invalid Message Handling

         + SUBTITLE : Handling of Bogus messages.

         + PURPOSE: To check that if a message with no significance for SGP is
           received at SGP it is discarded and an ERROR message is sent with
           Cause "Protocol Error".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                             NIF

                                  ASP is Active

         NTFY    ---------------->
         (AS-Active)

                  <---------------    Error
                             (Cause = Protocol Error)

         DATA Msg---------------->
         (Interface Id = X)
                                Data Receive Ind   --------->

       TEST DESCRIPTION:

       1. Send NTFY message with Status as AS-active from ASP to SGP.

       2. Check A: SGP will send an Error message with Cause "Protocol Error".
          The NTFY message will be discarded.

       3. Check B: State of ASP at SGP is not disturbed.

       4. Send DATA message with Interface Identifier = X and other required
          parameters with valid values from ASP to SGP.

    Manish Sharma, HSS                                          [Page 76]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       5. Check C: A DATA Receive indication is sent to the NIF.

       6. Repeat the above test for other messages which are only meant to be
          sent from SGP and not to be received (example- ASPAC-Ack, ASPIA-
          Ack).



         "Error - Refused - Management Blocking"

         + TEST NUMBER : 4.3.22

         + TITLE : Refused - Management Blocking

         + SUBTITLE : Refused - Management Blocking

         + PURPOSE: To check that if  ASPUP or ASPAC messages are received at
           SGP and Management is Locked out an ERROR message is sent to the
           requesting ASP with Cause "Refused-Management Blocking".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in ASP-Down state and is "blocked" at SGP.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                            SM + NIF

                                   ASP is Down

         ASPUP     ---------------->

                   <---------------    Error
                        (Cause = Refused - Management Blocking)

         ASPAC     ---------------->

                   <---------------    Error
                         (Cause = Refused - Management Blocking)


       TEST DESCRIPTION:


    Manish Sharma, HSS                                          [Page 77]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       1. Send ASPUP message from ASP to SGP.

       2. Check A: Error should be sent from SGP with Cause
          "Refused - Management Blocking" to ASP.

       3. Check B: The state of ASP at SGP is not disturbed.

       4. Send ASPAC message from ASP to SGP.

       5. Check A: Error should be sent from SGP with Cause
          "Refused - Management Blocking" to ASP.

       6. Check B: The state of ASP at SGP is not disturbed.




         "ERROR Message Handling"

         + TEST NUMBER : 4.3.23

         + TITLE : ERROR Handling

         + SUBTITLE : Handling of Received Error

         + PURPOSE: To check that if an ERROR message is received then that is
           reported to the SM and no ERROR message is sent to peer which sent
           the ERROR message in the first place.

         + TEST CONFIGURATION:   A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                            SM + NIF

                                   ASP is Active

         ERROR       ---------------->
         (Cause = Invalid version)
                                    Error Ind   --------->

       TEST DESCRIPTION:

    Manish Sharma, HSS                                          [Page 78]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       1. Send ERROR message with Cause "Invalid Version" from ASP to SGP.

       2. Check A: Error should be reported to the SM.

       3. Check B: No ERROR message must be received at the ASP.

       4. Repeat the test case for other Cause values in ERROR message.


       Note: Further action at the SGP are implementation dependent and ERROR-
       Code dependent.
       SM may tear down the connection or no action may be taken.






         "Error - Unexpected Parameter"

         + TEST NUMBER :4.3.24

         + TITLE : Invalid Message Handling

         + SUBTITLE : Unexpected parameter in MAUP messages.

         + PURPOSE: To check that if a message containing an Invalid Parameter
           is received at SGP then the SGP responds with an ERROR message
           containing cause "Unexpected Parameter".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP, and ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                           SM + NIF

                                  ASP is Active

         DATA Msg ---------------->
         (Parameter Tag = 0x13
             in place of 0x2 )


    Manish Sharma, HSS                                          [Page 79]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                     <--------------- ERROR
                   (Cause = Unexpected Parameter)

         DATA Msg ---------------->
         (Interface Id = X)
                                  DATA Receive Ind --------->

       TEST DESCRIPTION:

       1. Send DATA message with a parameter other than Interface Identifier
          from ASP to the SGP.

       2. Check A: ERROR message will be received at ASP containing cause
          "Unexpected Parameter".

       3. Check B: State of ASP at SGP is not disturbed.

       4. Send a DATA Message from ASP with valid parameters including
          Interface Identifier = X.

       5. Check C: A DATA Receive Indication is sent to NIF.
       6. Repeat the above test case for other MAUP and ASPM messages.



         "Error - ASP Identifier Required"

         + TEST NUMBER :4.3.25

         + TITLE : Invalid Message Handling

         + SUBTITLE : Absence of ASP Identifier in ASPUP message when
           required.

         + PURPOSE: To check that if an ASPUP message is received at the SGP
           without any ASP identifier and SGP cannot identify the ASP by pre-
           configured address/port number information, SGP send an ERROR
           message to the ASPUP message sending ASP with Cause "ASP Identifier
           Required".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP, and ASP is Down. The Address/Port number information for
           the ASP is not configured at the SGP.

    Manish Sharma, HSS                                          [Page 80]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                          SM + NIF

                                    ASP is Down

         ASPUP ---------------->
         (No ASP ID)

                     <--------------- ERROR
                   (Cause = ASP Identifer Required)

       TEST DESCRIPTION:

       1. Send ASPUP message without ASP Identifier from ASP to SGP.

       2. Check A: ERROR message will be received at ASP containing cause
          "ASP Identifier Required".







         "Error - Invalid ASP Identifier"

         + TEST NUMBER :4.3.26

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid ASP Identifier in ASPUP message.

         + PURPOSE: To check that if an ASPUP message is received at the SGP
           with a non-unique ASP identifier, SGP sends an ERROR message
           to the ASPUP message sending ASP with Cause "Invalid ASP
           Identifier".

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and both ASPs (i.e. ASP1 and ASP2). ASP1 is in ASP-Inactive state
           and the ASP-Identifier for ASP1 is 'T'. ASP2 is in ASP-Down State.

         EXPECTED MESSAGE SEQUENCE :

    Manish Sharma, HSS                                          [Page 81]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         ASP2                           SGP                           SM + NIF

                                  ASP1 is Inactive
                                  ASP2 is Down

         ASPUP (ASP2)---------------->
         (ASP ID = 'T')

                     <--------------- ERROR (to ASP2)
                      (Cause = Invalid ASP Identifier)


       TEST DESCRIPTION:

       1. Send ASPUP message with ASP Identifier 'T' from ASP2 to SGP.

       2. Check A: ERROR message will be received at ASP2 containing cause
          "Invalid ASP Identifier". The ASPUP message is discarded.

       3. Check B: No ERROR message is received at ASP1.








         "Error - Missing Parameter"

         + TEST NUMBER :4.3.27

         + TITLE : Invalid Message Handling

         + SUBTITLE : Missing Mandatory Parameter

         + PURPOSE: To check that if a message is received at the SGP
           not containing a Mandatory Parameters, SGP responds with an ERROR
           message to the message sending ASP with Cause "Missing Parameter".

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP, and ASP is Active.

         EXPECTED MESSAGE SEQUENCE :
    Manish Sharma, HSS                                          [Page 82]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         ASP                           SGP                           SM + NIF

                                      ASP is Active

         DATA Msg ---------------->
         (No Interface Id)

                     <--------------- ERROR
                      (Cause = Missing Parameter)

         DATA Msg ---------------->
         (Interface Id = X)
                                  DATA Receive Ind ---------->

       TEST DESCRIPTION:

       1. Send DATA message without any Interface Identifier in the M2UA
          Header from ASP to SGP which is a mandatory parameter for MAUP
          messages like the DATA message.

       2. Check A: ERROR message will be received at ASP containing cause
          "Missing Parameter".

       3. Check B: State of the ASP at SGP is not disturbed.

       4. Send a DATA Msg from ASP to SGP with valid parameters including
          Interface Identifier = X.

       5. Check C: A DATA Receive Indication is sent to SM.

       6. Repeat the above Test case for other MAUP and ASPM messages
          containing Mandatory Parameters.




       4.4 MAUP Messages

         4.4.1 Link Management Messages

         "Link Management"

         + TEST NUMBER :4.4.1

    Manish Sharma, HSS                                          [Page 83]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + TITLE :  Link Management

         + SUBTITLE : Link Establish and Release Request

         + PURPOSE: To check that if Establish Request is received from
           ASP then NIF is indicated that establish request has been received.
           Also a corresponding indication is sent to NIF in case a Release
           Request is received.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.


          EXPECTED MESSAGE SEQUENCE :

          ASP                               SGP                        NIF+SM

                                         ASP is Active

          ESTABLISH REQUEST ------------>
                                     Establish Request Ind ---------->

          RELEASE REQUEST -------------->
                                     Release  Request Ind------------>


       TEST DESCRIPTION:

       1. Send ESTABLISH REQUEST message from ASP to the SGP with Interface
          Identifier X and Y.

       2. Check A: Establish Request indication should be received at the NIF.

       3. Repeat the above test case for RELEASE REQUEST message from ASP to
          SG. Release Request indication should be sent to the NIF.

       4. When ASP sends an Establish Request message, it starts a timer. This
          Timer is stopped after receiving Establish Confirm message from the
          other side.

          Repeat the above test case arranging the data such that the Timer at
          ASP expires and ASP resends the Establish Request message and
          restart the Timer.
    Manish Sharma, HSS                                          [Page 84]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003




       Note: The NIF maps the Establish Request Indication and the Release
       Request Indication that reach the NIF to Start Req and Stop Req
       Primitives respectively which are sent to the MTP2 at the SG side.








         "Link Management"

         + TEST NUMBER :4.4.2

         + TITLE :  Link Management

         + SUBTITLE : Establish and Release Confirmation and Indication
           Primitive from NIF

         + PURPOSE: To check that if Establish and Release Confirm Primitive
           is sent from NIF to M2UA at SGP then SGP sends ESTABLISH
           CONFIRMATION and RELEASE CONFIRMATION message to the concerned ASP.
           If Release Indication primitive is received from NIF then RELEASE
           INDICATION is sent from SGP to ASP.

         + TEST CONFIGURATION: D

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 in AS1 and AS2 respectively. Both ASPs are Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                             SGP                        NIF+SM

                                   ASP1, ASP2 are Active

                                                 <------Establish Confirmation
                                                           (Interface Id = X)

           (ASP1)<-----------------ESTABLISH CONFIRMATION

                                                 <------Release Confirmation

    Manish Sharma, HSS                                          [Page 85]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                                                           (Interface Id = X)

           (ASP1)<-----------------RELEASE CONFIRMATION


                                                 <------Release Indication
                                                          (Interface Id = X)
           (ASP1)<-----------------RELEASE INDICATION



       TEST DESCRIPTION:

       1. Send Establish Confirmation Primitive from NIF to M2UA at SGP with
          Interface Identifier = X.

       2. Check A: ESTABLISH CONFIRMATION message will be received at ASP1
          containing the Interface Identifier passed to it from NIF.

       3. Check B: ESTABLISH CONFIRMATION message is received only at ASP1 and
          not at ASP2.

       4. Repeat the above test case for Release Confirmation Primitive and
          Release Indication Primitive. In these cases RELEASE CONFIRAMTION
          and RELEASE INDICATION messages will be received at ASP1 and not at
          ASP2.

       5. Repeat the above test case with Interface Identifier P.
          In this case message will be received at ASP2 and not at ASP1.


       Note: Here the NIF maps the "In Serv" Indication and "Out of Serv"
       Indication sent by the MTP2 at the SG side to Estsblish Confirm and
       Release Confirm Primitive respectively sent to the M2UA layer of the
       SGP. Again, the NIF maps "Out of Serv" primitive  to Release Indication
       which is then sent to M2UA at SGP.











    Manish Sharma, HSS                                          [Page 86]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         "State Request"

         + TEST NUMBER : 4.4.3

         + TITLE :  STATE Request primitive

         + SUBTITLE : STATE Request primitive

         + PURPOSE: To check that if State request message is received from
           ASP then NIF is sent State Request primitive.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                             SGP                        NIF+SM

                                     ASP is Active

         STATE REQUEST ------------>
         (State = Status_LPO_Set)
                                     State Request  --------------->

         TEST DESCRIPTION:

         1. Send STATE REQUEST message from ASP to SGP with state parameter
            Status_LPO_Set and Interface Identifier X.

         2. Check A: State Request primitive will be received at the NIF at SG
            containing the Interface Identifier X and State received.

         3. Repeat the above test case for other valid State parameter
            values(example-STATUS_LPO_CLEAR).









    Manish Sharma, HSS                                          [Page 87]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         "State Request(Audit)-1"

         + TEST NUMBER :4.4.4

         + TITLE :  STATE Request primitive

         + SUBTITLE : Auditing of SS7 link state

         + PURPOSE: To check that if State Request message for auditing of the
           Link state is received from ASP then it is processed appropriately.
           (When the SS7 link is in-service ).

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. The state of SS7 link is In-Service.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                        NIF+SM

                                    ASP is Active

         STATE REQUEST ------------>
         (State = Status_Audit)

                  <--------------Establish Confirm

                  <--------------State Confirm
                            (State = Status_Audit)

       TEST DESCRIPTION:

       1. Send STATE REQUEST message from ASP to SG with State parameter
          Status_Audit for the link which is In-Service and with Interface
          Identifier X.

       2. Check A: State Confirm massage with state parameter is received at
          ASP.

       3. A message Establish Confirm is also received at ASP indicating
          the link is in-service.




    Manish Sharma, HSS                                          [Page 88]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003




         "State Request(Audit)-2"

         + TEST NUMBER :4.4.5

         + TITLE :  STATE Request primitive

         + SUBTITLE : Auditing of SS7 link state

         + PURPOSE: To check that if State Request message for auditing of the
           Link state is received from ASP then it is processed appropriately.
           (When the state of SS7 link is In-Service, but congested).

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between
           SGP and ASP. ASP is Active. The state of SS7 link is In-Service,
           but congested.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                          NIF+SM

                                    ASP is Active

         STATE REQUEST ------------>
         (State = Status_Audit)

                  <--------------Establish confirm

                  <--------------Congestion Indication

                  <--------------State Confirm
                                (State = Status_Audit)


       TEST DESCRIPTION:

       1. Send STATE REQUEST message from ASP to SG with State parameter
          Status_Audit for the link which is In-Service but congested and with
          Interface Identifier X.

       2. Check A: State Confirm massage with state parameter is received at

    Manish Sharma, HSS                                          [Page 89]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

          ASP.

       3. Check B: A Establish confirm message is received at ASP indicating
          the link is In-Service.

       4. Check C: A Congestion Indication message is received at ASP
          indicating the level of congestion.




         "State Request(Audit)-3"

         + TEST NUMBER : 4.4.6

         + TITLE :  STATE Request primitive

         + SUBTITLE : Auditing of SS7 link state

         + PURPOSE: To check that if State Request message for auditing of the
           Link state is received from ASP then it is processed appropriately.
           (When the state of SS7 link is in-service, but in Remote Processor
            Outage).

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. The state of SS7 link is in-service, but in
           Remote Processor Outage.

         EXPECTED MESSAGE SEQUENCE :

         ASP                               SGP                         NIF+SM

                                       ASP is Active

         STATE REQUEST ------------>
         (State = Status_Audit)

                      <--------------Establish confirm
                      <--------------State Indication
                                 (Event = Event_RPO_Enter)

                      <--------------State Confirm
                                 (State = Status_Audit)

    Manish Sharma, HSS                                          [Page 90]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       TEST DESCRIPTION:

       1. Send STATE REQUEST message from ASP to SGP with state parameter
          Status_Audit for the link which is in Remote Processor Outage and
          with Interface Identifier X.

       2. Check A: State Confirm massage with State parameter is received at
          ASP.

       3. Check B: An Establish confirm message is received at ASP indicating
          the link is In-Service.

       4. Check C: A State Indication message is received at ASP with the
          Event field containing EVENT_RPO_ENTER.



         "State Request(Audit)-4"

         + TEST NUMBER : 4.4.7

         + TITLE :  STATE Request primitive

         + SUBTITLE : Auditing of SS7 link state

         + PURPOSE: To check that if State Request message for auditing of the
           Link state is received from ASP then it is processed appropriately.
           (When the state of SS7 link is Out-of-Service).

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. The state of SS7 link is Out-of-Service.

         EXPECTED MESSAGE SEQUENCE :

         ASP                              SGP                           NIF+SM

                                      ASP is Active

         STATE REQUEST ------------>
         (State = Status_Audit)

                    <--------------Release Indication

    Manish Sharma, HSS                                          [Page 91]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                    <--------------State Confirm
                                   (State = Status_Audit)

       TEST DESCRIPTION:

       1. Send STATE REQUEST message from ASP to SGP with state parameter
          Status_Audit for the link which is now Out-of-Service and with
          Interface Identifier X.

       2. Check A: State Confirm message with state parameter is received at
          ASP.

       3. Check B: A Release Indication message is also received at ASP
          indicating the link is Out-of-Service.






         "State Confirm"

         + TEST NUMBER : 4.4.8

         + TITLE :  STATE Confirm primitive

         + SUBTITLE : STATE Confirm primitive

         + PURPOSE: To check that if State Confirm primitive is received from
           Upper Layer Protocol (ULP) at SGP with interface identifier and
           State then STATE CONFIRM message is sent from SGP to all the ASP
           which are handling traffic for that Interface Identifier.

         + TEST CONFIGURATION: D

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 in AS1 and AS2 respectively and both ASPs are active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                           NIF+SM

                                  ASP1, ASP2 are Active


                                                 <--------------State Confirm
    Manish Sharma, HSS                                          [Page 92]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                                   (State = Status_LPO_Set)
                   (ASP1)<--------------STATE CONFIRM


       TEST DESCRIPTION:

       1. Send State Confirm primitive from NIF at SGP with State
          Status_LPO_Set and Interface Identifier X.

       2. Check A: STATE CONFIRM message will be received at ASP1 with state
          as Status_LPO_Set.

       3. Check B: STATE CONFIRM message will not be received at ASP2.

       4. Repeat the above test case for different valid values of State
          Parameter. STATE CONFIRM message will be received at ASP1 with the
          State parameter sent in State Confirm primitive from NIF at the SGP.




         "Congestion Indication"

         + TEST NUMBER : 4.4.9

         + TITLE :  Congestion Indication primitive

         + SUBTITLE : Congestion Indication primitive

         + PURPOSE: To check that if the MSU buffer fill increases above an
           Onset threshold or decrease below an Abatement threshold or crosses
           a Discard threshold ,the SGP sends a congestion indication message
           to ASP which is handling traffic for that Interface Identifier.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SGP is having SCTP association with
           ASP and the ASP is active.
           The MSU buffer fill is above the threshold value.

         EXPECTED MESSAGE SEQUENCE :

         SU+SM                ASP              SGP                    NIF+SM


    Manish Sharma, HSS                                          [Page 93]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                                      ASP is Active

                                               <----------Cong. Indication

                                <--------Congestion Indication
                                           (Congestion Status)
                                           (Interface Id = X)

              <--------Congestion Indication

                                              <----------Congestion Cease Ind

                                <--------Congestion Indication
                                       (Congestion Status = LEVEL_NONE)
                                       (Interface Id = X)

              <--------Congestion Cease Ind

       TEST DESCRIPTION:

       1. CHECK A: M2UA at SGP receives Congestion Indication primitive from
          NIF with corresponding Congestion Status, Discard Status and with
          Interface Identifier X.

       2. CHECK B: Congestion Indication message is sent to peer M2UA at
          ASP from M2UA at SGP with corresponding level of congestion and
          Discard Status.

       3. CHECK C: The M2UA at ASP sends a Congestion Indication primitive to
          the ULP after it receives a Congestion Indication message from SGP.

       4. Now, let MTP2 at SGP detect no Congestion.
          CHECK D: M2UA at SGP receives Congestion Cease Indication from NIF.

       5. CHECK E: Congestion Indication message with Congestion Status
          LEVEL_NONE is sent to peer M2UA at ASP from M2UA at SGP.

       6. CHECK F: The M2UA at ASP sends a Congestion Cease Indication to the
          ULP after it receives a Congestion Indication message from SGP.

       Note1: For networks that do not support multiple levels of congestion,
       only the LEVEL_NONE and LEVEL_3 values will be used.  For networks
       that support multiple levels of congestion, it is possible for all
       values to be used.


    Manish Sharma, HSS                                          [Page 94]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       Note2: The Discard Status in the Congestion Indication is an optional
       field and might not be supported in an implementation.
         "State Indication"

         + TEST NUMBER : 4.4.10

         + TITLE :  STATE Indication  primitive

         + SUBTITLE : STATE Indication  primitive

         + PURPOSE: To check that if State Indication primitive is received
           from ULP at SGP with Interface Identifier then STATE INDICATION
           message is sent from SGP to all the ASPs which are handling traffic
           for that Interface Identifier.

         + TEST CONFIGURATION: D

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 in AS1 and AS2 respectively and both ASPs are active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                               ASP1, ASP2 are Active

                                           <------------ State Indication
                                         (State = Event_RPO_ENTER)
                                           (Interface Id = X )

         (ASP1)<-------------------STATE INDICATION

       TEST DESCRIPTION:

       1. Send State Indication primitive with Event field equal to
          Even_RPO_ENTER from NIF at SGP with Interface Identifier X.

       2. Check A: STATE INDICATION message will be received at ASP1 with
          Event field as Event_RPO_Enter.

       3. Check B: STATE INDICATION message will not be received at ASP2.

       4. Repeat the above test case for different valid State Indications
          from NIF(example - RPO Rcvr Indication). STATE INDICATION message

    Manish Sharma, HSS                                          [Page 95]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

          will be received at ASP1 with the Event parameter sent in  State
          Indication primitive from NIF at the SGP.

       5. Repeat the above Test by sending the RPO Indication primitive with
          Interface Identifier equal to P. The STATE INDICATION message will
          be received at ASP2 and not ASP1.








         "Retrieval Request "

         + TEST NUMBER : 4.4.11

         + TITLE :  Retrieval Request message

         + SUBTITLE : Retrieval Request message

         + PURPOSE: To check that if RETRIEVAL REQUEST message is received
           from ASP with Action parameter as Action_Rtrv_BSN then SGP sends
           Retrieval Request primitive to the NIF.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Active

         RETRIEVAL REQUEST ------------>
         (Action = Action_Rtrv_BSN)
         (Sequence Number = 0)
                               Retrieval Request --------------->
                              (Action = Action_Rtrv_BSN)
                             (Sequence Number = 0)

       TEST DESCRIPTION:

       1. Send RETRIEVAL REQUEST message from ASP to SGP with Action parameter
    Manish Sharma, HSS                                          [Page 96]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          as Action_Rtrv_BSN, Interface Identifier X.
          Sequence Number parameter should be 0 this case.

       2. Check A: NIF at SGP will receive Retrieval Request primitive
          with action field as Action_Rtrv_BSN.

       3. Repeat the above test case with the other valid Action parameter
          value i.e. Action_Rtrv_Msgs. In case of action parameter as
          Action_Rtrv_Msgs Sequence Number field should contain the Forward
          Sequence Number(FSN) of the far end.



         "Retrieval Confirm, Indication and Complete Indication"

         + TEST NUMBER : 4.4.12

         + TITLE :  Retrieval CONFIRM, INDICATION and COMLETE INDICATION
                    messages

         + SUBTITLE : Retrieval CONFIRM, INDICATION and COMLETE INDICATION
                      messages

         + PURPOSE: To check that if Retrieval Confirm Primitive is received
           from NIF with Action as Action_Rtrv_BSN and BSN retrieved in
           Sequence Number field then SGP sends RETRIEVAL CONFIRM message to
           the concerned ASP with the Action and BSN number passed to it from
           NIF.

         + TEST CONFIGURATION: D

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 and both ASPs are Active. Let there be total of "n" number of
           messages to be retrieved.

         EXPECTED MESSAGE SEQUENCE :

         ASP                           SGP                           NIF+SM

                                 ASP1, ASP2 are Active

         RETRIEVAL REQUEST ------------>
         (Action = Action_Rtrv_BSN)
         (Sequence Number = 0)

    Manish Sharma, HSS                                          [Page 97]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                                   Retrieval Request --------------->
                                   (Action = Action_Rtrv_BSN)
                                  (Sequence Number = 0)

                                                  <----------Retrieval Confirm
                                                   (Action = Action_Rtrv_BSN)
                                                  (Sequence Number = BSN)
                                                   (Interface Identifier = X)

                  (ASP1)<------------RETRIEVAL CONFIRM
                                    (Action = Action_Rtrv_BSN)
                                    (Sequence Number = BSN)

         RETRIEVAL REQUEST ------------>
         (Action = Action_Rtrv_MSGS)
         (Sequence Number = FSN)
                                  Retrieval Request --------------->
                                  (Action = Action_Rtrv_MSGS)


                                  (Sequence Number = FSN)

                                               <----------Retrieval Indication
                                                        MSU from retransmit
                                                       queue and not last MSU
                                                        (Interface Id = X)
           (ASP1)<---------------RETRIEVAL INDICATION

                                              <----------Retrieval Indication
                                                        MSU from retransmit
                                                        queue and not last MSU
                                                           (Interface Id = X)

           (ASP1)<---------------RETRIEVAL INDICATION

                                              <----------Retrieval Indication
                                                        MSU from retransmit
                                                        queue and not last MSU
                                                           (Interface Id = X)

           (ASP1)<---------------RETRIEVAL INDICATION


                                        ... n-1 RETRIEVAL INDICATIONs


    Manish Sharma, HSS                                          [Page 98]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                       <----------Retrieval Complete
                                                          Indication
                                                        MSU from retransmit
                                                        queue and last MSU
                                                         (Interface Id = X)

        (ASP1)<------------RETRIEVAL COMPLETE INDICATION


       TEST DESCRIPTION:

       1. Send RETRIEVAL REQUEST from ASP to SGP with Action parameter as
          Action_Rtrv_BSN and Sequence Number as 0.
          SGP will receive retrieval request and send it to NIF.
          Send Retrieval Confirm primitive from NIF at SGP with action
          Action_Rtrv_BSN and BSN in the Sequence Number field.

       2. Check A: RETRIEVAL CONFIRM message will be received at the ASP1.

       3. Check B: RETRIEVAL CONFIRM message will not be received at the ASP2.

       4. Check C: In the RETRIEVAL CONFIRM message, Action field is
          Action_Rtrv_BSN and Sequence Number field is BSN.
          Check the Result field for RESULT_SUCCESS.

       5. Repeat the above test case if the Sequence Number field in Retrieval
          Confirm primitive from NIF is not included, indicating BSN retreival
          failure.
          Check D: In the RETRIEVAL CONFIRM message, Action field is
          Action_Rtrv_BSN and the Result field contains RESULT_FAILURE.
          The Sequence Number field is not included.

       6. Send RETRIEVAL REQUEST from ASP to SGP with Action field equal to
          Action_Rtrv_MSGS and FSN in the Sequence Number field. SGP will
          receive retrieval request and send it to NIF.
          Send Retrieval Indication primitive containing MSU n-1 times from
          NIF.

       7. Check E: RETRIEVAL INDICATION is sent n-1 times to the ASP1 with the
          PDU containing the MSU received from NIF.

       8. Send Retrieval Complete Indication primitive containing MSU from NIF
          and it is the last MSU.


    Manish Sharma, HSS                                          [Page 99]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       9. Check F: RETRIEVAL COMPLETE INDICATION is received at the ASP1 with
          the PDU containing the MSU received from NIF.

       10. Repeat the above test cases for Interface Identifier P.
           In this case messages will be received at ASP2 and not at ASP1.



         4.4.2 Data Transfer Messages

         "DATA Primitive"

         + TEST NUMBER : 4.4.13

         + TITLE : DATA Primitive at SGP

         + SUBTITLE : Handling of DATA Primitives in AS active state

         + PURPOSE: To check that on receiving DATA Send primitive from ULP,
           DATA message is sent to the AS. Also on receiving DATA message from
           ASP, NIF is sent Receive Data Indication from M2UA at SGP.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                                SGP
         NIF+SM

                                        ASP is Active


                                                            <-------- Data
                                                           (Interface Id = X)
                        <----------------- DATA Msg


         DATA Msg--------------->
                                    Data Receive Ind ------------->

       TEST DESCRIPTION:

       1. Send DATA Send Primitive from the NIF to M2UA at SGP side to send
    Manish Sharma, HSS                                          [Page 100]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          Protocol Data to the ASP with Interface Identifier X.

       2. Check A: DATA message is received at the ASP containing the data and
          the Interface Identifier X passed by the NIF.

       3. Send DATA message from ASP to SGP containing Protocol Data and
          Interface Identifier X.

       4. Check B: Data Receive Indication is received at the NIF.




         "DATA Primitive"

         + TEST NUMBER : 4.4.14

         + TITLE : DATA Primitive at SGP

         + SUBTITLE : Handling of DATA Primitives in AS active state for
           Override AS traffic mode type.

         + PURPOSE: To check that on receiving DATA Send primitive from ULP,
           DATA message is sent to the ASP for Override AS traffic mode type.

         + TEST CONFIGURATION:C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASPs and ASP1 is active. The Traffic Handling Mode for the AS
           is configured as Override at SGP.

         EXPECTED MESSAGE SEQUENCE :

         ASP                            SGP                         NIF+SM

                                     ASP1 Active
                                     ASP2 Inactive

                                                         <-------- Data
                                                        (Interface  Id = X)
              (ASP1)<----------------- DATA Msg

                                                         <-------- Data
                                                         (Interface Id = Y)

    Manish Sharma, HSS                                          [Page 101]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

              (ASP1)<----------------- DATA Msg

                                      ASP2 Active
                                      ASP1 Inactive

                                                         <-------- Data
                                                         (Interface Id = X)
              (ASP2)<----------------- DATA Msg

                                                         <-------- Data
                                                         (Interface Id = Y)
              (ASP2)<----------------- DATA Msg

       TEST DESCRIPTION:

       1. Send Data Send primitives from NIF to M2UA at SGP with Interface
          Identifiers Xand Y following which SGP will send Protocol DATA to
          ASP1.

       2. CHECK A: Both the DATA messages are sent to ASP1.

       3. Make ASP2 Active in Override mode in AS1.
          Again send the Data Send Primitives from NIF to M2UA at SGP with
          Interface Identifiers X and Y.

       4. CHECK B: Both the DATA messages are sent to ASP2.


         "DATA Primitive"

         + TEST NUMBER : 4.4.15

         + TITLE : DATA Primitive at SGP

         + SUBTITLE : Handling of DATA Primitive in AS active state, for
           Loadshare AS traffic mode type.

         + PURPOSE: To check that on receiving DATA primitive from ULP, DATA
           message is sent to appropriate ASP for Loadshare AS Traffic
           Handling Mode.

         + TEST CONFIGURATION: C

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and both ASPs and both ASPs are active. The Traffic Handling Mode
           for the AS is configured as Loadshare at SGP.
    Manish Sharma, HSS                                          [Page 102]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         EXPECTED MESSAGE SEQUENCE :

         ASP                               SGP                          NIF+SM

                                        ASP1, ASP2 are Active

                                                             <-------- Data
                                                           (Interface Id = X)
                 (ASP1)<----------------- DATA Msg

                                                             <-------- Data
                                                            (Interface Id = Y)
                 (ASP2)<----------------- DATA Msg


       TEST DESCRIPTION:

       1. Send Data Send primitives from NIF to M2UA at SGP with Interface
          Identifiers X and Y following which SGP will send Protocol DATA to
          ASP.

       2. CHECK A: First DATA message is sent to ASP1 and the second is sent
          to ASP2.








         "DATA Primitive"

         + TEST NUMBER : 4.4.16

         + TITLE : DATA Primitive at SGP

         + SUBTITLE : Handling of DATA Primitive in AS active state, for
           Broadcast AS traffic mode type.

         + PURPOSE: To check that on receiving DATA primitive from ULP, DATA
           message is sent to the ASP for Broadcast AS traffic mode type.

         + TEST CONFIGURATION: C

    Manish Sharma, HSS                                          [Page 103]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and both ASPs and only ASP1 is Active. ASP2 is Inactive.The Traffic
           Handling Mode for the AS is configured as Broadcast at SGP.

         EXPECTED MESSAGE SEQUENCE :

         ASP                             SGP                           NIF+SM

                                      ASP1 is Active
                                      ASP2 is Inactive

                                                             <-------- Data
                                                          (Interface  Id = X)

              (ASP1)<----------------- DATA Msg

                                                            <-------- Data
                                                           (Interface Id = Y)
              (ASP1)<----------------- DATA Msg


                                         ASP2 Active
                                         ASP1 Active

                                                            <-------- Data
                                                            (Interface Id = X)
              (ASP1)<----------------- DATA Msg
                                       (Corelation Id)

              (ASP2)<----------------- DATA Msg
                                       (Corelation Id)

         DATA Ack (ASP1)------------->
          (Correlation Id)



         DATA Ack (ASP2)------------->
          (Correlation Id)

                                                            <-------- Data
                                                            (Interface Id = Y)

              (ASP1)<----------------- DATA Msg
              (ASP2)<----------------- DATA Msg
    Manish Sharma, HSS                                          [Page 104]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003




       TEST DESCRIPTION:

       1. Send Data Send primitives from NIF to M2UA at SGP with Interface
          Identifiers X and Y following which SGP will send Protocol DATA to
          AS.

       2. CHECK A: Both DATA messages are sent to ASP1.

       3. Make ASP2 Active in Broadcast mode in AS1.
          Again send Data Send primitives from NIF to M2UA at SGP with
          Interface Identifiers X and Y.

       4. CHECK B: Both the DATA messages are sent to all active ASP i.e.
          ASP1, ASP2.
          First DATA message after a new ASP Active contains Correlation Id.

       5. CHECK C: The SGP will receive DATA Ack messages for the DATA
          messages containing Correlation Ids sent.
          CHECK D: The DATA Ack messages should have the same Correlation Ids
          which were sent in the DATA messages.



         "TTC DATA Primitive"

         + TEST NUMBER : 4.4.17

         + TITLE : TTC DATA Primitive

         + SUBTITLE : Handling of TTC DATA Primitive in AS active state.

         + PURPOSE: To check that on receiving TTC DATA Send primitive from
           ULP, TTC DATA message is sent to the AS. Also, on receiving TTC
           DATA message from ASP, NIF is sent Receive Data Indication.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is active.

         EXPECTED MESSAGE SEQUENCE :


    Manish Sharma, HSS                                          [Page 105]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         ASP                            SGP                            NIF+SM

                                    ASP is Active

                                                           <-------- TTC Data

                 <----------------- TTC DATA Msg

         TTC DATA  Msg --------------->

                                 TTC DATA Receive Ind ------------->

       TEST DESCRIPTION:

       1. Send TTC DATA Send Primitive from the NIF to M2UA at SGP side to
          send Protocol Data to the ASP with Interface Identifier X.

       2. Check A: TTC DATA message is received at the ASP containing the data
          and the Interface Identifier X passed by the NIF.

       3. Send TTC DATA message from ASP to SGP containing Protocol Data and
          Interface Identifier X.

       4. Check B: TTC DATA Receive Indication is received at the NIF.






         "Message Routing"

         + TEST NUMBER : 4.4.18

         + TITLE :  Message Routing

         + SUBTITLE : Message Routing towards ASP

         + PURPOSE: To check that if NIF sends a Data Send primitive
           containing Protocol DATA to be send to the ASP then it is sent to
           the correct ASP.

         + TEST CONFIGURATION: D

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 in AS1 and AS2 respectively, and both ASPs are Active.

    Manish Sharma, HSS                                          [Page 106]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         EXPECTED MESSAGE SEQUENCE :

         ASP1              ASP2                SGP                      NIF+SM

                                  ASP1, ASP2 are Active

                                                             <--------  Data
                                                            (Interface Id = X)
                 <------------------------- DATA Msg

                                                            <--------  Data
                                                            (Interface Id = Y)
                 <------------------------- DATA Msg

                                                            <--------  Data
                                                            (Interface Id = P)
                              <------------ DATA Msg

       TEST DESCRIPTION:

       1. Send Data Send primitive from NIF to M2UA in the SGP containing
          Protocol Data to be sent to the ASP with Interface Identifier X.

       2. Check A: DATA message will be received at the ASP1.

       3. Repeat the above test case for Data Send primitive containing
          Protocol Data and Interface Identifier Y. Data message should be
          received at ASP1.

       4. Repeat the above test case for Data Send primitive containing
          Protocol Data and Interface Identifier P. Data message should be
          received at ASP2.



         "Message Routing"

         + TEST NUMBER :4.4.19

         + TITLE :  Message Routing

         + SUBTITLE : Routing for DATA not matching any Interface Identifier

         + PURPOSE: To check that if NIF sends a Data Send primitive

    Manish Sharma, HSS                                          [Page 107]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

           containing Protocol DATA and Interface Identifier not defined at
           the SGP then Error Message should be returned or some default
           routing is given to this message.

         + TEST CONFIGURATION: D

         + PRE-TEST CONDITIONS: SGP is having SCTP association with ASP1 and
           ASP2 and both ASPs are Active. Interface Identifier Z, is not
           defined at SGP.

         EXPECTED MESSAGE SEQUENCE :

         ASP1              ASP2                SGP                      NIF+SM

                                 ASP1, ASP2 are Active

                                                             <--------  Data
                                                            (Interface Id = Z)

                                              Error     ------------------>

       TEST DESCRIPTION:

       1. Send Data Send primitive from NIF in the SGP with Interface
          Identifier Z.

       2. Check A: Error should be returned or some default routing will be
                   given to this protocol data.










         "SCTP Stream Management"

         + TEST NUMBER : 4.4.20

         + TITLE : SCTP Stream Management

         + SUBTITLE : Same Stream selection for same Interface Identifier

         + PURPOSE: To check that all the messages for the same Interface
    Manish Sharma, HSS                                          [Page 108]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                    Identifier are sent on the same SCTP stream.

         + TEST CONFIGURATION: A

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP with two streams and ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         ASP                        SGP                        NIF+SM

                                 ASP is Active

                                                    <--------  Data
                                                       (Interface Id = X)
                <----------------- DATA Msg

                                                    <--------  Data
                                                       (Interface Id = X)
                <----------------- DATA Msg

                                                    <--------  Data
                                                       (Interface Id = X)
                <----------------- DATA Msg

        TEST DESCRIPTION:

       1. Send three or more DATA Send Primitives with same Interface
          Identifier value X from the NIF to M2UA at SGP side to send Protocol
          Data to the ASP.

       2. Check A: DATA messages are received at the ASP containing the same
          Stream Id.

       3. Repeat the above test with other Interface Identifier Y.

       4. Repeat the above case if number of streams between ASP and SGP is
          more than two but AS is handling only two Interface Identifiers. One
          or more streams may not be used for sending DATA message.


       5. Repeat the above case if number of streams between ASP and SGP is
          two but AS is handling four Interface Identifiers. Send DATA
          messages for all Interface Identifier. DATA messages should be sent

    Manish Sharma, HSS                                          [Page 109]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

          on both the streams and DATA messages for the same Interface
          Identifier are sent on the same stream.

       Note: The method to distribute messages on different SCTP streams is
       implementation specific.









       5.  Test Cases for Testing M2UA at ASP

        5.1 Layer Management Messages

         5.1.1 SCTP Connection Management Messages

         "SCTP Connection Management"

         + TEST NUMBER : 5.1.1

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Establishment

         + PURPOSE: To check that on receiving M-SCTP-Establish primitive from
           SM, ASP M2UA initiates and establishes an SCTP association with
           SGP.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is not established between
           SGP and ASP.

         EXPECTED MESSAGE SEQUENCE :

         SGP                             ASP                           SU+SM

                                              <--------M-SCTP-Establish
                                                                Request

                   SCTP_ASSOCIATE request issued to SCTP from M2UA at ASP.

                   SCTP Association will be established between ASP with SGP.
    Manish Sharma, HSS                                          [Page 110]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



                   M2UA at ASP will receive
                             SCTP-COMMUNICATION_Up Primitive from SCTP.

                                 M-SCTP-Establish Confirm--------->

       TEST DESCRIPTION:

       1. Send M-SCTP-Establish Request Primitive with required parameters
          from the SM at ASP side to establish an SCTP association with the
          SGP.

       2. Check A: SCTP association will be established and M-SCTP-Establish
          confirm will be received at the SM.










         "SCTP Connection Management"

         + TEST NUMBER : 5.1.2

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Status

         + PURPOSE: To check on receiving M-SCTP_STATUS request from SM, M2UA
           will send the M-SCTP_STATUS Indication primitive to SM.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                           ASP                        SU+SM

                                   ASP is Active

    Manish Sharma, HSS                                          [Page 111]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                             <--------- M-SCTP_STATUS request

                               M-SCTP_STATUS Indication ---------->

       TEST DESCRIPTION:

       1. Let the SM at ASP send M-SCTP_STATUS request to M2UA at ASP.

       2. Check A: M-SCTP_STATUS Indication will be received at SM.







         "SCTP Connection Management"

         + TEST NUMBER :5.1.3

         + TITLE :  SCTP Connection Management

         + SUBTITLE : SCTP Connection Termination

         + PURPOSE: To check that on receiving SCTP-Communication Down
           Indication (SCTP CDI) primitive from SCTP, M2UA at ASP will send
           the M-SCTP Status primitive to the SM.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in Active state. Let the SM at SGP send M-
           SCTP_RELEASE to M2UA at SGP. The M2UA then sends a SCTP-SHUTDOWN
           primitive to the local SCTP.

         EXPECTED MESSAGE SEQUENCE :

         SGP                             ASP                             SU+SM

                                   ASP is Active

                                              <----------M-SCTP_RELEASE
                                                                Request

                  M2UA at ASP sends SCTP-SHUTDOWN primitive to SCTP Layer.

    Manish Sharma, HSS                                          [Page 112]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                  SCTP association between ASP and SGP is terminated.

                  M2UA at ASP will receive SCTP CDI Primitive from SCTP.

                          M-SCTP_RELEASE Confirm ------>

                                            M-SCTP_Status Ind--------->


                                                            <-------- Data
                                  Send Failure --------------->


       TEST DESCRIPTION:

       1. Terminate the association between SGP and ASP by sending
          M-SCTP_RELEASE Request from SU to M2UA at ASP.

       2. Check A: SCTP association will be down and on receiving
          Communication Down Indication primitive from SCTP, M-SCTP_Status
          indication will be received at SM.

       3. Check B: State of ASP will be down. Send DATA Send primitive from
          the SU to M2UA at ASP to send Protocol DATA. ASP will report send
          failure.

       4. Repeat the above Test case when SCTP Shutdown is initiated by SGP
          side. In that case M-SCTP_RELEASE Indication primitive will be
          received at SU as compared to M-SCTP_RELEASE Confirm primitive in
          this case.

       5. Repeat the above Test Case when SCTP CDI indicating COMMUNICATION-
          LOST is received in case of an ungraceful SCTP Shutdown.








        5.2 ASPM Messages

         5.2.1 ASPSM and ASPTM Messages


    Manish Sharma, HSS                                          [Page 113]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         "Timer T(ack) Cancellation"

         + TEST NUMBER :5.2.1

         + TITLE :  AS Management

         + SUBTITLE : Timer T(ack) Cancellation

         + PURPOSE: To check that T(ack) at ASP is cancelled on receiving
           ASPIA-Ack from SGP before T(ack) expires.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active. Let value of Timer T(ack) be z seconds.


         EXPECTED MESSAGE SEQUENCE :

         ASP                          SGP                          NIF+SM

                                  ASP is Active

         ASPIA  --------------->
                   Time = z seconds
                   (T(ack) expires)

         ASPIA  --------------->

                                  Status Ind.----------------->
                                  (ASP Inactive)
               Time < z seconds
               T(ack) is running

                        <-------- ASPIA-Ack

       TEST DESCRIPTION:

       1. Send ASPIA message from ASP to SGP and restrict the ASPIA-Ack at
          SGP.

       2. Check A: After T(ack) expires i.e. after z seconds ASP resends ASPIA
          message to SGP.

       3. Don't restrict the ASPIA-Ack for the next ASPIA message from ASP.

    Manish Sharma, HSS                                          [Page 114]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       4. Check B: Before Timer T(ack) expires ASPIA-Ack is received at ASP
          and retransmission of ASPIA messages is stopped.

       5. Repeat the above Test for other similar messages for which
          acknowledgement is expected(example- ASPUP, ASPDN, ASPAC).


       Note: The retransmission of ASP Inactive messages and other such
       messages is implementation specific, in some implementations the
       retransmission may be put under the control of Layer Management.






         "ASPM messages"

         + TEST NUMBER :5.2.2

         + TITLE :  AS management

         + SUBTITLE : ASP-Up-Ack message is not received in response to ASPUP
                      message

         + PURPOSE: To check that if ASP-Up-Ack message is not received in
           response to the ASPUP message then ASP keeps on sending ASPUP
           message at an interval for some time and after specified time will
           report the SM.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in Down State.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                          SM

                                     ASP is Down

                                                  <--------------- ASP-Up

                <--------------------- ASPUP


    Manish Sharma, HSS                                          [Page 115]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                          Timer T(ack) expires

                <--------------------- ASPUP

                          Timer T(ack) expires

                                 .

                                 .

                                 .

               <---------------------- ASPUP

                         Timer T(ack) expires

               <---------------------- ASPUP

                         Timer T(ack) expires

               <---------------------- ASPUP

                                  n tries


                                     Status Ind  --------------->

       TEST DESCRIPTION:

       1. Send ASP-Up primitive from SM to M2UA at ASP. ASP will send ASPUP
          message to the SGP. Restrict the ASPUP-Ack message at the SGP.

       2. Check A: ASPUP message will be retransmitted to the SGP.

       3. Check B: After n tries M2UA at ASP sends Status Indication to SM.

       4. Repeat the above test case for similar messages i.e. that expect an
          acknowledgement from the peer M2UA(example-ASPDN, ASPAC, ASPIA).


       Note: T(ack) is provisionable, with a default of 2 seconds. The value
       of n is also implementation dependent.




    Manish Sharma, HSS                                          [Page 116]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         "ASPM messages"

         + TEST NUMBER :5.2.3

         + TITLE :  AS management

         + SUBTITLE : ASP-Down-Ack message is received in response to ASPUP
                      message

         + PURPOSE: To check that if ASP-Down-Ack message is received in
           response to the ASPUP message then ASP sends the ASPUP message
           again.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in Down State.

         EXPECTED MESSAGE SEQUENCE :

         SGP                              ASP                            SM

                                       ASP is Down

                                                      <--------------- ASP-Up
                  <--------------------- ASPUP

         ASP-Dn-Ack  --------------->

                 <---------------------- ASPUP

       TEST DESCRIPTION:

       1. Send ASP-Up primitive from SM to M2UA at ASP. ASP will send ASPUP
          message to the SGP. Send ASP-Down-Ack message from the SGP in
          response to the ASPUP message before Timer T(ack) expires.

       2. Check A: ASPUP message can be retransmitted to the SGP.

       3. Check B: The ASP-Dn-Ack message from SGP is discarded.

       4. Repeat the above test case using ASP-Active-Ack, ASP-Inactive-Ack
          being sent in place of ASP-Dn-Ack message.

    Manish Sharma, HSS                                          [Page 117]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       Note: This case is implementation specific. Every time an Ack message
       Is received when one is expected the T(ack) timer is cancelled. But in
       Case of Invalid Ack message the Request is sent again and the Timer
       T(ack) is started again. The default time for T(ack) is 2 seconds but
       it is provisional. The number of trials before the ASP gives up is
       again implementation dependent.



         "ASPM messages"

         + TEST NUMBER :5.2.4

         + TITLE :  ASP Management messages towards SGP

         + SUBTITLE : ASP Management messages towards SGP

         + PURPOSE: To check that if SM sends primitive to send ASP management
           messages to M2UA at ASP then the corresponding message is sent to
           the SGP.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                             ASP                              SM

                                     ASP is Active

                                                         <-------- ASP-
                                                                 Inactive

                 <--------------------- ASPIA

         ASPIA-Ack  --------------->
         NTFY(AS-Pending) --------->

             Timer T(r) expires

         NTFY(AS-Inactive) -------->

                                     Status Ind------------------>
    Manish Sharma, HSS                                          [Page 118]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003




                                                       <------------- ASP-Down
                <--------------------- ASPDN

         ASPDN-Ack  -------------->

                                    Status Ind------------------>

                                                       <--------------- ASP-Up
                <--------------------- ASPUP

         ASPUP-Ack  -------------->
         NTFY(AS-Inactive) ------->


                                    Status Ind------------------>

                                                        <-------- ASP-Active
                <--------------------- ASPAC

         ASPAC-Ack  -------------->
         NTFY(AS-active) --------->

                                   Status Ind------------------>

       TEST DESCRIPTION:

       1. Send ASP-Inactive Primitive from SM to M2UA at ASP.

       2. Check A: ASPIA message will be received at the SGP.

       3. Check B: Corresponding ASP-Inactive-Ack and NTFY message with status
          AS-Pending in response to the ASPIA message will be received at ASP.
          After the expiry of Timer T(r) a NTFY message with Status AS-
          Inactive will be received at ASP.

       4. Check C: A Status Indication is sent to the SM by M2UA at ASP.

       5. Check D: ASPM messages are received on stream 0.

       6. Repeat the test case for other primitives from SM to M2UA like
          ASP-Down, ASP-Up and ASP-Active. Corresponding Ack and NTFY messages
          will be sent from SGP to ASP.

    Manish Sharma, HSS                                          [Page 119]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       Note: All messages which should be sent on Stream 0 include all ASPM
       messages with the exception of ASPTM, BEAT and BEAT Ack messages.
       Thus, for the ASPTM messages Check in Line 5 above is not applicable.

       Note: The ASPM messages at the ASP may be initiated by the Layer
       Management by sending corresponding Primitives to M2UA or may be
       initiated automatically by an M2UA management function.





         "ASPM messages"

         + TEST NUMBER :5.2.5

         + TITLE :  Invalid message processing

         + SUBTITLE : ASP-Up-Ack is received in response to ASPDN message

         + PURPOSE: To check that if ASP-Up-Ack message is received in
           response to the ASPDN then the ASP-Up-Ack message is discarded and
           ASPDN is sent again.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                               ASP                             SM

                                      ASP is Active

                                                             <-------- ASP-
                                                                       Down
                   <--------------------- ASPDN

       ASP-Up-Ack  --------------->

                   <--------------------- ASPDN

       TEST DESCRIPTION:
    Manish Sharma, HSS                                          [Page 120]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       1. Send ASP-Down Primitive from SM to M2UA at ASP. ASPDN message will
          be sent to the SGP. Send ASP-Up-Ack in response to the ASPDN message
          before Timer T(ack) expires.

       2. Check A: ASPDN message is retransmitted to the SGP.

       3. Check B: The ASP-Up-Ack message from SGP is discarded.

       4. Repeat the above test case using ASP-Active-Ack, ASP-Inactive-Ack
          being sent in place of ASP-Up-Ack message.

       Note: Every time an Ack message is received when one is expected the
       T(ack) timer is cancelled. But in case of Invalid Ack message the
       Request is sent again and the Timer T(ack) is started again. The
       Default time for T(ack) is 2 seconds but it is provisionable. The
       number of trials before the ASP gives up is again implementation
       dependent.



         "ASPM messages"

         + TEST NUMBER :5.2.6

         + TITLE :  Invalid message processing

         + SUBTITLE : ASP-Active-Ack is received in response to ASPIA message

         + PURPOSE: To check that if ASP-Active-Ack message is received in
           response to the ASPIA then the ASP-Active-Ack message is discarded
           and ASPIA is sent again.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                              SM

                                    ASP is Active


    Manish Sharma, HSS                                          [Page 121]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                                                 <-------------- ASP-Inactive
                <--------------------- ASPIA

         ASPAC-Ack  --------------->

                <--------------------- ASPIA


       TEST DESCRIPTION:

       1. Send ASP-Inactive Primitive from SM to M2UA at ASP. ASPIA message
          will be sent to the SGP. Send ASP-Active-Ack in response to the
          ASPIA message before Timer T(ack) expires.

       2. Check A: ASPIA message is received again at the SGP.

       3. Check B: The ASP-Active-Ack message from SGP is discarded.

       4. Repeat the above test case using ASP-Up-Ack, ASP-Dn-Ack being sent
          in response to the ASPIA message in place of ASP-Active-Ack.

       5. Repeat the above test case using ASPAC in place of ASPIA message and
          using ASP-Inactive-Ack, ASP-Up-Ack, ASP-Dn-Ack being sent in
          response to the ASPAC message from the ASP.



       Note: Every time an Ack message is received when one is expected the
       T(ack) timer is cancelled. But in case of Invalid Ack message the
       Request is sent again and the Timer T(ack) is started again. The
       Default time for T(ack) is 2 seconds but it is provisionable. The
       number of trials before the ASP gives up is again implementation
       dependent.




         "ASPM messages"

         + TEST NUMBER :5.2.7

         + TITLE :  ACK messages at ASP are not acknowledged.

         + SUBTITLE : ACK messages at ASP are not acknowledged.

         + PURPOSE: To check that ACK messages at ASP are not acknowledged.
    Manish Sharma, HSS                                          [Page 122]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Down.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                              SM

                                      ASP is Down

                                                     <--------------- ASP-Up
                 <--------------------- ASPUP

         ASPUP-Ack  --------------->


       TEST DESCRIPTION:

       1. Send ASP-Up primitive from SM to ASP. ASPUP message will be sent
          from ASP to SGP. Send ASP-Up-Ack from the SGP.

       2. Check A: ASPUP-ACK message at ASP is not acknowledged.

       3. Repeat the above test case for ASPAC, ASPIA, ASPDN messages.
          The result should be same in all the cases.










        5.3 MGMT Messages

         5.3.1 ERROR Messages

         "Error - Invalid Version"

         + TEST NUMBER : 5.3.1


    Manish Sharma, HSS                                          [Page 123]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         + TITLE :  Invalid Message Handling

         + SUBTITLE : Invalid Version Error

         + PURPOSE: To check that if any message with Invalid version is
           received at the ASP then ASP responds with ERROR message containing
           cause "Invalid Version" and diagnostic information filled with the
           version the ASP supports.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                           ASP                           SM + SU

                                    ASP is active

         DATA Msg---------------->
         (Version = 2.0)

                  <---------------    ERROR
                              (Cause = Invalid Version)

       TEST DESCRIPTION:

       1. Send DATA message from SGP to ASP containing version 2.0 in the
          Common Message Header and other valid parameters.

       2. Check A: ERROR message is received at the SGP containing cause
          Invalid Version.

       3. Check B: Diagnostic Field Parameter in ERROR is filled with version
          1.0 .

       4. Repeat the above test cases for other messages from SGP to ASP like
          ESTABLISH CONFIRM, RELEASE CONFIRM, RELEASE INDICATION, STATE
          CONFIRM, STATE INDICATION, DATA RETRIEVAL CONFIRM, DATA RETRIEVAL
          INDICATION and DATA RETRIEVAL COMPLETE INDICATION.


       Note: The Diagnostic information in the ERROR messages is an optional
       parameter which contains information germane to error condition. In
       case it is not included the Check in Line 3 above is not applicable.
    Manish Sharma, HSS                                          [Page 124]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         "Error - Unsupported Message Class"

         + TEST NUMBER :5.3.2

         + TITLE : Unsupported Message Handling

         + SUBTITLE : Unsupported Message Class Error

         + PURPOSE: To check that if a message with message class not defined
           is received at ASP, ASP responds with ERROR message containing
           cause "Unsupported Message Class".

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                           ASP                         SM + SU

                                  ASP is Active

         Message ---------------->
         (Message Class = 1)

                  <---------------    ERROR
                        (Cause = Unsupported Message Class)

         DATA    ---------------->
         (Interface Id = X)
                                 Data receive Ind ------->


       TEST DESCRIPTION:

       1. Send a message with Message Class 1 or any other value which is not
          defined from SGP to ASP with other valid parameters.

       2. Check A: ERROR message will be received at the SGP containing cause
          "Unsupported Message Class".

       3. Check B: State of ASP is not disturbed.


    Manish Sharma, HSS                                          [Page 125]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       4. Send DATA message from SGP to ASP with Interface Identifier = X and
          other required parameters with valid values.

       5. Check C: A DATA Receive Indication is sent to SU by M2UA at ASP.






         "Error - Unsupported Message Type"

         + TEST NUMBER :5.3.3

         + TITLE : Unsupported Message Handling

         + SUBTITLE : Unsupported Message Type Error

         + PURPOSE: To check that if a message with message type not defined
           is received at ASP, ASP responds with ERROR message containing
           cause "Unsupported Message Type".

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP1 is active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                           ASP                        SM + SU

                                    ASP is Active

         Message ---------------->
         (Message Type = 0x610)

                  <---------------    ERROR
                         (Cause = Unsupported Message Type)

         DATA Msg ---------------->
        (Interface Id = X)
                                 Data receive Ind ------->

       TEST DESCRIPTION:

       1. Send a message with message type 0x610 or any other value which is
          not defined from SGP to ASP with other valid parameters.
    Manish Sharma, HSS                                          [Page 126]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       2. Check A: ERROR message is received at the SGP containing Cause
          Unsupported Message Type and the Message is discarded.

       3. Check B: State of ASP is not disturbed.

       4. Send DATA message from SGP to ASP with Interface Identifier = X and
          other required parameters with valid values.

       5. Check C: A DATA Receive Indication is sent to SU by M2UA at ASP.

       6. Repeat the above test cases by sending ASPUP, ASPDN, ASPAC, ASPIA
          messages from AS which the ASP is not expected to receive. In this
          case error will be reported to the SM and message will be discarded.


         "Error - Invalid Interface Identifier "

         + TEST NUMBER :5.3.4

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid Interface Identifier in MAUP messages

         + PURPOSE: To check that if a message with invalid Interface
           Identifier i.e. Interface Identifier not defined at ASP is received
           then ASP responds with ERROR message containing Cause
           "Invalid Interface Identifier".

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                             ASP                           SM + SU

                                    ASP is Active

         DATA Msg ---------------->
         (Interface Id = P)

                    <---------------    ERROR

    Manish Sharma, HSS                                          [Page 127]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                        (Cause = Invalid Interface Identifier)

         DATA Msg---------------->
         (Interface Id = X)
                                    Data receive Ind ------->

       TEST DESCRIPTION:

       1. Send DATA message with Interface Identifier P that is not defined at
          ASP.

       2. Check A: ERROR message will be received at SGP containing cause
          "Invalid Interface Identifier".

       3. Check B: State of ASP is not disturbed.

       4. Send DATA message from SGP to ASP with Interface Identifier = X and
          other required parameters with valid values.

       5. Check C: A DATA Receive Indication is sent to SM.
       6. Repeat the above test case for other MAUP messages.




         "Error - Parameter Field Error"

         + TEST NUMBER : 5.3.5

         + TITLE : Invalid Message Handling

         + SUBTITLE : Wrong Length Field of a Parameter in the Common Message
                      Header.

         + PURPOSE: To check that if an MAUP or MGMT message with wrong length
           field of a Parameter in Common Message Header or M2UA Header is
           sent to ASP then ASP responds with Error message with Cause
           "Parameter Field Error".

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

    Manish Sharma, HSS                                          [Page 128]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         SGP                              ASP                           SM+SU

                                   ASP is Active

         RELEASE INDICATION --------------------->
         (Length in Interface Id Parameter = 7)

                   <--------------------Error
                         (Cause = Parameter Field Error)

         DATA Msg  ---------------->
         (Interface Id = X)
                                  Data receive Ind   --------->

       TEST DESCRIPTION:

       1. Send RELEASE INDICATION message with length in Interface Id
          Parameter in M2UA Header less than 8 from SGP to ASP.

       2. Check A: RELEASE INDICATION message will be discarded and ERROR
          message with Cause "Parameter Field Error" will be sent to the ASP.

       3. Check B: State of ASP is not disturbed.

       4. Send DATA message from SGP to ASP with Interface Identifier = X and
          other required parameters with valid values including the Length
          Field.

       5. Check C: A Data Receive Indication is sent to SM.

       6. Repeat the above test case for other messages like STATE INDICATION,
          RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, which include
          Parameters in the Common Message Header or M2UA Header.



         "Error - Invalid Stream Identifier"

         + TEST NUMBER : 5.3.6

         + TITLE : Invalid stream Identifier

         + SUBTITLE : MGMT messages on SCTP stream other than 0


    Manish Sharma, HSS                                          [Page 129]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         + PURPOSE: To check that if a MGMT message is received on a stream
           other than 0, then an error message is sent to the peer with Cause
           "Invalid stream Identifier" .

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                           SM+SU

                                    ASP is Active

                   <-------------------ASPIA

         ASPIA-Ack ----------------->

         NTFY(AS-Inactive)---------->
         (SCTP Stream other than 0)

                  <--------------------Error
                           (Cause = Invalid Stream Identifier)

                 <-------------------ASPAC

         ASPAC-Ack ----------------->
         NTFY(AS-active)---------->


       TEST DESCRIPTION:

       1. Send an ASPIA message from ASP to SGP with valid parameters.

       2. An ASPIA-Ack message and a NTFY message with state AS-Pending will
          be received at ASP. After the expiry of Timer T(r) SGP will send a
          NTFY message with State AS-Inactive. Send this NTFY message on an
          SCTP Stream other than 1.

       2. Check A: ERROR message with Cause "Invalid Stream Identifier" will
          be sent to SGP.

       4. Check B: The state of ASP remains Inactive.

       5. Now send an ASPAC message from ASP to SGP. A corresponding ASPAC-Ack
    Manish Sharma, HSS                                          [Page 130]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          and NTFY with Status AS-Active are received at ASP. Ensure that
          these messages are sent with all valid parameter values including
          SCTP Stream.

       6. Check C: No ERROR message is sent to SGP.

       7. Check D: The State of ASP is Active now.

       8. Repeat the above test for other messages which are expected to
          come on SCTP Stream 0 at ASP(example- ASP-Up-Ack, ASP-Dn-Ack).

       Note: In case an expected Ack message is received on an SCTP Stream
       other than 0 at ASP, in addition to the ERROR message the corresponding
       message for which the Ack is expected will be again sent and this
       process will continue unless a valid Ack message arrives or ASP gives
       up.




         "Error - Unexpected message"

         + TEST NUMBER : 5.3.7

         + TITLE : Unexpected message

         + SUBTITLE : MAUP message received at ASP when it is not active

         + PURPOSE: To check that if a MAUP message is received on an ASP when
           it is not active, then a error message to the peer is sent with
           Cause "Unexpected message".

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Inactive. Arrange the data in SGP such that
           ESTABLISH REQUEST message is sent to ASP.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                          SM+SU

                                   ASP is Inactive


    Manish Sharma, HSS                                          [Page 131]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         ESTABLISH REQUEST---------->

                  <--------------------Error
                            (Cause = Unexpected Message)

                  <------------------- ASPAC

                 ESTABLISH REQUEST---------->

                  <--------------------ERROR
                           (Cause = Unexpected Message)

                                                         <----------Data
                                    Send Failure--------->

       ASPAC-ACK---------------->
       NTFY(AS-Active)---------->

       DATA Msg ---------------->
       (Interface Id = X)
                                   Data receive Ind   --------->

       TEST DESCRIPTION:

       1. Send DATA message to ASP from SGP while ASP is in Inactive State.

       2. Check A: ERROR message with Cause "Unexpected Message" will be
          received at SGP.

       3. Check B: The State of ASP is not disturbed.

       4. Now send ASPAC from ASP side to SGP & before sending the ASPAC-ACK,
          send DATA Msg to ASP from SGP.

       5. Check C: ERROR message with Cause "Unexpected Message" will be
          received at SGP.

       6. Send DATA Send Primitive from SU to M2UA at ASP.

       7. Check C: Send Failure Indication is sent to the SU by M2UA at ASP.

       8. Now send ASPAC-ACK & NTFY(AS-Active) to ASP from SGP.

       9. Check: State of ASP is now active.

       10. Repeat the above test case for other MAUP messages.
    Manish Sharma, HSS                                          [Page 132]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         "Error - Invalid parameter value"

         + TEST NUMBER : 5.3.8

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid State Parameter in STATE CONFIRM message

         + PURPOSE: To check that if STATE CONFIRM  message with Invalid State
           Parameter is received at ASP then the message is discarded and an
           ERROR message is sent to SGP.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                          SM+SU

                                    ASP is Active

                                              <---------------State Request

           <-----------------------  STATE REQUEST

         STATE CONFIRM ---------------->
         (State = 0xb)
                                   message discarded

                   <---------------    Error
                           (Cause = Invalid Parameter Value)

         DATA Msg ---------------->
         (Interface Id = X)
                                 Data receive Ind   --------->


       TEST DESCRIPTION:

       1. The SU at ASP sends an State Request Primitive to M2UA at ASP
          corresponding to which M2UA sends STATE REQUEST message to M2UA at
          SGP.

    Manish Sharma, HSS                                          [Page 133]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       2. Send STATE CONFIRM  message with State Parameter 0Xb from SGP to ASP
          which is invalid.

       3. Check A: The message is discarded at ASP and an ERROR message with

          Cause "Invalid Parameter Value" is sent to SGP.

       4. Check B: State of ASP is undisturbed.

       5. Send DATA message with Interface Identifier = X and all other valid
          values from ASP to SGP.

       6. Check C: A DATA Receive Indication is received at SM.






         "Error - Invalid parameter value"

         + TEST NUMBER :5.3.9

         + TITLE : Invalid Message Handling

         + SUBTITLE : Invalid Action Parameter in RETRIEVAL CONFIRM message

         + PURPOSE: To check that if RETRIEVAL CONFIRM  message with Invalid
           Action Parameter is received at ASP then message is discarded and
           an ERROR message is sent to the peer.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                              ASP                          SM+SU

                                       ASP is Active

                                              <---------------Retrieval
                                                               Request
                                                              (Action = 0x1)

    Manish Sharma, HSS                                          [Page 134]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


              <--------------------RETRIEVAL REQUEST

         RETRIEVAL CONFIRM ---------------->
         (Action = 0x4)

                                   message discarded

                     <---------------    ERROR
                            (Cause = Invalid Parameter Value)


         DATA Msg---------------->
         (Interface Id = X)

                                   Data receive Ind   --------->


       TEST DESCRIPTION:

       1. Send RETRIEVAL REQUEST message with Action parameter value 0x1 from
          ASP to SGP with Sequence Number = 0.
          Send RETRIEVAL CONFIRM  message with Action Parameter 0X4 which is
          invalid from SGP to ASP.

       2. Check A: The message is discarded and an ERROR message with
          Cause "Invalid Parameter Value" is sent to SGP.

       3. Check B: State of ASP is undisturbed.

       4. Send DATA message with Interface Identifier = X and other required
          parameters with valid values from SGP to ASP.

       5. Check C: A DATA Receive Indication is sent to SM.

       6. Repeat the above test case for invalid value of Sequence Number
          field like -2 etc. Response should be same.


       Note: The Sequence Number parameter is optional, if it is not used Line
       6 of the above Test case is not applicable.



         "Error - Invalid parameter value"

    Manish Sharma, HSS                                          [Page 135]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + TEST NUMBER :5.3.10

         + TITLE : Invalid Message Handling

         + SUBTITLE : ERROR message with invalid Error Code

         + PURPOSE: To check that if ERROR message with Invalid Error Code
           parameter is received then M2UA at ASP doesn't take any action but
           discard the message.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                          SM+SU

                                    ASP is Active

                                                <---------------STATE Request

               <---------------------STATE REQUEST

         ERROR --------------------->
         (Error Code = 0x14)


       TEST DESCRIPTION:

       1. Send STATE REQUEST message from ASP to the SGP. In response to this
          message, send ERROR message with Error Code 0x14 which is invalid
          from SGP to the ASP.

       2. Check A: This ERROR message is discarded.

       3. Further actions are implementation dependent.

       Note: The M2UA at ASP may notify to SM about receipt of an invalid
       ERROR message from SGP depending upon implementation. Depending on
       implementation it may even close the SCTP Association with the peer.



    Manish Sharma, HSS                                          [Page 136]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         "Error - Missing Parameter"

         + TEST NUMBER :5.3.11

         + TITLE : Invalid Message Handling

         + SUBTITLE : Missing Mandatory Parameters

         + PURPOSE: To check that if a message is received at the ASP not
           containing a Mandatory Parameter, ASP responds with an ERROR
           message to the message sending SGP with Cause "Missing Parameter".

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.


         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                           SM+SU

                                      ASP is Active

         DATA Msg ---------------->
         (No Interface Id)

                      <--------------- ERROR
                         (Cause = Missing Parameter)

         DATA Msg ---------------->
         (Interface Id = X)

                                     Data Receive Ind   --------->

       TEST DESCRIPTION:

       1. Send DATA message without any Interface Identifier from SGP to ASP
          which is a mandatory parameter in M2UA Header for MAUP messages .

       2. Check A: ERROR message will be received at ASP containing cause
          "Missing Parameter".

       3. Check B: State of the ASP is not disturbed.

    Manish Sharma, HSS                                          [Page 137]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       4. Send a DATA Msg from SGP to ASP with valid parameters including
          Interface Identifier = X.

       5. Check C: A DATA Receive Indication is sent to SM.

       6. Repeat the above Test case for other MAUP and ASPM messages
          containing Mandatory Parameters.




         "Error - Unexpected Parameter"

         + TEST NUMBER :5.3.12

         + TITLE : Invalid Message Handling

         + SUBTITLE : Unexpected Parameter in MAUP messages

         + PURPOSE: To check that if a message containing an invalid parameter
           is received at ASP then the ASP responds with an ERROR message
           containing cause "Unexpected Parameter".

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

          EXPECTED MESSAGE SEQUENCE :

          SGP                             ASP                        SM+SU

                                      ASP is Active

          DATA Msg --------------------->
         (Parameter Tag = 0x13
          in place of 0x2 )

                    <--------------------ERROR
                            (Cause = Unexpected Parameter)

          DATA Msg ---------------->
          (Interface Id = X)
                                   Data receive Ind   --------->

    Manish Sharma, HSS                                          [Page 138]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       TEST DESCRIPTION:

       1. Send DATA message with a parameter other than Interface Identifier
          from SGP to ASP.

       2. Check A: ERROR message will be received at ASP containing Cause
           "Unexpected Parameter".

       3. Check B: State of ASP is not disturbed.

       4. Send a DATA Msg from SGP to ASP with valid parameters including
          Interface Identifier = X.

       5. Check C: A DATA Receive Indication is sent to SM.

       6. Repeat the above test case for other MAUP and ASPM messages.


         " ERROR Message Handling "

         + TEST NUMBER :5.3.13

         + TITLE : ERROR Handling

         + SUBTITLE : Handling of Received Error.

         + PURPOSE: To check that if an ERROR message is received then that is
           reported to the SM and no ERROR message is sent to peer which sent
           the ERROR message in the first place.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in Active state.

         EXPECTED MESSAGE SEQUENCE :

         SGP                               ASP                          SM+SU

                                       ASP is Active


         ERROR  --------------------->

    Manish Sharma, HSS                                          [Page 139]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

         (Cause = Invalid Version)

                                        Error Ind------------->

       TEST DESCRIPTION:

       1. Send ERROR message with Cause "Invalid Version" from SGP to ASP.

       2. Check A: M2UA at ASP should report the error to its SM.

       3. Check B: No ERROR message must be received at the SGP.

       4. Repeat the test case for other Cause values in ERROR message.



       Note: Further action at the SGP are implementation dependent and ERROR-
       Code dependent.
       SM may tear down the connection or no action may be taken.




        5.4 MAUP Messages

         5.4.1 Link Management Messages

         "Link Management"

         + TEST NUMBER :5.4.1

         + TITLE :  Link Management

         + SUBTITLE : Link Establish and Release Confirmation

         + PURPOSE: To check that if Establish Request Primitive is received
           from SU at ASP then M2UA at ASP sends ESTABLISH REQUEST message to
           SGP and if ESTABLISH CONFIRMATION is received from SGP then SU is
           indicated by M2UA that Establish Confirmation has been received.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between
           SGP and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :
    Manish Sharma, HSS                                          [Page 140]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         SGP                            ASP                           SU+SM

                                    ASP is Active

                                               <-----------Establish Request

             <------------------  ESTABLISH REQUEST

         ESTABLISH CONFIRMATION---->

                             Establish Confirmation-------->

                                               <------------Release request

             <------------------  RELEASE REQUEST

         RELEASE CONFIRMATION--------->

                              Release Confirmation--------->

       TEST DESCRIPTION:

       1. Send Establish Request primitive from the SU at the ASP to M2UA.

       2. Check A: ESTABLISH REQUEST message should be sent to the SGP.

       3. Send ESTABLISH CONFIRMATION message to the ASP in response to the
          received ESTABLISH REQUEST message with Interface Identifier X.

       4. Check B: Establish Confirmation indication should be sent to SU from
          M2UA at ASP.

       5. Repeat the above test case for Release Request primitive from SU
          at ASP to M2UA. RELASE REQUEST message should be received at SGP.
          Send RELEASE CONFIRMATION message in response to the received
          message.
          Check C: Release Confirmation indication should be sent to the SU
          from M2UA at ASP.







    Manish Sharma, HSS                                          [Page 141]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         "Link Management"

         + TEST NUMBER :5.4.2

         + TITLE :  Link Management

         + SUBTITLE : Release Indication message

         + PURPOSE: To check that if RELEASE INDICATION message is received at
           ASP then SU is reported of it.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                            SU+SM

                                     ASP is Active

         RELEASE INDICATION------------>

                                  Release Indication-------->


       TEST DESCRIPTION:

       1. Send RELEASE INDICATION message from SGP to ASP with Interface
          Identifier X.

       2. Check A: Release Indication primitive will be sent to SU from M2UA
          at ASP.












    Manish Sharma, HSS                                          [Page 142]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003




         "Link Management"

         + TEST NUMBER :5.4.3

         + TITLE :  Link Management

         + SUBTITLE : STATE REQUEST and CONFIRMATION message

         + PURPOSE: To check that if State request primitive is received from
           SU at ASP then STATE REQUEST message is sent from ASP to the SGP
           with state received from SU and if STATE CONFIRM message is
           received from SGP then SU is indicated of that.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                            ASP                             SU+SM

                                    ASP is Active

                                                          <-------State
                                                                 Request
                                                      (State =STATUS_EMER_SET)

             <-------------------  STATE REQUEST
                              (State = STATUS_EMER_SET)

         STATE CONFIRM----------->
         (State = STATUS_EMER_SET)

                                   State Confirm------------->

       TEST DESCRIPTION:

       1. Send State Request primitive with State parameter STATUS_EMER_SET
          from the SU at the ASP to M2UA and Interface Identifier X.

       2. Check A: STATE REQUEST message is sent to the SGP with the State

    Manish Sharma, HSS                                          [Page 143]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

          parameter STATUS_EMER_SET.

       3. Send STATE CONFIRM message to the ASP in response to the received
          message with Interface Identifier X.

       4. Check B: State Confirmation indication should be received at the SU.

       5. Repeat the above test case for other valid State parameter

          values(example - STATUS_LPO_CLEAR).

       6. Repeat the above test case for STATE INDICATION message from SGP to
          ASP. State Indication primitive should be received at the SU with
          the State received in STATE INDICATION message.



         "Link Management"

         + TEST NUMBER : 5.4.4

         + TITLE :  Link Management

         + SUBTITLE : Retrieval Request and Retrieval Confirm

         + PURPOSE: To check that if Retrieval Request primitive is received
           from SU at ASP with specified parameter values then RETRIEVAL
           REQUEST message is sent to SGP and if RETRIEVAL CONFIRM message is
           Received from SGP, the SU is indicated of that.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is Active.


         EXPECTED MESSAGE SEQUENCE :

         SGP                          ASP                          SU+SM

                                   ASP is Active

                                                    <-------Retrieval request
                                                    (Action = Action_Rtrv_BSN)

           <------------------  RETRIEVAL REQUEST
    Manish Sharma, HSS                                          [Page 144]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         RETRIEVAL CONFIRM----------->
         (Action = Action_Rtrv_BSN)

                                Retrieval  Confirm------------->

       TEST DESCRIPTION:

       1. Send Retrieval Request primitive from SU at ASP with Action
          parameter as Action_Rtrv_BSN and Interface Identifier X.

       2. Check A: RETRIEVAL REQUEST message will be received at SGP with
          Action parameter Action_Rtrv_BSN.

       3. Send RETRIEVAL CONFIRM message from SGP to ASP with Action parameter
          Action_Rtrv_BSN from SGP to ASP and with BSN as the value of
          Sequence Number field .

       4. Check B: Retrieval Confirm Indication primitive will be received at
          SU.

       5. Repeat the above test case for other value of Action Parameter i.e.
          ACTION_RTRV_MSGS. The results should be same.







         "Link Management"

         + TEST NUMBER :5.4.5

         + TITLE :  Link Management

         + SUBTITLE : Retrieval Indication and Retrieval Complete Indication

         + PURPOSE: To check that if RETRIEVAL INDICATION and RETRIEVAL
           COMPLETE INDICATION messages are received from SGP then SU are
           indicated of that.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP

    Manish Sharma, HSS                                          [Page 145]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                               and ASP. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                           ASP                           SU+SM

                                   ASP is Active

                                                <-----------Retrieval request
                                                     (Action=Action_Rtrv_BSN)
                                                     (Sequence Number = 0)

              <---------------  RETRIEVAL REQUEST
                              (Action=Action_Rtrv_BSN)
                              (Sequence Number = 0)

         RETRIEVAL CONFIRM--------------->
         (Action = Action_Rtrv_BSN)
         (Sequence Number = BSN)

                                  Retrieval Confirm------------->

                                                <-----------Retrieval request
                                                     (Action=Action_Rtrv_MSGS)
                                                     (Sequence Number = FSN)

             <---------------  RETRIEVAL REQUEST
                          (Action=Action_Rtrv_MSGS)
                          (Sequence Number = FSN)

         RETRIEVAL CONFIRM--------------->
         (Action = Action_Rtrv_MSGS)
         (Sequence Number = 0)




                                  Retrieval Confirm------------->

         RETRIEVAL INDICATION  ---------->
          (MSU from retransmit
            queue and not last MSU)

                                  Retrieval Indication---------->

         RETRIEVAL COMPLETE INDICATION--->
    Manish Sharma, HSS                                          [Page 146]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


          (MSU from retransmit
            queue and last MSU)
         (Interface Identifier = X)

                             Retrieval Complete Indication------------>

       TEST DESCRIPTION:

       1. Send Retrieval Request primitive from SU to M2UA at ASP with Action
          Action_Rtrv_BSN, no Sequence Number and Interface Identifier X.
          RETRIEVAL REQUEST message will be sent to SGP. In response to it
          send a RETRIEVAL CONFIRM message from SGP to ASP containing BSN as
          the Sequence Number.

       2. CHECK A: A Retrieval Confirm Indication primitive is sent to SU at
          ASP.

       3. Send Retrieval Request primitive from SU to M2UA at ASP with Action
          Action_Rtrv_MSGS, FSN as Sequence Number and Interface Identifier X.
          RETRIEVAL REQUEST message will be sent to SGP. In response to it
          send a RETRIEVAL CONFIRM message from SGP to ASP containing no
          Sequence Number.

       4. CHECK B: A Retrieval Confirm Indication primitive is sent to SU at
          ASP.

       5. Send RETRIEVAL INDICATION and RETRIEVAL COMPLETE INDICATION messages
          containing the MSUs to be retransmitted with the MSU in RETRIEVAL
          COMPLETE INDICATION to be last from the retransmission queue.

       6. CHECK C: Retrieval Indication and Retrieval Complete Indication
          primitive will be received at SU sent by M2UA at ASP.






         5.4.2 Data Transfer Messages

         "DATA Transfer Primitive"

         + TEST NUMBER : 5.4.6

         + TITLE : DATA Primitive at ASP

    Manish Sharma, HSS                                          [Page 147]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + SUBTITLE : Handling of DATA Primitive in AS active state

         + PURPOSE: To check that on receiving DATA Send primitive from SU,
           DATA message is sent to the SGP. Also on receiving DATA message
           from SGP, SU is given Receive Data Indication.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
                                and ASP. ASP is Active.

          EXPECTED MESSAGE SEQUENCE :

          SGP                           ASP                             SU+SM

                                    ASP is Active

                                                               <-------- Data
                                                            (Interface Id = X)
                   <----------------- DATA Msg

         DATA Msg --------------->
                                Data Receive Ind ------------->

       TEST DESCRIPTION:

       1. Send DATA Send Primitive from the SU at ASP side to send Protocol
          Data to the SGP with Interface Identifier = X.

       2. Check A: DATA message is received at the SGP containing the data and
          the Interface Identifier X passed by the SU at ASP.

       3. Send DATA message from SGP containing Protocol Data and Interface
          Identifier X to ASP.

       4. Check B: DATA Receive Indication is sent to SU.



         "TTC DATA Primitive"

         + TEST NUMBER : 5.4.7

         + TITLE :  TTC DATA Primitive

    Manish Sharma, HSS                                          [Page 148]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


         + SUBTITLE : Handling of TTC DATA Primitive in AS active state

         + PURPOSE: To check that on receiving TTC DATA primitive from SU,
           TTC DATA message is sent to the SGP. Also on receiving TTC DATA
           message from SGP, SU is sent Receive Data Indication.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
                                and ASP. ASP is active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                           ASP                            SU+SM

                                    ASP is Active

                                                  <------------- TTC Data
                 <----------------- TTC DATA Msg

         TTC DATA Msg --------------->
                                 TTC Data Receive Ind ------------->

       TEST DESCRIPTION:

       1. Send TTC DATA Send Primitive from SU to M2UA at ASP side to send
          Protocol Data to the SGP with Interface Identifier = X.

       2. Check A: TTC DATA message is received at the SGP containing the data
          and the Interface Identifier X passed by the SU at ASP.

       3. Send TTC DATA message from SGP containing Protocol Data and
          Interface Identifier X to ASP.

       3. Check B: TTC DATA Receive Indication primitive is sent to SU with
          the Protocol Data and Interface Identifier X.










    Manish Sharma, HSS                                          [Page 149]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



         "SCTP Stream Management"

         + TEST NUMBER :5.4.8

         + TITLE :  SCTP Stream Management

         + SUBTITLE : Stream Selection

         + PURPOSE: To check that all the messages for the same Interface
           Identifier are sent on the same SCTP stream.

         + TEST CONFIGURATION: E

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP with two streams. ASP is Active.

         EXPECTED MESSAGE SEQUENCE :

         SGP                              ASP                        SU+SM

                                      ASP is Active

                                                           <--------  Data
                                                           (Interface Id = X)
                     <----------------- DATA Msg

                                                           <--------  Data
                                                           (Interface Id = X)
                     <----------------- DATA Msg

                                                           <--------  Data
                                                           (Interface Id = X)
                     <----------------- DATA Msg

       TEST DESCRIPTION:

       1. Send three or more DATA Send Primitives with same Interface
          Identifier value X from the SU to M2UA at ASP side to send Protocol
          Data to the SGP.

       2. Check A: DATA messages are received at the SGP containing the same
          Stream Id.

       3. Repeat the above test with other Interface Identifier Y.
    Manish Sharma, HSS                                          [Page 150]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       4. Repeat the above case if number of streams between ASP and SGP is
          more than two but AS is handling only two Interface Identifiers. One
          or more streams may not be used for sending DATA message.


       4. Repeat the above case if number of streams between ASP and SGP is
          two but AS is handling four Interface Identifier. Send DATA messages
          for all Interface Identifier. DATA messages should be sent on both
          the streams and DATA messages for the same Interface Identifier are
          sent on the same stream.


       Note: How the messages will be distributed on different SCTP streams is
       implementation specific.








       6. Interface Identifier Management Messages

         "Dynamic Registration"

         + TEST NUMBER :6.1

         + TITLE :  Dynamic Registration

         + SUBTITLE : Dynamic Registration.

         + PURPOSE: To check that Dynamic Registration request and response
           messages are sent and received.

         + TEST CONFIGURATION: A (Both SGP and ASP under test)

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP in Active State. SGP supports Dynamic Registration.


         EXPECTED MESSAGE SEQUENCE :

         SM+SU              ASP                   SGP                SM + NIF

    Manish Sharma, HSS                                          [Page 151]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                        ASP is Active

         Reg Req------->
         (Single valid
          Link Key LK1)
                         REG REQ---------->
                         (Link Key = LK1)
                                                 REG Ind    -------->

                              <----------------- REG RSP
                                          (Reg. Status = SUCCESS
                                           Associated Interface Id)

               <-------- Reg Confirm

                              <----------------- REG RSP
                                          (Reg. Status = SUCCESS
                                           Associated Interface Id)

                         Error ------------>
                        (Cause = Unexpected message)

         Reg Req ------->
         (single valid
          link key LK1)

                        REG REQ---------->
                       (Link Key = LK1)


                              <----------------- REG RSP
                                   (Reg. Status = Error-Overlapping Link Key
                                       Interface Id = 0)


         Reg Req ------->
         (Multiple(n) Valid Link Keys)

                        REG REQ---------->
                        (Link Key = LK2,
                         Link Key = LK3,
                         .....)

                             <----------------- REG RSP
                                    (Reg. Status = SUCCESS
    Manish Sharma, HSS                                          [Page 152]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                    Associated Interface Id)

                                                      .

                                                      .

                                                      1 or more

                             <----------------- REG RSP
                                    (Reg. Status = SUCCESS
                                     Associated Interface Id)

       TEST DESCRIPTION:

       1. Send Reg Req primitive from SM to M2UA at ASP for single and valid
          link key LK1.

       2. CHECK A: REG REQ message for LK1 is sent to SGP from ASP.
          REG Indication is sent to the SM at SGP on receiving REG REQ.

       3. REG RES is sent to the ASP with result status SUCCESS, and
          corresponding associated Interface Identifier.
          Now again send an REG RES message from SGP to ASP with parameters
          same as the previous REG RES message sent to ASP.

       4. CHECK B: ASP sends an ERROR message with Cause "Unexpected message".

       5. Again send an Reg Req primitive from SM to M2UA at ASP for single
          and valid Link Key LK1 which has already been registered.

       6. CHECK C: REG RESP is sent to the ASP from SGP with Registration
          Status field containing "Error - Overlapping Link Key".
          The Interface Identifier field is set to 0.

       7. Send Reg Req primitive from SM to M2UA at ASP for multiple and valid
          Link Key LK2, LK3, etc.

       8. CHECK D: One or more REG RESP is sent to the ASP from SGP with
          appropriate result status. And all the REG RES messages are having
          same Local-LK-Identifier.


       Note: The response of ASP to a duplicate REG RES message from SGP is
       implementation specific. The ASP may silently discard such messages. In

    Manish Sharma, HSS                                          [Page 153]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       that case the CHECK in Line 4 above is inapplicable.


       Note: The multiplicity of REG RES messages in response to a single REG
       REQ message containing multiple Link Keys depends on implementation.






         "Dynamic Registration"

         + TEST NUMBER : 6.2

         + TITLE :  Dynamic Registration.

         + SUBTITLE : Registration of a Link Key at SGP.

         + PURPOSE: To check that on receiving a Link Key Registration Request
          for a valid and existing Link key from an ASP, the SGP adds it and
          confirms the registration to the ASP.
          Also if the SGP determines that the received Link Key data is
          Invalid or contains invalid parameters, the SGP returns a
          Registration Response message containing a Registration Result as
          appropriate.

         + TEST CONFIGURATION: D  (SGP and ASPs under test)

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP1 and ASP2. ASP1 is in Inactive and ASP2 is in Active State.
           Link Key LK2 is configured at the SGP side and it is for AS2.
           AS1 and AS2 have Interface Identifier as X and Y respectively.

         EXPECTED MESSAGE SEQUENCE :

         ASP                              SGP                     SM + NIF

                                     ASP1 is Inactive
                                     ASP2 is Active

                                                           <-------- Data
                                                           (Interface Id = X)

                                      Send Failure --------->

                                                           <-------- Data
    Manish Sharma, HSS                                          [Page 154]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                                                          (Interface Id = Y)
            (To ASP2)<-----------------DATA Msg

         REG REQ(ASP1) ----------------->
         (Link Key = LK2)
                                        Reg Ind  -------->

                     <----------------- REG RSP
                                (Reg Status = SUCCESS,
                                 Interface Id = Y)


                 Reg Confirm Primitive is sent to SM from M2UA at ASP



         ASPIA(ASP2)   ---------------->
         (Interface Id = Y)
                                      Status Ind ------->

             (To ASP2)<-------------- ASP-Inactive-Ack
             (To ASP2)<-------------- NTFY(AS-Pending)

                      Timer T(r) Expires

             (To ASP2)<-------------- NTFY(AS-Inactive)


                                                           <-------- Data
                                                          (Interface Id = Y)
                                    Send Failure --------->

         ASPAC(ASP1)   ---------------->
         (Interface Id = Y)
                                     Status Ind ------->

             (To ASP1)<------------  ASP-Active-Ack
             (To ASP1)<------------  NTFY(AS-Active)
                                                            <-------- Data
                                                           (Interface Id = Y)
             (To ASP1)<----------------DATA Msg


       TEST DESCRIPTION:

    Manish Sharma, HSS                                          [Page 155]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


       1. Send DATA Send primitive from NIF to M2UA at SGP with Interface Id =
          X. As it is for AS1 and AS1 has only one ASP, ASP1, which is in
         INACTIVE state now, DATA send will fail at SGP and a Failure
         Indication will be sent to NIF.

       2. Send DATA Send primitive from NIF at SGP with Interface Id = Y. As
          It is for AS2 and AS2 has only one ASP, ASP2, which is in ACTIVE
          state now, DATA Msg will be send to ASP2.

       3. Send REG REQ for Link Key LK2 from ASP1 to SGP.

       4. Check-A: M2UA at SGP will send REG Indication to SM and REG RSP with
          result (SUCCESS, Interface Identifier = Y) will be sent to ASP.
          And Reg Confirm primitive will be sent to SM at ASP.

       6. Send ASPIA from ASP2 to SGP for Interface Identifier = Y. Now AS2
          and ASP2 will be inactive. Send DATA Send primitive from NIF at SGP
          for Interface Identifier = Y, this will Fail as AS2 is Inactive now.

       6. Send ASPAC from ASP1 to SGP for Interface Identifier = Y.

       7. Check-B: AS2 and ASP1 becomes active.

       8. Send DATA Send primitive from NIF to M2UA at SGP for Interafce Id Y.

       9. Check C: DATA Msg will be sent to ASP1 from SGP.


       In addition to the above Tests perform the following DOs and CHECKs for
       the mentioned results.

       DO-1: Send REG REQ from ASP to SGP with a Link Key such that, the sent
       Link Key is already configured at the SGP, the sending ASP is not
       within the list of ASPs of the corresponding AS, but addition of ASP is
       not allowed(REG REQ is not authorized) at SGP.

       CHECK-1: REG RES with Registration Status "Error - Permission Denied"
       is sent to ASP.

       DO-2: Send REG REQ from ASP to SGP with a link key such that, the sent
       Link key is already configured at the SGP, the sending ASP is already
       within the list of ASPs of the corresponding AS, and addition of ASP is
       allowed(REG REQ is supported) at SGP.

       CHECK-2:REG RES with Registration Status "Error - Overlapping Link Key"
    Manish Sharma, HSS                                          [Page 156]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


               is sent to ASP.

       DO-3: Send REG REQ from ASP to SGP with a Link Key such that, the sent
       Link Key is valid but not configured at the SGP, the sending ASP is not
       within the list of ASPs of the corresponding AS, and dynamic
       configuration of ASP is supported at SGP.

       CHECK-3: M2UA at SGP will send REG Indication to SM and REG RSP with
                result (SUCCESS, Associated Interface Id) will be sent to ASP.
                Also check that the Interface Identifier sent is unique.

       DO-4: Send REG REQ from ASP to SGP with a Link Key such that, the sent
       Link Key is valid but not configured at the SGP, the sending ASP is not
       within the list of ASPs of the corresponding AS, and dynamic
       configuration of ASP is not supported at SGP.

       CHECK-4:REG RES with Registration Status "Error - Link Key not
               Provisioned" is sent to ASP.

       DO-5: Send REG REQ from ASP to SGP with a Link Key such that, the sent
       Link Key is invalid.

       CHECK-5:REG RES with Registration Status "Error - Invalid Link Key" is
               sent to ASP.

       DO-6: Send REG REQ from ASP to SGP with a Link Key such that, the sent
       Link Key has invalid Signaling Data Link Identifier(SDLI).

       CHECK-6: REG RES with Registration Status "Error - Invalid SDLI" is
                sent to ASP.

       DO-7: Send REG REQ from ASP to SGP with a Link Key such that, the sent
       Link Key has invalid Signaling Data Terminal Identifier (SDTI).

       CHECK-7: REG RES with Registration Status "Error - Invalid SDTI" is
                Sent to ASP.

       DO-8: Send REG REQ from ASP to SGP with a Link Key such that the sent
       Link key is valid but not configured at the SGP, the sending ASP is not
       Within the list of Asps of the corresponding AS, dynamic configuration
       Of ASP is supported at SGP, and SGP has no more capacity to add new
       Link Key entry or AS entry.

       CHECK-8: REG RES with Registration Status "Error - Insufficient

    Manish Sharma, HSS                                          [Page 157]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

                Resources" is sent to ASP.







         "Dynamic De-Registration"

         + TEST NUMBER: 6.3

         + TITLE:  Dynamic De-Registration

         + SUBTITLE: Dynamic De-Registration.

         + PURPOSE: To check that Dynamic De-Registration request and
                    response messages are sent and received.

         + TEST CONFIGURATION: A (Both SGP and ASP under test)

         + PRE-TEST CONDITIONS: SCTP association is established between SGP
           and ASP. ASP is in Inactive State.

         EXPECTED MESSAGE SEQUENCE:

         SM+SU               ASP                      SGP             SM + NIF

                                  ASP is Inactive

         DeReg req------->
         (Single valid
          Interface Id = X)

                         DEREG REQ---------->
                         (Interface Id = X)
                                                   DeReg Ind    -------->

                               <-----------------   DEREG RSP
                                                (Interface Id = X
                                                 De-Reg Status = SUCCESS)

                               <-----------------   DEREG RSP
                                                (Interface Id = X
                                                 De-Reg Status = SUCCESS)

                         Error ----------->
    Manish Sharma, HSS                                          [Page 158]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003


                  (Cause = Unexpected Message)

         DeReg req------->
         (Single valid
          Interface Id = X)

                        DEREG REQ---------->
                        (Interface Id = X)


                               <---------------    DEREG RSP
                                              (Interface Id = X
                                       De-Reg Status = Error - Not Registered)
         De-Reg req------->
         (Multiple(n) valid Interface Identifier)

                        DEREG REQ---------->
                       (Interface Identifier = ID1,
                        Interface Identifier = ID2,
                        .....)

                               <----------------- DE-REG RSP
                                             (Interface Id = ID1
                                                   De-Reg Status )
                                             (Interface Id = ID2
                                                   De-Reg Status )
                                                      .

                                                      .

                                                      .
                                             (Interface Id = IDn
                                                   De-Reg Status )

       TEST DESCRIPTION:

       Do the following and check for the mentioned results.

       1. Send DeReg Req primitive from SM to M2UA at ASP  for single and
          valid Interface Identifier X.

       2. CHECK A: DEREG REQ messages for Interface ID X is sent to SGP from
          ASP.


    Manish Sharma, HSS                                          [Page 159]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003

       3. M2UA at SGP sends DEREG Indication to the SM on receiving DEREG REQ
          message from ASP.
          DEREG RES is sent to the ASP with De-Registration Status SUCCESS,
          and corresponding Interface Identifier as in the DEREG REQ message.
          Now again send DEREG RES message from SGP to ASP with parameters
          same as the previous DE-REG RESP message sent to ASP.

       4. CHECK B: ASP sends an ERROR message with Cause "Unexpected message".

       5. Send DeReg Req primitive from SM to M2UA at ASP for single and valid
          Interface Identifier X when the ASP is no more registered in AS.

       6. CHECK C: DEREG RES is sent to ASP from SGP with De-Registration
          Status "Error - Not Registered".

       7. Send DeReg Req primitive from SM to M2UA at ASP with multiple and
          valid Interface Identifiers ID1, ID2, etc for which the ASP is
          registered.

       8. CHECK D: One DEREG RES is sent to the ASP from SGP with appropriate
          De-Registration Status for all Interface Identifiers in the DEREG
          REQ message. Also check that De-Reg Result for each Interface
          Identifier in DEREG REQ message also includes that Interface
          Identifier.

       In addition to the above Tests perform the following DOs and CHECKs for
       the results as mentioned:

       DO-1:Send DEREG REQ from ASP to SGP for single and invalid Interface
       Identifier.

       CHECK-1:DEREG RES is sent to the ASP from SGP with De-Registration
               Status "Invalid Interface Identifier".


       Note: The de-registration procedure does not necessarily imply the
       Deletion of Link Key and Application Server configuration data at the
       SG. Other ASPs may continue to be associated with the Application
       Server, in which case the Link Key data CANNOT be deleted.  If a De-
       registration results in no more ASPs in an Application Server, an SG
       MAY delete the Link Key data.





    Manish Sharma, HSS                                          [Page 160]

    Internet Draft         M2UA Conformance Test Plan                Oct 2003



       7. Acknowledgements

       The author would like to thank puneet dhal who has done
       a great job and completed this test spec effectively,
       Dipak Bash, Satyendra Kumar Varshney, Yogesh Gahlaut and Sandeep
       Mahajan  for their insightful comments and suggestions.


       8. Authors' Addresses

          Manish Sharma

          Hughes Software Systems

          Electronic City, Plot 17,

          Sector 18, Gurgaon - 122015.

          Harayana, India

          EMail: sharmam@hss.hns.com



       9. References

       [M2UA]    :  SS7 MTP2-User Adaptation Layer (M2UA)

                     RFC 3331

       [2960]    :  RFC 2960 "Stream Control Transport Protocol"

                      R. Stewart, et al, November 2000.

       [ITU-MTP] :  ITU-T Recommendations Q.701-Q.705, 'Signaling

                    System No. 7 (SS7) - Message Transfer Part (MTP)'