MPLS and DiffServ for UMTS QoS in GPRS Core Network Architecture

Hemant Chaskar
Nokia Research Center
5 Wayside Road
Burlington, MA 01803, USA
Hemant.Chaskar@nokia.com

 

Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043, USA
Rajeev.Koodli@nokia.com

Index terms-- UMTS QoS, GPRS, core network, MPLS, DiffServ, PDP

Abstract-- This paper describes a method for supporting UMTS QoS in the GPRS core network using advanced IP QoS and traffic engineering mechanisms, namely MPLS and DiffServ. In particular, we describe how GTP tunnels can be elegantly implemented using MPLS, and how DiffServ QoS paradigm can be used to support UMTS QoS classes in the core network. This solution can be integrated with PDP thereby rendering backward compatibility with current GPRS architecture and providing smooth evolution path to an all IP core network architecture.

 

  1. Introduction
  2. The General Packet Radio Service (GPRS) is the enhancement to Global System for Mobile Communication (GSM) to provide packet data services to GSM subscribers. GPRS aims at making efficient use of GSM radio resource for bursty packet data transfer. This is in contrast to conventional circuit switched data services available in GSM. GPRS operator can allocate certain number of time slots, called packet data channels or PDCHs, in each TDMA frame (of 8 time slots) of a particular carrier frequency for packet data services. The actual number of PDCHs depends on the volume of packet data traffic in the cell. The data rate for each PDCH varies between 9.05 kbps and 21.4 kbps, depending on the coding scheme used. A special multiframe structure has been defined for GPRS. It specifies a multiframe of 52 TDMA frames which is divided into 12 blocks of 4 TDMA frames each. Each of these blocks can transfer one RLC block over the air interface. Resource assignment to any terminal is based on these blocks of 4 TDMA frames. If the mobile terminal has multi-slot capability, it can simultaneously receive data on more than one PDCHs.

    GPRS introduces two new network elements, namely Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN), in the GSM architecture in order to support packet data services (see Figure 1). SGSN maintains the mobility context for the mobile station (MS) and also performs authentication procedures. SGSN is connected to the Base Station Subsystem (BSS) over a frame relay network on one side and to the GGSN over IP backbone (called core network or CN) on the other side. GGSN acts as a gateway to public data networks such as the Internet. Note that the GSM BSS is shared by GPRS and GSM circuit switched services.

    Figure 1: GPRS Architecture

    Data packets are transported between SGSN and GGSN using IP tunnels. For example, an IP packet destined to the MS is encapsulated into another IP packet by GGSN. The outer IP header has serving SGSN’s IP address as the destination address. The encapsulated packet is then forwarded through the CN using hop-by-hop forwarding. At SGSN, the outer IP header is stripped. The original packet is then forwarded by SGSN to MS via appropriate BSS using link layer procedures, i. e., over a radio access bearer. GPRS Tunneling Protocol (GTP) implemented at SGSN and GGSN is responsible for performing these tasks of encapsulation at GGSN and mapping onto appropriate radio access bearer at SGSN. Packet Data Protocol (PDP) is used to perform signaling tasks of GTP. Figure 2 shows the protocol stack in GPRS transmission plane.

    Need for QoS support in CN:

    Preliminary deployment of GPRS will be for packet data services of best-effort nature, such as WWW, email, FTP etc. As more and more communication services, including real-time services, are offered over IP, it becomes critical for the GPRS network to support Quality of Service (QoS) for data transfer. Further, emerging radio technologies such as EDGE and UMTS WCDMA will considerably increase the data rates on the radio interface, thereby making multimedia services to the handheld terminal a reality. Indeed, one likely scenario is that Third Generation (3G) system will deploy WCDMA radio interface connected to evolved GPRS CN. These trends necessitate the use of efficient and scalable QoS mechanisms for the CN. Note that both GPRS and UMTS specify various QoS attributes to be associated with packet data transfer, however these specifications fall short of describing any mechanisms to support these attributes.

    The need for IP QoS provisioning in the GPRS network has been realized by other researchers as well (see [1], [2], [3], [4], [5]). In particular, authors of [2], [3] and [4] have discussed the possibility of using Integrated Services (IntServ) QoS mechanism in the CN. The proposal in [3] uses RSVP messaging between SGSN and GGSN to establish QoS enabled GTP tunnels across the CN. In [4], the authors propose the use of GSM circuit switched services for guaranteed service class of IntServ and the GPRS packet switched services for the controlled load class of IntServ. However, IntServ QoS mechanism is notably complex and has poor scalability in large networks. Further, when the MS changes serving SGSN due to mobility, the QoS-enabled GTP tunnels have to be re-established, now between the GGSN to the new SGSN. In the IntServ approach stated above, RSVP messaging and resource reservation has to be re-initiated between the GGSN and the new SGSN. This increases the complexity of IntServ approach and adds more latency to the handover procedure. The possibility of using Differentiated Services (DiffServ) approach [5] rather than IntServ approach is also briefly discussed in the above references.

    In this paper, we propose a combination of multiprotocol label switching (MPLS) and DiffServ to implement QoS enabled GTP tunnels. MPLS is a label-based forwarding technique that has excellent scalability properties, and more importantly, it is a useful tool for traffic engineering in IP core networks. The approach here is to establish aggregate GTP tunnels, called Label Switched Paths (LSPs), for different types of traffic across the CN during the traffic engineering phase. This gives considerable control over the routes that the packets of different types of traffic take between SGSN and GGSN. The queuing and forwarding treatment offered to packets at the internal nodes along these routes in the CN, depends on the DiffServ per-hop behavior (PHB) that the packet is assigned to at the edge of the CN, i. e., at SGSN or GGSN. We describe, how PDP messaging that occurs at the time of activation of PDP context can be used to assign the corresponding packet stream to particular LSP and PHB. When the MS changes serving SGSN due to mobility, for downlink traffic, it is only required to change the label mapping context at GGSN that would cause the subsequent packets of the MS to be routed to new SGSN. Thus, in our approach, SGSN handoff does not require per-flow QoS signaling across the CN, and hence, it allows faster, QoS enabled re-routing of packets to new SGSN.

    The rest of the paper is organized as follows. Section II describes in detail the QoS solution proposed in this paper. In particular, Section II.A describes the role of MPLS for traffic engineering in the CN. The mapping between UMTS QoS classes and DiffServ code points is described in Section II.B, and Section II.C describes integration of PDP with the QoS architecture proposed here. Finally, Section III contains conclusions and directions for future work.

  3. QoS Solution for CN
    1. MPLS for routing in the CN
    2. MPLS is a packet forwarding technique being standardized by IETF [7]. MPLS uses labels to make forwarding decisions at the network nodes, in contrast to the traditional destination-based hop-by-hop forwarding in IP networks. In MPLS, the space of all possible forwarding options in a network domain is partitioned into "forwarding equivalence classes" (FECs). For example, all the packets destined for a given egress may belong to the same FEC. The packets are labeled at the ingress depending on the FEC to which they belong. Each of the intermediate nodes uses the label of incoming packet to determine its next hop, and also performs "label swapping," i.e., replaces the incoming label with the new outgoing label that identifies the respective FEC for the downstream node. The label swapping maps corresponding to the FEC are established using standard protocols such as RSVP or CR-LDP (Constraint-based Routing Label Distribution Protocol). Such a label-based forwarding technique reduces the processing overhead required for routing at the intermediate nodes, thereby improving their packet forwarding performance. Also, label merging procedure used by MPLS creates multipoint-to-point packet forwarding trees in contrast to a routing mesh in conventional network based on a similar paradigm such as ATM networks. This reduces considerably the size of forwarding table at the intermediate nodes, thereby improving their scalability.

      Another important capability that MPLS provides is that of "constraint-based routing." The ingress node can establish an explicit route through the network. Rather than inefficiently carrying the explicit route in each packet, MPLS allows explicit route to be carried only at the time LSP is set up using standardized protocols such as RSVP or CR-LDP. The subsequent packets traversing this path are forwarded using packet labels. Constraint-based routing is potentially useful for traffic engineering [8]. For example, the service provider can provision LSPs for real-time traffic over the best path between ingress and egress, while route best-effort traffic over sub-optimal path.

      In order to exploit the power of MPLS for traffic engineering and scalability in the CN, we propose to modify GTP-UDP/TCP-IP stack in the CN gateways (SGSN and GGSN) as shown in Figure 3. LSPs of required capacities are established for different traffic classes between SGSN and GGSN, during traffic engineering phase. Then, for example, an IP packet arriving at GGSN from the Internet is first parsed to identify the FEC to which it belongs, and hence, the LSP over which it is to be forwarded through the CN. The fields in the packet header such as source/destination IP addresses, TCP/UDP port numbers, IPv6 flow label etc., can be used for parsing purposes. The parsing context in programmed in the GGSN at the time of PDP context activation (see Section C for details). GGSN attaches a label to this IP packet which then is used for forwarding (and label swapping) at the intermediate nodes in the CN. The label is stripped off at SGSN. With this, for example, data packet destined to the MS may traverse a different path through CN, while VoIP packet destined to the same MS may follow the best path. Also, note that MPLS can co-exist with conventional GTP-TCP/UDP-IP stack.

    3. DiffServ for packet forwarding in the CN

