40
© Nokia Networks Oy 1 (40) 2G SGSN SG5 OM Integrating TCP/IP Interfaces in 2G SGSN Configuration and Integration

Integrating Tcpip Interfaces_sg5_final

Embed Size (px)

Citation preview

Page 1: Integrating Tcpip Interfaces_sg5_final

© Nokia Networks Oy 1 (40)

2G SGSN SG5 OM

Integrating TCP/IP Interfaces in 2G SGSN Configuration and Integration

Page 2: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

2 (40) © Nokia Networks Oy

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia Networks' customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia Networks and the customer. However, Nokia Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Networks will, if necessary, explain issues which may not be covered by the document.

Nokia Networks' liability for any errors in the document is limited to the documentary correction of errors. Nokia Networks WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according to the applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only.

Copyright © Nokia Networks Oy 2005. All rights reserved.

Page 3: Integrating Tcpip Interfaces_sg5_final

Contents

© Nokia Networks Oy 3 (40)

Contents

1 Objectives................................................................................... 4

2 Introduction ................................................................................ 5

3 Protocol stacks .......................................................................... 7 3.1 Gn interface ................................................................................. 7 3.1.1 GPRS Tunneling Protocol (GTP) ................................................. 7 3.2 Gb interface ................................................................................. 8 3.2.1 Gb over IP load sharing ............................................................... 9 3.3 SS7 over IP (SIGTRAN) interfaces............................................ 11 3.3.1 M3UA ......................................................................................... 12 3.3.2 SCTP ......................................................................................... 12 3.3.3 Association sets and associations ............................................. 13 3.3.4 SGP-ASP communication.......................................................... 13 3.3.5 Basic Configurations of SS7 signalling over IP.......................... 14

4 Integration ................................................................................ 16 4.1 Configure network interfaces ..................................................... 16 4.1.1 Redundant interfaces................................................................. 16 4.1.2 Physical and logical IP addresses ............................................. 17 4.2 Create routes ............................................................................. 18 4.3 Gn interface configuration.......................................................... 19 4.3.1 Create domain name server ...................................................... 19 4.4 Gb over IP configuration ............................................................ 20 4.5 SS7 over IP configuration .......................................................... 20

5 Session Management .............................................................. 22 5.1 PDP Context Activation.............................................................. 23 5.2 PDP Context Deactivation procedure ........................................ 27 5.2.1 PDP context deactivation initiated by MS .................................. 28 5.3 PDP Context Modification procedure......................................... 29 5.4 Exercises ................................................................................... 29 5.4.1 Define IP interface parameters .................................................. 29 5.4.2 Activate a PDP Context ............................................................. 30

6 QoS – Quality of Service ......................................................... 31 6.1 QoS Mapping ............................................................................. 32 6.2 ARP support in admission control .............................................. 35 6.3 Operator configurable DiffServ Codepoints ............................... 35 6.4 Weighted Far Queuing (WFQ) and Random Early

Detection (RED)......................................................................... 36 6.5 Service-based QoS control ........................................................ 37 6.6 Secondary PDP contexts ........................................................... 38 6.7 TCP Optimisation....................................................................... 39

Page 4: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

4 (40) © Nokia Networks Oy

1 Objectives

After this session the participant should be able to:

Describe the TCP/IP protocol stack used by the 2G SGSN

Configure the Gn interface

Configure the Gb interface over IP

Configure the SS7 interfaces over IP

List Session Management procedures

Explain QoS and related parameters in Nokia 2G SGSN

With reference to any documentation.

Page 5: Integrating Tcpip Interfaces_sg5_final

Introduction

© Nokia Networks Oy 5 (40)

2 Introduction

Nokia 2G SGSN gives the operator the option of implementing any of its interfaces over an IP network. Each computer unit includes an IP protocol stack, and therefore they can be individually configured to act as an IP host or IP router. The units can be connected to each other via LAN, and every unit includes a redundant network interface.

Since Release SG3 of Nokia 2G SGSN there is also the option to configure the SS7 and Gb interfaces over IP. Both interfaces were already described in previous modules. This module describes only the IP transmission option for these interfaces.

Gn and Ga interface are originally IP-based interfaces. The Gn interface allows the SGSN to communicate with other GPRS Support Nodes (GSNs) via the IP-based GPRS backbone (Figure 1). The main connection is to the GGSNs that offer access to external data networks. In addition, connections are also needed to other SGSNs to support inter-SGSN routing area updates, for instance. The Gn interface is used for both transmission of user packet data and for the signalling needed in mobility and session management support between the GSN elements.

Ga interface will be covered in module “Integrating Ga interface”.

Figure 1. Gn interface location

Page 6: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

6 (40) © Nokia Networks Oy

A LAN Unit (LANU) is introduced in Release SG5. Each LANU contains two ESB26 switches where the redundant Ethernet interfaces connect. More about LANU can be found in module “SGSN Architecture”.

Page 7: Integrating Tcpip Interfaces_sg5_final

Protocol stacks

© Nokia Networks Oy 7 (40)

3 Protocol stacks

3.1 Gn interface

Figure 2. Gn protocol stack

Figure 2 illustrates the Gn protocol stack. It consists of the following layers:

Layers 1 & 2, compliant with Ethernet standards 10BaseT or 10BaseTX

Internet Protocol version 4 (IPv4) or version 6 (IPv6)

User Datagram Protocol (UDP)

GPRS Tunnelling Protocol (GTP).

3.1.1 GPRS Tunneling Protocol (GTP)

The GPRS Tunneling Protocol (GTP) is the protocol used between GPRS Support Nodes (GSNs) in the UMTS/GPRS backbone network. Nokia 2G SGSN supports both versions of GTP: GTPv0 and GTPv1. Among other differences, GTPv1 procedures are separated: GTP control plane (GTP-C) and data transfer (GTP-U) procedures.

GTP (GTP-C and GTP-U) is defined for the Gn interface, i.e. the interface between GSNs within a PLMN. GTP allows multi-protocol packets to be tunneled through the UMTS/GPRS Backbone between GSNs.

In the control plane, GTP specifies a tunnel control and management protocol (GTP-C) which allows the SGSN to provide packet data network access for an MS. Control Plane signalling is used to create, modify and delete tunnels.

In the user plane, GTP uses a tunneling mechanism (GTP-U) to provide a service for carrying user data packets.

Page 8: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

8 (40) © Nokia Networks Oy

In GPRS no other systems need to be aware of GTP. UMTS/GPRS MSs are connected to an SGSN without being aware of GTP.

Nokia 2G SGSN implementing GTP protocol version 1 is able to fallback to GTP protocol version 0.

Control plane (GTP-C)

