About SGSN Testing
With the UMTS test case, you can test both the control and bearer planes of an SGSN's Gb or Iu-PS interfaces and its Gn interface, and a GGSN's Gi interface. When you test the Iu-PS interface, you can choose to use either SS7-based or IP-based signalling and test with Ethernet physical layers. This topic describes the protocols used in both planes and the messages used to perform basic procedures.
Control Plane Protocols
A suite of control protocols form the Iu-PS and Gb interfaces. These protocols can be divided into three layers: transport, radio, and system. The transport layer provides general purpose transport of control messages between network elements. The radio layer manages radio access from the MN to the SGSN. The system layer manages the interworking of network elements, MN access to the core network, mobility management, and the GTP tunnels used for control and bearer plane traffic.
Iu-PS Interface
The diagram below shows the protocol stacks and interfaces involved in Iu-PS control plane testing with an SS7 transport layer. As part of the test definition, you will define the attributes and behaviors of the upper layers of the RNC side of the Iu-PS interface (shown in blue). When the test simulates a GGSN, you can also define the GGSN side of the Gn interface.
You can also test the Iu-PS interface using an IP-based control stack. In this configuration, you have the choice of using an Ethernet physical layer, as shown.
Transport Layer
Transport layer protocols are defined on the IuPS tab. You may define the following layers in the test case:
-
Message Transfer Part level 3 - Broadband (MTP3-B) — MTP3-B provides point-to-point message routing in SS7 over a broadband medium.
-
Stream Control Transmission Protocol (SCTP) — SCTP is a reliable transport protocol that can transport PSTN signalling messages over IP networks.
-
Message Transfer part level 3 - User Adaption layer (M3UA) — M3UA supports MTP3-B signalling, such as SCCP, over IP.
-
Signalling Connection Control Part (SCCP) — SCCP provides the means for end-to-end transport in SS7 and is used to provide a common interface to RANAP for both SS7 and IP network protocols.
Radio Layer
The radio layer — Radio Access Network Application Part (RANAP) — is also defined on the IuPS tab. RANAP provides RNC link management (the Iu connection between an RNC and SGSN) and Radio Access Bearer (RAB) management for MNs, including RAB mobility management and signal integrity.
Gb Interface
The diagram below shows the protocol stacks and interfaces involved in Gb control plane testing. As part of the test definition, you will define the attributes and behaviors of the upper layers of the BSS side of the Gb interface. When the test simulates a GGSN, you can also define the GGSN side of the Gn interface.
Transport Layer
Transport layer protocols are defined on the Gb tab. The following layers are definable in the test case:
-
Network Service (NS) — Transports BSSGP PDUs.
-
Base Station System GPRS Protocol (BSSGP) — Conveys routing and QOS-related information between a BSS and an SGSN.
Radio Layer
-
The radio layer — Logical Link Control (LLC) — provides a highly reliable ciphered logical link between the MN and the SGSN and it is also defined on the Gb tab. In addition to ciphering, LLC is responsible for sequence control, flow control, and error detection, notification, and recovery.
System Layer
The system layer protocols are the same for both the Iu-PS and Gb interfaces, and they are defined on the MN tab. The Gn system layer is defined on the Gn tab when an emulated GGSN is used. The system layer is responsible for managing MN access control, mobility management, and PDP context management.
-
GPRS Mobility Management (GMM) — GMM provides MN connection management including attaching the MN to the Core Network (CN), authentication services, location management, and detaching the MN from the CN. A successful attachment creates a GMM context.
-
Session Management (SM) — After a GMM context has been established, SM provides MN PDP context management including context activation, modification, and deactivation.
-
GPRS Tunneling Protocol (Control) (GTP-C) — GTP-C provides GTP tunnel management for the Gn interface and is used to tunnel control plane messages across the Gn interface.
Bearer Plane Testing
The bearer, or user, plane provides general purpose transport of IP-based application data between an MN and an application server (Network Host). When you add Data Traffic to the test, you can define the application layer protocols and messages for both the MN and Network Host sides of the data stream. When the test simulates the GGSN, you can select the PDP and define the IP addresses that will be assigned to the PDP contexts.
Iu-PS Interface
Bearer plane transport is based on TCP/IP rather than SS7, with UDP and IP occupying the transport and network levels. The application level can be carried by IPv4 or IPv6 payload data protocols depending on the GGSN's configuration. Bearer plane traffic traverses the Iu-PS and Gn interfaces via the GTP-U tunnels managed by the control layer.
Gb Interface
The Sub-Network Dependent Convergence Protocol (SNDCP) provides multiplexing, compression, decompression, segmentation, and re-assembly services for the layers above LLC. It is responsible for mapping network-level characteristics onto the characteristics of the underlying network.
Basic UMTS Procedures
In the default configuration, a UMTS test simulates a number of RNCs that each establish a number of links with an SGSN and then begins to attach simulated MNs to the SGSN and activate MN PDP contexts with the GGSN. The test can also simulate a Network Host for bearer plane testing. The procedures that accomplish these events are generally described below.
The messages in the diagram below represent simple, successful transactions and do not encompass all of the message supported by the UMTS application. Since the MNs and RNCs are simulated, no actual messages are exchanged between them.
GPRS Attach
After all of the RNC links have been established, the test begins to attach MNs to the SGSN SUT with RANAP messages containing GMM payloads. The RNC node establishes an SCCP connection with the SUT and sends a RANAP Initial UE with a GMM Attach Request payload. The SUT responds with an Identity Request and the MN replies with an Identity Response containing an IMSI, IMEI, IMEISV, or an invalid P-TMSI depending on the method you select.
If the MN's identity is validated, the SUT sends an Authentication Request containing an authentication challenge and the cipher keys necessary to calculate the MN's response. The MN replies with an Authentication Response.
If the MN is successfully authenticated, the SUT and the RNC node exchange RANAP Security Mode messages that establish the encryption method and integrity algorithm that will protect control and bearer plane signalling.
The SUT completes the attachment with an Attach Accept, which the MN acknowledges with an Attach Complete. At this point the MN can begin to activate PDP contexts with the GGSN.
In a Session Loading test, where MNs are re-attached after detaching, the MN will attempt to attach with the P-TMSI obtained in a previous iteration by default. If the SGSN determines that the P-TMSI is still valid, it can bypass the identity, cipher, and security mode exchanges and respond to the Attach Request with an Attach Accept. You can configure the test to always use an invalid P-TMSI during re-attach attempts.
PDP Context Activation
If PDP contexts are enabled, the test waits for any PDP Context Activate Delay after the MN has successfully attached to the SGSN SUT, and then attempts to activate the defined number of PDP contexts with the GGSN using RANAP and SM. The RNC node sends a RANAP message with an SM Activate PDP Context Request payload to the SGSN. The SGSN in turn, sends a GTP Create PDP Context Request to the GGSN.
The GGSN validates the context request and if it is valid, the GGSN assigns an IP address to the PDP context (if an address was requested), establishes its end of the GTP-U tunnel and replies to the SGSN with a Create PDP Context Accept message containing the tunnel and context information. When the SGSN receives the context accept, it establishes its end of the GTP-U tunnel with the GGSN.
After the SGSN-GGSN tunnel is established, the SGSN sends a RAB Assign Request to the RNC with the tunnel information. If the RNC can successfully establish a RAB for the PDP context, it replies with a RAB Assign Response containing its tunnel information. On receipt of the RAB response, the SGSN establishes its end of the RNC-SGSN tunnel and replies to the RNC with an SM Activate PDP Context Accept. The PDP context is now fully established and ready for user plane traffic.
PDP Context Deactivation
An MN initiates a context deactivation by sending an SM Deactivate PDP Context Request to the SGSN. The SGSN sends a Delete PDP Context Request to the GGSN, triggering the GGSN to release the context and tear down its tunnel with the SGSN. Upon completion, the GGSN replies with a Delete PDP Context Accept, allowing the SGSN to tear down its tunnel with the GGSN.
After the SGSN-GGSN tunnel has been torn down, the SGSN notifies the RNC with a RAB Release Request. The RNC tears down its tunnel with the SGSN and replies with a RAB Release Response. The SGSN then tears down its tunnel with the RNC, completing the deactivation, and replies with a Deactivate PDP Context Accept that notifies the MN of the context deactivation.
GPRS Detach
After all of its PDP contexts have been torn down, the MN detaches its IMSI from the SGSN with a GMM Detach Request. If the signalling connection has been released, the request will be sent in an Initial UE Message rather than a Direct Transfer message. The SGSN responds with a Detach Accept, and the MN is free to attach to another network.
The example message flow shows an MN-initiated detach but the network can also initiate a detach for various reasons. In that case, the SGSN sends the Detach Request to the MN and deactivates any active PDP contexts, and the MN responds with a Detach Accept.
Iu Release
The Iu Release procedure releases the MN's signalling connection with the SGSN without detaching the MN. A release can be initiated by either the RNC or the SGSN. An RNC can initiate a release due to user inactivity or a UTRAN-related reason, such as signal loss or an O&M event. The SGSN can initiate a release due to user inactivity, after it completes a transaction with the MN, at the completion of a successful SRNS relocation, or when a relocation is cancelled.
The RNC initiates an Iu release by sending an Iu Release Request to the SGSN, triggering the SGSN to begin the release procedure. The SGSN initiates a release, or responds to an RNC-initiated release, with an Iu Release Command. On receipt of the release command, the RNC releases the resources associated with the connection and then returns an Iu Release Complete to the SGSN. The SGSN releases the signalling resources and the procedure is complete.
You can trigger an RNC-initiated Iu Release during a test with the Signalling Connection setting on the SM sub-tab. When an MN's connection has been released, the Paging and Service Request procedures may be used to re-establish the connection.
Paging and Service Request
The Paging procedure is used by the SGSN to request that an MN establish an Iu signalling connection, and is initiated with a RANAP Paging Request sent to the MN via its RNC. The SGSN may page the MN when it receives a data packet addressed to one of the MN's PDP contexts, when it is necessary to execute an SM transaction such as a PDP context modification, or to prompt the MN to re-attach after a network failure.
The Service Request procedure is initiated by the MN in order to establish a signalling connection. Receipt of a Paging Request can trigger this procedure, or it can be triggered when the MN attempts to send a data packet or an SM message (deactivate an existing context or create a new context) and a suitable connection does not exist. The MN indicates the type of connection requested (signalling, data, or paging response) in the Service Request. You can configure a test to perform a Service Request prior to PDP context activation by defining a PDP Context Activate Delay time that exceeds the idle time threshold provisioned on the SGSN, causing the SGSN to release the signalling connection.
The SGSN determines, based on the cipher key sequence number and P-TMSI contained in the Service Request whether it is necessary to perform the GMM identification or authentication and ciphering procedures (see GPRS Attach). The security mode control procedure is always performed, as shown in the message flow.
If the MN requested a data connection, the SGSN requests the RNC to establish RABs for the MN's PDP contexts. When it receives the RAB Assign Response from the RNC, the SGSN completes the Service Request procedure by sending a Service Accept message to the MN unless the Service Request was triggered by a Paging Request. The MN can then send data packets. If the MN requested a signalling or paging response connection, the procedure is completed and the MN can send SM or RANAP messages after it receives the Security Mode Complete message.
Routing Area Update
The Routing Area Update (RAU) procedure informs the SGSN of the current location of an MN. The MN always initiates the procedure, and can do so on a periodic basis or whenever it detects that it has entered a new routing area. You can configure the timing of periodic updates in your test and select a Mobility or Session Loading with Mobility test activity to simulate an MN moving into a new routing area within the UTRAN.
This example shows the procedure that is performed during an intra-SGSN handoff between two RNCs. The MN initiates the procedure by sending an RAU request containing the new routing area to the SGSN.
The SGSN notifies the old RNC of the MN movement with an SRNS Context Request that contains a list of RABs associated with the MN. The old RNC stops forwarding packets to the MN, starts buffering those packets, and responds with the next uplink and downlink GTP sequence numbers for each RAB.
At this point, the SGSN may initiate RAB establishment with the new RNC or it may wait until the procedure is complete. You can use the Early RAB Assignment checkbox in the RANAP settings to trigger RAB establishment at this point in the update procedure.
The SGSN then issues a data forward command containing the list of affected RABs to the old RNC, indicating that the RNC should forward the buffered packets to the SGSN for delivery to their final destination. After the packets have been received, the SGSN directs the old RNC to release the MN's Iu connection.
The SGSN completes the procedure with a Routing Area Update Accept, which may contain a new P-TMSI, and the MN confirms the end of the procedure with a Routing Area Update Complete message.
Combined Hard Handoff and SRNS Relocation Procedure
The Combined Hard Handoff and Serving Radio Network System (SRNS) Relocation procedure moves the RNC end of the RNS-SGSN connection from one RNC to another RNC when an Iur interface (RNC-RNC) is not available. In this case, the handoff is initiated by the MN's serving RNC (source RNC) when the RAN determines that the MN should be serviced by a different RNC (target RNC). Since the source and target RNCs cannot communicate directly, all of the PDP context information and forwarded data packets are transferred to the target RNC through the SGSN. If the MN's routing area changes in the process, this procedure is followed by a Routing Area Update without the context transfers.
The source RNC initiates the procedure by sending a Relocation Required message to the SGSN. The SGSN notifies the target RNC of the potential handoff with a Relocation Request and includes information about the RABs to be established.
After the target RNC has successfully allocated resources for the requested RABs and the Iu connection, it acknowledges the relocation request and includes tunnel endpoint information for the SGSN and the radio information necessary for the MN to establish a connection. At this point, the target RNC is ready to receive packets destined for the MN.
When the SGSN is prepared for the relocation, it issues a Relocation Command to the source RNC and indicates, based on the QOS profile, the RABs subject to data forwarding. The source RNC can then begin to forward acceptable downlink packets addressed to the MN to the target RNC through the Iu interface. The target RNC can choose to either buffer or discard any packets received based on QOS.
The source RNC transfers the serving RNC role to the target RNC by sending a Forward SRNS Context message that contains the next uplink and downlink sequence numbers for each RAB subject to data forwarding. The target RNC assumes the serving RNC function and sends a Relocation Detect message to the SGSN when the MN has established a connection. The new serving RNC initiates the termination of the relocation procedure with a Relocation Complete message to the SGSN.
After it receives the Relocation Complete, the SGSN directs the source RNC to release the MN's old Iu connection. The source RNC releases the Iu resources when its data forwarding timer expires and responds with a Release Complete, triggering the SGSN to release the Iu resources for this connection.
This procedure can optionally be included in a Mobility or Session Loading with Mobility test with the Perform Serving RNS Relocation Procedure checkbox.