End-2-End QoS Provisioning in UMTS networks

Haibo Wang Devendra Prasad

December 2, 2004

Contents

1 Overview and Problem Definition 31.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Project Time Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 UMTS 62.1 UMTS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 PDP Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Mobile-Node initiated PDP context . . . . . . . . . . . . . . . . . 122.3.2 PDP Context Activation and Modification . . . . . . . . . . . . . . 132.3.3 Network-Requested PDP Context Activation . . . . . . . . . . . . 162.3.4 GGSN-Initiated PDP Context Modification . . . . . . . . . . . . . 17

3 QoS Support from end-to-end viewpoint 193.1 QoS architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 QoS Profile Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 QoS Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Simulation Design and Simulator Limitation 244.1 What is available in ns-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 What is not there . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 What can be calculated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 What Trace file data Contain . . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Simulation Design Limitation: . . . . . . . . . . . . . . . . . . . . . . . . 264.6 Simulation Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2

Chapter 1

Overview and Problem Definition

1.1 Background

1.2 Problem Definition

When considering an End-2-End QoS provisioning via a UMTS network, there could be along chain(e.g, from a MS user to a real-time application server located in Internet) involvedwith several issues:

Figure 1.1: Layered Service architecture of an E2E QoS chain in UMTS

1. How a middle-ware should be defined to mapping an application type to L4 or L3(IP)QoS profile?

3

CHAPTER 1. OVERVIEW AND PROBLEM DEFINITION

2. If an IP QoS profile has be identified from end to end with Diffserv or Interserv, howto map it to a UMTS QoS profile?

3. how this mapped UMTS Qos class can be supplied from MS till GGSN? This meansmechanisms in 3 interfaces must be defined to guarantee this Qos class:

• MS-RNC: RRM policy involved.

• RNC-SGSN: GTP protocol involved, transmission based on ATM or IP net-work.

• SGSN-GGSN: GTP protocol involved, transmission based on IP network.

Inside the UTRAN and CN, UMTS QoS control mechanisms suport per-flow re-source allocation and control employing the UMTS PDP context concept [?]. Theseresource management mechanisms include call/packet access control(CAC/PAC),services classify, buffer management, and scheduler.

4. When packets go outside of GGSN, IP QoS serve again, but given the IP QoS havebeen encapsulated but not changed, UMTS need not to do a reverse mapping. It willbe leave to external IP network.

5. If the server located in the IMS inside the same operator’s network, IP QoS mecha-nism has to be defined after GGSN deliver the user packets.

1.3 Project Time Plan1. Overview: Sept. 8th - Oct. 1st

(a) Overview Paper study

(b) More relevant study in order to rectify the existing problem.

(c) Problem definition(preliminary)

2. Play-Scenario decision: Sept. 25th - Oct. 29th

(a) Study on UMTS PDP context and QoS.

(b) Study on IP QoS.

(c) Problem delimitation

(d) Simulation study and installation.

3. Simulation: Oct 30th - Dec 1st

(a) Simulator Limitation (What’s there, what’s not and other possibilities).

(b) Simple Simulation Design based on Simulator limitation.

4. Simulation: Dec 2nd- Dec 20th

4

1.3. PROJECT TIME PLAN

(a) Make the first end-2-end simulation model(Best Effort).

(b) Identification of a new strategy for End-2-End QoS provision

5. Simulation: Dec 21nd- Jan 10th

(a) Simulation Results Analysis.

(b) Propose a new strategy for End-2-End QoS provision.

6. 9-Semester Presentation: Jan 13th, 2005

7. Simulation Analysis and Measurement: Feb 10th - March 15th

(a) Simulation results Analysis with possible analytical model.

(b) Design measurement setup for proposed E2E QoS strategy.

(c) Measurement with emulator

8. Further output study: March 16st - April 10th Analysis

(a) Measurement results analysis together with simulation result.

(b) upgrade simulator based on output analysis if necessary.

9. Project report/Thesis finalize: April 11th - May 1st.

(a) Build or polish analytic model based on simulation and measurement output.

(b) Finish all report/Thesis documents.

10. Thesis Defence Preparation: May 2nd - June 15th

(a) Thesis hand in

(b) Preparation for defence.

5

Chapter 2

UMTS