The control plane relates to GPRS Mobility Management functions like for example GPRS Attach, GPRS Routing Area Update and Activation of PDP Contexts. The GPRS Tunneling Protocol-Control plane (GTP-C) performs the control plane signalling between GSN nodes.

The GTP-C control plane flow is logically associated with, but separate from, the GTP-U tunnels. For each GSN-GSN pair one or more paths exist. One or more tunnels may use each path. GTP-C shall be the means by which tunnels are established, used, managed and released. A path may be maintained by keep-alive echo messages. This ensures that a connectivity failure between GSNs can be detected in a timely manner.

User plane (GTP-U)

GTP-U Tunnels are used to carry encapsulated T-PDUs and signalling messages between a given pair of GTP-U Tunnel Endpoints. The Tunnel Endpoint ID (TEID) which is present in the GTP header shall indicate which tunnel a particular T-PDU belongs to. In this manner, packets are multiplexed and de-multiplexed by GTP-U between a given pair of Tunnel Endpoints. The TEID value to be used in the TEID field shall be negotiated for instance during the GTP-C Create PDP Context procedure that takes place on the control plane.

3.2 Gb interface

The Gb interface in the 2G SGSN can be implemented so that the subnetwork is based on IP and the physical layer is Ethernet (Figure 3). With the Gb over IP feature, the NS-VC is a pair of UDP/IP addresses: one UDP/IP address in the BSS and another in the 2G SGSN, in other words, the NS-VC is composed by IP endpoint addresses. Both IP and FR-based Gb interfaces exist parallel in the same 2G SGSN. Statistics on the number of packets gone through the NS-VCs towards the BSS are collected so that the operators have a possibility to see the traffic distribution between the FR and IP subnetworks.

Based on the nature of IP, the NS-VC is a pair of IP endpoint addresses, one IP endpoint address in the BSS and another in the 2G SGSN. These IP endpoint addresses may be configured statically or dynamically. Static and dynamic configuration cannot be used in the same Network Service Entity (NSE).

Page 9: Integrating Tcpip Interfaces_sg5_final

Protocol stacks

© Nokia Networks Oy 9 (40)

Figure 3. Gb over IP protocol stack

The static configuration appears when the operator creates an IP NS-VC into the 2G SGSN PAPU by giving the PAPU unit index, NS-VC identifier, name of the NS-VC, NSE identifier, local UDP port number, remote IP endpoint, remote IP endpoint's data weight and remote IP endpoint's signalling weight. The same IP endpoint and weight parameters of the NS-VC must be given from the BSS side as well.

In the static configuration the local endpoint parameters are known and need to be input for configuration. In the dynamic operation the local endpoint parameters are set and the remote endpoint parameters are found with the help of the auto-configuration procedures. In that case the BSS knows at least one 2G SGSN IP endpoint (a pre-configured IP endpoint) to initiate the procedures. Auto-configurations are initiated by the BSS.

3.2.1 Gb over IP load sharing

The load sharing function distributes user data traffic among the available IP endpoints in the Gb interface.

In traditional stand-alone PAPU configuration, as each NSEI in Nokia 2G SGSN has only one local IP endpoint, load sharing is done according to remote IP endpoints. The remote IP endpoint weights are given using GPRS NS Layer Handling MML in the static configuration or using dynamic configuration.

Page 10: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

10 (40) © Nokia Networks Oy

Figure 4. IP NS-VC configuration for stand-alone PAPU

IP load sharing in PAPU group

Since the PAPU group can support up to 16 local IP endpoints in each NSE (one endpoint per NSE in each PAPU), load sharing is done also between the local IP endpoints in addition to weighted remote endpoint selection.

Local IP endpoint is selected according to general 2G SGSN Link Selector Parameter (LSP) rules, which are common to Frame Relay and IP sub-networks. By default, the local endpoint selected from the same unit, which has MS's BVC-control. If the default endpoint is not available, then endpoint is selected from the unit which controls the MS, or finally from any available unit which belongs to the same NSE.

Figure 5. IP NS-VC configuration for PAPU group

Page 11: Integrating Tcpip Interfaces_sg5_final

Protocol stacks

© Nokia Networks Oy 11 (40)

Resource Distribution

The Resource Distribution function allows the BSS or the 2G SGSN temporarily change the IP endpoint to which it receives NS SDUs, disregarding IP endpoint weights and thus overriding the Load Sharing function for the selection of the remote IP endpoint. The Nokia 2G SGSN does not initiate Resource Distribution, but supports it if the BSS requests it.

3.3 SS7 over IP (SIGTRAN) interfaces

Figure 6. SS7 over IP protocol stack

The SS7 over IP feature is based on protocols that have been standardised in the IETF SIGTRAN working group, ensuring interoperability with other network elements that support signalling over an IP network.

IETF SIGTRAN protocols change the three lowest layers (Message Transfer Part (MTP) layers 1-3) of narrowband SS7 signalling protocol stacks, while the upper layers stay the same as with PCM based signalling. The main enabling protocol for IP-based signalling transfer is the Stream Control Transmission Protocol (SCTP). This protocol was specifically designed to support capabilities similar to those found in Message Transfer Part (MTP), but on an unreliable IP transport.

SS7 signalling transport over IP contains several user adaptation layers, however, here only the MTP3 User Adaptation (M3UA) layer is used. M3UA

Page 12: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

12 (40) © Nokia Networks Oy

provides an interface that is compatible with MTP3. In other words, it supports MTP3 applications on top of SCTP and IP.

As integration is done at the SS7 network layer, it is possible to provide signalling between IP- and PCM-based signalling nodes through Signalling Gateways.

3.3.1 M3UA

M3UA supports the transport of any SS7 MTP3-User signalling (such as ISUP and SCCP messages) over IP, using the services of the Stream Control Transmission Protocol (SCTP). The protocol is used for communication between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident database. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport.

3.3.2 SCTP

SCTP is a reliable transport protocol operating on top of a potentially unreliable connectionless packet service such as IP. It offers acknowledged error-free non-duplicated transfer of datagrams (messages). Detection of data corruption, loss of data and duplication of data is achieved by using checksums and sequence numbers. A selective retransmission mechanism is applied to correct loss or corruption of data.

Originally, SCTP was designed to provide a general-purpose transport protocol for message-oriented applications, as is needed for the transportation of signalling data. Its design includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.

SCTP can be used as the transport protocol for applications where monitoring and detection of loss of session is required. For such applications, the SCTP path/session failure detection mechanisms, especially the heartbeat, will actively monitor the connectivity of the session.

The decisive difference to TCP is multhoming and the concept of several streams within a connection (which will be referred to as association in the rest of these documents). While in TCP a stream is referred to as a sequence of bytes, an SCTP stream represents a sequence of messages (and these may be very short or long).

