Contentskom.aau.dk/group/04gr995/Report/reportMay9.pdf · 2.2.2 UTRAN . . . . . . . . . . . . . . ....
70
Contents 1 Introduction 8 1.1 Motivation .............................. 8 1.2 QoS Basic Concept ......................... 8 1.3 Problem Statement ......................... 10 1.4 Project Time Plan .......................... 11 1.5 About this report .......................... 12 2 Overview of UMTS 13 2.1 UMTS Services ........................... 13 2.2 UMTS Architecture ......................... 14 2.2.1 User Equipment ...................... 15 2.2.2 UTRAN ........................... 15 2.2.3 Core Network (CN) ..................... 16 2.2.4 Interfaces .......................... 17 2.3 UMTS protocol stack ........................ 17 2.3.1 UMTS user plane ...................... 17 2.3.2 UMTS control plane .................... 19 2.4 UMTS Air Interface ......................... 20 2.4.1 The physical layer ..................... 20 2.4.2 The MAC layer ....................... 21 2.4.3 RLC layer .......................... 22 2.4.4 RRC layer ......................... 22 2.4.5 Transport channels ..................... 23 2.5 PDP Context ............................ 23 2.5.1 PDP context states ..................... 24 2.5.2 PDP context procedures .................. 25 3 UMTS QoS 26 3.1 UMTS QoS architecture ...................... 26 3.2 UMTS QoS classes ......................... 27 3.3 UMTS QoS mechanisms ...................... 28 1
Transcript of Contentskom.aau.dk/group/04gr995/Report/reportMay9.pdf · 2.2.2 UTRAN . . . . . . . . . . . . . . ....
Contents
1 Introduction 81.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 QoS Basic Concept . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . 101.4 Project Time Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5 About this report . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Overview of UMTS 132.1 UMTS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 UMTS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 User Equipment . . . . . . . . . . . . . . . . . . . . . . 152.2.2 UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Core Network (CN) . . . . . . . . . . . . . . . . . . . . . 162.2.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 UMTS protocol stack . . . . . . . . . . . . . . . . . . . . . . . . 172.3.1 UMTS user plane . . . . . . . . . . . . . . . . . . . . . . 172.3.2 UMTS control plane . . . . . . . . . . . . . . . . . . . . 19
2.4 UMTS Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.1 The physical layer . . . . . . . . . . . . . . . . . . . . . 202.4.2 The MAC layer . . . . . . . . . . . . . . . . . . . . . . . 212.4.3 RLC layer . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.4 RRC layer . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.5 Transport channels . . . . . . . . . . . . . . . . . . . . . 23
2.5 PDP Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.1 PDP context states . . . . . . . . . . . . . . . . . . . . . 242.5.2 PDP context procedures . . . . . . . . . . . . . . . . . . 25
3 UMTS QoS 263.1 UMTS QoS architecture . . . . . . . . . . . . . . . . . . . . . . 263.2 UMTS QoS classes . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 UMTS QoS mechanisms . . . . . . . . . . . . . . . . . . . . . . 28
1
CONTENTS
3.3.1 QoS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.2 Traffic Flow Template . . . . . . . . . . . . . . . . . . . 283.3.3 PDP context signalling procedure . . . . . . . . . . . . . 31
3.4 UMTS QoS management entities and mechanism . . . . . . . . . 333.5 Conslusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 IP QoS 384.1 DiffServ approach . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.1 Per Hop Behaviors(PHB) and Differentiated Services CodePoint(DSCP) . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.2 Per Hop Behaviors . . . . . . . . . . . . . . . . . . . . . 394.1.3 Traffic classification and conditioning . . . . . . . . . . . 414.1.4 Queuing - RED . . . . . . . . . . . . . . . . . . . . . . . 414.1.5 Meter and Marker functions - Policy . . . . . . . . . . . . 434.1.6 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 IntServ/RSVP Policy . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Comparison between IntServ and DiffServ . . . . . . . . . . . . . 46
5 NS-2 simulator and preliminary simulation 475.1 Overview of ns2 . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2 DiffServ module . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1 AF PHB Implementation with multiple RED queues . . . 495.2.2 Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.3 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 UTRAN extension . . . . . . . . . . . . . . . . . . . . . . . . . 515.3.1 UTRAN nodes and links . . . . . . . . . . . . . . . . . . 515.3.2 RLC object . . . . . . . . . . . . . . . . . . . . . . . . . 525.3.3 Error Model for DCH . . . . . . . . . . . . . . . . . . . . 52
6 Delimitation 536.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . 536.2 State-of-the-Art . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.1 Works on E2E framework . . . . . . . . . . . . . . . . . 546.2.2 Works on mapping: SAMU project . . . . . . . . . . . . 546.2.3 Works on Policy: EVEREST project . . . . . . . . . . . . 556.2.4 Works on CAC . . . . . . . . . . . . . . . . . . . . . . . 556.2.5 Works on simulation: SEACORN project . . . . . . . . . 566.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3 Problem Delimitation . . . . . . . . . . . . . . . . . . . . . . . . 57
2
CONTENTS
7 Preliminary Simulation 587.1 Simulation including UTRAN . . . . . . . . . . . . . . . . . . . 58
7.1.1 Simulation settings . . . . . . . . . . . . . . . . . . . . . 587.1.2 Simulation result and conclusion . . . . . . . . . . . . . . 59
7.2 Simulation on DiffServ wired network . . . . . . . . . . . . . . . 607.2.1 Simulation topology and settings . . . . . . . . . . . . . . 607.2.2 Simulation result and conclusion . . . . . . . . . . . . . . 60
8 Proposed QoS Mechanism Algorithm 618.1 General Traffic model assumptions . . . . . . . . . . . . . . . . . 628.2 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628.3 Call Admission Control(CAC) and Resource Reservation : . . . . 638.4 policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.5 Scheduling and buffering . . . . . . . . . . . . . . . . . . . . . . 64
Bibliography 69
3
List of Figures
1.1 Entities involved in E2E UMTS QoS Provision . . . . . . . . . . 10
2.1 UMTS Network Architecture in Release 99 . . . . . . . . . . . . 142.2 UMTS Radio Access Network(UTRAN) Architecture [8] . . . . . 152.3 UMTS Protocol Stack: User Plane . . . . . . . . . . . . . . . . . 182.4 UMTS Protocol Stack: Control Plane . . . . . . . . . . . . . . . 192.5 PDP Context State Transition . . . . . . . . . . . . . . . . . . . . 24
3.1 UMTS End-to-End QoS Architecture . . . . . . . . . . . . . . . 263.2 PDP Context Activation Procedure for UMTS [11] . . . . . . . . 323.3 Secondary PDP Context Activation Procedure for UMTS [11] . . 333.4 GGSN-Initiated PDP Context Modification Procedure for UMTS
[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5 UMTS QoS Management functions in the control plane[1] . . . . 343.6 UMTS QoS Management functions in the user plane[1] . . . . . . 36
4.1 The DS field structure . . . . . . . . . . . . . . . . . . . . . . . . 384.2 The architecture a DiffServ Domain . . . . . . . . . . . . . . . . 394.3 Assured Forwarding PHB Group . . . . . . . . . . . . . . . . . . 404.4 Possible implementation of Expedited Forwarding PHB . . . . . . 404.5 Logical structure of a packet classifier and traffic conditioner . . . 424.6 An example TSW meter algorithm [17] . . . . . . . . . . . . . . 444.7 TSW3CM Marking Algorithm [17] . . . . . . . . . . . . . . . . . 44
5.1 Simplified Userars view of NS . . . . . . . . . . . . . . . . . . . 47
7.1 E2E Network topology in using Best Effort strategy . . . . . . . . 587.2 Traffic throughput in a 10% overload scenario . . . . . . . . . . . 59
8.1 Proposed Queuing Mechanism . . . . . . . . . . . . . . . . . . . 658.2 PDP context process . . . . . . . . . . . . . . . . . . . . . . . . 67
4
List of Tables
2.1 UTRAN Key Parameters . . . . . . . . . . . . . . . . . . . . . . 20
3.1 UMTS QoS classes . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 UMTS bearer attributes defined for each traffic class . . . . . . . 293.3 Valid Packet Filter Attribute Combinations . . . . . . . . . . . . 30
7.1 Traffic Model Settings . . . . . . . . . . . . . . . . . . . . . . . 59
8.1 Traffic Model Assumptions . . . . . . . . . . . . . . . . . . . . . 628.2 UMTS Vs DiffServ Mapping . . . . . . . . . . . . . . . . . . . 63
5
Abbreviation List
QoS Quality of ServiceUMTS Universal Mobile Telecommunications SystemIP Internet Protocol3G Third-generation mobile telephone technology3GPP 3rd Generation Partnership Project3GPP2 3rd Generation Partnership Project 2 ( the standardization group for CDMA2000)IETF Internet Engineering Task ForceUTRAN UMTS Terrestrial Radio Access NetworkUE User EquipmentRRM Radio Resource ManagementSGSN Serving GPRS Support NodesGGSN Gateway GPRS Support NodesITU International Telecommunication UnionIMT-2000 International Mobile Telecommunications 2000ETSI Europe European Telecommunications Standards InstituteSMS Short Message ServiceMMS Multimedia Messaging ServiceCN Core NetworkUTRAN UMTS Terrestrial Radio Access NetworkUE User EquipmentGSM Global System for Mobile CommunicationUSIM UMTS Subscriber Identity ModuleME Mobile EquipmentWCDMA Wideband Code Division Multiple AccessCDMA Code Division Multiple AccessFDD Frequency Division DuplexTDD Time Division DuplexRNC Radio Network ControllerGPRS General Packet Radio ServiceMSC Mobile Switching CenterVLR Visitor Location Register
6
ABBREVIATION LIST
GMSC Gateway MSCEIR Equipment Identity RegisterHLR Home Location RegisterAuC Authentication CentreMAC Medium Access ControlRLC Radio Link ControlPDCP Packet Data Convergence ProtocolGTP-U GPRS Tunnelling Protocol for the user planeUDP User Datagram ProtocolRRC Radio Resource ControlRANAP Radio Access Network Application Protocol
7
Chapter 1
Introduction
1.1 MotivationThere is a growing interest in the end-to-end Quality of Service(E2E QoS) pro-vision in both the standards for 3G mobile radio systems(in 3GPP/3GPP2) andfor IP infrastructure(in IETF), which reflects the trend that as the mobile Internet-like services get more and more popular, the market requires the real-time andquality-assured services provision by the mobile communication world which isgoing to be a convergence of all-IP backbone[3GPP Release 5] and UniversalMobile Telecommunications System (UMTS) radio access network.
UMTS has been designed to support integrated services no matter voice, data,video, etc. Among them broadband multi-media services is regarded as the keyto UMTS success. Some most important services require UMTS to provide band-width on demand, mixed traffic types, efficient network transport and/or guaran-teed QoS features, and those services may be roughly divided into realtime andnon-realtime with quite different demand to the UMTS network.
This project focus on investing the E2E QoS provisioning for realtime servicesincluding both external IP network (Internet) and the packet-switched domain ofUMTS network. Related concepts are reviewed, well-known approaches in bothInternet and UMTS system to provide QoS are described, and a new E2E QoSprovision mechanism is proposed.
1.2 QoS Basic ConceptGenerally, Quality of Service is the collective effect of service performance thatdetermines the degree of the end user of a given service. Put it in another way, QoS
8
ABBREVIATION LIST
can be seen as the degree of satisfaction of an end-user for an delivered service.
This concept usually leads to the basic idea of QoS, to distinct traffic into dif-ferent types, corresponding to their different features and different demands to thenetworks, and to be delivered to the customers on different charges.
Consequently, certain QoS mechanisms must be implemented to provide/ensurethe E2E QoS features of applications matching their traffic type. We distinguishtwo main categories of mechanisms, QoS provision mechanisms and QoS controlmechanisms [1], depending on whether it works before a traffic flow start or duringthe traffic flow passing through the communication network:
• QoS provision mechanisms include parameters mapping, admission and re-source reservations schemes.
• QoS control mechanisms consist of traffic shaping, scheduling, policing andcontrol mechanisms.
From application point of view, E2E QoS requirements have to be identified inmeasurable QoS metrics, those are delay, jitter, loss rate and throughput.[3GPP1999a]
Delay It is the elapsed time for a packet to traverse the network from the sourceto the destination. At the network layer, the end-to-end packet latency is thesum of processing delay, transmission delay, queuing delay and propagationdelay.
Jitter It is defined as the variation in delay encountered by similar packets follow-ing the same route through the network.The jitter requirement only affectsreal-time streaming applications because this QoS requirement arises fromthe continuous traffic characteristics of this class of applications. Jitter isgenerally included as a performance parameter since it is very important atthe transport layer in packetized data systems, due to the inherent variabil-ity in arrival times of individual packets. Services intolerant of delay vari-ation will usually try to reduce the delay variation by means of buffering.However, late data arrivals make data useless, resulting in receiver bufferunderflow, and early arrival can lead to receiver buffer overflow.
Loss Rate Loss rate refers to the percentage of data loss among all the delivereddata in a given transmission time interval, which can be evaluated in framelevel or packet level. Loss rate requirements apply to all classes of appli-cations. In general, real-time applications might tolerate a limited amount
9
ABBREVIATION LIST
of data lost, depending on the error resiliency of the decoder, and the typeof application. On the other hand, non-real-time applications typically havemuch more strict requirement on data loss.
Throughput It is defined as the rate at which packets are transmitted in a net-work. It can be expressed as a maximum rate or an average rate.
1.3 Problem StatementEnd-to-End QoS has to be satisfied through the inter-working of all the entitiesthat the user data is passing through. Figure 1.1 shows the entities involved whena User Equipment (UE) is connected via a UMTS network to a server on theInternet. From QoS point of view, the entities can be divided into external IPdomain QoS and UMTS domain QoS.
Internet/External
UE UTRAN
GGSN
GGSN
SERVER
SGSN
Um Iu−psGi
Gp
Other PLMN
Figure 1.1: Entities involved in E2E UMTS QoS Provision
In UMTS domain, although 3GPP specifies detailed signalling procedure ofQoS requirements(in terms of traffic classes, delay parameters,etc.), the standard-ization does not provide the mechanisms to support QoS during user-data transfer:QoS parameters need to be mapped to appropriate Radio Resource Management(RRM) strategies in UTRAN and IP-layer transport mechanisms in the Core Net-work (CN).
In IP domain, there are already some well-known mechanisms for QoS provi-sioning, namely Diffserv[2] and InterServ[3], but how these mechanisms shouldbe utilized in the UMTS architecture is still an open issue.
That is, the first task of this project is to identify the mechanisms relevant forQoS provisioning in the full E2E transmission chain, both in UMTS network side
10
ABBREVIATION LIST
and in external IP network side. Potential investigation scenarios should focusedamong one or more of the following aspects:
• QoS provisioning in UTRAN via RRM.
• QoS provisioning in the IP based UMTS Core Network, including GGSNand SGSN and/or the routers in UMTS IP backbone.
• QoS mapping between UMTS network and external IP network (Internet).
Once specific investigation aspects is identified, new QoS provisioning algorithmshould be proposed and implemented in simulation tools to evaluate its perfor-mance.
1.4 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 22th - Dec 23th
(a) Make the first end-2-end simulation model(Best Effort).
(b) Propose a new strategy for End-2-End QoS provision
4. 9-Semester Presentation: Feb 24th, 2005
5. Simulator and report updating: Feb 25th - March 17th
(a) Traffic Model, QoS Metrics and Error Model upgrading.
(b) Update report structure with more detailed proposed QoS algorithmdesign.
11
ABBREVIATION LIST
6. Proposed QoS strategy implementation : March 2nd - May 15th
(a) DiffServ implementation: March 2nd - April 8th;
(b) UMTS core network scheduling and congestion control (queueing man-agement): April 2nd - may 1st;
(c) PDP context and GGSN implementation (CAC, policing): April 18th- May 15th.
7. Project report/Thesis finalize: May 15th - June 15th .
(a) Simulation output analysis and/or simulator final modification.
(b) Finish all report/Thesis documents.
8. Thesis Defence Preparation: June 15th - June 27th.
(a) Thesis hand in (June 15th)
(b) Preparation for defence.
1.5 About this reportThe report is organized as follows. The first chapter explain the motivation andbasic concepts as well as problems in this project. Then Chapter 2, 3 and 4 reviewthe main characteristics of UMTS network, UMTS QoS and IP QoS, as the back-ground to understand the problem. After that, Chapter 5 analysis some relatedprojects, their contribution and drawback. Chapter 6 delimitate the investigationscenarios of this project based on the analysis of Chapter 5 and also the features ofsimulation tools. Afterwards, a new E2E QoS provisioning algorithm of UMTSis proposed in Chapter 7, and the implementation is described in Chapter 8 andsimulation result is analyzed in Chapter 8. Finally, conclusion is drawn in Chapter9.
12
Chapter 2
Overview of UMTS
3G Systems are intended to provide a global mobility with wide range of servicesincluding telephony, paging, messaging, Internet and broadband data. Interna-tional Telecommunication Union (ITU) started the process of defining the stan-dard for third generation systems, referred to as International Mobile Telecommu-nications 2000 (IMT-2000). In Europe, European Telecommunications StandardsInstitute (ETSI) and later the Third Generation Partnership Project (3GPP) wasresponsible of Universal Mobile Telecommunications System (UMTS) standard-ization process.
2.1 UMTS ServicesUMTS offers traditional tele-services (such as circuit-switched voice or SMS) andbearer services. It is possible to negotiate and renegotiate the characteristics of abearer service at session or connection setup stage and during ongoing session orconnection.
Bearer services have different QoS parameters for maximum transfer delay,delay variation and bit error rate. Offered data rate targets are:
• 144 kbits/s satellite and rural outdoor
• 384 kbits/s urban outdoor
• 2048 kbits/s indoor and low range outdoor
UMTS network services with different QoS classes were divided into four typesof traffic:
• Conversational class (voice, video telephony, video gaming)
13
ABBREVIATION LIST
• Streaming class (multimedia, video on demand, webcast)
• Interactive class (web browsing, network gaming, database access)
• Background class (email, MMS, file downloading)
2.2 UMTS Architecture
A UMTS network consist of three interacting domains; Core Network (CN),UMTS Terrestrial Radio Access Network (UTRAN) and User Equipment (UE)[7]. The main function of the core network is to provide switching, routing andtransit for user traffic. Core network also contains the databases and networkmanagement functions. The UTRAN provides the air interface access method forUser Equipment. Figure 2.1 depicted the overall architecture of UMTS network,
Figure 2.1: UMTS Network Architecture in Release 99
which includes both the UMTS and GSM network entities. The UTRAN is evo-lutionary new for UMTS, while the CN can be seen as a smooth evolution fromGSM CN. The following subsection will describe the UMTS specific parts in thisarchitecture.
14
ABBREVIATION LIST
2.2.1 User Equipment
User equipment is the equipment used by the user to access UMTS services, whichis made up of two parts: the UMTS Subscriber Identity Module(USIM) and Mo-bile Equipment(ME). USIM is a modular IC-card stores the identity of the sub-scriber (user), operator and service provider and user service profile. ME is theradio terminal(the mobile phone) for radio communication via the Uu interface.
2.2.2 UTRAN
In UTRAN, Wideband Code Division Multiple Access(WCDMA) technologywas selected for radio access, which supports a transmission rate theoreticallyup to 2Mbit/s (realistic up to about 300kb/s). UMTS WCDMA is a Direct Se-quence CDMA system where user data is multiplied with quasi-random bits de-rived from WCDMA Spreading codes. WCDMA has two basic modes of op-eration: Frequency Division Duplex (FDD) and Time Division Duplex (TDD).A specific structure of UTRAN is depicted in figure 2.2. As in figure 2.2, the
Figure 2.2: UMTS Radio Access Network(UTRAN) Architecture [8]
UTRAN physical entities are made up of two entities: Node-B and Radio Net-work Controller(RNC).
Node-B
A Node B is A logical node responsible for radio transmission / reception in one ormore cells to/from the User Equipment, in UTRAN it terminates the Iub interfacetowards the RNC[9]. In more detail, it take care of Modulation/Demodulation,
15
ABBREVIATION LIST
CDMA Physical Channel coding, Forward Error Correction(FEC), Closed looppower control, etc. Hence it also involved in RRM.
RNC
A RNC is in charge of controlling the use and the integrity of the radio resources[9].It controls one or more Node B and is the access point between UTRAN and CN.Its functions are Radio Resource Control, Admission Control, Channel Alloca-tion, Handover Control, Broadcast Signalling, Open Loop Power Control, etc.
2.2.3 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 (CS) and packet switched (PS) do-mains. Some of the circuit switched elements are Mobile services Switching Cen-ter (MSC), Visitor location register (VLR) and Gateway MSC(GMSC). Packetswitched elements are Serving GPRS Support Node (SGSN) and Gateway GPRSSupport Node (GGSN). Some network elements, like EIR, HLR, and AUC areshared by both domains.
MSC and GMSC
The MSC is a switching node that supports circuit-switched connections, usermobility and handover procedures. GMSC is a special MSC which also serve asinterfaces to various external networks, i.e., the Integrated Services Digital Net-work (ISDN). The MSC is the central network entity of the CS domain.[10]
HLR and VLR
The Home Location Reigster (HLR) is a database in the user’s home system whichkeeps all the user profile, e.g., roaming areas, allowed services, authenticationkeys. And the VLR is a database similar to HLR but locates in the network a useris currently operating. And the information in VLR is updated as soon as a userchanges location area.
SGSN and GGSN
The SGSN carries out routing function in PS domain and handle with authen-tication and current user position, like MSC/VLR in CS domain. GGSN offersinterfaces to external PS networks like the Internet.
16
ABBREVIATION LIST
According to the latest 3GPP R5 specification, IP will be the main protocolfor transporting user packets inside the PS core network. However, user pack-ets are not directly routed via IP routing protocol but based on GPRS TunnelingProtocol(GTP).
2.2.4 InterfacesAn interface refers to the connection between different network entities. In thisproject the most relevant UMTS interfaces are:
• Uu: The interface between the user equipment and the UMTS network istermed the Uu reference point (UMTS radio interface).
• IuB: This interface locate between Node-B and RNC.
• Iu: This interface connect UTRAN and Core Network. There are tow typesof Iu, Iu PS for connecting to PS domain and Iu CS connecting to CS do-main.
• Gn: This one between SGSN and GGSN.
• Gi: Gi interface GGSN with external packet switched network (Internet).
2.3 UMTS protocol stackThe protocols over Uu and Iu interfaces are divided into two structures [11]:
1. User plane protocols: The user plane consists of a layered protocol struc-ture providing user information transfer, along with associated informationtransfer control procedures (e.g. flow control, error detection, error correc-tion and error recovery).
2. Control plane protocols: The control plane consists of protocols for con-trol and support of the user plane functions, including requesting the service,controlling different transmission resources, handover, etc.
In the following, we briefly explain these two protocol structures.
2.3.1 UMTS user planeFigure ?? depicts the user plane of the UMTS network. The UE and UTRANinclude L1, MAC, RLC and PDCP layers. The definition of these layers is asbelow:
17
ABBREVIATION LIST
L1
RLC
PDCP
MAC
E.g., IP,PPP
Application
L1
RLC
PDCP
MAC
L1
UDP/IP
GTP-U
L2
Relay
L1
UDP/IP
L2
GTP-U
E.g., IP,PPP
3G-SGSNUTRANMSIu-PSUu Gn Gi
3G-GGSN
L1
UDP/IP
GTP-U
L2
L1
UDP/IP
GTP-U
L2
Relay
Figure 2.3: UMTS Protocol Stack: User Plane
• Packet Data Convergence Protocol (PDCP): This transmission function-ality maps higher-level characteristics onto the characteristics of the under-lying radio-interface protocols. PDCP provides protocol transparency forhigher-layer protocols. PDCP supports e.g. IPv4, PPP and IPv6. Introduc-tion of new higher-layer protocols shall be possible without any changes tothe radio-interface protocols. PDCP provides protocol control informationcompression. PDCP is specified in 3GPP TS 25.323 [11].
• Radio Link Control (RLC): The RLC protocol provides logical link con-trol over the radio interface. There may be several simultaneous RLC linksper MS. Each link is identified by a Bearer Id. RLC is defined in 3GPP TS25.322 [11].
• Medium Access Control (MAC): The MAC protocol controls the accesssignalling (request and grant) procedures for the radio channel. MAC isspecified in 3GPP TS 25.321.
• Physical layer (PHY or L1): The physical layer offers information transferservices to MAC and higher layers.
UTRAN, SGSN and GGSN include the following layers:
• GPRS Tunnelling Protocol for the user plane (GTP-U): This protocoltunnels user data between UTRAN and the SGSN, and between the SGSNand the GGSN in the core network. GTP encapsulates all PDP ProtocolData Units (PDU). GTP is specified in 3GPP TS 29.060
18
ABBREVIATION LIST
• User Datagram Protocol/Internet Protocol (UDP/IP): These are the back-bone network protocols used for routing user data and control signalling.
2.3.2 UMTS control planeThe UMTS control plane is illustrated in 2.4. The control plane consists of the
RLC
RRC
L1
GMM /SM / SMS
RRC
MAC
L1
RANAP
L2
Relay
L1
L2
SGSNRNSMSIu-PsUu
RLC
SCCP
SignallingBearer
MAC
L1
SignallingBearer
RANAP
SCCP
GMM /SM / SMS
Figure 2.4: UMTS Protocol Stack: Control Plane
following layers:
• UMTS Mobility Management and Session Management (GMM/SM): GMMsupports mobility management functionality such as attach, detach, secu-rity, and routing area update and SM supports PDP context activation andPDP context deactivation.
• Short Message Service (SMS) supports the mobile-originated and mobile-terminated short message service.
• Radio Resource Control (RRC) : This a signalling protocol for the controland configuration of the radio interface.
• The RLC protocol offers logical link control over the radio interface for thetransmission of higher layer-signalling messages and SMS.
• The MAC protocol controls the access signalling (request and grant) proce-dures for the radio channel.
• The physical layer offers information transfer services to MAC and higherlayers.
19
ABBREVIATION LIST
UTRA Mode FDDMultiple access scheme W-CDMACarrier spacing 4.4 - 5.2 MHzChip rate 3.84 Mchip/s (Mcps)Spreading factor range 4 - 512Modulation QPSKPulse shaping root raised cosine, roll-off = 0.22Frame length 10 msTime-slots per frame 15
Table 2.1: UTRAN Key Parameters
• Radio Access Network Application Protocol (RANAP): This protocol en-capsulates and carries higher-layer signalling, handles signalling betweenthe SGSN and UTRAN, and manages the GTP connections on the Iu inter-face. The layers below RANAP are defined in.
2.4 UMTS Air InterfaceSome UMTS air interface issues are described more specifically in this sectionbecause they are highly relevant with most UMTS simulation implementations,while the more general elements in the previous two sections can often been sim-plified.
Wide and CDMA technology was selected to for UTRAN air interface. UMTSWCDMA is a Direct Sequence CDMA system where user data is multiplied withquasi-random bits derived from WCDMA Spreading codes. In UMTS, in additionto channelization, Codes are used for synchronization and scrambling. WCDMAhas two basic modes of operation: Frequency Division Duplex (FDD) and TimeDivision Duplex (TDD). In this project only FDD mode is relevant, and its mainparameters are shown in Table 2.1.
2.4.1 The physical layerThe physical layer (PHY) is implemented in Node B within the UTRAN, whichdirectly handles the transmission of data over radio. its tasks related to the airinterface include:[10]
• provisioning of transport channels;
20
ABBREVIATION LIST
• mapping of transport channels to physical channels;
• macro diversity, soft handover;
• error protection(FEC, interleaving);
• (de-)multiplexing of Coded Composite Transport Channels (CCTrCH);
• synchronization (frequency and time) and power control;
• measurement of FER, SIR, interference power etc.
The physical layer is controled by RRC sub-layer. For example, the leverl of errorprotection via Forward Error Correction (FEC) is configured by RRC. PHY alsoreport the calculated Frame Error Rate (FER), the Signal to Interference Ratio(SIR) and the measured interference power. The RRC then decide the parametersaccording to the reported situation.
2.4.2 The MAC layerThe MAC layer coordinates access to the physical medium for data transmission.MAC layer places different data streams to be transmitted in queues, handles pri-orities/schedule them according to the QoS negotiated at connection set-up stage.MAC layer also report to RRC sublayer and receive configuration instructionsfrom it. Tasks of MAC is concluded as follow: [10]
• provisioning of logical channels
• mapping of logical channels to transport channels
• selection of appropriate transport formats
• priority handling/scheduling
• monitoring of the traffic volume
• ciphering (for transparent RLC mode)
• no segmentation of data!
The RLC layer delivers the data to MAC layer over logical channels. A logi-cal channel describes which type of data should be transmitted. The MAC layermaps these logical channels to transport cahnnels that represent the interface tothe physical layer. The MAC layer thus take charge of multiplexing of severalparallel data streams from the logical channels to the transport channels.
21
ABBREVIATION LIST
2.4.3 RLC layer
RLC is a sub layer of data link layer. The goal of this layer is to protect datastreams from errors caused by radio propagation. To achieve this target, the RLCmake segmentation and reassembly of higher-layer Service Data Units (SDU)into/from smaller RLC payload units (called Protocol Data Unit, PDU), and man-age retransmission for the error PDUs. The following mode are configured inRLC layer:
Transparent Mode (TM) In this mode, the RLC doesnart add a protocol headerand erroneous packets are dropped or marked (no error protection). Thismode is suitable for error-tolerant but delay sensitive data, such as videoand audio.
Unacknowledged Mode (UM) There are no error correction either, but RLC adda sequence number and thus can ensure the uniqueness of the transmitteddata. Segmentation and reassembly is done by adding a header to RLCPDUs. The packets are encrypted.
Acknowledged Mode (AM) In this mode Automatic Repeat Request (ARQ) mech-anism is used to protect the RLC PDU. The protection level and the delayperformance of the RLC can be configured by the RRC by changing themaximum retransmissions number. The packets are encrypted.
2.4.4 RRC layer
The Radio Resource Control (RRC) sublayer is in the control phane in layer 3, itsmain functions include:
• broadcast of system information
• set-up and management of Radio Bearers
• mobility management: location management and handover
• out loop power control
• configuration of lower layers
• collection of measurements from lower layers
22
ABBREVIATION LIST
2.4.5 Transport channelsIn UTRA FDD mode, there are logical channels, which are mapped to transportchannels, and they are again mapped to physical channels. Logical to Transportchannel conversion happens in Medium Access Control (MAC) layer. The trans-port channels relevant to simulation are:
• Foward Access Channel (FACH)FACH is used as down-link Common Packet Channel.
• Random Access Channel (RACH)This channel is used for up-link rapid access and transfer of short and smallpackets.
• Dedicated Channel (DCH)The normal data and signalling of a user takes place over the DCH.
2.5 PDP ContextWhere is the reference of this section?The Packet Data Protocol (PDP) context is a data structure present on both theSGSN and the GGSN which contains the subscriber’s session information whenthe subscriber has an active session. This terminology is inherent from GPRScore network. A Mobile 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 PDPaddresses simultaneously 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 originatedfrom a PDP address can be transported over a 3GPP PS core network.
A PDP context is maintained and used by network nodes to determine how toforward user packets destined and originated from a particular PDP address. ThePDP context maintained by a mobile, an SGSN, and a GGSN link together a RadioAccess Bearers (RABs) and a CN Bearer to form a 3GPP Bearer for the mobile.
A PDP context maintained on the SGSN and the GGSN carry the followinguseful information.
• PDP address used by the mobile to and receive PDP Packets.
• Routing Information used by the network node to determine where to for-ward a user packet such as identifier (established between SGSN and GGSN
23
ABBREVIATION LIST
for this PDP context), Access Point Name (APN). APN is a logical nameused by SGSN to determine which GGSN is suitable for a mobile and de-termination of the service request by user or address of an access point inan external packet network to which user packet should be forwarded byGGSN.
• Quality of Service (QoS) Profile:
1. QoS Profile Subscribed: describe QoS characteristic subscribed bymobile user.
2. QoS profile Requested: Describe QoS characteristic currently requestedby mobile user.
3. QoS profile negotiated; QoS actually provided by the network to themobile at the current time.
2.5.1 PDP context states
Figure 2.5: PDP Context State Transition
PDP context can be divided into two different state namely ACTIVE and IN-ACTIVE states as shown in Figure 2.5. ACTIVE state contains up to date infor-mation for forwarding PDP context between the mobile and the GGSN. Activestate doesnart guarantee the RAB establishment over the RAN to transport userpacket. RABs may be established only when mobile has a user packet to send tothe network or the network user packet for the mobile.
In PDP INACTIVE state may contain a valid PDP address but not valid rout-ing, mapping information needed to determine how to process packets. If GGSN
24
ABBREVIATION LIST
has user packets to send to a mobile but the PDP context for the destination PDPaddress is in INACTIVE state, the GGSN may use network requested PDP con-text activation procedure to change the PDP context of the destination mobile toACTIVE state.
2.5.2 PDP context proceduresPDP context is used for user data session management. These session manage-ment procedures include:
• PDP context activation, in which PDP address, QoS profile are set.
• PDP context modification, in which QoS profile is modified.
• PDP context deactivation, in which packet data session is released.
A GPRS-attached (GPRS, this terminology is still used by 3GPP to call the packetdomain of UMTS CN) MS can initiate the activation, modification, and deactiva-tion functions at any time for a PDP context in the MS, the SGSN, and the GGSN.A GGSN may request the activation of a PDP context to a GPRS-attached sub-scriber. A GGSN may initiate the deactivation of a PDP context. The details ofthese procedures will be explained in the following chapter concern UMTS QoSmanagement issues.
25
Chapter 3
UMTS QoS
3.1 UMTS QoS architecture
The 3GPP has defined an architecture to supply a certain network QoS betweentwo Terminal equipments (TE) with several layers of Bearer Services. A bearerservice includes all aspects to enable the provision of a contracted QoS. These as-pects are among others the control signalling, user plane transport and QoS man-agement functionality. A UMTS bearer service layered architecture is depictedin figure 3.1, each bearer service on a specific layer offers it’s individual servicesusing services provided by the layers below. [5]
TE TEMT RAN EDGENODE
GATEWAYCNCN
End−to−End Service
UMTS Bearer Service
Radio Acess Bearer Service ServiceCN Bearer
BackboneBearer Service
Radio BearerService
RAN AcessBearer Service
Physical RadioBearer Service Bearer Service
Physical
TE/MT Local Bearer Service
ExternalBearer Service
Figure 3.1: UMTS End-to-End QoS Architecture
26
ABBREVIATION LIST
For example, The UMTS Bearer Service, that the UMTS operator offers, pro-vides the UMTS QoS. The UMTS Bearer Service consists of two parts: the RadioAccess Bearer (RAB) Service for the cellular wireless network, and the Core Net-work (CN) Bearer Service for the backbone network.
The radio access bearer service provides confidential transport of signallingand user data between MT and its corresponding SGSN with the QoS adequateto the negotiated UMTS bearer service or with the default QoS for signalling.This service is based on the characteristics of the radio interface and is main-tained for a moving MT. The radio access bearer service is realized by a RadioBearer Service and an Iu Bearer Service. The role of the radio bearer service isto cover all the aspects of the radio interface transport. This bearer service usesthe UTRA FDD/TDD mechanism. The Iu bearer service provides the transportbetween UTRAN and CN. The Iu bearer services for packet traffic shall providedifferent bearer services for a variety of QoS.
The core network bearer service of the UMTS core network connects the SGSNwith the GGSN. The role of this service is to efficiently control and utilize thecore network in order to provide the contracted UMTS bearer service. The UMTSpacket core network shall support different bearer services for a variety of QoSmechanisms. The core network bearer service uses a generic Layer1/Layer2 func-tionality in order to fulfil the QoS requirements of the core network bearer service.These layers are not specific to UMTS but may reuse an existing standard and isselected according to operator’s choice.
The Bearer Service (BS) concept is important for this project in that it allowsto divide the E2E QoS problem into a set of sub-problems concerning the QoSprovision inside a specific Bearer Service and the QoS profile mapping amongthem(between 2 BSs in the same plane or between an upper layer and a lowerlayer).
3.2 UMTS QoS classesThe UMTS network classify user data flows according to their QoS requirements.The flows that have similar QoS requirements are aggregated together by the net-work. The 3GPP defined four classes ; each class is characterized by delay, delayjitter, loss rate and throughput requirements. The main distinguishing factors be-tween the classes are delay sensitivity and loss rate sensitivity. A QoS class ischaracterized by a set of measurable network parameters values. A specific set
27
ABBREVIATION LIST
Traffic Class Examples ofApplication
RealTime
Delay Jitter LowLossRate
GuaranteedBit Rate
Conversational Voice/VideoTelephony
Yes Stringent Stringent Yes
Streaming streamingvideo
Yes Constrained Constrained Yes
Interactive Web Browsing No Loose YesBackground Email, Back-
ground down-load
No Yes
Table 3.1: UMTS QoS classes
of parameters is defined for each bearer service,i.e., the UMTS bearer service hasthe following attributes :
3.3 UMTS QoS mechanismsThe main standard UMTS QoS mechanism is the PDP context mechanism. PDPcontext procedure consists of a series of signalling for the user to set-up a virtualconnection with the GGSN and to guarantee its QoS requirements on this connec-tion. A user can have more than one PDP context with different QoS requirementsfor different applications at the same time. There are two main parts in the PDPcontext: QoS profile and Traffic Flow Template(TFT). [1]
3.3.1 QoS ProfileA QoS profile is a group of user QoS requirements to be used to establish a UMTSbearer servece. One QoS profile is associated with one PDP context. The user cannegotiation its QoS profile with the network, and the network will provide theQoS level that its resource can support.
3.3.2 Traffic Flow TemplateWhen more than one PDP contexts are associated to a PDP address, there shallbe a Traffic Flow Template (TFT) for each or all but one context [12]. A TFTis a series of rules for the UMTS networks to detect a flow requiring a certain
28
ABBREVIATION LIST
Traffic class Conversational Streaming Interactive BackgroundMaximum bit-rate (kbps)
<2048 <2048 <2048- over-head
<2048-overhead
Delivery order Yes/No Yes/No Yes/No Yes/NoMaximum SDUsize (octets)
51500 or1502
51500 or1502
51500 or1502
51500 or1502
SDU format in-formation
X X
Delivery of erro-neous SDUs
Yes/No/- Yes/No/- Yes/No/- Yes/No/-
Residual BER 5 × 10−2∼
10−6
5 × 10−2∼
10−6
4×10−3∼ 6×
10−8
4×10−3∼ 6×
10−8
SDU error ratio 10−2∼ 10−5 10−1
∼ 10−5 10−3∼ 10−6 10−3
∼ 10−6
Transfer delay(ms)
100 (max) 250 (max)
Guaranteed bitrate (kbps)
<2048 <2048
Traffic handlingpriority
1,2,3
Allocation/Retentionpriority
1,2,3 1,2,3 1,2,3 1,2,3
Source statisticsdescriptor
X X
Table 3.2: UMTS bearer attributes defined for each traffic class
29
ABBREVIATION LIST
Packet filter attribute Combination I Combination I Combination ISource Address and SubnetMask
X X X
Protocol Number (IPv4) /Next Header (IPv6)
X X
Destination Port Range XSource Port Range XSource Port Range XIPSec SPI XTOS (IPv4) / Traffic Class(IPv6) and Mask
X X X
Flow Label (IPv6) X
Table 3.3: Valid Packet Filter Attribute Combinations
QoS. It includes one up to eight packet filters, each with a packet filter identifier.If present, the TFT shall be sent transparently via the SGSN to the GGSN toenable packet classification and policing for downlink data transfer (see 3GPP TS23.060).
A valid packet filter contains at least one of the following attributes:
• Source Address and Subnet Mask.
• Protocol Number (IPv4) / Next Header (IPv6)
• Destination Port Range
• Source Port Range
• IPSec Security Parameter Index (SPI)
• Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask
• Flow Label (IPv6)
Some of the listed attributes can be combined in a packet filter but others cannot. Table 3.3 shows the legal combinations, in which the items with an "X" cancoexist in one packet filter.
30
ABBREVIATION LIST
3.3.3 PDP context signalling procedureThree PDP context procedures are relevant to QoS management, they will beshortly introduced in this subsection.
• The PDP Context Activation Procedure, to establish a PDP context betweenthe MS and the network for a specific QoS on a specific Network ServiceAccess Point Identifier (NSAPI). This context is initiated by the MS or thenetwork.
• The secondary PDP Context activation Procedure, to establish an additionalPDP context between the MS and the network for a specific TFT and QoSprofile on a specific NSAPI. Each additional PDP context requests a differ-ent TFT and QoS profile.
• The PDP Context Modification Procedure, initiated by the network or theMS in order to change the QoS or TFT for a PDP context.
The PDP Context Activation Procedure
Each PDP address may be described by one or more PDP contexts in the MS orthe network. The PDP Context Activation procedure is used to activate the firstPDP context for a given PDP address and APN, whereas all additional contextsassociated to the same PDP address and APN are activated with the secondaryPDP context activation procedure.[12]
The PDP Context Activation Procedure will establish the first PDP context fora specific QoS on a specific Network Service Access Point Identifier (NSAPI). Itcan be initiated by the MS or the network.
1. The UE sends an Activate PDP Context Request message to the SGSN. Thismessage contains a PDP Type, PDP Address and QoS Requested parametersamong others. For IP external network, the PDP type and address are IP andIP address. If it request a dynamic PDP(IP) address, this field will be leftempty.
2. The SGSN validates the Activate PDP Context Request using the informa-tion provided by the UE and the PDP context subscription records. TheSGSN has the right to rejects the PDP context activation request if it deter-mined the Activate PDP Context Request is invalid. The SGSN may restrictthe requested QoS attributes according to its capabilities, the current load,and the subscribed QoS profile.
31
ABBREVIATION LIST
GGSN
9. Activate PDP Context Accept
4. Create PDP Context Response
4. Create PDP Context Request
1. Activate PDP Context Request
SGSNRANMS
5. Radio Access Bearer Setup
C1
C2
6. Invoke Trace
8. Update PDP Context Response
8. Update PDP Context Request
Figure 3.2: PDP Context Activation Procedure for UMTS [11]
3. The SGSN sends a Create PDP Context Request message to the affectedGGSN. The message contains PDP Type, PDP Address, QoS Negotiatedand Charging Characteristics among other parameters.
4. The GGSN creates a new entry in its PDP context table and generates aCharging Id. The new entry allows the GGSN to route PDP PDUs betweenthe SGSN and the external PDP network, and to start charging. The GGSNthen returns a Create PDP Context Response message to the SGSN withPDP Address, QoS Negotiated and Charging Id among other parameters.PDP Address is included if the GGSN allocated a PDP address.
5. If the UE has requested a dynamic address, the SGSN inserts the PDP ad-dress received from the GGSN in the PDP context. The SGSN returns anActivate PDP Context Accept message to the UE with PDP Type, PDP Ad-dress and QoS Negotiated. The SGSN is now able to route PDP PDUsbetween the GGSN and the UE, and to start charging.
For each PDP context a different QoS profile may be requested, depends on theapplication type associated with it, i.e, a video telephony may require a very strictdelay attribute while a E-mail is not sensitive to delay at all. If a QoS requirementis beyond the capabilities of the UMTS network, the network negotiates the QoSprofile as close as possible to the requested QoS profile. The UE can either acceptthe negotiated QoS profile, or deactivates the PDP context. If the PDP ContextActivation Procedure fails or if the SGSN returns an Activate PDP Context Rejectmessage, the UE may still set up another activation within a maximum number ofattempts.
32
ABBREVIATION LIST
The Secondary PDP Context Activation procedure
The Secondary PDP Context Activation procedure may be used to activate a PDPcontext with the same PDP address of an already active PDP context, but with adifferent QoS profile. A major part of the Secondary PDP Context is the TFT.The TFT contains attributes that specify an IP header filter that is used to directdata packets received from the interconnected external packet data network to thenewly activated PDP context. The Secondary PDP Context Activation proceduremay be executed without providing a TFT to the newly activated PDP context if allother active PDP contexts for this PDP address already have an associated TFT,otherwise a TFT shall be provided.[1] The Secondary PDP Context Activation
GGSN
7. Activate Secondary PDP Context Accept
3. Create PDP Context Response
3. Create PDP Context Request
1. Activate Secondary PDP Context Request
SGSNRANMS
4. Radio Access Bearer Setup
C1
C2
6. Update PDP Context Response
6. Update PDP Context Request
Figure 3.3: Secondary PDP Context Activation Procedure for UMTS [11]
procedure is similar with the first PDP Context Activation procedure, as shown in3.3. The only difference is that UE sends its TFT along with other parameters.
The PDP Context Modification Procedure
A PDP Context Modification Procedure can be initiated by a UE, SGSN or GGSNto change the QoS or TFT negotiated during PDP context activation procedure. AGGSN initiated Modification procedure is depicted in 3.4just for an example. Thediscussion of this procedure is beyond our investigation scope.
3.4 UMTS QoS management entities and mechanismQoS management functions for UMTS bearer service in the control plane
Figure 3.5 depicts the major steps of QoS management in the control plane. Thesesteps are explained below.
33
ABBREVIATION LIST
GGSN
6. Update PDP Context Response
1. Update PDP Context Request
SGSNRANMS
4. Modify PDP Context Request
5. Modify PDP Context Accept
3. Radio Access Bearer Modification
C1
Figure 3.4: GGSN-Initiated PDP Context Modification Procedure for UMTS [11]
Figure 3.5: UMTS QoS Management functions in the control plane[1]
34
ABBREVIATION LIST
1. UMTS BS manager in the UE expresses the QoS profile of the user (UMTSbearer service attributes) to its counterpart in the SGSN through the PDPContext mechanism (Activate PDP Context Request or Activate SecondaryPDP Context Request).
2. The UMTS BS manger in the SGSN verifies the subscription data of theuser in order to verify if the user has the right to request such a service.
3. The UMTS BS manger of the SGSN makes an admission control in orderto check if it has enough resources for the requested service.
4. The UMTS BS manager of the SGSN translates the UMTS bearer serviceattributes into RAB service attributes, Iu bearer service attributes and corenetwork bearer service attributes. It then requests its Iu BS manager, its CNBS manager and the RAB manager in the UTRAN to provide the requiredservices.
5. The RAB manager verifies with its admission/capability control whether theUTRAN supports the specific requested service and whether the requiredresources are available.
6. The RAB manger translates the RAB service attributes into radio bearer ser-vice and Iu bearer service attributes and requests the radio BS manager andthe Iu BS manager to provide bearer services with the required attributes.
7. Once the radio access bearer is successfully established, the RAB managerinforms the UMTS BS manager in the SGSN.
8. The UMTS BS manager in the SGSN speaks with its counterpart in theGGSN in order to request the QoS requirements of the user (Create PDPContext Request).
9. The GGSN UMTS BS manager makes an admission control to verify if ithas enough resources to handle the new traffic.
10. The GGSN UMTS BS manager translates the UMTS bearer service at-tributes into core network bearer service attributes and requests its core net-work BS manager to provide the service.
QoS management functions for the UMTS bearer service in the user plane
Figure 3.6 depicts the major steps of QoS management in the user plane for thedownlink direction. These steps are as follows:
35
ABBREVIATION LIST
Figure 3.6: UMTS QoS Management functions in the user plane[1]
1. The GGSN classifies the incoming traffic in order to find out the appropriatePDP context. The classification entity tries to find out a matching TFT forthe traffic.
2. The traffic then passes a conditioner entity whose role is to verify if thetraffic is conforming with the user contract.
3. The traffic then passes the mapper function in order to be marked with thenetwork specific QoS indication. In case of IP based network service in thecore network and the Iu interface, this function simply marks the DS bitsof the packet according to the local Differentiated Services policy used inthese links.
4. The packet then passes through the resource manager. This entity decideswhen the packet can be transmitted to the next node.
3.5 ConslusionThrough the overview of the UMTS QoS specifications, we can conclude that the3GPP has supplied a complete group of standards for the UMTS services and theirattributes on different layers of bearer services, as well as the functions/entitiesand the signalling procedures to achieve these attributes, but how to achieve themwas not specified. This is exactly the problem we called "UMTS QoS provision-ing". Till this chapter it can be sum up in two scenarios:
• QoS provisioning on control plane:This function relates to resource reservation protocols at call set-up (Call
36
ABBREVIATION LIST
Admission Control). Call Admission control determines if the call can beaccepted by the network while guaranteeing the requested QoS defined byattributes in Table 3.2 and for a given duration. UMTS CAC is based on theconcept of equivalent bandwidth. CAC is performed along the path betweenboth terminals throughout the network. It is also performed at lower layers; an automatic mapping function translates representations of QoS betweendifferent layers. If the resources are available, then are reserved otherwise alower QoS is proposed.
Key words: CAC, Mapping.
• QoS provisioning on user plane:They act on traffic flow according to requested levels of QoS. As describedin the user plane management for downlink, the mechanisms include
– GGSN specifically: classifier, conditioner, mapper/marker.
– GGSN, SGSN, UTRAN: Traffic differentiation is performed using dif-ferent queues or buffers to maintain QoS, using classical IP Differ-entiated services mechanisms or MPLS/ATM (Multi Protocol LabelSwitching). This allows flow scheduling, shaping (regulation), polic-ing (control that the user does not exceeds QoS).
37
Chapter 4
IP QoS
4.1 DiffServ approach
DiffServ was designed as a simple architecture of QoS which can provide E2Eservices across different operator’s domain without requiring a complex signallingprocess for every connection. The way of DiffServ to achieve this goal is to useaggregates flows and Per-Hop-Behaviors (PHBs) [?].
4.1.1 Per Hop Behaviors(PHB) and Differentiated Services CodePoint(DSCP)
This approach make use of the Type Of Service (TOS) field in IPv4 to definedifferent serving manner for different classes of packet flows, that is, PHB. TheTOS field now is called Differentiated Services field and the services class infor-mation used by PHB is recorded inside DS field and called DiffServ Code Point(DSCP). There are a lot of mechanisms such as queueing, scheduling, and policingto implement PHB, which are described in following two subsections. A DiffServ
DSCP CU
DSCP (DiffServ Code Point) – 6 bits. CU (Currently Unused) – 2 bits
Figure 4.1: The DS field structure
domain has theree main components. They are
• Bandwidth Broker (BB): The Bandwidth Broker is responsible for config-uring the network routers with correct PHBs for the defined service.
38
ABBREVIATION LIST
• Edge Router: An edge router exams incoming packets, classify them andmark them with a code point reflects the desired level of service, and en-sure a user traffic adhere to its policy specifications by shaping and policingtraffic.
• Core Router: A core router exam the code point of incoming packets andforward them accordingly.
BB
Edge Router Edge Router
Core Router
Core Router Core Router
DSDomain
OtherDomain
OtherDomain
Figure 4.2: The architecture a DiffServ Domain
4.1.2 Per Hop BehaviorsThere are two well know PHBs: Assured Forwarding (AF) and Expedited For-warding (EF).
Assured Forwarding (AF)
The AF-PHB group provides N independent PHB classes, each with M dropprecedence levels. There are N=4 classes and M=3 drop precedence levels withineach class defined in the current specification [?]. Each DS node must allocatea certain amount of buffer space and bandwidth to each AF class, one possibleapproach is to assign 4 PHB classes with 4 physical queues and 3 virtual queuesin each for the 3 drop precedences.
With the AF PHB, customers will get reliable services from their service providers,even in time of network congestion. The SLA between the customer and the Inter-net Service Provider (ISP) will specify the amount of bandwidth allocated. It is the
39
ABBREVIATION LIST
customers responsibility to decide how their applications share his total amountof bandwidth.
AF11
AF11
AF11
AF11
AF12
AF13
AF41
AF42
AF43
AF11
AF11
AF11
AF21
AF22
AF23
AF11
AF11
AF11
AF31
AF32
AF33
Class 1 Class 2 Class 3 Class 4
Low drop
Medium drop
High drop
Drop precedence within a class
Figure 4.3: Assured Forwarding PHB Group
Expedited Forwarding (EF)
The EF-PHB group was designed for customers with fixed peak bit rate trafficto supply low-loss, low-latency and low-jitter end-to-end services. Packet loss,latency, and jitter in wired networks are mainly due to that traffics have to wait inqueue while transmitted through networks. Therefore, providing lowloss, latency,and jitter for some high priority traffics can be achieved by guarantee they alwayssee no, or very small queue.
Queues arise when (short-term) traffic arrival rate exceeds departure rate atsome node. Thus, for an EF-PHB traffic stream, the departure rate must equalor exceed a configurable rate. EF traffic should average at least the configuredrate when measured over any time interval equal to or longer than a packet timeat the configured rate. The SLA specifies a peak bit rate for a flow or an aggre-gation of flows, and the customer is responsible for not exceeding the peak rate;otherwise, excess traffic will be dropped.[?]
RED
EF PHB
DefaultPHB
Figure 4.4: Possible implementation of Expedited Forwarding PHB
40
ABBREVIATION LIST
4.1.3 Traffic classification and conditioningTraffic classification and conditioning are the key functions for implementing of aDiffServ model. This function is made up of fore logical modules: [?]
Classifier Packet classifiers select packets in a traffic stream based on the contentof some portion of the packet header. Two types of classifiers are defined.The Behavior Aggregate (BA) classifier classifies packets based on the DScodepoint only. The Multi Field (MF) classifier selects packets based onthe value of a combination of one or more header fields, such as sourceaddress, destination address, DS field, protocol ID, source port, destinationport numbers and other information such as incoming interface.
Meter Traffic meters measure the temporal properties of the stream of packetsselected by a classifier according to a traffic profile specified in a TCA. Ameter passes state information to other conditioning functions to trigger aparticular action for each packet, which is either in or out of profile (to someextent).
Marker Packet markers set the DS field of a packet to a particular code-point,adding the marked packet to a particular DS behavior aggregate. The markermay be configured to mark all packets which are steered to it to a singlecode-point, or may be configured to mark a packet to one of a set of code-points used to select a PHB in a PHB group, according to the state of ameter. When the marker changes the code-point in a packet it is said tohave arre-markedas the packet.
Shapper/Dropper Shapers delay some or all of the packets in a traffic stream inorder to bring the stream into compliance with a traffic profile. A shaperusually has a finite-size buffer, and packets may be discarded if there is notsufficient buffer space to hold the delayed packets. Droppers discard someor all of the packets in a traffic stream in order to bring the stream intocompliance with its traffic profile. This process is known as arpolicingasthe stream. Note that a dropper can be implemented as a special case of ashaper by setting the shaper buffer size to zero for a few packets.
4.1.4 Queuing - REDRED is a congestion avoidance algorithm that can be implemented in both edgeand core routers. The simplest queue algorithm for routers is Drop Tail. Whenthere is sufficient buffer space Drop Tail queues accept any incoming packet, andwhen buffer is full it simply drop any new packet that arrives. [15]
41
ABBREVIATION LIST
Meter
Classifier MarkerShaper/dropper
Packets
Figure 4.5: Logical structure of a packet classifier and traffic conditioner
Instead, RED queue compute a weighted average queue size to detect a conges-tion before the queue becomes really full, because a sustained long queue is a signof network congestion. As any packet arrives, a RED gateway checks the weightedaverage queue size and compare with its minimum and maximum thresholds. Ifthere is congestion, it either drops a packet or sets a bit in a header field of thepacket according to a certain probability.
There are three phases for a RED gateways which drops packets:
Normal operation: If the average queue size is less than the minimum threshold,no packets are dropped.
Congestion avoidance: If the average queue size is between the minimum andmaximum thresholds, packets are dropped with a certain probability. Thisprobability is a function of the average queue size, so that larger queues leadto higher drop probabilities.
Congestion Control: If the average queue size is greater than the maximum thresh-old, all incoming packets are dropped.
The effects of RED gateways in a network will be:
• Control the average queue size, and reduce the average queuing delay.
• Act as a low-pass filter, hence the burst traffic get easier to be dropped.
• Avoid synchronization of TCP connections. A TCP based traffic source willreduce its transmitting rate when some of its burst packets will be droppedwhich cause RTT time-out. But the Drop Tail queue will all the packetsin congestion which cause all the TCP source reduce their transmitting rateat the same time and the total throughput suddenly becomes very low af-ter the congestion period. RED drops packets randomly before the bufferget overflow, which prevents this synchronization problem, reduces trafficoscillation effect and hence increase the overall throughput.
42
ABBREVIATION LIST
4.1.5 Meter and Marker functions - PolicyA policy determines the treatment that a traffic aggregate will receive at the edgedevice. Edge devices use policy information to determine with what code point tomark packets. Each policy defines a policer type, a target rate, and other policer-specific parameters. As a minimum, each policy defines two code points; and thechoice of code point depends on a comparison between the aggregatears targetrate and current sending rate [15]. Each traffic aggregate has an associated po-licer type, meter type, and initial code point. The meter type specifies the methodfor measuring the state variables needed by the policer. Some well-known me-ters/markers are explained below.
Time Sliding Window Three/Two Color Marker(TSW3CM/TSM2CM)
The TSW3CM has been primarily designed for traffic streams that will be for-warded based on the AF PHB in routers[17]. The TSWTCM meters a trafficstream and marks packets to be either green, yellow or red based on the measuredthroughput relative to two specified rates: Committed Information Rate (CIR) andPeak Information Rate (PIR). The packets contributing to sending rate below orequal to the CIR with be marked with green color. Packets contributing to the por-tion of the rate between the CIR and PIR are marked yellow, and packets causingthe rate to exceed PIR are marked with red. As its special case, Time Sliding Win-dow Two Color Marker (TSW2CM) only use only CIR to evaluate traffic streamrate and mark them with either green or red.
The TSW3/2CM consists of two independent components: a rate estimator, anda marker to associate a colour (drop precedence) with each packet. If the marker isused with the AF PHB, each color would correspond to a level of drop precedence.
Meter A TSW meter works as shown in figure 4.6:
Marker A TSW3CM marker works as depicted in figure 4.7:
43
ABBREVIATION LIST
========================================================================|Initially: || || AVG_INTERVAL = a constant; || avg-rate = CTR; || t-front = 0; || ||Upon each packet's arrival, the rate estimator updates its variables: || || Bytes_in_win = avg-rate * AVG_INTERVAL; || New_bytes = Bytes_in_win + pkt_size; || avg-rate = New_bytes/( now - t-front + AVG_INTERVAL); || t-front = now; || ||Where: || now = The time of the current packet arrival || pkt_size = The packet size in bytes of the arriving packet || avg-rate = Measured Arrival Rate of traffic stream || AVG_INTERVAL = Time window over which history is kept || |
Figure 4.6: An example TSW meter algorithm [17]
=================================================================== | avg-rate = Estimated Avg Sending Rate of Traffic Stream | | | | if (avg-rate <= CTR) | | the packet is green; | | else if (avg-rate <= PTR) AND (avg-rate > CTR) | | (avg-rate - CTR) | | calculate P0 = ---------------- | | avg-rate | | with probability P0 the packet is yellow; | | with probability (1-P0) the packet is green; | | else | | (avg-rate - PTR) | | calculate P1 = ---------------- | | avg-rate | | (PTR - CTR) | | calculate P2 = ----------- | | avg-rate | | with probability P1 the packet is red; | | with probability P2 the packet is yellow; | | with probability (1-(P1+P2)) the packet is green; | | |
Figure 4.7: TSW3CM Marking Algorithm [17]
44
ABBREVIATION LIST
Token Bucket Algorithm
4.1.6 Scheduling
When multiple queues are sharing the a common transmission media, there mustbe a scheduler to decide how to pick up packets from each queue to send out.The simplest scheduler is Round Robin (RR), which just select packet from eachqueue circularly, and all the queues have exactly equal chances to send.
A more useful scheduler for queuing with different classes is Weighted roundrobin (WRR). WRR shares link access circularly, like RR. But each queue hasa weight which assigns a relative share of link access time compared to otherqueues. In a long term, the percentage of each queue to be served is:
Pi =Wi
Wtotal
Wicžthe weight of queue i; Wtotal: the sum of all queue weights.There could be two implementation methods of WRR: a standard WRR and aWeighted Interleaved round robin (WIRR) implementation. Assume Wi is integerand Wtotal is the total number of packets the scheduler served in one circle, WRRkeep serving packets for the selected queue until Wi packets have been sent or thequeue is empty. On the other hand, the WIRR works as follow:
beginfor each queue(i), temporaryWeight(i) = queueWeight(i)
then repeatif queue(i) is not empty or temporaryWeight(i) > 0;
pick 1 packet from each queue in turn;temporaryWeight(i) = temporaryWeight(i) − 1;
elseskip it, go to pick packet from the next queue;
untilall temporaryWeight(i) = 0;
go to begin.
Another type of scheduler is Priority(PRI). In PRI the queue with highest prioritywill always be served first until it’s empty, then the second highest priority queuewill be served, and the lowest priority queue can only be picked when all the otherqueues have been empty.
45
ABBREVIATION LIST
4.2 IntServ/RSVP Policy
4.3 Comparison between IntServ and DiffServ
46
Chapter 5
NS-2 simulator and preliminarysimulation
5.1 Overview of ns2NS is an event driven network simulator developed at UC Berkeley that simulatesvariety of IP networks. It implements network protocols such as TCP and UDP,traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queuemanagement mechanism such as Drop Tail, RED and CBQ, routing algorithmssuch as Dijkstra, and more. NS also implements multicasting and some of theMAC layer protocols for LAN simulations. The NS project is now a part of theVINT project that develops tools for simulation results display, analysis and con-verters that convert network topologies generated by well-known generators to NSformats. Currently, NS (version 2) written in C++ and OTcl (Tcl script languagewith Object-oriented extensions developed at MIT) is available.
Figure 5.1: Simplified Userars view of NS
47
ABBREVIATION LIST
As shown in Figure 5.1, in a simplified user’s view, NS is Object-oriented Tcl(OTcl) script interpreter that has a simulation event scheduler and network com-ponent object libraries, and network setup (plumbing) module libraries (actually,plumbing modules are implemented as member functions of the base simulatorobject). In other words, to use NS, you program in OTcl script language. To setupand run a simulation network, a user should write an OTcl script that initiates anevent scheduler, sets up the network topology using the network objects and theplumbing functions in the library, and tells traffic sources when to start and stoptransmitting packets through the event scheduler. The term "plumbing" is usedfor a network setup, because setting up a network is plumbing possible data pathsamong network objects by setting the "neighbor" pointer of an object to the ad-dress of an appropriate object. When a user wants to make a new network object,he or she can easily make an object either by writing a new object or by makinga compound object from the object library, and plumb the data path through theobject. This may sound like complicated job, but the plumbing OTcl modulesactually make the job very easy. The power of NS comes from this plumbing.
Another major component of NS beside network objects is the event scheduler.An event in NS is a packet ID that is unique for a packet with scheduled time andthe pointer to an object that handles the event. In NS, an event scheduler keepstrack of simulation time and fires all the events in the event queue scheduled forthe current time by invoking appropriate network components, which usually arethe ones who issued the events, and let them do the appropriate action associatedwith packet pointed by the event. Network components communicate with oneanother passing packets, however this does not consume actual simulation time.All the network components that need to spend some simulation time handlinga packet (i.e. need a delay) use the event scheduler by issuing an event for thepacket and waiting for the event to be fired to itself before doing further actionhandling the packet. For example, a network switch component that simulates aswitch with 20 microseconds of switching delay issues an event for a packet to beswitched to the scheduler as an event 20 microsecond later. The scheduler after20 microsecond dequeues the event and fires it to the switch component, whichthen passes the packet to an appropriate output link component. Another use of anevent scheduler is timer. For example, TCP needs a timer to keep track of a packettransmission time out for retransmission (transmission of a packet with the sameTCP packet number but different NS packet ID). Timers use event schedulers ina similar manner that delay does. The only difference is that timer measures atime value associated with a packet and does an appropriate action related to thatpacket after a certain time goes by, and does not simulate a delay.
48
ABBREVIATION LIST
NS is written not only in OTcl but in C++ also. For efficiency reason, NSseparates the data path implementation from control path implementations. Inorder to reduce packet and event processing time (not simulation time), the eventscheduler and the basic network component objects in the data path are writtenand compiled using C++. These compiled objects are made available to the OTclinterpreter through an OTcl linkage that creates a matching OTcl object for eachof the C++ objects and makes the control functions and the configurable variablesspecified by the C++ object act as member functions and member variables of thecorresponding OTcl object. In this way, the controls of the C++ objects are givento OTcl. It is also possible to add member functions and variables to a C++ linkedOTcl object. The objects in C++ that do not need to be controlled in a simulationor internally used by another object do not need to be linked to OTcl. Likewise,an object (not in the data path) can be entirely implemented in OTcl. Figure 2shows an object hierarchy example in C++ and OTcl. One thing to note in thefigure is that for C++ objects that have an OTcl linkage forming a hierarchy, thereis a matching OTcl object hierarchy very similar to that of C++.
5.2 DiffServ moduleThe DiffServ module in NS-2 implemented the AF PHB with a modified RandomEarly Detection (RED) queue mechanism. This module was contribute by NortelNetworks. [15]
5.2.1 AF PHB Implementation with multiple RED queuesIn the Diffserv approach QoS was provided by dividing traffic into different classesand marking each packet with a code point corresponding to its class, and schedul-ing packets accordingly. The Assured Forwarding mechanism in NS-2 includes 4physical queues for 4 PHB classes, and 3 virtual queues in each physical one forthe 3 drop precedences. Those drop precedences enable differential treatment oftraffic within a single class.
Different RED parameters are used for the virtual queues, causing packets fromone virtual queue to be dropped more frequently than packets from another. Apacket with a lower drop precedence is given better treatment in times of conges-tion because it is assigned a code point that corresponds to a virtual queue withrelatively lenient RED parameters.
For example, one code point might be used for assured traffic and another forbest effort traffic. The assured packet virtual queue will have higher minimum
49
ABBREVIATION LIST
and maximum thresholds than those of best effort queue, meaning that best effortpackets will enter the congestion avoidance and congestion control phase prior toassured packets.
Core routers
Core routers only have the functionality of performing PHB on incoming packets.In NS-2, core routers maintain at most 4 physical queues, each of them can haveno more than 3 virtual queues or precedences. An incoming packet is placed ina virtual queue within a physical queue based on the DSCP-value in the packet’sIP-header. A physical queue is implemented as a RED-queue and virtual queueswithin the same physical queue all use the same buffer to temporarily store pack-ets. However, all virtual queues can be configured with their own RED-parameters(minimum and maximum thresholds and dropping probability).
Edge routers
Edge routers include the same PHB functionality as core routers, and in additionperform the following functions:
• policing
• metering
• packet marking
5.2.2 PolicerThe DiffServ module currently supports six policer types.
TSW2CM (TSW2CMPolicer): uses a CIR and two drop precedences. The lowerprecedence is used probabilistically when the CIR is exceeded.
TSW3CM (TSW3CMPolicer): uses a CIR, a PIR, and three drop precedences.The medium drop precedence is used probabilistically when the CIR is ex-ceeded and the lowest drop precedence is used probabilistically when thePIR is exceeded, as explained in [17].
Token Bucket (tokenBucketPolicer): uses a CIR and a CBS and two drop prece-dences. An arriving packet is marked with the lower precedence if and onlyif it is larger than the token bucket.
Single Rate Three Color Marker (srTCMPolicer): uses a CIR, CBS, and anEBS to choose from three drop precedences, as explained in [18].
50
ABBREVIATION LIST
Two Rate Three Color Marker (trTCMPolicer): uses a CIR, CBS, PIR, and aPBS to choose from three drop precdences, as explained in [19].
These policers have been explained in the IP QoS chapter. We compared TSW2CMand Token Bucket policiers, and found out that technically by carefully choosingtheir parameters, the difference between their effects on UDP traffic would bequite minor. Hence we just select TSW2CM policer in out simulation.
5.2.3 Scheduler
5.3 UTRAN extensionThe Enhanced UMTS Radio Access Network extensions to ns-2 (version 2.26)was developed within the SEACORN project for Ericsson TelecommunicationB.V.. Detailed information, and updates to code and documentation can be foundat the following website:http://www.ti-wmc.nl/eurane
The Enhanced UMTS extensions for ns-2 comprise of an additional three nodes,namely the Radio Network Controller (RNC), Basestation (BS) and the UserEquipment (UE), whose functionality allow for the support of the following trans-port channels:
• FACH
• RACH
• DCH
• HS-DSCH
The main functionality additions to ns-2 come in the form of the RLC Acknowl-edged Mode (AM), Unacknowledged Mode (UM) MAC-d/-c/sh support for RACH/FACHand DCH, and MAC-hs support for HS-DSCH, i.e. HSDPA.
5.3.1 UTRAN nodes and linksThe Node RNC, BS and UE are new object classes introduced in EURANE. Basedon different configurations, different kinds of classifiers and link objects are usedto compose different nodes. For instance, when creating a BS node, bandwidth
51
ABBREVIATION LIST
and TTI of both uplink and downlink can be set respectively. The most importantparameter should be determined first is the node type, after that, other charactersof this node type can be configured further.
Each UMTS node has zero or more UMTS network interfaces (NIF) stacks,composed of objects representing different layers in the stack, the major compo-nents being RLC, MAC and physical layer objects. Channels are connected to thephysical layer object in the stack. NIFs are also important for packet tracing sincethe common methods in ns-2 can not trace the traffic within radio links.
Typically, NIF stacks at the UE will have all of these objects but those at the BSwill only have MAC layer and physical/channel layer objects. At the RNC, eachNIF stack will only be composed of one RLC layer object.
5.3.2 RLC objectThe main functionality additions to ns-2 is the RLC Acknowledged Mode (AM)and Unacknowledged Mode (UM), which is implemented at RNC and UE. TheRLC entity AM is used for the Dedicated Channel (DCH) and the two Commonchannels (RACH and FACH) in acknowledged mode, correspondingly anotherRLC entity AM-hs is developed to support HS-DSCH. Unacknowledged mode isalso supported for DCH and HS-DSCH by the subsets of AM and AM-hs, namelyUM and UM-hs, respectively. Without indication, all simulations in this thesis aretaken under AM.
5.3.3 Error Model for DCH
52
Chapter 6
Delimitation
6.1 Problem StatementWhat is missing in 3GPP standardization?
• UTRAN part: QoS parameters mapping to Radio Resource Managementstrategies (vertical mapping)
• UMTS core network part: IP layer transport mechanisms on the Gn and Giinterface
Refer to TS23.207 structure figure.
From an E2E point of view, problems to be solved include:
1. External IP network: IETF standard QoS mechanism lC DiffServ or Inter-Serv
2. UMTS network domain:
• Control plane:
– QoS attributes mapping between External IP QoS classes andUMTS QoS classes (horizontal mapping), and UMTS Bear Ser-vice (BS) attributes mapping to Core Network (CN) BS and RadioAccess Bearer (RAB) and further to Radio BS and Iu BS (verticalmapping).
– Call Admission Control in every multiplexing point (GGSN, SGSN,etc) according to Equivalent Bandwidth(EB).
• User Plane:
53
ABBREVIATION LIST
– GGSN policing: check downlink flow and filter it according toTFT
– Scheduling and congestion control mechanisms in CN transmis-sion (I,e, WFQ, WRED, etc)
– QoS differentiation implementation in RRM
3. Other open issues: Application level End2End QoS provisioning, i.e, SIPsignalling
6.2 State-of-the-Art
6.2.1 Works on E2E framework1. "A FRAMEWORK FOR DYNAMIC SLA-BASED QOS CONTROL FOR
UMTS". Only framework, no detail implementation and simulation result.
2. "SUPPORT OF IP QOS OVER UMTS NETWORKS", M. Ricardo1,2, J.Dias3,2, G. Carneiro2, J. Ruela1. From ARROW project(2001-2002). AUMTS/InterServ(RSVP) framework only.
6.2.2 Works on mapping: SAMU projectAdvanced Services by Mastering UMTS (SAMU)Duration: July 1999 – September 2002SAMU project is a collaborative project approved by the French RNRT (Telecom-munication Research National Network) and aims at improving the services of-fered to the users in an UMTS mobile system. For that purpose, the followingtopics were under investigation:
1. Defining smart resource allocation strategies for a CDMA mobile system.(RRM)
2. Defining an efficient way to map IP over UMTS, to provide the user withan end-to-end QoS.(QoS)
3. Complementary to the 2 previous ones. It aims at using agent software tomake the system autonomous. (Agent)
4. Demonstrating the feasibility of IP services over UMTS for users in theircars.
http://samu.crm-paris.com/Edocuments.htm
54
ABBREVIATION LIST
The innovative work in QoS from SAMU includes UMTS/IP QoS mapping ar-chitecture and UMTS link layer optimization for TCP. For example: publications,not only internal report and their relevance to our project.The mapping part is really helpful for our project. But not QoS specifically simu-lation result presented in their report or papers.
6.2.3 Works on Policy: EVEREST project
January 2004 - December 2005,http://www.everest-ist.upc.es/The objective of the EVEREST project is to devise and assess a set of specificstrategies and algorithms for access and core networks, leading to an optimisedutilization of scarcely available radio resources for the support of mixed serviceswith end-to-end QoS mechanisms within heterogeneous networks beyond 3G.
This project proposed an E2E QoS architecture, based on policy managementand centralized entities, to introduce QoS in heterogeneous radio access networkswith common RRM(CRRM) capabilities.Main approach: UMTS QoS mapping to DiffServ, and centralized BandwidthBroker. Publications:EXTENDING QoS POLICY-BASED MECHANISHMS TO B3G MOBILE AC-CESS NETWORKS Conference: 13th IST Mobile and Wireless Communica-tions Summit 2004, 27-30 June, Lion (France) Authors: N. Nafisi; L. Wang,H.Aghvami, R. Ferrus, A. Gelonch, J. Perez-Romero, O. Sallent, R. AgustiIs there any solidate simulation result?
6.2.4 Works on CAC
• QoS Issues in Next Generation Radio Access Networks: a arMeasurement-Basedas Approach G. Araniti, A. Molinaro, S. Pulitanoar, and A. Squillaci.
CAC on wired part of UTRAN.
• Lei Xiao, Tung Chong Wong, and Yong Huat Chew, "End -To-End QoS ofMulti-Class traffic in WCDMA and DiffServ Network.",PIMRC 2004.
CAC based on EB, in both DiffServ in UMTS CN and external DiffServnetwork. Simulation result provided.
55
ABBREVIATION LIST
6.2.5 Works on simulation: SEACORN projectSimulation of Enhanced UMTS Access and Core Networks (SEACORN)Duration: March, 2002 – March, 2004SEACORN aimed at Enhanced UMTS networks research areas including:
1. Identification and characterization of the new services;
2. radio link techniques required to increase the bit rate and the capacity gain;
3. new network protocols for the access network and TCP/IP for the core net-work, ;
4. dynamic simulation build-up.
In area 3, the contribution of SEACORN is
• Development, and implementation of resource management algorithms en-abling QoS provisioning and differentiation while optimizing resource ef-ficiency, in a multi-service UMTS dynamic network simulator consideringboth up- and downlink communications;
• Development and implementation of resource management mechanisms forIP-based core networks in a dynamic network simulator.
And a system level simulator was developed based on Network Simulator 2(NS-2).
http://seacorn.ptinovacao.pt/Examples of published papers and their relevance to our project:SIMULATION OF RADIO RESOURCE MANAGEMENT ALGORITHMS FORENHANCED lC UMTS Arnaldo Brito, Josle Lo, Lulłs Correia and Amlerico Cor-reiaThis paper simulate a RRM implementation with CAC and Power Control. Nonovel algorithm was presented.We build up our simulation based on the UMTS extension developed in SEACORNproject.
6.2.6 ConclusionContributions and drawbacks of these related works:
1. Many E2E QoS frameworks were proposed but solid implementation andsimulation output are still missing.
56
ABBREVIATION LIST
2. QoS attributes mapping are designed but not all implemented.
3. Some work more focused on the RRM implementation, some on CAC con-trol, no core network QoS user plane mechanisms are investigated in depth.
4. None of the framework gives a clear picture about the impact of mixingreal-time and non-realtime traffics on the QoS aspects.
6.3 Problem DelimitationChosen scenarios:
• External IP network: DiffServ
• UMTS network domain:
– QoS attributes mapping between External IP QoS classes and UMTSQoS classes (horizontal mapping)
– Call Admission Control in GGSN, according to Equivalent Bandwidth(EB).
– Scheduling and congestion control mechanisms in CN transmission.
57
Chapter 7
Preliminary Simulation
7.1 Simulation including UTRAN
The first preliminary simulation on E2E is based on best effort QoS strategy,meaning different type of traffics (in UMTS traffic classes definition) are treatedequally.
UE2
UE3
UE1
Node B SGSNRNC GGSN
ApplicationServer1
ApplicationServer2
ApplicationServer3
Figure 7.1: E2E Network topology in using Best Effort strategy
7.1.1 Simulation settings
Traffic model
Mobility Model
none
58
ABBREVIATION LIST
TrafficType
Trafficsource
Protocol DataRate
Real-time CBR UDP 384kbpsNon-realtime
Exponential UDP varies
Table 7.1: Traffic Model Settings
Packet loss model
NS-2 standard error model is implemented to represent the RLC PDU loss dueto wireless propagation, which is a Uniform distributed error with fixed averagepacket loss rate that can be achieved given fast power control is used. But sincethe RLC layer is working on AM mode, error PDU can be recovered so the finalpacket loss is mainly due to queue overflow.
7.1.2 Simulation result and conclusion
Figure 7.2User throughput when the total traffic load is higher then the bandwidthin Core network (SGSN-GGSN).In case of Best Effort transmission, the real-time traffics will suffered from the
Figure 7.2: Traffic throughput in a 10% overload scenario
mixing with non-realtime Traffics in case of network congestion.
59
ABBREVIATION LIST
7.2 Simulation on DiffServ wired networkThe purpose of this part is to evaluate the impact of different IP network QoSprovisioning mechanisms when they are implemented in UMTS core network,and their performance under different higher layer protocols and UMTS trafficclasses.
7.2.1 Simulation topology and settings
7.2.2 Simulation result and conclusionThe simulation output as well as analysis can be concluded as follow: RED queueis a very efficient congestion control mechanism for TCP based traffics, usuallyInteractive and Background classes such as HTTP and FTP applications; but itcannot be better than DropTail queue for UDP based traffic types, mostly realtimetraffics.
60
Chapter 8
Proposed QoS MechanismAlgorithm
The proposed QoS mechanism algorithm is divided into sections. Since, QoSmechanism consists of both the provision and control. The provision mechanismtakes care of Mapping, Call Admission Control (CAC) and Resource Reservation.The Control Mechanism takes care of traffic shaping, Scheduling, Policing andcontrol. Figure 1 shows five different section of proposed mechanism is:
1. PDP Context Activation
2. Call Admission Control and Resource Reservation
3. Mapping
4. Scheduling at GGSN and External network
5. Policing and Control,
These five section covers end-to-end QoS mechanism. As the PDP context Acti-vation procedure is not available in the simulator. The proposed PDP context isbased on the time based event generation in order to neutralize the effect of miss-ing PDP Context Module. A unique way of creating and keeping PDP contextinformation is to maintain a database at the GGSN. CAC is one of the buildingblocks of any communication setup as it affects the total performance of the net-work. In the proposed one, the PDP context and CAC are synchronized at theGGSN. Splitting the total resources into used resources and available resourcesperforms the resource reservation. The information about used and available re-sources is kept in the database in order to make CAC easier. One of the mostdifficult parts for the end-to-end QoS for an UMTS network is mapping when
61
ABBREVIATION LIST
the external network is not a part of the UMTS network. The proposed algo-rithm consider IP network as an external network. The Mapping is done basedon the recommendation of 3GPP and IETF. Priority allocation is proposed at theGGSN based on the traffic classes to achieve the guaranteed bit rate per user.In the UMTS network there are four different classes with different delay andjitter criteria. The Scheduling is done based on three different technique namelyBest Effort (BF), Expedited Forwarding (EF), Assured Forwarding (AF). The pro-posed algorithm considers the possibility of downgrade or upgrade guaranteed bitrate depending on the congestion. The bottleneck considered in the proposed al-gorithm is the bandwidth between the SGSN and GGSN. The obvious questionarises with that consideration is: Why between the SGSN and GGSN? Basedon the preliminary simulation, it is evident that the mixing of Real and non-realtime application during the congestion between GGSN and SGSN affect real-timeapplications significantly. The next sections show the stepwise process of the pro-posed implementation.
8.1 General Traffic model assumptions
As for our optimization target of the new algorithms, the general traffic mix isassumed as follow:
TrafficType
Application RT/NRT Protocol Random Process Data Rate
C Voice RT UDP EXP On/Off 30kbps(ontime)
S Videostreaming
RT UDP EXP On/Off 64kbps(Ontime)
I WWW NRT TCP Pareto On/Off variesB FTP NRT TCP Pareto On/Off varies
Table 8.1: Traffic Model Assumptions
8.2 Mapping
Mapping is one of the important aspects, As the external network is consideredas IP network instead of UMTS network. Therefore, conversion of IP compat-ible parameters to the UMTS compatible is the core of this project. The QoSmechanism can be implemented on two different Services such as Integrated and
62
ABBREVIATION LIST
Differentiated one. Differentiated service (DiffServ) is chosen over integrated ser-vice due to their complexity, Scalability and Signaling. In DiffServ, packets areclassified into a relatively small number of classes at the network edge. DiffServdoesn’t mandate the use of any end-to-end signaling protocol and there is no needfor cooperative signaling among all nodes for session setup. On the other handIntegrated Service use end-to-end signaling. There is IP and UMTS QoS profileattributes proposed by the 3GPP as well as IETF for mapping. In DiffServ, thereis no hard guarantee about fixed delay or loss rate values related to each QoSclasses. The traffic profile stored at the edge router only includes maximum burstsize and the arrival rate of the traffic as absolute value. In UMTS, there are severalparameters for each QoS class. Some of these parameters have an equivalent inthe DiffServ. These are the guaranteed bit rate and maximum Service Data Unit(SDU) size of the UMTS QoS parameters. The incoming traffic profile attributesarrival rate and the maximum burst size would be translated at the Core network(CN) and mapped with the UMTS QoS attributes guaranteed bit rate and SDUSize.
The proposed mapping between UMTS service classes and DiffServ DSCPs isdescribed in table 8.2
UMTS traffic type DiffServ DSCPC EFS AF1XI AF2XB BE
Table 8.2: UMTS Vs DiffServ Mapping
8.3 Call Admission Control(CAC) and Resource Reser-vation :
The CAC is done in conjunction with resource reservation. Table 1 shows theparameters and how the available and used bandwidth can change dynamicallydepending upon the traffic type, number of user and total available bandwidth. InFigure 1b, in the beginning there is only UE1 with a Bandwidth requirement of1MB and the total bandwidth is 10 MB. The database checks for the requestedbandwidth and traffic type. If the bandwidth is available then it recommends al-locating it to the specified user. So the used bandwidth would be 1MB and the
63
ABBREVIATION LIST
Available bandwidth would be 9MB for further allocation to the different user.Then the UE2, UE3 comes up with a request of 3 MB and 4 MB respectively. Inthat case the total used bandwidth would be 8 MB after allocation and Availablebandwidth would reduce to 2MB.If UE1 decide to release its bandwidth then theused bandwidth would be 7MB and Available bandwidth will increase to 3MB.In a scenario, when UE is requesting bandwidth for a certain traffic but at thatpoint of time there is not that much bandwidth available to allocate in that casedatabase will send a message back about the maximum possible availability ofBW. For example, if the request from a UE is for 3Mb and the available BW isonly 2MB.CAC is designed on the basis of 66the network can allocate 2MB out ofrequested 3MB then send an Ack back to UE with a message about the maximumpossible available BW. If UE send an Ack back with ’yes’ then start allocatingthe resource otherwise drops the request. In that case UE has to start a new PDPsetup with lower BW request. Once the databases allocate the resources to theUE then there will be a trigger-based generation of traffic from the applicationserver based on an external network. The CAC and resource reservation must becompleted within 10ms. Therefore the total setup of PDP context to Traffic flowis 45ms.
UserEquipment
PDPContext
AccessPoint Name
IPAddress
Traffic Type UsedBand-width
UE1 PDP1 APN1 IP1 Conversational 1MBUE2 PDP2 APN2 IP2 Streaming 0.5MBUE3 PDP3 APN3 IP3 Interactive 0.2MB... ... ... ... ... ...Total BW 3MBAvailableBW
1.7MB
8.4 policing
8.5 Scheduling and bufferingScheduling, Queuing and Priority Allocation:Once the translation at the GGSNis done. Priority would be allocated based on the traffic type as shown in Fig-ure 3. For example conversational, Interactive, streaming and background classwould be allocated a priority of 1, 2,3 and 4 based on the delay tolerance [SAMU,Page10, Table 6]. Priority 1 is the height weight where as 4 is the lowest weight.At the GGSN Queuing is created with five buffers. In the best case scenario all theincoming packet is put in the queue with First in first out (FIFO). Once the Queue
64
ABBREVIATION LIST
is filled, then the entire incoming packet will be dropped and that would increaseQoS metric incredibly higher.
The packet handling can be done in different ways based on the QoS metrics
Main Queue,1222234453
Priority 1 Queue
Priority 2 Queue
Priority 3 Queue
Priority 3 Queue
External NWExternal NW
Edge Router
GGSN
Database,21
3
4
5
6
7
Figure 8.1: Proposed Queuing Mechanism
requirements. Proposed algorithm consider following ways to do it.
• EF/AF/BF
• Random Early Detection AF1-3
EF/AF/BF 1. EFIn Expedited forwarding, packet is served at least by the configuredrate over a defined time interval regardless of the traffic load of theservice types. Four queues are generated for each traffic class withpriority FIFO queue. The purpose of creating multiple queues insteadof one is to keep the queue length small. If the queue length is mini-mized, queuing delay is minimized. Once queuing delay is minimized,
65
ABBREVIATION LIST
packet delay and jitter would be minimized. Packets will go to theircorresponding queue in case of traffic arrival rate exceeds departurerate at some node. The Real time applications carry higher prioritythan the non-real time applications. The ideal time a packet shoulddepart from the queue such that packet service rate on a given out-put interface is greater than the packet arrival rate at that interface.The ideal departure time of a packet is the arrival time plus the packettransmission time if the queue is empty. Otherwise the ideal departuretime depends on the ideal departure time of a previous packet if queueis not empty. The packets are scheduled as it arrives at the queue withFIFO. The packets associated with any traffic class will wait in thequeue for 5 seconds (Assumption) before getting dropped
2. Assured Forwarding(AF)The AF per hop behavior define four AF classes for packet delivery.Each classis forwarded independently as different AF classes cannotbe aggregated. Certain amount of forwarding resources such as bufferspace and bandwidth are allocated to each configured class. There isno priority implied among classes although the forwarding resourcesallocated to each AF can be different. Packets within each AF classare marked with three different levels of drop precedence. When thenetwork is congested then the packets would be dropped according totheir precedence. The packets with the higher dropping precedencewould be discarded earlier than packets with the lower drop prece-dence. Therefore, packet-forwarding assurance in AF PHB dependson the forwarding resources allocated to the AF class, traffic load ofthe AF class and the drop precedence of each packet. Figure 4 showsthe Assured forwarding PHB group and in that it is evident that AF43would be discarded first in case of congestion.
3. BFIn the Best Effort, queue is filled with First-in-first-out manner.
Random Early Detection (RED) AF1-3 :Active queue management such as RED can be used to avoid abrupt changein dropping behavior. In RED AF1-3, the queue is divided into thresholdsfor dropping packets of different class. In the beginning all the packets areadmitted to the queue. When the queue reaches the first threshold then thehighest precedence based packets would be discarded onwards. For exam-ple class four i.e. AF43-41 would be discarded. Then the packets originat-ing from class 1 to class 3 would be accepted. When the second thresholdreaches then AF33-AF31 would be discarded. Since the main purpose of
66
ABBREVIATION LIST
AF11
AF12
AF13 AF23 AF33 AF43
AF42AF32AF22
AF21 AF31 AF41Low Precedence
Medium Precedence
High Precedence
22222111111111111111 2223333111 1232343113
Threshold for
class 4
Threshold for
class 3
Threshold for
class 2
Threshold for
class 1
Figure 8.2: PDP context process
67
ABBREVIATION LIST
this algorithm is to keep the dropping rate for the real time application atthe lowest level and to keep the promised guaranteed bit rate)
68
Bibliography
[1] SAMU project, QOS Deliverable SP2-D1,http://samu.crm-paris.com/,2001.
[2] IETF, RFC 2475, "An Architecture for Differentiated services", 1998
[3] IETF, RFC 1633, "Integrated Services in the Internet Architecture: anOverview", 1994
[4] IETF, RFC 2998, " A framework for Integrated Services operation overDiffServ Networks ", Nov 2000
[5] 3GPP TS 23.107, "QoS Concept and Architecture (Release 6)", 2002.
[6] 3GPP TS 23.207, "End-to-End QoS Concept and Architecture"
[7] 3G TS 23.101: "General UMTS Architecture".
[8] 3G TS 25.401: "UTRAN Overall Description".
[9] 3GPP, TR 23.905 v6.7.0, "Vocabulary for 3GPP Specifications (Release6)", 2004.
[10] B.Walke, P.Seidenberg, M.P.Althoff, "UMTS: The Fundamentals", JohnWiley and Sons Ltd, 2002, ISBN 0-470-8455-7.
[11] 3GPP TS 23.060 v 6.7.0, "General Packet Radio Service (GPRS) Servicedescription Stage 2 (Release 6)", 2005
[12] 3GPP TS 24.008 version 6.7.0 (Release 6), "Mobile radio interface Layer3 specification; Core network protocols; Stage 3", 2005
69
BIBLIOGRAPHY
[13] http://seacorn.ptinovacao.pt/
[14] SOQUET project, http://.../
[15] Peter Pieda,Jeremy Ethridge, Mandeep Baines, Farhan Shallwani, "ANetwork Simulator Differentiated Services Implementation", Open IP,Nortel Networks, July 26, 2000
[16] Clark, D. and W. Fang. "Explicit Allocation of Best Effort Packet DeliveryService."
[17] RFC 2859: "A Time Sliding Window Three Color Marker", June, 2000.
[18] Heinanen, J , T. Finland, and R. Guerin. "A Single Rate Three ColorMarker" (Internet draft). May, 1999.
[19] Heinanen, J., T. Finland, and R. Guerin. "A Two Rate Three Color Marker"(Internet draft). May, 1999.
70