3G Systems are intended to provide a global mobility with wide range of services includ-ing telephony, paging, messaging, Internet and broadband data. International Telecommu-nication Union (ITU) started the process of defining the standard for third generation sys-tems, referred to as International Mobile Telecommunications 2000 (IMT-2000). In EuropeEuropean Telecommunications Standards Institute (ETSI) was responsible of UMTS stan-dardisation process. In 1998 Third Generation Partnership Project (3GPP) was formed tocontinue the technical specification work.

2.1 UMTS ArchitectureA network architecture is defined by 1)functional groups and 2)reference points. Func-

tional groups are defined by a set of functions, which may be performed by one or morephysical piece of equipment; reference points are conceptual points separating functionalgroups, representing a physical interface between pieces of equipment.

A UMTS network consist of three interacting domains; Core Network (CN), UMTSTerrestrial Radio Access Network (UTRAN) and User Equipment (UE). The main functionof the core network is to provide switching, routing and transit for user traffic. Core networkalso contains the databases and network management functions. The UTRAN provides theair interface access method for User Equipment. Base Station is referred as Node-B andcontrol equipment for Node-B’s is called Radio Network Controller (RNC).

6

2.1. UMTS ARCHITECTURE

Mobile Phone, PDA, Notebook, etc

BSS from GSM

User Equipment(UE)

UMTS Radio Acess Network

(UTRAN)

Domain (CS)

Circuit Switched Packet Switched

Domain (PS)

is called UTRA

Radio Link between UTRAN and UE

Radio Access Network(RAN)

Core Network (CN)

A Iu−ps

Iu−cs Gb

Subsystem(IMS)IP Multimedia

External Networks(Internet, PSTN,...)

Gi

Gi

Figure 2.1: UMTS Basic Network Architecture

• Core Network (CN)

The basic Core Network architecture for UMTS is based on GSM network withGPRS. All equipment has to be modified for UMTS operation and services. TheCore Network is divided in circuit switched and packet switched domains. Some ofthe circuit switched elements are Mobile services Switching Centre (MSC), Visitorlocation register (VLR) and Gateway MSC. Packet switched elements are ServingGPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN). Somenetwork elements, like EIR, HLR, VLR and AUC are shared by both domains.

According to the latest 3GPP R5 specification, IP will be the main protocol fortransporting user packets inside the PS core network. However, user packets are notdirectly routed via IP routing protocol but based on GPRS Tunneling Protocol(GTP).

7

CHAPTER 2. UMTS

Figure 2.2: UMTS Core Network Transmission

• UTRAN

Wide band CDMA(WCDMA)technology was selected to for UTRAN air inter-face, which supports a transmission rate theoretically up to 2Mbit/s (realistic up toaÖ300kb/s). UMTS WCDMA is a Direct Sequence CDMA system where user datais multiplied with quasi-random bits derived from WCDMA Spreading codes. InUMTS, in addition to channelisation, Codes are used for synchronisation and scram-bling. WCDMA has two basic modes of operation: Frequency Division Duplex(FDD) and Time Division Duplex (TDD). A specific structure of UTRAN is depictedin figure 2.3.

Figure 2.3: UMTS Radio Access Network(UTRAN): Architecture

The functions of Node-B are:

– Air interface Transmission / Reception

– Modulation/Demodulation

– CDMA Physical Channel coding

8

2.1. UMTS ARCHITECTURE

– Micro Diversity

– Error Handing

– Closed loop power control

The functions of RNC are:

– Radio Resource Control

– Admission Control

– Channel Allocation

– Power Control Settings

– Handover Control

– Macro Diversity

– Ciphering

– Segmentation / Reassembly

– Broadcast Signalling

– Open Loop Power Control

• User Equipment

The UMTS standard does not restrict the functionality of the User Equipment inany way. Terminals work as an air interface counter part for Node-B and have manydifferent types of identities. Most of these UMTS identity types are taken directlyfrom GSM specifications.

UMTS mobile station can operate in one of three modes of operation:

– PS/CS mode of operation: The MS is attached to both the PS domain and CSdomain, and the MS is capable of simultaneously operating PS services and CSservices.

– PS mode of operation: The MS is attached to the PS domain only and mayonly operate services of the PS domain. However, this does not prevent CS-likeservices to be offered over the PS domain (like VoIP).

– CS mode of operation: The MS is attached to the CS domain only and mayonly operate services of the CS domain.

9

CHAPTER 2. UMTS

2.2 Protocol Stack