In Nokia implementation it is possible to use only one stream for data messages. Management messages are always sent to stream 0. It is possible to configure with an association set parameter whether the data stream is 0 or 1. However, it is recommended to use data stream 1. If stream 1 is used, the total stream count for the association is 2, otherwise, it is 1.

Page 13: Integrating Tcpip Interfaces_sg5_final

Protocol stacks

© Nokia Networks Oy 13 (40)

Once the message traffic is load-shared between associations there is not much additional advantage of load sharing also to individual streams inside an association. Also, the main emphasis in load sharing is on balancing the CPU load in signalling units. That is why one data stream is enough.

3.3.3 Association sets and associations

Each association is defined by the signalling unit in which the association exists and by the destination IP address. One signalling unit can be connected to multiple association sets. When there is a Nokia network element at the peer, it is recommended that inside one association set the unit is only connected to one association (Figure 7). By using multiple signalling units in one association set (one association per signalling unit), you share the load among more than one computer units and at the same time makes the signalling connection redundant.

When there is a multiple association set between two network elements, it is recommended that the signalling unit is only connected to one association set.

Figure 7. Association set and associations

3.3.4 SGP-ASP communication

SGP-ASP communication is needed when communicating between MTP-3 peers in SS7 and IP domains. To enable the communication, a seamless interworking function is needed in the SG (Signalling Gateway) at the M3UA layer for the MTP3-User peers in the SS7 and IP domains.

In case of communication between Nokia network elements, the Application Server (AS) and Signalling Gateway (SG) concepts are mapped to network

Page 14: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

14 (40) © Nokia Networks Oy

elements, for example, AS = MSS, SG = MGW. Furthermore, the signalling units in those network elements are mapped to Application Server Processes (ASPs) inside the MSS and Signalling Gateway Processes (SGPs) inside the MGW.

When a signalling message arrives to the signalling gateway from an SS7 link, the M3UA routing function determines first the association set. Inside the association set an association is selected, based on the SLS value, and the signalling message is forwarded to the signalling unit where the association exists. When there is a Nokia network element at the peer, it is recommended that there is only one association in one signalling unit inside one association set.

3.3.5 Basic Configurations of SS7 signalling over IP

When IP transport is used in the signalling network, the SEP network element is usually in the IP network. The SEP network element acts as an AS and then it is connected to the TDM network via a Signalling Gateway, that is, a network element working in both network types. The AS can be a server or a database, but also any other network element where signalling is transported via the IP network (Figure 8).

Figure 8. Basic example of a network that uses IP

When IP connection is used, the signalling unit must have an Ethernet port, through which it can be connected to the network element internal LAN (Figure 9).

Page 15: Integrating Tcpip Interfaces_sg5_final

Protocol stacks

© Nokia Networks Oy 15 (40)

Figure 9. An example of point-to-point IP connection

Page 16: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

16 (40) © Nokia Networks Oy

4 Integration

The IP interface integration is comprised of the following steps:

Configure network interfaces

Create routes

After the above procedures configuration will depend on the interface. For the Gn interface the following steps are still needed:

Create domain name server data

Configure IP parameters

4.1 Configure network interfaces

4.1.1 Redundant interfaces

Each functional unit is connected to the LANU via two network interfaces. The purpose is to offer connection redundancy. Only one of the interfaces is active at a time. In case the active one goes down, the functional unit performs automatic interface switchover. The connection redundancy improves the overall connection reliability as it ensures service continuity without major interruptions (Figure 10).

Figure 10. Connection redundancy

Page 17: Integrating Tcpip Interfaces_sg5_final

Integration

© Nokia Networks Oy 17 (40)

4.1.2 Physical and logical IP addresses

There are two types of IP addresses in the 2G SGSN: physical and logical. The term physical means that there is a static mapping between the address and one certain physical computer unit (identified with unit type and unit index). The mapping does not change unless it is explicitly forced to do so, for example via an MML interface. As opposed to this, logical IP addresses are assigned to functional units, for example to a PAPU or an OMU. This implies that a logical IP address inherits the redundancy scheme of its functional unit and because of that, may move between different computer units. Thus, a logical IP address configured to either a 2N or N+1 redundant functional unit becomes itself 2N or N+1 redundant.

Each group will create a redundant connection to a functional unit according to the table below (provided by the instructor):

Group Functional Unit

IP Address Netmask

Length

1

2

3

4

1. Interrogate the network interfaces. ( ZQR )

Command: ______________________________________

2. Create network interface for the functional unit. (ZQR)

Note: Both redundant interfaces must be configured. The interfaces are named EL0 and EL1

Command: ______________________________________

3. Test if the interface is working from a network element connected to the backbone.(ZQR)

Command: ______________________________________

Note

For integration over IPv6 network, use the command group ZQ6.

Page 18: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

18 (40) © Nokia Networks Oy

4.2 Create routes

This step is optional. It is not needed if IP packets are not sent through routers.

IP routing is the exchange of information in order to have the information necessary to make correct IP forwarding decisions. Routing information is exchanged between routers by using routing protocols.

The TCP/IP protocol stack can operate as a host or a router. It defaults to operate as a host and must be explicitly configured as a router. This means that IP forwarding is activated only when the stack is configured to operate as a router.

Routing in Nokia 2G SGSN can be either static or dynamic. In static routing the 2G SGSN will have a fixed routing table, which includes the destination IP networks and corresponding next hops. In dynamic routing, the SGSN exchange information on the destination IP networks and corresponding next hops. This dynamic information is exchanged via the OSPF routing protocol (command group ZQK).

In static configuration the operator needs to manually define the needed routing information when configuring Nokia 2G SGSN.

First fill in this table provided by the instructor:

Group

Functional

Unit Destination

Network Gateway

1

2

3

4

1. Create routing data based on the table above. (ZQR)

Command: ______________________________________

2. Ping gateway defined inside routing data configuration to check if it is reachable by the Functional Unit interface. (ZQR)

Command: ______________________________________

Page 19: Integrating Tcpip Interfaces_sg5_final

Integration

© Nokia Networks Oy 19 (40)

4.3 Gn interface configuration

4.3.1 Create domain name server

1. Interrogate domain name servers list (ZQR)

(If they are not defined, define them)

Command: ____________________________________

2. Test that DNS is working by pinging an Access Point Name defined in the network (ZQRX)

Command: ____________________________________

DNS query using with POSIX subsystem

1. Access the service terminal for a working PAPU (ZDD)

Command: ____________________________________

2. Load the POSIX subsystem:

21:MAN>ZLP:P,POM

21:MAN>P

21:POM>

3. Choose an existent Access Point Name in your network and query the DNS typing the command below:

S:system,pontst~gethostbyname~<APN>~>temp

Where <APN> is the APN selected by the user.

Example:

If <APN> is “BASIC.NOKIA-OCD.COM.MNC009.MCC262.GPRS” the command shall be:

21:POM>S:system,pontst~gethostbyname~BASIC.NOKIA-OCD.COM.MNC009.MCC262.GPRS~>temp

Now type the file named “temp” with the following command:

S:type,temp

Example printout:

setjmp returns 0 gethostbyname(BASIC.NOKIA-OCD.COM.MNC009.MCC262.GPRS): name=basic.nokia-ocd.com.mnc009.mcc262.gprs addrtype=2

Page 20: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

20 (40) © Nokia Networks Oy

length=4 addr=192.168.10.25 addr=192.168.10.21 h_errno=0 [EOF]

4.4 Gb over IP configuration

The following configuration steps are need for Gb over IP integration:

1. Create network service virtual connection

2. Create MSC/VLR to LA association

3. Change state of network service virtual connection.

Steps 2 and 3 above have already been performed during Gb integration over Frame Relay.

1. Create an NS-VC over IP. (ZFW)

Command: __________________________________________

2. Unlock the connection. (ZFW)

Command: __________________________________________

Notes

The local UDP port number shall be defined in either static or dynamic configuration.

RIPE, RPNBR, RDW, and RSW shall be defined only in static configuration.

4.5 SS7 over IP configuration

Integration steps

If SS7 over IP is implemented, ET connection and MTP creation are replaced by the steps below:

Create an association set

Add associations to the association set

Check the associations

Give IP addresses to own signalling units

Create source IP addresses for SCTP

Page 21: Integrating Tcpip Interfaces_sg5_final

Integration

© Nokia Networks Oy 21 (40)

Create IP type SS7 signalling link and link set

Create the SS7 signalling route set

1. Create an association set for the IP connection to the SP (ZOY)

Command: ________________________________

2. Add an association to the association set towards the SP (ZOY)

Command: ________________________________

3. Check if the association was created correctly and that it has the correct IP address and values for parameters “ASP MESSAGES” and “ASP MESSAGES IN IPSP” (ZOY)

Command: __________

4. Check if an IP address to the SMMU that is going to be connected to the HLR is already configured (ZQR)

Command: ____________________________________________

If it is not, configure the SMMU IP interface (ZQR)

5. Create source IP address for SCTP (ZOY)

Command: ____________________________________________

6. Create IP type of signalling link and signalling link set (ZNS)

Command: ____________________________________________

7. Check if the signalling route to the SP is already created (ZNR)

Command: ____________________________________________

If there is no signalling route to the SP yet, create it (ZNR)

Page 22: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

22 (40) © Nokia Networks Oy

5 Session Management

Once a GPRS terminal is attached to the network it will be able to access an external IP network only after activating a PDP context. PDP context activation and deactivation procedures are used for this purpose. Session Management handles these procedures, establishing and removing subscriber's connection to external IP network.

All the subscribed PDP contexts of the MS, after the Attach procedure, are transferred to SGSN's subscription database located in SMMU. The database supports 80.000 subscribers and 640.000 subscriptions per SMMU.

There are several relevant data inside a PDP context subscription. The most important ones are:

PDP Type: IPv4 or IPv6.

PDP Address: empty, if dynamic address assignment used.

Access Point Name (APN): the identifier of the network the user is subscribed to.

QoS parameters: each subscribed context has its own QoS profile

The APN is composed of two parts:

The APN Network Identifier is a label (for example "corporation") or a set of labels separated by dots, which is a fully qualified domain name according to the DNS naming conventions (for example "company.com"). The APN Network Identifier shall not end with ".gprs".

The APN Operator Identifier is a fully qualified domain name according to the DNS naming conventions, and consists of three labels. The APN Operator Identifier shall end in ".gprs". For example, it may be "MNC010.MCC200.gprs".

A default network identifier part of the APN has to be defined in the configurable parameters (GNI) in case the MS does not request an APN and a wild card record is used in the subscription.

In the 2G SGSN, the DNS APN name to be used is formed by bonding the operator identifier part of the APN to the default network identifier part of the APN. Nokia 2G SGSN supports PDP types IPv4 and IPv6. The name of the default network identifier for the IPv6 PDP type is GNI6.

The APN operator identifier part is either generated from the MS user's IMSI in case the user requests access to user's HPLMN GGSN or the default operator identifier is used in case the user requests access to the PLMN where the 2G SGSN resides. Operators can configure the default operator identifier (parameter GOI) indicating the 2G SGSN's own PLMN. There can be several PLMNs under one 2G SGSN. A default operator of their own (parameter DEFAPN) can also be configured for each PLMN.

Page 23: Integrating Tcpip Interfaces_sg5_final

Session Management

© Nokia Networks Oy 23 (40)

5.1 PDP Context Activation

The PDP context activation procedure is shown in Figure 11. In Nokia GPRS only MS can initiate the PDP context activation procedure.

MS BSS GGSNSMMUPAPU

7. SM. Activate PDP Context Accept

6. GTP. Create PDP Context Response

5. GTP. Create PDP Context Request

1. SM. Activate PDP Context Request

2. Authentication

3. IMEI check

4. APN selection

Figure 11. PDP context activation procedure

1. The MS sends an SM.Activate PDP context request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) to the PAPU in which its MM context is stored. The parameters contained in the message are:

NSAPI (Network - Service Access Point): identifies the PDP context associated with a PDP address at SNDCP protocol layer. When the MS requests the activation of a PDP context, the MS selects one of its unused NSAPIs. The NSAPI is a part of the Tunnel Identifier (TID) between SGSN and GGSN for GTPv0.

TI: transaction identifier (see Note);

PDP Type: indicates the type of protocol the MS shall use IPv4 or IPv6.

PDP address: (IPv4 or IPv6) indicates whether the MS requires the use of a static PDP address or whether it requires the use of a dynamic PDP address. The MS shall leave PDP Address empty to request a dynamic PDP address.

Access Point Name: the MS may use it to select a reference point to a certain external network. Access Point Name logical name referring to the external packet data network that the subscriber wishes to connect to.

Page 24: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

24 (40) © Nokia Networks Oy

QoS Requested: indicates the desired QoS profile. Rel´97/98 attributes are reliability class, delay class, precedence class, peak throughput, mean throughput. Nokia 2G SGSN also supports Rel´99 attributes as Traffic classes, Traffic Handling Priorities, SDU Error Ratios, Residual Bit Error Ratios, Delivery of Erroneous SDUs, Guaranteed Bit rate, Maximum Bit rate, Allocation / Retention Priorities and Delivery Order.