The DiffServ QoS architecture [9] is based on a model where traffic entering a network domain is classified and possibly conditioned at the boundaries of the network domain, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single DiffServ Code Point (DSCP). DSCP is included in the IP header of the packet at the ingress edge of the network domain. DiffServ proposes differentiation in the queuing and forwarding treatment received by packets at the routers in the network domain, on the basis of DSCPs included in their headers at the ingress of the network domain. IETF has standardized two groups of behavior aggregates, namely expedited forwarding or EF (one instance or class) and assured forwarding or AF (four instances or classes each containing three drop-precedence levels). The actual policies used for marking, queuing and forwarding of packets at routers in DiffServ domain is implementation-specific issue. EF PHB group has been defined with the intention of providing leased-line like service using DiffServ. This is achieved by regulating the total rate of all the flows registered with the EF PHB class to be less than the service rate allocated to the EF PHB class at that node. Strict policing is enforced on the flows, and any non-conforming packets are dropped at the ingress itself. The AF PHB group has provision for classifying packets into different precedence levels. Three such levels have been specified and each level is associated with a drop precedence (DP). Thus, each AF class has three DSCPs reserved, one for each level. AF PHB group defines a relationship between these three precedence levels. If congestion occurs at a particular forwarding node, a packet with the lowest DP (green) must have the lowest probability of being dropped. Likewise, a packet with the highest DP (red) has the highest probability of dropping. Congestion control mechanism must be used with the AF PHB class. Random Early Detection (RED) has been proposed as one possible technique for congestion control. Other mechanisms with similar capabilities can be used as well. The congestion control mechanism must maintain the relationship between different precedence levels.