GPRS Tunnelling Protocol (GTP)GPRS Tunnelling Protocol is the defining protocol of the GPRS core network. It is an IPover IP tunnelling protocol (though, in principle it can also carry other protocols such asPPP or, in older versions, X.25). As of 2004 there are two versions defined, version 0 andversion 1. Interestingly version 0 and version 1 are considerably different in structure. Inversion 0 the signalling protocol (the protocol which sets up the tunnels by activating thePDP context is combined with the tunnelling protocol on one port. Version 1 is actuallyeffectively two protocols, one for control (called GTP-C) and one for user data tunnelling(called GTP-U). GTP-U is also used to transport user data from the RNC to the SGSN inUMTS networks. However, in this case signalling is done using RANAP instead of GTP-C.

There are two main purposes to use GTP to tunnel user packets:

1. Tunnelling enables GPRS protocols, rather than IP protocols, to be used inside thePS CN domain for routing and mobility management.

2. Tunnelling makes the transport inside a PS CN domain independent of the protocolused in external packet networks. Hence there will be no need for the UMTS networkto understand external packet data protocols.

Figure 2.4: UMTS Protocol Stack

2.2.1 limitation

related to GTP

10

2.3. PDP CONTEXT

2.3 PDP ContextA Mobile or User Terminal (UE) needs to acquire and configure itself with a PDP address

(i.e. an IP Address when the PDP is IP). Mobile may use single or multiple PDP addressessimultaneously as per requirement. A PDP context must be established (to get PDP address)and activated in the Packet Switched (PS) Core Network (CN) domain and on the mobile,before any user packets destined to or originated from a PDP address can be transportedover a 3GPP PS core network.

A PDP context is maintained and used by network nodes to determine how to forwarduser packets destined and originated from a particular PDP address. The PDP contextmaintained by a mobile, an SGSN, and a GGSN link together a Radio Access Bearers(RABs) whereas a CN Bearer to form a 3GPP Bearer for the mobile.

A PDP context maintained on the SGSN and the GGSN carry the following useful infor-mation.

• PDP address used by the mobile to and receive PDP Packets.

• Routing Information used by the network node to determine where to forward auser packet such as identifier (established between SGSN and GGSN for this PDPcontext), Access Point Name (APN). APN is a logical name used by SGSN to deter-mine which GGSN is suitable for a mobile and determination of the service requestby user or address of an access point in an external packet network to which userpacket should be forwarded by GGSN.

• Quality of Service (QoS) Profile:

1. QoS Profile Subscribed: describe QoS characteristic subscribed by mobile user.

2. QoS profile Requested: Describe QoS characteristic currently requested by mo-bile user.

3. QoS profile negotiated; QoS actually provided by the network to the mobile atthe current time.

PDP context can be divided into two different state namely ACTIVE and INACTIVEstates as shown in Figure 1. ACTIVE state contains up to date information for forwardingPDP context between the mobile and the GGSN. Active state doesnart guarantee the RABestablishment over the RAN to transport user packet. RABs may be established only whenmobile has a user packet to send to the network or the network user packet for the mobile.

In PDP INACTIVE state may contain a valid PDP address but not valid routing, mappinginformation needed to determine how to process packets. If GGSN has user packets to sendto a mobile but the PDP context for the destination PDP address is in INACTIVE state, theGGSN may use network requested PDP context activation procedure to change the PDPcontext of the destination mobile to ACTIVE state.

11

CHAPTER 2. UMTS

Figure 2.5: PDP Context State Transition

2.3.1 Mobile-Node initiated PDP contextItars a three step process to activate mobilears user access to 3GPP packet switched

network and services .The first step is GPRS attach as shown in figure 2a.GPRS attachprocedure is used by mobile to register with the PS CN domain or precisely with the SGSN.A mobile provides its identity and service requirements to the SGSN during attach process.SGSN after authentication with Home Subscriber Server (HSS, is a database), authorizeGPRS attach to the mobile. GPRS attach perform following functions:

• GPRS attach facilitate the establishment of Mobility Management Context on themobile, in the Radio Access Network (RAN)(e.g., on the Radio network controller,and on the SGSN. This allows the RAN and the SGSN to track the mobile location.

• A signaling connection establishment between the mobile and the SGSN. The mo-bile and the SGSN use this signaling connection to exchange signaling and controlmessages needed to perform the GPRS attach procedure. The mobile can keep on us-ing the signaling connection to exchange signaling message, once the GPRS attachis completed (i.e., PDP context activation).

• Provides mobile an opportunity to access SGSN based services like sending andreceiving SMS messages which is paged by SGSN.

Figure 2.6: Step 1:Mobile registers with PS CN via GPRS attach

PDP Context Activation and RAB Establishment: A PDP context for PDP address hasto be established and activated on the mobile, and in the PS CN as shown in Figure 2b.Therefore a mobile can use a PDP address to send and receive user packets over a 3GPP PS

12

2.3. PDP CONTEXT

CN. After the GPRS attach, a mobile can request the network to establish and activate itsPDP address. PDP context activation trigger the PS CN domain to establish the CN Bearerand RAB needed to transport user packets to and from the mobile.

Figure 2.7: Step 2: Activate PDP Context and establish Radio Access Bearer

Register with the IP Multimedia Subsystems (IMS) The mobile needs to be registeredwith the IMS in order to access the IP-based real-time voice or multimedia services pro-vided by IMS. Since the Signal Initiation Protocol (SIP) is used by the IMS to providereal-time services. Hence, User has to use the SIP registration Process to register with theIMS as shown in Figure 2C.

Figure 2.8: Step 3: Registration with the IMS (Mobile Initiated)

2.3.2 PDP Context Activation and Modification

PDP Context Activation has the following main functions:

PDP address allocation The mobile is allocated a PDP address by the network if needed.

CN Bearer Establishment The network creates, activates the PDP context and establishnecessary bearer on GGSN and SGSN for transporting user as well as signaling trafficfor the activated PDP context.

RAB Assignment The network establishes the RAB to carry user traffic.

The PDP Context Activation and Modification can be Mobile initiated, GGSN initiated andNetwork requested. The next section is specific to Mobile initiated.

13

CHAPTER 2. UMTS

Mobile-Initiated: PDP context Activation and Modification: The procedure for mobile-initiated PDP context activation by keeping an assumption that the radio access networkis Universal terrestrial radio Access network (UTRAN) is shown in figure 3. A mobileinitiates PDP context activation (Step 1, Figure 3). The message carries the followinginformation:

PDP Address THE PDP Address field can either be mobile specified PDP address or0.0.0.0 in order to indicate to the network that the mobile will acquire a PDP ad-dress from an external IP network.

Network-layer Service Access Point Identifier (NSAPI) The unused NSAPI can be usedby the mobile to send user packet originated from the PDP address or to receive userpacket addressed to the PDP address.

PDP type Used by the mobile to indicate the type of PDP such as IP, Point-to-Point Pro-tocol (PPP).

APN Contains the APN requested by mobile.

PDP Configuration Options Mobile use this option to communicate optional PDP pa-rameters directly with GGSN (i.e., these parameters will not be interpreted by theSGSN).

Figure 2.9: Mobile initiated PDP Context activation

1. The mobile uses the PDP Address field in the Activate PDP Context request messageto inform the network about the use of a static PDP address or be assigned a dynamicPDP address. In order to use a static PDP address, the mobile need o provide thestatic address in the PDP Address field of the Activated PDP Context Request. For adynamic assignment of PDP address assigned by the visited PS domain or an externalpacket network, the mobile need to set the PDP Address field of the Activate PDPContext Request to zero.

14

2.3. PDP CONTEXT

2. The APN used by the mobile to select a service (or GGSN) in the PS domain or acontact point in an external packet network. A Domain Name System (DNS) can beused to translate an APN to an IP address.

3. An SGSN uses the APN and the configuration information stored on the SGSN toselect the mobile’s serving GGSN. Through its configuration information, the SGSNknows the PDP type subscribed by each user, the APN configured by the networkoperator to support each PDP type. When the APN received from the mobile in theform of Activate PDP Context Request matches an APN in the mobiles subscribedAPN’s. The SGSN use the APN to query the DNS to discover the IP address of theGGSN for the mobile. If SGSN receives a PDP context Activation request from themobile without an APN then the SGSN may use an APN in the mobile’s subscriptionprofile that is configured by the network operator to support the PDP type specified inthe Activate PDP context Request. If the APN provided in the Activate PDP Contextrequest matches no APN subscribed by the mobile, the SGSN will reject the mobile’sActivate PDP Context Request.

4. Once SGSN selects the mobile serving GGSN, the SGSN sends a create PDP contextRequest to the selected GGSN . SGSN request GGSN to establish a PDP context forthe mobile as well as the GPRS Tunneling Protocol (GTP) tunnel between the SGSNand the GGSN to transport the user packets for this PDP context. Upon receiving theCreate PDP Context Request, the GGSN activate a service provided by the GGSN(e.g., dynamic PDP address assignment by the GGSN) or find a contact point on theexternal packet network (e.g., a PDP address server) by using the APN associatedwith PDP Context Request.

5. GGSN creates a new PDP context and insert it into its PDP context table. The GGSNwill also establish a CN Bearer (GTP Tunnel) between the GGSN and the SGSN forthe PDP context. Then the GGSN sends a Create PDP context Response messageback to the SGSN. If the mobile want to have a dynamic PDP address from an exter-nal packet network, then the PDP context created by the SGSN, GGSN for a mobilewill not carry a valid PDP context. This active PDP context will allow a mobileto send PDP packets through the PS domain to contact a PDP address server in theexternal packet networks to acquire a PDP address.

6. Upon receiving the Create PDP Context Response, the SGSN triggers the processto establish RAB for the mobile using the RAB Assignment procedure. When theRABs have been established successfully. The SGSN sends an Invoke Trace messageto the RNC to request the RAN to start collecting statistics on the network resourcesused for the PDP context.

7. The QoS attributes associated with the RABs is worse than the QoS profile in thePDP context stored on the GGSN. The SGSN informs the GGSN by sending anUpdate PDP Context request to the affected GGSN.

8. On receiving a positive Update PDP Context Response from the GGSN, the SGSNwill inform the mobile of successful PDP context activation by sending Activate PDP

15

CHAPTER 2. UMTS

Context activation.

2.3.3 Network-Requested PDP Context Activation

The GGSN may use the Network-Requested PDP Context Activation process to estab-lish and activate a PDP context for the PDP address in order to deliver the packets from theGGSN to the mobile in case of mobile does not have an active PDP context for the PDPaddress. Weather the GGSN should initiate Network-Request PDP Context Activation foreach specific PDP address based on the operator policy for the GGSN. The GGSN musthave static information about the PDP address to support Network-requested PDP ContextActivation. The GGSN starts Network-Requested PDP Context Activation by sending aSend-Routing-Information-for-GPRS message to the Home Location register (HLR) to re-trieve the address of the destination mobile serving SGSN as shown in Figure 4,Step1, 2.

Figure 2.10: Network-Requested PDP Context Activation

1. The HLR uses the mobile’s International Mobile Subscriber Identity (IMSI) associ-ated with the message to determine weather the request ca be granted and to searchthe HLR database for the requested information regarding this mobile. The HLRreturns with Send-Routing-information-for-GPRS-ACK message.

2. The message carries the address of the mobile’s serving SGSN if the HLR determinesto grant the Send-Routing-Information-for-GPRS received from the GGSN. On theother hand, an error occurs if the HLR cannot grant the Send-information-for-GPRSmessage.

3. After getting the positive ACK from the HLR, the GGSN sends a packet Data Unit(PDU) Notification Request message to the serving SGSN.

16

2.3. PDP CONTEXT

4. Upon receiving PDU Notification Request, the SGSN instruct the mobile to initiatePDP context activation. The Notification message carries the mobile’s IMSI, the PDPtype, the PDP Address for which a PDP context should be activated and the APN thatthe SGSN as well as mobile should use to determine which GGSN to use. The SGSNsends back PDP Notification Response to GGSN with a specific message that it willhonor PDU Notification Request.

5. Then the SGSN sends PDP Context Activation Request to mobile to start PDP Con-text action process.

6. The Request PDP Context activation Message carries the APN the SGSN has re-ceived from the GGSN. The mobile in the Mobile-Initiated PDP context Activationprocedure can use APN.

2.3.4 GGSN-Initiated PDP Context ModificationSince the PDP context information elements often need to be modified including the PDP

address and the QoS profiles. In Release 5, the GGSN is allowed to initiate the process tomodify the PDP address in an active PDP context. However, QoS profile modification canbe initiated by the mobile,GGSN,SGSN or the RAN.

Figure 2.11: GGSN Initiated PDP Context Modification

1. In a GGSN -Initiated PDP Context Modification procedure as shown in Figure 5, theGGSN sends Update PDP Context Request message to the SGSN.

2. The message carries Tunnel Endpoint Identifier (TEID),NSAPI,PDP Address andQoS Requested. TEID identifies the SGSN end of the GTP tunnel associated withthe PDP context to be modified.NSAPI identifies the PDP context to be modified.PDP Address contain the new PDP address if the GGSN wants to modify it.QoSRequested contains the suggested QoS profile by the GGSN. If requested then theSGSN provides a QoS Negotiated profile to the mobile to offer.The Negotiated QoS

17

CHAPTER 2. UMTS

profile can be constructed by the SGSN capabilities,current load, the QoS profilesubscribed by the user,and the Requested QoS profile received in the Update PDPContext Request message from the GGSN.The SGSN sends a Modify PDP ContextRequest message to the mobile with PDP Address and Negotiated QoS profile.

3. On receiving the Modify PDP Context Request, the mobile can accept or reject therequested message.The mobile returns the Modify PDP Context Accept message tothe SGSN by accepting the request.

4. The mobile can also reject the request by deactivating the affected PDP context usingthe Mobile-Initiated PDP Context Deactivtion procedure.Once the SGSN receivesthe PDP modify requst acceptance message from the mobile. It initiate RAB As-signment procedure to modify the RABs, if needed to support the negottiated QoSprofiles. The SGSN then sends back Update PDP Context Response message to theGGSN for the successful completion of the GGSN-Initiated PDP Context Activationprocedures.

18

Chapter 3

QoS Support from end-to-end viewpoint

To build an End-to-End QoS simulation environment with UMTS network for real-timeapplications, a video stream application was selected to be transferred between 1 serverand multiple UEs inside 1 UMTS cell.

3.1 QoS architectures

End-to-End QoS means that the evaluation of the service is done from the end-user prospec-tive. The end user could be a terminal or another UMTS network. The QoS types includethe concept necessary in order to justify the QoS architecture and strategy proposed. Theproposed topology would include the simplest topology design based on certain QoS para-meter such as delay, packet loss, jitter and throughput.

It is a challenging and complex problem to design all-IP based communication scenario.In such a scenario, where the access network is UMTS, the core networks may or may notprovide the QoS support and application may have different transport requirements. SinceApplication oriented transport requirement could be different than networks own QoS char-acteristics. Hence, a general requirement review of these concepts is necessary to justifythe QoS architecture.

From Application Point: The Applications are viewed in two different way with respectto network. The Applications in IP world (Proposed by IETF) are termed as elastic orreal-time. In UMTS network (Proposed by 3GPP), Applications are classified basedon the generated traffic. There are four different types of traffic such as Conversa-tional, Streaming, Interactive and background. The Table 1 shows the applicationassociated with those types of traffic and their bottleneck parameters in order to getthe best QoS.

19

CHAPTER 3. QOS SUPPORT FROM END-TO-END VIEWPOINT

Traffic Application Jitter Delay(E2E) Symmetric/Asymmetric Round-Robin/BER

Conversational Audio-Video Low Low SymmetricStreaming Video(Continuous

flow)Medium Medium Asymmetric

Interactive Web Browsing Asymmetric LowBackground Email Not Im-

portantNot Impor-tant

From IP QoS Point of view: the IP QoS point of view can be seen in a scenario, whenthe transport of IP packet through set of network and one of them is UMTS network,as represented in Fig.3.1. In that case, the network element dealing with IP terminalequipment, GGSN and Server need to be cooperating. That enables them to handletheir packet queues, so that the packets generated by the applications can be trans-ported with same predictable and differentiated guarantees. The known approachesfor dealing with IP QoS are Integrated Services (IntServ) and Differentiated Services(DiffServ).

UE GGSN ExternalServer

IP

Networks(UMTS)

NetworkAccess

IP

Figure 3.1: Reference Architecture

DiffServ provides an IP based QoS technology which attempts to solve the QoS prob-lem without making resource reservation for flow establishment and maintenance.The control is based on DiffServ Code Point (DSCP). The DSCP is placed in the IPheader. The DiffServ aware router differentiates the traffic based on DSCPs of thereceived packet. DiffServ does not maintain state information about the traffic flow.Different flow with same DSCP values are treated in the same way and consideredas single flow with unique per hop behavior (PHB). DiffServ main advantage is itssimplicity.

Integrated Service provides application requirements to the network, which have tocontain QoS mechanisms to insure the promised QoS. The Resource reservation pro-tocol, which transports the QoS requirements along the path from the sender to thereceiver in order to make resource reservation.

20

3.2. QOS PROFILE PARAMETERS

UMTS QoS: When terminal attached itself to the network a PDP Context is established.PDP Context provides the UMTS Bearer Service. PDP Context means creating atunnel between terminal and the GGSN. The terminal equipment endpoint of thistunnel moves with the terminal and new tunnels may be dynamically activated (Sec-ondary PDP context). In that case traffic flow templates (TFT) are associated witheach Secondary PDP context. QoS is the main attributes of a PDP context and isnegotiated during PDP context activation. During the PDP context activation, thereare number of attributes should be negotiated. Common to all traffic classes are themaximum bitrate, delivery order, maximum Service Data Unit (SDU) size, SDU er-ror ratio, residual bit error ratio, delivery of erroneous SDUs, and allocation/retentionpriorities. The Conversational and Streaming traffic classes consider SDU format in-formation, transfer delay and the guaranteed bit rate. In the interactive traffic Class,the traffic handling priority can be negotiated.

3.2 QoS Profile ParametersThe QoS attributes or QoS Profile parameters are one of the important aspects of this sim-ulation design in order to map it with the incoming traffic. The UMTS packet core networkshould support different backbone bearer service for variety of QoS either in IP layer orATM (Asynchronous Transfer Mode). The attributes used in the simulation design are asfollows:

1. Traffic Class: The core network can be optimized for these types of application. Thetype can be Conversational, streaming, interactive or background. By including thetraffic class itself as an attribute, the GGSN can make assumptions about the trafficsource and optimize the transport for that traffic type. Buffer allocation can be basedon traffic class.

2. Maximum bitrate (kbps): It is the maximum number of bits delivered by GGSNand to GGSN at a Service Access Point (SAP) within a period of time, divided bythe duration of time. The traffic is conformant with maximum bit rate as long asit follows a token bucket algorithm where token rate equals Maximum bit rate andbucket size equals maximum Service Data Size (SDU).The purpose is to limit thedelivered bit rate to applications or external networks with such limitations and allowmaximum wanted core network bearer bit rate to defined for applications able tooperate with different rates.

3. Guaranteed bitrate (kbps): It is the guaranteed number of bits delivered at a SAPwithin a period of time (provided that there is data to deliver), divided by the dura-tion of the period. The traffic is conformant with the guaranteed bit rate as long asit follows a token bucket algorithm where token rate equals guaranteed bit rate andbucket size equals k*Maximum SDU size. Guaranteed bit rate can be used to facili-tate admission control based on available resources, and for resource allocation withGGSN. Quality requirements expressed by delay and reliability attributes only applyto incoming traffic up to the guaranteed bit rate.

21

CHAPTER 3. QOS SUPPORT FROM END-TO-END VIEWPOINT

4. Delivery order (y/n): It indicate weather the core network bearer shall provide in-sequence SDU delivery or not. It specifies if out-of-sequence SDUs are acceptableor not. This information cannot be extracted from the traffic class. Weather out-of-sequence SDUs are dropped or re-ordered depends on the specified reliability.

5. Maximum SDU size (octets): It is the maximum allowed SDU size. The maximumsize is used for admission control and policing.

6. SDU error ratio: It indicates the fraction of SDUs lost or detected as erroneous.SDU error ratio is defined only for conforming traffic. By reserving resources, SDUerror performance is independent of the loading conditions, whereas without reservedresources, such as in interactive and background classes, SDU error ratio is used astarget value.

7. Delivery of erroneous SDUs (y/n/-): It indicate whether SDU with errors shall bedelivered or not. ’Yes’ implies that error detection is employed and that erroneousSDUs are delivered together with an error indication, ’no’ implies that error detec-tion is employed and that erroneous SDUs are discarded.’-’ implies that SDU aredelivered without considering error detection.

8. Transfer Delay (ms): It indicates maximum delay for the 95th percentile of the distri-bution of delay for all delivered SDUs during the lifetime of a bearer service, wheredelay for an SDU is defined as the time from a request to transfer an SDU at one SAPto its delivery at the other SAP. It specifies the core network part of the total transferdelay for the UMTS bearer.

9. Traffic handling priority: It specifies the relative importance for handling of all SDUsbelonging to a core network bearer compared to the SDUs of other bearers. Priorityis an alternative to absolute guarantees, and thus these two attributes types cannot beused together for a single bearer.

10. Allocation/Retention Priority: It Specifies the relative importance of a core networkbearer compared to other core network bearers for allocation and retention. The allo-cation/retention priority attribute is a subscription parameter, which is not negotiatedfrom the mobile terminal.

3.3 QoS MetricsThe well know QoS metrics include the following:

1. Delay: The latency or absolute delay is an important parameter from a user prospec-tive. It is the elapsed time for a packet to traverse the network from the source tothe destination. At the network layer, the end-to-end packet latency is the sum ofprocessing delay, packet delay, transmission delay, queuing delay and propagationdelay.

22

3.3. QOS METRICS

2. Jitter: The late data arrivals make data useless, resulting in receiver buffer underflow,and early arrival can lead to receiver buffer overflow. It is defined as the variation indelay encountered by similar packets following the same route through the network.

3. Loss rate: loss requirements apply to all classes of applications because the purposeof a communication application is to deliver data in the first place. Any data lostmeans that such delivery is not achieved.

4. Throughput

23

Chapter 4

Simulation Design and SimulatorLimitation

The simulator was decided to be built on the basis of network simulator version 2 (ns-2).And the first simulator is a simple one to identify E2E QoS problems only based on ns-2.26all-in-one package without its extension(UMTS, etc). The reason is the available UMTSextension was designed to emulate the air interface on layer 1 and 2 which are not the mainconcern of this project, even though the air interface emulation result can be included laterto generate some parameters like packet loss, propagation delay, etc. So all the followingdiscussion is based on the availabilities and limitations of ns-2.

4.1 What is available in ns-21. Router Queue Management Techniques like Drop Tail, RED(Random Early Detec-

tion),CBQ

2. Multicast, Unicast

3. GPRS

4. Traffic Source Generator-www, CBR (Constant Bit rate), VBR

5. Transport Agents- UDP/TCP.

6. Routing.

7. Packet Flow.

8. Network Topology (Based on Nodes, Link). Nodes are considered as any networkentity like Server, Router,Node B or Mobile.

9. Applications- Telnet, FTP, Ping.

10. Tracing Packets on all links/specific links.

11. Implementation of RED queue in DiffServ Module, Edge and Core Router, Policy.

24

4.2. WHAT IS NOT THERE

4.2 What is not there1. SGSN and GGSN is not implemented.

2. PDP Context is not implemented

3. QoS Profile Parameters are not considered

4. Air- Interface or Propagation is not implemented, Basic propagation model is there

4.3 What can be calculated1. Delay.

2. Jitter.

3. Processing Time.

4. Round trip times.

5. Number of intermediate nodes.

6. Throughput graphs.

4.4 What Trace file data Contain1. Operation performed in the simulation.

2. Operation performed in the simulation.

3. Node 1 of what is being traced(Source Node).

4. Node 2 of what is being traced(Destination Node).

5. Packet type.

6. Packet size.

7. Flags.

8. IP flow identifier.

9. Packet source node address.

10. Packet destination node address.

11. Sequence number.

12. Unique packet identifier

25

CHAPTER 4. SIMULATION DESIGN AND SIMULATOR LIMITATION

4.5 Simulation Design Limitation:1. 1. In NS-2 Network Topology is based on the Nodes and the links. Different section

of the network is shown by the nodes and configured afterwards as per the require-ments. The connections between the two Nodes are done through the Single or Du-plex links. The configuration parameter for Duplex Link is: Bandwidth, Delay andQueue types.

2. 2. The traffic Application that go on the top of a UDP agent to simulate networktraffic e.g. CBR (Constant Bit Rate), Configuration parameters are

• Packet Size: Constant Size of packets generated e.g. 48

• Rate: sending rate e.g. 64kb

• Interval: Interval time between packets e.g. 0.05

• Random: Flag to introduce noise in the departure times, default is off, 1 is on.

• Maximum Packet: the maximum number of packets to send

4.6 Simulation DesignThe Simulation design is based on the limitation of NS-2 Simulator 2.26 as discussed in theprevious section. The simple Topology is designed on the basis of following assumptions:

1. The PDP Context is already negotiated.

2. The QoS Profile parameters are assumed at the beginning of the simulation in orderto map the incoming traffic from the other UMTS or External network or ApplicationServer.

3. The Nodes will be considered as SGSN, GGSN and RNC. The connection betweenthem would be either Single or Duplex Link.

4. There are multiple user and their assumed PDP addresses are stored in the PDP con-text in the beginning of the simulation.

5. There are only one SGSN, GGSN instead of multiple. So the Access Point Name atthe PDP Context is known in the beginning of the simulation.

6. Data can be sent from the application server to the UE via GGSN .So the source of thedata would be Application server and the destination would be UE. Streaming classcan be adopted with UDP as the transport link. Since the PDP Context is alreadynegotiated and has PDP address of all the UE. GGSN checks the APN and forwardthe packet or data to the concerning UE.

26