PDP Configuration Options: may be used to request optional PDP parameters from the GGSN and they are sent to MS transparently through the PAPU.

Note

The Transaction Identifier (TI) allows distinguishing up to 16 different bi-directional messages flows for a given PD (protocol discriminator) and a given SAP. Such a message flow is called a transaction. The TI is composed of the TI value (3 bits) and the TI flag(1 bit).

Transactions are dynamically created, and their TI value is assigned at creation time. TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction a free TI value (i.e., a value not yet used for the given PD, the given SAP, and with the given initiator) is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction.

Two identical TI values may be used when each value pertains to a transaction initiated by the different sides of the interface. In this case the TI flag shall avoid ambiguity. The transaction identifier flag can take the values "0" or "1". The TI flag is used to identify which side of the interface initiated the transaction. A message has a TI flag set to "0" when it belongs to transaction initiated by its sender, and to "1" otherwise. Hence the TI flag identifies who allocated the TI value for this transaction and the only purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.

2. Depending on PLMN parameter "Authentication repetition rate for MO PDP context activation" (MOA) the PAPU performs Authentication procedure.

3. Depending on PLMN Parameter "IMEI check repetition rate for MO PDP context activation" (IMOA) the PAPU may perform the equipment checking functions.

4. If security functions succeeded the PAPU validate the PDP Type, PDP Address, and Access Point Name, if any, provided by the MS and the PDP context subscription records stored in Visiting GPRS subscriber database located in SMMU. If the MS does not specify an APN, the PAPU must select one. The APN selection rules, APN validation and the mapping from APN to a GGSN are described more detailed in the

Page 25: Integrating Tcpip Interfaces_sg5_final

Session Management

© Nokia Networks Oy 25 (40)

reference at the end of this module. In this figure there is a summary for APN selection algorithm in SGSN:

Requested Context includes:

Subscription (from HLR) Selected APN

PDP- Type

PDP-Address

APN

Includes one PDP-context that contains: Requested PDP-Type Requested PDP-Address Requested APN

Requested APN

Includes only one PDP-context that contains: Requested PDP-Type Requested PDP-Address

APN from Subscription

--

Includes more PDP-contexts that contain: Requested PDP-Type Requested PDP-Address

Reject

Includes only one PDP-context that contains: Requested PDP-Type Requested APN

APN from Subscription

Includes one PDP-context that contains: Requested PDP-Type Wildcard for APN

Requested APN

YES APN from Subscription

--

Includes more PDP-contexts that contain: Requested PDP-Type Requested APN

Does one allow dynamic addressing?

NO Reject

a) Includes only one PDP-context that contains an APN: Requested PDP-Type

APN from Subscription

b) Includes one PDP-context that contains: Requested PDP-Type with a wildcard for the APN

Default APN

-- --

c) Includes more PDP-contexts that contain:

Requested PDP-Type Reject

--

Reject

-- --

Reject

-- -- Reject

Page 26: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

26 (40) © Nokia Networks Oy

Requested Context includes:

Subscription (from HLR) Selected APN

PDP- Type

PDP-Address

APN

Includes only one PDP-context that contains: PDP Type (static PDP address) an APN

APN from Subscription

Includes only one PDP-context that contains: PDP Type (not defined) a wildcard for the APN

Default APN

Includes only one PDP-context that contains: PDP Type (not defined) an APN

APN from Subscription

- - -

Includes more PDP contexts. Reject

5. If a GGSN address can be derived, the PAPU creates a TEID (Tunnel Endpoint Identifier) Data I and a TEID Control Plane for the requested PDP context. If MS requests a dynamic address, the PAPU lets a GGSN allocate the dynamic address. The PAPU may restrict the requested QoS attributes given its capabilities, the current load, and the subscribed QoS. The PAPU sends to the affected GGSN the following message: GTP. Create PdP Context Request (PDP Type, PDP address, Access Point Name, QoS Negotiated, TEID Data I, TEID Control Plane, Selection Mode, PdP configuration Options, SGSN Address for signalling, SGSN address for user traffic). The following parameters are included:

APN: APN(F) coming out from the APN selection algorithm.

PDP address: IPv4 or IPv6 address (shall be empty if dynamic allocation is requested from MS).

Selection Mode: indicates whether a subscribed APN was selected, or whether a non-subscribed APN sent by MS or chosen by SGSN was selected. Selection Mode is set according to APN selection algorithm. The GGSN may use Selection Mode when deciding whether to accept or reject the PDP context activation. For example, if an APN requires subscription, then the GGSN is configured to accept only the PDP context activation with Selection Mode equal to subscribed APN.

TEID Data I, TEID Control Plane, SGSN Address for signalling and SGSN address for user data.

6. GGSN creates a new entry in its PDP context table with IMSI, NSAPI, PDP Type, PDP address, PAPU address, QoS negotiated, APN and creates a Charging Id. The new entry allows GGSN to route data packets

Page 27: Integrating Tcpip Interfaces_sg5_final

Session Management

© Nokia Networks Oy 27 (40)

between the external network and the PAPU. The GGSN may further restrict QoS negotiated given its capabilities and current load. If QoS Negotiated received from the PAPU is incompatible with the PDP context being activated (e.g., the reliability class is insufficient to support the PDP type), then the GGSN rejects the Create PDP Context Request message. If GGSN accept the PdP context then return a GTP.Create PdP Context Response (TEID Data I, TEID Control Plane, PDP Address, Reordering Required, PDP Configuration Options, QoS Negotiated, Charging Id, Cause, Charging Gateway address, GGSN address for signalling, GGSN address for user data) to PAPU. The parameters contained in the message are:

PDP address is included in case GGSN has allocated a PDP address.

Reordering Required indicates whether the PAPU shall reorder data packets before delivering them to the MS.

PDP Configuration Options contain optional PDP parameters that the GGSN may transfer to the MS.

TEID Data I, TEID Control Plane, GGSN address for signalling, GGSN address for user data.

7. The PAPU creates a PDP Context in its memory for that subscriber containing NSAPI, GGSN address, QoS negotiated and TI along with the other field described in Appendix A. If the MS has requested a dynamic address, the PDP address received from the GGSN is inserted in the PDP context. The PAPU selects a Radio Priority based on QoS Negotiated, and returns the SM.Activate PDP Context Accept (PDP Type, PDP Address, NSAPI, QoS Negotiated, Radio Priority Level, PDP Configuration Options) to MS.

MS and PAPU establish a new LLC link for the PdP context if Negotiated QoS precedent class was not already in use. MS starts the compression parameter negotiation with PAPU. PAPU sends information charging to MCHU.

The PAPU is now able to route data packets between the GGSN and the MS.