UMTS QoS specification [6] describes four classes of traffic, namely Conversational, Streaming, Interactive and Background. The main distinguishing factor between these classes is delay sensitivity of their traffic. Conversational real-time services, like video telephony, are the most delay sensitive applications and those data streams should be carried in Conversational class. Streaming class is to be used to carry real-time traffic flows of non-interactive nature. Interactive and Background classes are mainly meant to be used by traditional Internet applications like WWW, Email, Telnet, FTP and News. They have looser delay requirements, compared to Conversational and Streaming classes. The main difference between Interactive and Background class is that Interactive class is mainly used by interactive applications, e.g. interactive Email or interactive Web browsing, while Background class is meant for background traffic, e.g. background download of Emails or background file downloading. DiffServ can be used to support the above mentioned UMTS QoS classes in the CN. The following table shows the mapping of UMTS QoS classes on different DiffServ PHB classes. For the AF PHBs in Table 1, the first suffix of DSCP indicates the QoS class to which the IP packet belongs, while the second suffix indicates the properties such as conformance of that IP packet to the agreed service level agreement (SLA), traffic handling priority etc.

The process of marking packets with appropriate DHCPs at the edge router is also called as "packet classification." The intermediate routers in the CN use these DSCPs to offer appropriate queuing and forwarding treatment to IP packets.

 

UMTS Traffic Class

Conformance,

Policy, Traffic Handling Priority

Conversational

EF

Streaming

AF11, AF12, AF13

Interactive

AF21, AF22, AF23

Background

Best Effort

 

Table 1: Mapping of UMTS QoS Classes on DiffServ PHB classes

The parameters in IP packet that can be for packet classification can be varied. Some examples are given below.

  • (Source/Destination IP address, Source/Destination port number) can be used to uniquely identify the packets of particular IP flow. The port number may not be always accessible in cases such as use of IPSEC or may not be easily accessible in case of IPv6 packets.

  • (Source/Destination IP address, Protocol ID in IP header, packet size): This combination can get around knowing port numbers. Of course, this may not give the correct classification always. Also, Protocol ID may not be readily available in IPv6 packets.
  • (Source/Destination IP address, Flow label): This combination particularly applies for IPv6 packets. The schemes for negotiating flow label on end-to-end basis need to be developed. An example is to negotiate flow label on an end-to-end basis during VoIP call establishment using Session Initiation Protocol (SIP).

It is required to program appropriate packet classification contexts in the edge nodes of the CN (SGSN and GGSN) at the time of PDP context activation or modification. This may require few modification so the PDP messages, at minimum, PDP ACTIVATE and PDP MODIFIY messages should include information about the IP header fields to be used for packet classification. If the current PDP specification is used without any modifications, packet classification based only of IP addresses is still possible. The semantics of PDP messaging with respect to MPLS and DiffServ in the CN is given in the next section.

 

 

    1. Integration with PDP

PDP messaging [10] can be used to program FEC mapping context and packet classification context at SGSN and GGSN. PDP is the signaling protocol used to establish (contexts for) different communication bearers in UMTS network. We describe below the integration of PDP with the protocol stack of Figure 3.