5.2 PDP Context Deactivation procedure

The PDP context deactivation can be initiated by the MS or by the network or it may be performed implicitly within the GPRS detach. The network initiates a PDP context deactivation due to a lack of GGSN or PAPU resources or due to a GGSN failure.

Page 28: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

28 (40) © Nokia Networks Oy

5.2.1 PDP context deactivation initiated by MS

MS starts this procedure in order to release the connection to IP network outside GPRS backbone network. The deactivation procedure is illustrated in Figure 12.

MS BSS GGSNPAPU

5. SM.Deactivate PDP Context

4. GTP.Delete PDP Context Response

4. GTP.Delete PDP Context Request

2. Authentication

3. IMEI check

1. SM. Deactivate PDP Context

Figure 12. PDP context deactivation initiated by MS

1. The MS sends a SM. Deactivate PDP Context Request (TI, SM Cause) message to the PAPU. The message contains the TI in use for the PDP context to be deactivated and a SM Cause code that typically indicates one of the following causes: "insufficient resources", "regular PDP context deactivation", or "QoS not accepted".

2. Depending on PLMN parameter "Authentication repetition rate for MO PDP context deactivation", the PAPU performs Authentication procedure.

3. Depending on PLMN Parameter "IMEI check repetition rate for MO PDP context deactivation”, PAPU may perform the equipment checking functions.

4. The PAPU sends a GTP.Delete PDP Context Request (TEID Control Plane) message to the GGSN. The GGSN removes the PDP context and returns a GTP.Delete PDP Context Response (TEID Control Plane) message to the PAPU. If the MS was using a dynamic PDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the GPRS backbone network.

5. The PAPU releases the data link between the MS's and PAPU's data transfer layers (LLC, SNDCP) which was established in the PDP context activation procedure. The PAPU releases also the resources allocated to

Page 29: Integrating Tcpip Interfaces_sg5_final

Session Management

© Nokia Networks Oy 29 (40)

this PDP context in its memory and confirms the deactivation to the MS with Deactivate PDP Context Accept (TI) message to the MS.

At GPRS detach, all PDP contexts for the MS are implicitly deactivated.

The PAPU informs charging service in MCHU about the deactivation procedure and the charging is stopped for this PDP context.

5.3 PDP Context Modification procedure

A PAPU can decide to modify parameters that were negotiated during activation procedure for one or several PDP context. The following parameters can be modified:

QoS

Radio Link Priority

Operator may modify the subscriber's PDP context record / records in HLR for example define a new APN to be used or change the PDP address type from dynamic to static etc. HLR may indicate the modification of a subscribed PDP context record to the SGSN (SMMU) serving this subscriber. In SGSN this means that any active PDP context / contexts which were activated using the modified subscribed PDP context record need to be modified or deactivated. The active PDP context has to be deactivated if for example PDP type changes, if APN changes so that APN which previously was NTC.NOKIA.COM changes to OTHER.NETWORK.ORG or if the subscribed wildcard APN changes to for example NTC.NOKIA.COM. In this case SGSN checks if the active APN is the same as the new subscribed APN in which case the active context is not deactivated. Deactivation of the active context is also performed when roaming user is using VPLMN APN and the subscribed PDP context is changes so that the use of VPLMN APN is no longer allowed.

5.4 Exercises

5.4.1 Define IP interface parameters

1. Output the default value of the IP interface parameters defined in SGSN. (ZEJ)

Command: ____________________________________

2. Output the identifiers for the default access point of the GGSN. (ZEJ)

(If it is not defined yet, you can create it now!)

Page 30: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

30 (40) © Nokia Networks Oy

Command: ____________________________________

3. Output the default operator identifier (DEFAPN) for the Home PLMN (ZMX)

Command: ____________________________________

4. Output the subscription for one existent MS in the database (ZMM)

Command: ____________________________________

5.4.2 Activate a PDP Context

1. Activate a PDP context!

2. Test PDP Context Activation by typing gtpdump at GGSN console.

Page 31: Integrating Tcpip Interfaces_sg5_final

QoS – Quality of Service

© Nokia Networks Oy 31 (40)

6 QoS – Quality of Service

Basically QoS definitions set the limits how user experiences the PDP Context, i.e. how fast data can be transferred and so on. QoS Profiles containing these definitions are stored in the HLR and within subscriber data definition these are tied together with PDP Contexts. Thus, QoS Profile information with its parameters is a part of PDP Context definition.

When a subscriber performs GPRS Attach or RA Update procedure, the PDP Context information and QoS Profile information is transferred from the HLR to the SGSN. As an example, the following figure shows how QoS information is present in SGSN subscriber database.

VISITING GPRS SUBSCRIBER DATA HANDLING COMMAND <MM_> <ZMMS:IMSI=244060000002021:;

SGSN SGSN00 2005-02-22 11:48:36

IMSI ..INTERNATIONAL MOBILE SUBSCRIBER IDENTITY .... 244060000002021

OPERATOR DETERMINED BARRING DATA:

BAOC ... BARRING OF ALL OUTGOING CALLS ........................ N BOIC ... BARRING OF OUTGOING INTERNATIONAL CALLS .............. N BOIH ... BARRING OF OUTGOING INTERNATIONAL CALLS EXCEPT THOSE DIRECTED TO THE HOME PLMN COUNTRY .............. N

BOS1 ... OPERATOR SPECIFIC BARRING CATEGORY 1 ................. N BOS2 ... OPERATOR SPECIFIC BARRING CATEGORY 2 ................. N BOS3 ... OPERATOR SPECIFIC BARRING CATEGORY 3 ................. N BOS4 ... OPERATOR SPECIFIC BARRING CATEGORY 4 ................. N

PDP CONTEXTS:

PDP ADDRESS TYPE ............................ IPv4 PDP ADDRESS ................................. DYNAMIC

QOS PROFILE VERSION ........................ REL99 DELIVERY OF ERRONEOUS SDU .................. Y DELIVERY ORDER ............................. Y TRAFFIC CLASS .............................. B MAXIMUM SDU SIZE ........................... 1502 MAXIMUM BITRATE FOR UPLINK ................. 64 MAXIMUM BITRATE FOR DOWNLINK ............... 64 SDU ERROR RATIO ............................ 5 RESIDUAL BER ............................... 1 TRAFFIC HANDLING PRIORITY .................. 1 TRANSFER DELAY ............................. 160 GUARANTEED BITRATE FOR UPLINK .............. 64 GUARANTEED BITRATE FOR DOWNLINK ............ 64 ALLOCATION/RETENTION PRIORITY .............. 2 APN ......................................... * VPLMN ALLOWED ............................... N

Figure 13. Example printout of subscriber QoS profile in SGSN

Page 32: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

32 (40) © Nokia Networks Oy

This example printout shows how QoS Background attributes can be defined. The following bullets give explanation to the most important parameters.

PDP Address Type: IPv4. This PDP Context uses IPv4 addressing.

PDP Address: Dynamic. This PDP Context uses dynamic addressing. The network allocates addresses.

QoS Profile Version: REL99. This QoS Profile uses R99 (nowadays 3GPP System R3) QoS Attribute definitions. These differ from R97/R98 Attributes but can be mapped to each other as explained a bit later.

Delivery of Erroneous SDU: Y. If received SDU (Service Data Unit) is erroneous it is still delivered.

Delivery Order: Y. SDUs are delivered further exactly in the same order they have been received by the node. This requirement concerns especially QoS Conversational Class and in some cases sensitive QoS Streaming Class traffic.

Traffic Class: B. This parameter defines traffic class to be one of the following: Conversational (C), Streaming (S), Interactive (I) and Background (B).

Maximum SDU Size: 1502. This defines the maximum length of a SDU in octets.

Maximum Bitrate for Uplink/Downlink: 64. These values set the absolute maximum width of the Bearer user may get. This value is expressed in kb/s.

Transfer Delay: 160. This value gives maximum limit (in milliseconds) the connection stands for delay.

Guaranteed Bitrate for Uplink/Downlink: 64. These figures define absolute minimum bandwidth the system must offer under all circumstances for this connection. Note: In QoS Classes Streaming and Conversational this parameter is obligatory. In other QoS Classes guarantees can be defined but they are not necessary.

APN: *. Wildcard APN is used.

VPLMN Allowed: N. This example subscriber with this PDP Context is not allowed to perform access through any VPLMN.

6.1 QoS Mapping

2G SGSN is able to handle both R97/98 and R99 QoS Profiles. This is natural, since the 3G/UMTS network implementation creates the situation where both 2G and 3G terminals may use 2G SGSN resources. This happens when 3G terminal works in 2G mode. The following tables show the relations between R97/98 and R99 QoS Definitions.

Page 33: Integrating Tcpip Interfaces_sg5_final

QoS – Quality of Service

© Nokia Networks Oy 33 (40)

Table 1. Determining REL99 Attributes from REL97/98 Attributes

Resulting R99 Attribute Derived from R97/98 Attribute Name Value Value Name

Interactive 1, 2, 3 Traffic class Background 4

Delay class

1 1 2 2

Traffic handling priority

3 3

Delay class

10-6 1, 2 10-4 3

SDU error ratio

10-3 4, 5

Reliability class

10-5 1, 2, 3, 4 Residual bit error ratio 4*10-3 5

Reliability class

'no' 1, 2, 3, 4 Delivery of erroneous SDUs 'yes' 5

Reliability class

8 1 16 2 32 3 64 4 128 5 256 6 512 7 1024 8

Maximum bitrate [kbps]

2048 9

Peak throughput class

1 1 2 2

Allocation/Retention priority

3 3

Precedence class

yes' yes' Delivery order 'no' 'no'

Reordering Required (Information in the SGSN and the GGSN PDP Contexts)

Maximum SDU size 1 500 octets (Fixed value)

This mapping is applicable in the following cases:

Handover of PDP Context from GPRS R97/98 SGSN to GPRS R99 or UMTS SGSN (Cell and Network Re-selection)

PDP Context Activation in a serving R99 SGSN with a R97/98 GGSN. When GGSN respond to the PDP Context Activation, mapping of the changed R97/98 QoS Attributes received from the GGSN to R99 QoS Attributes is performed in the serving SGSN.

Page 34: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

34 (40) © Nokia Networks Oy

Table 2. Determining R97/98 Attributes from R99 Attributes

Resulting R97/98 Attribute Derived from R99 Attribute Name Value Value Name

1 conversational Traffic class 1 Streaming Traffic class

Interactive Traffic class 1 1 Traffic handling priority Interactive Traffic class 2 2 Traffic handling priority Interactive Traffic class 3 3 Traffic handling priority

Delay class

4 Background Traffic class 2 <= 10-5 SDU error ratio 3 10-5 < x <= 5*10-4 SDU error ratio

> 5*10-4 SDU error ratio 4 <= 2*10-4 Residual bit error ratio > 5*10-4 SDU error ratio

Reliability class

5 > 2*10-4 Residual bit error ratio

1 < 16 2 16 <= x < 32 3 32 <= x < 64 4 64 <= x < 128 5 128 <= x < 256 6 256 <= x < 512 7 512 <= x < 1024 8 1024 <= x < 2048

Peak throughput class

9 >= 2048

Maximum bitrate [kbps]

1 1 2 2

Precedence class

3 3

Allocation/retention priority

Mean throughput class Always set to 31 - yes' yes' Reordering Required

(Information in the SGSN and the GGSN PDP Contexts) 'no' 'no'

Delivery order

This mapping is applicable in the following cases:

PDP Context is handed over from GPRS R99 or UMTS to GPRS R97/98;

When a R99 UE performs a PDP Context Activation in a serving R99 SGSN while the GGSN is of R97/98. In this case the SGSN shall perform mapping of the R99 QoS attributes to the R97/98 QoS attributes;

A R99 HLR may need to map the stored subscribed QoS attributes in the HLR subscriber data to R97/98 QoS attributes that are going to be sent in the Insert Subscriber Data message from the R99 HLR to the R97/98 and R99 SGSN. It is an implementation issue if the R97/98 QoS attributes are stored in the HLR in addition to the R99 QoS attributes.

Page 35: Integrating Tcpip Interfaces_sg5_final

QoS – Quality of Service

© Nokia Networks Oy 35 (40)

6.2 ARP support in admission control

Nokia 2G SGSN Release SG5 offers support for allocation/retention priority in admission control. The ARP parameter ranges from 1 to 3. The default value for each ARP priority value is 100%. When ARP priority values are changed by MML, lower ARP priority can not be greater than higher priority but they can be equal.

Example:

RTBW = 100Mbit/s ARP1 = 100% ARP2 = 80% ARP3 = 60%

RTBW/PAPU (bit/s) x ARP1 (percents) = 100Mbit/s (max RTBW for ARP priority 1 contexts/PAPU)

RTBW/PAPU (bit/s) x ARP2 (percents) = 80Mbit/s (max RTBW for ARP priority 2 contexts/PAPU)

RTBW/PAPU (bit/s) x ARP3 (percents) = 60Mbit/s (max RTBW for ARP priority 3 contexts/PAPU)

When there are new procedures requiring bandwidth for different ARP priorities, SGSN checks if there is bandwidth left for this ARP priority. If not, the procedure for this ARP priority is discarded and correct counter is updated.