The MS in STANDBY or READY state sends an Activate PDP Context Request (NSAPI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN. The MS shall use PDP Address to indicate whether it requires the use of a static PDP address or dynamic PDP address. QoS Requested indicates the desired QoS profile.

SGSN performs authentication and radio access bearer (RAB) setup procedures. If the MS requests a dynamic address, then the SGSN lets a GGSN allocate the dynamic address. The SGSN may restrict the requested QoS attributes given its capabilities, the current load, and the subscribed QoS profile. The SGSN sends a Create PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS Negotiated, TID, Selection Mode, PDP Configuration Options) message to the affected GGSN.

Upon receiving this message, GGSN allocates (if required) PDP address. The PDP address and QoS Negotiated are then used by GGSN to program FEC mapping context and DiffServ packet classification context for the downlink traffic. Note that if PDP message is modified to include additional information such as TCP/UDP port numbers that the MS will use or IPv6 flow label, these fields can be used in programming FEC and packet classification contexts as well. At this time, all the contexts required for MPLS and DiffServ are established in SGSN and GGSN, and IP packets can be routed between SGSN and GGSN over LSP with appropriate packet forwarding treatment at the intermediate nodes of the CN.

The SGSN inserts the NSAPI along with the GGSN address in its PDP context. If the MS has requested a dynamic address, the PDP address received from the GGSN is inserted in the PDP context. The SGSN selects a Radio Priority Level based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address, NSAPI, QoS Negotiated, Radio Priority Level, PDP Configuration Options) message to the MS.

The above mentioned transactions are shown in Figure 4. The processing functions during PDP signaling required by MPLS and DiffServ are indicated by colored blocks in Figure 4. They are required to be implemented at SGSN and GGSN only.

 

Figure 4: Use of PDP to Program Packet Classifier and Mapping to FEC at the CN Edges

  1. COncluding Remarks
  2. We described the use of MPLS and DiffServ to support UMTS QoS in GPRS CN architecture. PDP signaling was used to program relevant QoS contexts at the edge nodes (SGSN and GGSN) of CN. Our solution enables deployment of advanced IP QoS mechanisms in the CN in a manner that is backward compatible and requires minimal or no changes to existing radio access network and mobile terminals. This way, it is possible to support evolution of service providers’ core networks to third generation (3G) in a cost-effective and efficient fashion. In this paper, we mainly talked about functionality placement and signaling aspects of using MPLS and DiffServ in the CN.

    An important topic of our current research along these lines is to devise mechanisms for packet forwarding based on DSCPs at the intermediate nodes in the CN. Yet another issue is methods for traffic engineering based on MPLS in the CN. The latter may involve issues such as active QoS monitoring along different LSPs, admission control and fault recovery.

    In this paper, we considered the use of existing PDP signaling framework to implement the tasks required to take advantage of MPLS and DiffServ deployed in the CN. An alternate approach would be to use IP based signaling, such as RSVP (note that use of RSVP does not necessarily mean that IntServ QoS mechanism is used) or IPv6 options [11], for these purposes. Such IP based signaling mechanisms can be used to establish secondary PDP contexts. As an illustration, MS can send RSVP message or IPv6 message embedded in IPv6 options to GGSN over the primary PDP context. GGSN can use the parameters in these messages to create appropriate FEC mapping context and DiffServ packet classifier for the packets that would be using the secondary PDP context.

     

  3. References

  1. M. A. Abu El-Ata, "Evolution of Mobile Cellular Communication Systems," 17th National Radio Science Conference (NRSC), February 2000.
  2. M. Puuskari, "Quality of Service Framework in GPRS and Evolution towards UMTS," 3rd European Personal Mobile Communication Conference, March 1999.
  3. G. Priggouris, S. Hadjiefthymiades, and L. Merakos, "Supporting IP QoS in the General Packet Radio Service," IEEE Network, pp. 8—17, September/October 2000.
  4. J. Mikkonen and M. Turunen, "An Integrated QoS Architecture for GSM Networks," International Conference on Universal Personal Communication (ICUPC), vol. 1, pp. 403—407, October 1998.
  5. R. Koodli and M. Puuskari, "Supporting Packet-Data QoS in Next-Generation Cellular Networks," IEEE Communication Magazine, pp. 180-188, February 2001.
  6. 3GPP Technical Specification 23.107, Version 3.2.0: QoS Concept and Architecture, March 2000.
  7. Rosen et al., "Multiprotocol Label Switching Architecture", work in progress, IETF draft-ietf-mpls-arch-06.txt, August 1999.
  8. Chuck Semeria, "Multiprotocol Label Switching: Enhancing Routing in the New Public Network," white paper, Juniper Networks Inc., http://www.juniper.net/techcenter/techpapers.
  9. S. Blake et. al., "An Architecture for Differentiated Services," IETF Request for Comments 2475, December 1998.
  10. GSM Technical Specification 03.60: General Packet Radio Service (GPRS); Service Description.
  11. H. Chaskar and R. Koodli, "QoS Support in Mobile IPv6," IEEE Broadband Wireless Summit, Networld+Interop, May 2001.