Exercise:

1. Output the ARP parameters located inside the QOS group (ZEJ)

Command: ____________________________________

6.3 Operator configurable DiffServ Codepoints

IP networks such as the GPRS backbone do not understand GPRS QoS classes, but use instead Differentiated Services. Therefore all IP packets that are sent to the Gb/Gn/Gp interface need to be properly marked. This feature allows the operator to define the Differentiated Services Codepoint values for GPRS QoS classes, charging and statistics. It is also possible to assign port-based DiffServ Code Points.

The mapping is based on the mobile subscriber's delay or traffic class values, and it is made before the SGSN sends packets to the GGSN (or SGSN). The mapping can be defined both real data packets and signalling messages (GTP-C) that are sent to the Gn/Gp interface

The mapping depends on bandwidth and provisioning of resources among the different Diffserv classes which the operators control to satisfy their cost and performance requirements.

Page 36: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

36 (40) © Nokia Networks Oy

Exercise

2. Output the DSCP parameters inside the QOS group (ZEJ)

Command: ____________________________________

6.4 Weighted Far Queuing (WFQ) and Random Early Detection (RED)

WFQ (Weighted Fair Queuing) Algorithm allows different weights to be set to different delay classes (traffic classes / traffic handling priorities). Five different scheduling priorities, or priority classes, can be defined. Scheduling priority is a 2G SGSN internal value, which is derived from R97 or R99 parameters.

It is possible to determine whether WFQ is going to be used on the GTP buffer, Gb buffer, or both. The ultra-high queue priority applies only to the Gb buffer.

Except for the Ultra-high queue priority, a certain percentage of the available resources (weight) is assigned to each priority class. So, for example, 50% of the resources are reserved for priority 1, 30% for priority 2, and 15% for priority 3. The weight values can be selected with MML commands within certain ranges. See Figure 14. With MML commands it is also possible to adjust the size of the priority buffers.

Dynamic weight change is applied to the ultra-high priority queue which is reserved for streaming-class traffic. If heavy streaming traffic causes congestion in the signalling or other high priority queues, the priority is temporarily dropped to operator configurable “non-guaranteed streaming priority” value and kept there until congestion is over.

A mechanism to prevent buffer congestion is implemented by the Random Early Detection (RED) algorithm. This algorithm provides early detection of possible buffer congestion and randomly discards packets. The more the buffer fills up, the higher is the probability that RED discards an incoming packet. There is a separate algorithm for each priority class. The RED functionality can be activated and deactivated with MML commands.

Page 37: Integrating Tcpip Interfaces_sg5_final

QoS – Quality of Service

© Nokia Networks Oy 37 (40)

Figure 14. WFQ and RED algorithms

Exercises

3. Output the WFQ and RED parameters inside the QOS group (ZEJ)

Command: ____________________________________

4. Output the Priority Buffer Control parameters (ZEJ)

Command: ____________________________________

6.5 Service-based QoS control

By the help of this feature HPLMN operator may control roaming users QoS (i.e. use of the SGSN capacity) based on the agreements with other operators.

Operator may define, based on the operator PLMN-ID, whether roaming subscriber is handled as HPLMN user or not. If the roaming user is not handled as HPLMN user, requested/subscribed QoS profile parameters can be downgraded to the operator defined maximum allowed level, if higher level is requested. This feature also allows QoS upgrade from GGSN

Exercises

5. Check if service-based QoS control applies to any of the created PLMN (ZMX).

Command: ____________________________________

6. Output the maximum settings for roaming users under service-based QoS control in MAXQOS group (ZEJ).

Command: ____________________________________

Page 38: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

38 (40) © Nokia Networks Oy

6.6 Secondary PDP contexts

The main reason for a secondary PDP context is that it allows the user to activate multiple PDP contexts to the same APN using the same IP address, but using a different Quality of Service for each of these contexts.

The secondary PDP context activation procedure is almost like a normal PDP context activation procedure with a couple of differences:

1. The secondary PDP context activation can only be initiated by the MS.

2. The secondary PDP context always uses the parameters of the primary PDP context as a basis for the activation procedure with the exception of the QoS parameters, which may differ from the ones in the active primary context or other secondary PDP contexts. The primary PDP context is the context which has been previously activated and whose APN and PDP address parameters the secondary PDP context uses. All of the secondary PDP contexts activated by using the parameters of the primary PDP context become linked to this primary context. Because the APN and PDP address are known when the secondary PDP context activation procedure is started, the APN selection procedure is bypassed when the 2G SGSN processes the secondary PDP context activation.

Figure 15. Secondary PDP contexts

Page 39: Integrating Tcpip Interfaces_sg5_final

QoS – Quality of Service

© Nokia Networks Oy 39 (40)

6.7 TCP Optimisation

TCP Optimisation was implemented to solve some problems and to improve the performance of Transmission Control Protocol (TCP) in connections over the General Packet Radio Service (GPRS).

For the end user, quicker downloads become possible.

The performance optimisation of this feature integrates a whole solution into the 2G SGSN that otherwise would need to be accomplished by expensive separate equipment sets. A further advantage of the feature is the synergy effects in combination with performance enhancing proxies.

The solutions include improvements related to the following:

Intelligent and parametric buffering

Window pacing

Redundancy elimination

Round-Trip Time (RTT) adjustment

MML changes

Statistics

Intelligent and parametric buffering allows the operator to configure buffer sizes for maximum throughput and minimised delays, and enables the definition of queue sizes for different priority classes.

Throughput capacity is not critical in the SGSN, but much more in the base station subsystem (BSS), where it will increase.

Window pacing decreases the size of the Acknowledge window of TCP packets in the uplink direction when the downlink buffers are becoming too full. This helps prevent potential buffer overflows and buffering delays.

Redundancy elimination involves two functions: duplicate tracking and redundancy elimination. Duplicate tracking involves the dropping of duplicate TCP packets according to specified criteria. In redundancy elimination, a retransferred TCP packet from the server is dropped if specified criteria are fulfilled.

Round-Trip Time (RTT) adjustment is introduced to delay MS-initiated TCP handshakes in order to make the Retransmission Timeout (RTO) in the server to allow TCP traffic to begin more slowly.

MML changes involve parameter additions to certain MML commands so that the operator can configure some new and old values with MML commands.

Statistics enhancements include new counters, for example, counters outputting the amount in bytes of TCP packets dropped by the redundancy elimination function.

Page 40: Integrating Tcpip Interfaces_sg5_final

Integrating TCP/IP Interfaces in 2G SGSN

40 (40) © Nokia Networks Oy

Exercise

7. Output the TCP Session parameters (ZEJ)

Command: ____________________________________