project report p1103 inter-operator ip qos framework...

Project Report

P1103

Inter-Operator IP QoS Framework - ToIP and UMTSCase Studies

UMTS Case Study

Editors:

Paolo Belloni (TILab)

Mauro Ficaccio (TILab)

Abstract

The intention of this document is to help operators and equipment vendors to identify and solvemany of the issues and challenges associated with early entry into the UMTS services marketplace.

This document builds on descriptions of UMTS QoS standardisation work in the 3GPP project andother consortia. It identifies open issues and gaps in the standardisation that need further work in3GPP or demand extra effort by the operators themselves to configure the system after their ownneeds.

Some relevant service scenarios are considered. The applicability and functionality of the 3GPPQoS framework in supporting a physical implementation is examined as well as the need of SLAsto preserve the QoS across operator domains.

EDIN 0281-1103

Project P1103

For full publication

January 2002

Disclaimer

This document contains material, which is the copyright of certain EURESCOM PARTICIPANTS,and may not be reproduced or copied without permission.

All PARTICIPANTS have agreed to full publication of this document.

The commercial use of any information contained in this document may require a license from theproprietor of that information.

Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the reportis capable of use, or that use of the information is free from risk, and accept no liability for loss ordamage suffered by any person using this information.

EURESCOM Project Report page 3 (44)

2001 EURESCOM Participants in Project P1103 EDIN 0281-1103

Preface

Currently, there is strong technical, economic and market pressure to develop and migrate PSTN,IP and mobile services onto a converged IP network spanning multiple operators networks. Thisintegrated IP technology situation creates new business opportunities that could change thetraditional POTS business completely.

Telecom operators can now aim at providing both data and voice services on a single networkplatform to be prepared for the explosion of the data traffic. Enhanced IP services that can beoffered on UMTS networks (e.g Telephony over IP ,IP VPNs ) represent a valuable example.

After the investment in costly 3G licenses Telcos are now facing multiple challenges coming withthe roll out of the UMTS system. It is of high importance that proper network and serviceprovisioning including all the QoS aspects could finally take place.

This report is the second of the project. It examines the validity and implementability of the UMTSQoS framework, and points out open issues that need further work. These issues may either bedealt with within 3GPP, or they may be operator specific issues.

An accompanying Technical Information includes a UMTS Quality of Service Survey [1].

The P1103 project started in April 2001 and finished in March 2002. Five companies wereparticipating.

(44) EURESCOM Project Report

EDIN 0281-1103 2001 EURESCOM Participants in Project P1103

Executive Summary

Why you should read this project report

UMTS represents a major opportunity for operators to introduce novel mobile multimedia services.It is also a major technical challenge, particularly in the provisioning and monitoring ofdifferentiated, and assured services.

This report gathers information from disparate sources and identifies the open technical issues.

The benefits for your company

Operators need to solve these challenges in order to create more value than is possible with a singleservice and network quality class.

Customers need more predictable services so that they can judge what QoS meets their serviceneeds. This need is increasing as customers put mission critical business applications onto mobiledevices.

Any company involved in delivering UMTS mobile services, networks, User Mobile Equipmentneeds to solve these open issues. This report will allow readers to plan how to solve these issues.

Aspects addressed by this project report

A critical area is the management of Service and Network Quality of Service and their interaction.

This document explores primarily Network Service QoS.

The document addresses the following subjects

• Evolution of UMTS: Provides a high level roadmap for the evolution of data and voice servicetowards All IP Multimedia subsystems

• Scenarios: Provides a set of realistic operation scenarios to establish requirements and openissues;

• Service Level Agreements: Identifies relevant UMTS SLA parameters, metrics and targets;

• Open Issues: Provides grouping of open issues and makes recommendation for which groupsare best placed to address and resolve them.

Conclusions

The analysis described in this report shows the following aspects to be addressed:

• Consistent mapping of QoS parameters at interfaces between heterogeneous bearertechnologies;

• Consistent mapping of QoS parameters at the Network bearer level upwards to managementsystems managing end to end services;

• Ensuring that these mapping support differentiated service offerings to customers, accordingto their needs;

• The need for QoS Provisioning and Monitoring systems to support the evolution from IP v4 toIP v6, and to support their combined use.

• QoS monitoring that can correlate QoS measurements from multiple bearer networks and drawconclusions related to relevant QoS requirements in Customer Service Level Agreements;

• Operators need to be able to provision QoS without excessive use of network resourcesespecially in the access and Radio networks.



Authors

Thor Eskedal (Telenor)

Chris Hatch (British Telecommunications plc)

David Milham (British Telecommunications plc)

Stuart Hughes (Broadcom)

Denis McCarthy (Broadcom)

Olav Østerbø (Telenor)

Giancarlo Vallazza (Sodalia)



Table of contents

Preface................................................................................................................................................................3Executive Summary ...........................................................................................................................................4Authors...............................................................................................................................................................5Table of contents................................................................................................................................................6Abbreviations .....................................................................................................................................................71 Introduction..............................................................................................................................................102 Evolution towards 3G mobile technologies .............................................................................................123 Scenarios ..................................................................................................................................................15

3.1 Introduction ......................................................................................................................................153.2 Introduction to Telephony over PS Domain (ToIP)..........................................................................15

3.2.1 Network service definition: Rel-5 ToIP ...................................................................................163.2.2 Service network architecture ....................................................................................................16

3.3 Introduction to Virtual Private Network...........................................................................................193.3.1 Network Service definition Rel-5 IP VPN ...............................................................................193.3.2 Service network architecture ....................................................................................................203.3.3 Security/ IPSec .........................................................................................................................22

3.4 Layered description of Rel-5 QoS parameters .................................................................................233.4.1 Application layer ......................................................................................................................233.4.2 IP end-to-end layer ...................................................................................................................243.4.3 UMTS bearer............................................................................................................................253.4.4 QoS parameters for ToIP service .............................................................................................263.4.5 QoS Parameters for IP VPN service.........................................................................................27

3.5 Concluding remarks .........................................................................................................................284 SLA..........................................................................................................................................................30

4.1 SLA definitions ................................................................................................................................304.2 End-user View..................................................................................................................................31

4.2.1 QoS Subscription options.........................................................................................................314.2.2 Architectural Considerations ....................................................................................................34

4.3 Interoperator View ...........................................................................................................................344.3.1 Roaming Agreements ...............................................................................................................344.3.2 Architectural Considerations/ Management .............................................................................34

5 Open issues ..............................................................................................................................................365.1 Open issues for high priority future studies......................................................................................36

5.1.1 Dimensioning of the transport in UMTS..................................................................................365.1.2 Network topology issues ..........................................................................................................375.1.3 QoS implementation.................................................................................................................375.1.4 QoS parameter mappings: ........................................................................................................375.1.5 Policy control/policy enforcement. ..........................................................................................385.1.6 Inter-domain QoS management................................................................................................395.1.7 Inter domain SLA negotiation..................................................................................................395.1.8 Resource management..............................................................................................................39

5.2 Open issues for additional future work ............................................................................................395.2.1 Cell planning ............................................................................................................................395.2.2 Transport network configuration..............................................................................................405.2.3 Handover strategy ....................................................................................................................405.2.4 Charging and QoS ....................................................................................................................405.2.5 Transport efficiency .................................................................................................................40

5.3 Issues that need further standardisation work within 3GPP or other standardisation fora. ..............415.4 Summary table of open issues ..........................................................................................................41

6 Conclusions..............................................................................................................................................43References........................................................................................................................................................44



Abbreviations

2G 2nd Generation (generally referring to GSM based services)2.5G 2.5 Generation (generally referring to GPRS based services)3G Third Generation3GPP Third Generation Partnership Project (produces WCDMA standard)3GPP2 Third Generation Partnership Project 2(produces CDMA2000 standard)AAA Authentication, Authorisation, Accounting

AAL2 ATM Adaptation Layer type 2

AAL5 ATM Adaptation Layer type 5ATM Asynchronous Transfer ModeAuC Authentication CenterCPE Customer Premises EquipmentBS Base StationBSC Base Station ControllerBSS Base Station SubsystemBSSAP+ Base Station System Application Part +CAMEL Customised Application for Mobile network Enhanced LogicCDMA Code Division Multiple AccessCDR Call Data RecordCGF Charging Gateway FunctionalityCM Connection ManagementCN Core NetworkCS Circuit SwitchedCSCF Call State Control FunctionDNS Domain Name ServerEDGE Enhanced Data rates for GSM EvolutionEIR Equipment Identity RegisterETSI European Telecommunications Standards InstituteGGSN Gateway GPRS Support NodeGMSC Gateway Mobile Switching CenterGPRS General Radio Packet ServiceGTP GPRS Tunnelling ProtocolGTP-C GTP-Control planeGTP-U User plane part of GPRS Tunnelling ProtocolHLR Home Location RegisterHPLMN Home PLMNID IdentityIETF Internet Engineering Task ForceIMS IP Multimedia SubsystemIMSI International Mobile Subscriber Identity

IMT-2000International mobile telephony, 3rd generation networks are referred as IMT –2000within ITU

IN Intelligent NetworkIP Internet ProtocolIPND IP Network DomainISDN Integrated Services Digital NetworkISUP ISDN Signalling User PartITU International Telecommunications UnionLA Location AreaLAI Location Area IdentityLAN Local Area NetworkLAU Location Area UpdateLCS Location ServicesMAC Medium Access ControlMAP Mobile Application Part



ME Mobile EquipmentMGW Media GatewayMM Mobility ManagementMPEG Motion Picture Experts GroupMPLS Multi-Protocol Label SwitchingMS Mobile StationMSC Mobile Switching CenterMSISDN Mobile Station ISDN NumberMSRN Mobile Subscriber Roaming NumberMT Mobile TerminationMTP Message Transfer PartNNI Network to Network InterfaceO&M Operation and maintenanceOSA Open Service AccessPDCP Packet Data Converge ProtocolPDN Packet Data NetworkPDP Packet Data ProtocolPDU Protocol Data UnitPLMN Public Land Mobile NetworkPS Packet SwitchedPSTN Public Switched Telephony NetworkP-TMSI Packet-TMSIQoS Quality of ServiceR ReleaseRA Routing AreaRAB Radio Access BearerRAI Routing Area IdentityRAN Radio Access NetworkRANAP RAN Application PartRAU Routing Area UpdateRFC Request For CommentsRLC Radio Link ControlRNC Radio Network ControllerRNS Radio Network Sub-systemRNSAP RNS application partRNTI Radio Network Temporary IdentityRRC Radio Resource ControlRRM Radio Resource ManagementRSVP ReSource Reservation ProtocolRT Real TimeSCCP Signalling Connection Control PartSCF Service Control FunctionSCN Switched Circuit NetworkSCTP Simple Control Transmission ProtocolSDP Session description protocolSDU Service data unitSGSN Serving GPRS Support NodeSIM Subscriber Identity ModuleSIP Session Invitation ProtocolSLA Service Level AgreementSLS Service Level SpecificationSM Session ManagementSMS Short Message ServiceSRNC Serving RNCSRNS Serving RNSSS7 Signalling system #7STC Signalling Transport Converter



STCP Stream Trasmission Control ProtocolTCAP Transaction Capabilities Application PartTCP Transport control protocolTD/CDMA Time division CDMA, combined TDMA and CDMATDD Time Division DuplexTDMA Time Division Multiple AccessTE Terminal EquipmentTEID Tunnel Endpoint IDentifierTFT Traffic Flow TemplateTMSI Temporary Mobile Subscriber IdentityTOS Type Of ServiceTR Transparent ModeTS Technical SpecificationT-SGW Transit Signalling GateWayUDP User Datagram ProtocolUE User EquipmentUEP Unequal Error ProtectionUL UplinkUM Unacknowledged ModeUMTS Universal Mobile Telecommunication SystemUNI User to Network InterfaceURL Uniform Resource LocatorUTRA UMTS Terrestrial Radio Access (ETSI)UTRA Universal Terrestrial Radio Access (3GPP)UTRAN UMTS Terrestrial Radio Access NetworkVLR Visitor Location RegisterVoIP Voice over IPVPLMN Visited PLMNVPN Virtual Private NetworkWCDMA Wideband CDMA, Code Division Multiple Access



1 Introduction

During the last few years we have seen a remarkable growth in mobile communication. As thistrend continues the consumers will demand the same service spectrum and quality regardless ofwhether they are communicating from a wired or wireless terminal. IP will be the main bearer, andcontrol and management functionalities as well as the mobility and security aspects will evolvetowards deploying IP only technology. The future vision is seamless connectivity between wirelessand fixed IP networks deploying common management and control functionality and supportingreal time as well as non real time services and multimedia. The multitude of access networks wesee today, both wired and wireless, will converge towards a common transport based on IPtechnology, and a multitude of operators and 3rd party service providers will set the sceneregarding the need for interoperability. To fulfil the IP vision it is of crucial importance that thenew access networks conform to the overall IP technology developments regarding QoS, security,management and mobility aspects. One of these new access networks is the UMTS (UniversalMobile Tele-communication System) access network.

The UMTS system is being specified by 3GPP (3rd Generation Partnership Project) and is one ofthe most advanced mobile networks envisioned to become the first world-wide 3G mobile network.The UMTS network will be able to interface to a multitude of backbone networks e.g. PSTN/ISDNand IP networks as well as the public Internet and different LANs/WANs. For the system to bebroadly deployed it is of crucial importance that the QoS mechanisms in UMTS are well designedand can easily and effectively be mapped to QoS mechanisms deployed in the internet, e.g. theIETF based QoS standards. See figure 1

Figure 1: UMTS network overview

The UMTS system is specified through different releases, which will gradually enhance the UMTSsystem from deploying an enhanced GSM/GPRS infrastructure to becoming an All-IP multimediaenabled mobile network adopting protocols, QoS mechanisms, mobility mechanisms and securitytechniques from the IETF community.

The scope of this document is to examine the validity and implementability of the UMTS QoSframework, and point out open issues that need further work. These issues may either be dealt withwithin 3GPP, or they may be operator specific issues like configuration of buffer lengths, mappingbetween different QoS mechanisms, number of traffic classes, and configuring the policy rules forresource allocation to suit the companies service strategy. Getting a good understanding of thechallenges operators will meet when implementing and managing the UMTS mobile network, asearly as possible, may avoid unnecessary problems and delays to the actual deployment.

This document will:

• Draw up the envisioned evolution path towards an “ALL IP” based UMTS network

7(��07 RNC SGSN GGSN

Radio AccessNetwork Core Network External Network

Host

QoS Governed by UMTS Mechanisms

QoS Governed by CN Mechanisms

QoS Governed byExternal Mechanisms

User traffic



• Define some relevant service scenarios and examine the applicability and functionality ofthe 3GPP QoS framework in supporting a physical implementation.

• Examine the need of SLAs to preserve the QoS across operator domains

• Point out open issues and gaps in the specifications that need further work by 3GPP, ordemand work effort by the operators themselves to configure the system after their ownneeds.

In summary, this document looks at how the 3GPP QoS management framework will actuallywork, by examining realistic scenarios, and thereby get a better knowledge of the complexity andchallenges an operator will meet when rolling out the 3G mobile network UMTS.

Roadmap to the document.

The report starts out in Chapter 2 by stating the major steps in an evolution path of the mobilenetwork from the GSM/GPRS system to an All-IP based UMTS network. The scenarios studied arethen presented in Chapter 3, explaining provision of two services; Telephony-over-IP (ToIP) and IPVirtual Private Network (IP-VPN). This is followed with a chapter describing SLA parameters andother aspects relevant to inter domain agreements. Prior to the Conclusions, Chapter 5 lists manyopen issues found through the review of 3GPP QoS documents and analysis of the two servicescenarios.



2 Evolution towards 3G mobile technologies

Within the context of summarising the technical specifications for the introduction of UMTS andits QoS aspects, in particular, it is useful to consider the migration aspects of moving from thecurrent ’2G’ generation GSM based services, through ’2.5G’ GPRS based services on to ’3G’ UMTSand all-IP based services. Most of the European countries have an operative GSM system todaywith widely mutual roaming agreements. At the present time the GPRS system is being launched inseveral countries and the 3G UMTS system R99 is planned to be launched during 2002. We see arapid evolution resulting in a heterogeneous system platform ranging from operative 2G systems,2,5G systems and 3G systems simultaneously. The challenge in front of us will be to operate andmanage different generation systems with often diverging managing platforms and technologies.Eventually, when the IP technology and IP based QoS mechanism mature, the key technical issuewill be more directed towards managing all-IP 3G services and direct the migration of servicesfrom the 2G and 2.5G to the 3G infrastructure in the most cost effective and seamless manner.

The discussion and set of figures in this section identifies the key issues and illustrates a realisticset of migration steps from deployment of 2G to 3G technologies. The migration is expected to becarried out gradually, smoothing out the investment costs over time. Deployment of the 2G and2.5G systems should be continued for as long as the cost/revenue ratio is favourable. Figures 2, 3and 4 presented below highlight only some discrete events on the path towards an all IP basedUMTS network. Other wireless systems such as Hiperlan, different WLANS, etc, will mostprobably influence the evolution, but are not considered in this short description.

At present, 3G specifications ’Release 99’, allow a formative implementation of 3G networks andservices, including management of the radio access network and telecom supply chain. Later (circa2002 - 2003), it is anticipated that Releases 4 and 5 will build on basic 3G services to supportevolution to the use of all-IP protocol, the key drivers, which will include managed end-to-end QoSacross multi-operator boundaries whilst supporting multi-services (e.g. voice, internet, secureaccess to corporate VPNs, messaging and entertainment).

A migration strategy is exemplified in Figures 2, 3 and 4, with the advantages and disadvantagesassociated with each stage listed in each figure.

Figure 2: 2G (GSM) and 2.5G (GPRS) combined system architecture

GSMRadio

GSM accessnetwork

PSTN/ISDN

PublicIP

SGSNGGSN

VMSC GMSC

VLR

GPRSVLR

HLR

Intelligence

CAMELIN SCP

GPRS

GSM

Advantages:Enhanced user rateRe-applies GSM voiceEnables roaming 2G/2.5G

Disadvantages:Locks in legacy technologyNo integration of Voice and IPPoor scope for seamless voice

GSMRadio

GSM accessnetwork

PSTN/ISDNPSTN/ISDN

PublicIP

PublicIP

SGSNGGSN

VMSC GMSC

VLR

GPRSVLR

HLR

Intelligence

CAMELIN SCP

GPRS

GSM

Advantages:Enhanced user rateRe-applies GSM voiceEnables roaming 2G/2.5G

Disadvantages:Locks in legacy technologyNo integration of Voice and IPPoor scope for seamless voice



Present 2G GSM/GPRS system

Figure 2 shows a combined system architecture, which supports the transmission of 2G GSM-basedmobile telephony service, and comparatively slow 2G data transmission rates (typically 9.6 Kb/s)with the higher data rate (typically 48 Kb/s) access to the Internet available from 2.5G GPRS-basedservices. The system has very poor QoS support for data services. The first launches of GPRS willeffectively support only best effort services. No DiffServ or other IP based QoS mechanisms areimplemented in the wire-line segments of the network.

Figure 3: 2G/2.5G/3G system architectures

The initial launch of 3G systems

Figure 3 shows a combined system architecture, which supports the transmission of 2G GSM-basedmobile telephony service, UMTS radio access and access to the internet. The GSM/GPRS systemwill be based on the GSM TDMA radio system, while the UMTS will base its radio interface onthe CDMA radio technology. The two systems have quite different characteristics regarding, e.g.bandwidth usage, QoS support and cell structure/coverage. Nevertheless, inter system handoversshall be supported and service maintainability is prioritised as far as the bandwidth and QoS criteriacan be met. At the initial launch of UMTS the system is not expected to support the full range ofQoS support. DiffServ and possible MPLS will most probably be implemented and becomeoperative in small scale. Configuration of QoS on the radio interface will be gradually enhanced asthe technology matures and the services need the full range of differentiation. The major questionevery operator has to consider is the implementation cost relative to probable revenues resultingfrom introducing high grade of QoS differentiation in the mobile system as opposed to, e.g. overdimensioning of the transmission links.

UMTSRadio

GSMRadio

GSM access network

PSTN/ISDN

PublicIP

SGSNGGSN

VMSC GMSC

VLR

GPRSVLR

HLR

Intelligence

CAMELIN SCP

GPRS

GSM

Advantages:Enhanced user rateRe-applies GSM voiceEnables roaming 2G/3G

Disadvantages:

- Locks in legacy technology

- No integration of Voice and IP

- Poor scope for seamless voice

UMTSRadio

GSMRadio

GSM access network

PSTN/ISDNPSTN/ISDN

PublicIP

PublicIP

SGSNGGSN

VMSC GMSC

VLR

GPRSVLR

HLR

Intelligence

CAMELIN SCP

GPRS

GSM

Advantages:Enhanced user rateRe-applies GSM voiceEnables roaming 2G/3G

Disadvantages:

- Locks in legacy technology

- No integration of Voice and IP

- Poor scope for seamless voice



Figure 4: Evolved 3G to ’All-IP’ networks & services

UMTS only infrastructure.

Figure 4 shows a system architecture in which all mobile access is via UMTS radio and harmonisedvoice and data is carried over an evolved GPRS network, removing the need to maintain a separateGSM radio access network. The architecture supports internet access with highly variable data ratesand VoIP/multimedia services capable of being forwarded over the PSTN or ISDN networks. Thisevolution step is anticipated, based on a notion of IP being capable of supporting all kinds ofservices with QoS for services matching the service quality we experience today on the CSnetworks.

Concluding comments

Architectures such as those depicted in Figures 3 and 4 depend on the deployment of UMTS radioaccess and the associated implementation of QoS requirements within and between theinterconnecting network segments. Different QoS policies, such as choice of MPLS, DiffServ orcomparable technologies need to be accommodated in the architecture design and associatednetwork management. Furthermore, all the QoS aspects need to be supported by efficientmanagement functions, covering the usual areas of service configuration & activation, faulthandling, performance assurance, security, accounting & billing together with well-specified andimplemented Integration Reference Points (IRP) between the various circuit switched (e.g. PSTN,ISDN) and packet switched (e.g. UMTS, GPRS) networks needed to support end to end services.

UMTSRadio

PSTN/ISDN

PublicIPSGSN

GGSN

GPRSVLR

HLR

Intelligence

CAMELIN SCP

Evolved GPRS

VoIP/Multi-media

GGSN

Advantages:Harmonised Voice & DataOpportunity for wired/wireless

Disadvantages:Management of VoIP & QoS is still a ‘gap’Needs standard development for wireless

UMTS accessnetwork

UMTSRadio

PSTN/ISDNPSTN/ISDN

PublicIP

PublicIPSGSN

GGSN

GPRSVLR

HLR

Intelligence

CAMELIN SCP

Evolved GPRS

VoIP/Multi-media

GGSN

Advantages:Harmonised Voice & DataOpportunity for wired/wireless

Disadvantages:Management of VoIP & QoS is still a ‘gap’Needs standard development for wireless

UMTS accessnetwork



3 Scenarios

3.1 Introduction

This chapter describes how some services could be implemented on the UMTS network. Theselected services are Telephony over IP (ToIP) and Virtual Private Network based on IP (IP-VPN).For each scenario a brief description is provided, of how the service could be provided andconfigured on the UMTS network. Thereafter, the scenario description focuses on the QoS aspectsand describes how the quality of the specific services could be provided and managed.

3GPP TS 23.207 describes how end-to-end QoS will be delivered for end-to-end services anddefines a number of scenarios that are considered to be significant. These scenarios cover the casesfor transport with and without policy inter-working and RSVP functionality at the GGSN andvarious functionalities at the terminal.

In this chapter the scenario number 3 from the TS 23.207 is used as case study (Ref. figure 8 and9). This scenario assumes that the UE and GGSN both support DiffServ edge functions, and thatthe backbone IP network is DiffServ enabled. In addition, the UE supports RSVP signalling, whichmay inter-work within the UE to control the DiffServ.

The goal of this analysis of two important services is to give the reader an overview of thecomplexity of the UMTS system, and point out the importance of careful configuration and QoSmapping on different levels. Through this analysis many open issues may be revealed that 3GPPhas yet solved. Other issues 3GPP will never standardise but are up to the operators to work out,either by themselves internally or by bilaterally agreements, e.g. SLAs for roaming and inter-working. It is very important that the operators are aware of the open points in the specificationsand the work issues they have to solve themselves before deploying the network.

The analysis first states the requirements of ToIP and IP-VPN respectively and describes thefunctionality of the UMTS entities supporting the services based on description of scenario 3 in TS23.207. Based on these requirements and the functionality of the UMTS network an elaborateddescription is provided regarding what steps need to be carried out by the UMTS network tosatisfactory support the services. The QoS requirements to successfully support the services arestated based on values (e.g. delay, jitter error rate) provided by 3GPP SA1 in TS 22.105. Theanalysis is summed up in a conclusion chapter trying to highlight the findings of this analysis.

3.2 Introduction to Telephony over PS Domain (ToIP)

A typical user is not concerned with how a particular service is provided, but he should be able tocompare similar services in terms of QoS parameters, which apply end to end. From a user’sviewpoint QoS parameters should be:

• focused on user-perceivable effects;

• network design independence;

• objectively measured at the service access point;

• assured by the service provider to a user.

In the following we focus on the ToIP service, which belongs to a conversational real-timeapplication category. A Real Time conversation scheme is strictly characterised by humanperception. Therefore, its QoS requirements are the strongest and most stringent. In particular,transfer time should be low and time variation between information entities of the stream should bepreserved. A failure to provide low enough transfer delay will result in unacceptable lack ofquality. The requirements on packet loss ratio are less hard than the ones on delay. This is becausethe human ear is tolerant to a certain amount of distortion of speech signal.



The analysis carried out in this section, moves from user QoS parameters as derived from userperception to a treatment of the QoS parameters as coded in the UMTS network.

3.2.1 Network service definition: Rel-5 ToIP

This service allows a 3G user to call another 2G/3G mobile or PSTN/ISDN fixed user, accessingthe world-wide IP cloud via UMTS network access.

With a UMTS release 5 system the mobile environment is converging towards a multi-serviceplatform that is able to provide via PS Domain, the new 3G specific services, as well as oldtraditional CS tele-services as defined in 3GPP TS 22.003 (see the figure 5). In particular, the focushere is on the telephony tele-service over IP connectivity provided by PS Domain.

'DWD

6HUYLFHV

&LUFXLW�6ZLWFKHG'RPDLQ

%DVLF�YRLFHVHUYLFHV

6XSSOHPHQWDU\

VHUYLFHV

2SHUDWRU

VSHFLILFVHUYLFHV

1HZ�DQG�LPSURYHG

3DFNHW�6ZLWFKHG'RPDLQ

1HZ�DQG�LPSURYHG

&LUFXLW�6ZLWFKHG

'RPDLQ

3DFNHW�6ZLWFKHG

'RPDLQ

1HZ�DQG�LPSURYHG 1HZ�DQG�LPSURYHG

0XOWLPHGLD

6HUYLFHV

%DVLF

VHUYLFHV

6XSSOHPHQWDU\VHUYLFHV

2SHUDWRUVSHFLILFVHUYLFHV

No reduction in feature set or qualityof service

EHIRUH DIWHU

Figure 5: Service provisioning evolution towards PS Domain

As a matter of fact, the connectivity layer is hidden to the user that perceives only the capability ofmaking a telephone call, independently from the transport mechanisms chosen from the operator todeliver the voice to the end destination.

3.2.2 Service network architecture

Here we list the main functionalities of the network entities involved in the provisioning of ToIPservice for UMTS networks.



3.2.2.1 UE

QoS functionalities required in the UE are part of the IP BS Manager or corresponding user planefunctions. In particular, the UE QoS capabilities that will be used in the scenario, which we aregoing to analyse, are the following:

• SIP/SDP Function

• RSVP/Intserv Function

• DiffServ Edge Function

• Binding Mechanism

SIP/SDP Function handles end-to-end QoS requirements at the application layer, which must bemapped, to both PDP context parameters for UMTS internal QoS provisioning and to IP layerparameters by the UE for end-to-end QoS provisioning.

RSVP/Intserv Function allows the UE to request end-to-end QoS using RSVP messages asdefined in IETF standards. RSVP messages may also include the authorisation token and flowidentifier(s) if they are available in the UE. Moreover, RSVP messages may be used to trigger PDPcontext activation/modification. RSVP is not used for QoS provisioning internally in the UMTSnetwork.

DiffServ Edge Function acts as a DiffServ (DS) classifier for the traffic coming from applicationsrunning on the UE. The DS Edge node i.e., the UE, must be able to mark IP packets by selectingthe appropriate DS Code Point (DSCP) in the packet header according to the QoS requirementsfrom the application. The DiffServ marking is used within the external backbone network.

Binding Mechanism is used to associate a PDP context bearer to the IP flow in order to support IPpolicy enforcement and QoS inter-working. At this scope a SIP session may be bound to a PDPcontext or to a RSVP session including the authorisation token and flow identifier(s) respectively inthe PDP Context Activation/Modification and in the RSVP messages. For IMS services theauthorisation token is provided during a SIP session by P-CSCF to UE.

Control plane

Within the IP Multimedia Subsystem we have control functionalities in the P-CSCF and in the S-CSCF.

3.2.2.2 P-CSCF

Amongst the CSCFs the P-CSCF is the one responsible of the resource authorisation. The reasonfor this is that only a module of the visited network can grant the UE of the necessary resources. Sothe main activities of P-CSCF (PCF) are:

• Authorise IP resources for the session using SDP in the SIP signalling messages;

• Decide new QoS authorisation when mid-call media or codec change, when a new flow isadded, etc;

• Enable service-based local policy control;

• Revoke the resources authorisation for the session at the IP multimedia session release.

Moreover, the P-CSCF generates the authorisation token, which is delivered to UE for each SIPsession (unique for each PDP Address associated with an APN).



3.2.2.3 S-CSCF

The S-CSCF is located in the home network and performs the session control services for the UE.This is because user profile is stored in HSS that is located in the home network. The functionsperformed by the S-CSCF during a session are:

• Registration;

• Session flows;

• Charging and resources utilisation.

3.2.2.4 HSS

HSS is the master database for a given user. Since it contains all the user profiles, e.g. services andservice specific information, it is interrogated by S-CSCF before it grants resources to UE. So thedecisions taken by P-CSCF could be modified before their enforcement according to the userprofile (in particular according to the QoS parameter ranges).

User plane

3.2.2.5 GGSN

QoS functionalities required in GGSN are part of IP BS Manager or corresponding user planefunctions. In particular the GGSN QoS capabilities that will be used in the scenario, which we aregoing to analyse, are the following:

• DiffServ Edge Function

• Service-based Local Policy Enforcement Point

• Binding Mechanism

DiffServ Edge Function should be compatible with IETF specifications for DiffServ. The IETFDiffServ architecture is here used to provide QoS for the external bearer service.

Service-based Local Policy Enforcement Point controls the QoS provided to particular IP flowusing admission control and packet handling/gating in the user plane. Policy-based admissioncontrol ensures that the resources used are within those reserved or allocated for a particular IPflow. Packet gating in the user plane is defined in term of a “gate” implemented in the GGSN. Thisgate is under control of P-CSCF (PCF) and operates on unidirectional streams. When the gate isopen the packets in a flow are under the DiffServ edge treatment (policing or marking). When thegate is closed all the packets in the flow are dropped. The packet classifier associated with a gate isa micro-flow classifier based on the standard 5-tuple (source IP address, destination IP address,source port, destination port, protocol).

Binding Mechanism associates PDP context bearer with one or more IP flows in order to supportservice-based local policy enforcement and QoS inter-working. Binding information is derivedfrom QoS and policy decision information provided by the PCF and is included in PDP contextActivation/Modification messages. At this scope PDP Configuration Option parameter shall beused.

3.2.2.6 SGSN

From a QoS point of view a SGSN is involved only in the PDP Context Activation/Modificationand in an indirect manner. So its role in the end-to-end QoS management is of minor importance.



3.3 Introduction to Virtual Private Network

3.3.1 Network Service definition Rel-5 IP VPN

The scenario presented in figure 6 considers a remote service, via UMTS access network, to acorporate IP VPN.

Core IPND router Network supportingCorporate IP VPN

BR

CR

CR

AA

AA

Fixed transit IPnetwork ‘T’

Legend:AA: Authentication and Authorisation Server BR / CR / CER: Border / Core / Customer Edge - RouterCPE: Customer premises Equipment GGSN: Gateway GSN GSN: GPRS Support NodeGPRS: General Packet Radio Service VPN: Virtual Private Network UTRAN: UMTS Terrestrial Radio AccessNNI: Network to Network Interface UMTS: Universal Mobile Telecommunications System

Users ofCPE

RemoteUser accessingCorporateIP VPN

BR

Authentication query

Users ofCPE

Corporate IP VPN

Network routerSupporting GGSN UTRAN

CER CER

NNI

Figure 6: Remote UMTS access scenario

In figure 6, a user of a Corporate IP VPN undertakes remote access using UMTS, via a fixed transitIP network, to a router, which supports the Corporate IP VPN. The fixed transit IP network doesnot provide part of the Corporate IP VPN but acts as a point of interconnection and packetforwarding from the UMTS Radio access network. The remote user has to be able to obtain accessto the Corporate IP VPN by means of signalling user name, password and other specified access-control requirements. This scenario should provide the remote user with bi-directional read, writeand voice communication with secure data and terminal equipment in the fixed IP VPN.Applications may include audio conferences, video conferences and date/file transfer.

3.3.1.1 Scenario requirements

• Corporate IP VPN, assumed to be managed by a Service Provider that owns or contracts withthe ’Core IPND router network’, which establishes all the necessary connectivity between thedispersed locations within the IP VPN. (Additional IPND router networks could beinterconnected to support the IP VPN between all end-to-end points, but this is omitted for thepurpose of simplicity in the scenario description).

• Inter-Operator requirements are involved in the relations between fixed transit IP network ’T’and the core IPND router network but it could be possible that the provider of the fixed transitIP network ’T’ coincide with the IPND.



• A pre-existing Service Level Agreement (SLA) and Network to Network interface (NNI)between the fixed transit IP network ’T’ and the core IPND router network. The SLA shouldinclude details of the secure access and packet forwarding capabilities between the respectivenetworks by means of an Authentication & Authorisation (AA) server or other technicalsolutions.

• A pre-existing Service Level Agreement (SLA) and Network to Network interface (NNI)between the UMTS access network and the fixed transit IP network ’T’, including details ofsecure access and packet forwarding capabilities.

All the networks involved in the scenario should have full network management capabilities totheir respective network technologies and automated management-to-management interfaces, forefficient service configuration, activation and other management requirements.

The scenario identifies a requirement to map and forward IP traffic from, across and betweenheterogeneous networks supporting respectively UMTS, MPLS, RSVP and local access lineparameters.

Automation of the network technology and peer-to-peer management communications: QoS policyshould be indicated in SLAs supporting the respective points of interconnection and agreementsshould be reached in SLSs to maintain the specified level of QoS assurance across the full end toend service instance for the duration of the communications session.

3.3.1.2 QoS parameters

• UMTS access network - the QoS parameters should be implemented, as described more fully inother parts of the document

• Fixed transit network ’T’ - the QoS parameters should include minimum packet forwarding rateand specified bounds on packet loss priority, delay, jitter, delay priority, round trip timetogether with resilience specifications.

• Customer Edge Routers and access network - QoS supported (typically) by IntServ and RSVP.The link between CERs and BRs may be (typically) leased line or ADSL.

• Core IPND network - QoS assured by the use of MPLS

3.3.2 Service network architecture

In this section the above requirements are fulfilled in the UMTS Release 5 network.

In the Rel-5, the nodes involved in the service provisioning are:

• UE

• CSCFs, in particular the S-CSCF that implements the subscriber services

• HSS

• SGSN

• GGSN

Regarding the provision of the IP VPN service, the UMTS release 5 and the release 1999, differ forthe access network and for the new definition of QoS management in the GGSN and the presenceof the P-CSCF containing information on the session.

The differences are associated with the Attach procedure used by the MS to require the activationof a service. In UMTS Release 5, during the PDP Context Activation, some session information ispassed to the P-CSCF. Then the MS sends the SIP message for the registration to the required P-CSCF, which forwards the SIP message to an I-CSCF, which use information derived from theHSS to select the S-CSCF that will act as Registrar for the MS.

In these scenarios it is the P-CSCF who authorises the use of the QoS resources necessary for thesession.



The provision of an IP VPN in the UMTS Rel 5 network, is described in figure 7:

Figure 7: IP VPN provisioning in UMTS network for a roaming user

The network operator that sells the IP VPN service, defines an IPSec tunnel with the corporate CPEand that tunnel will be used for all the connection to that Corporate Network.

The APN used by the mobile stations to access the service will contain the identification of theGGSN of the home UMTS network and also the identification of the corporate network target.

If the user is roaming it will use the RAN of the visited network to access the service and then aGTP tunnel to reach the GGSN in the home network that redirects the IP packets on the specificIPSec tunnel.

In order to provide security and authentication services, the GGSN in the home UMTS networkcould access the server RADIUS located in the Corporate Network or use its own information.

The operator can decide to provide access to the PS domain using a service-based local policy orwithout it. If the access is not based on a policy, it will use profile defined during the usersubscription whilst if the policy is present it will also use the information and the functionalitypresent in the GGSN and P-CSCF.

The QoS request is generated in the MS; if the device does not implement the IP BS managerfunction, the request is directly mapped in the PDP context, otherwise it is managed by the IPBSmanager located in the UE and in the GGSN

In the UMTS core network the QoS could be provided in two different ways:

• over provisioning of network capacity

Radio Access

Visited

Intra-operator

Backbone

Inter-operator

Backbone

GGS

S-CSCF

HSS

Location

Profile

Home

INTERNET

CP

Corporate

ServerRADIUS

IPSecTunnel

BG



• using IP layer QoS mechanisms

The most used IP layers QoS mechanisms are the Differentiated Services (DiffServ) and IntegratedServices. Both are defined by IETF.

The following scenario describes how the end-to-end QoS service could be provided.

This scenario defines that the MS must support RSVP and DiffServ functions. To realise the end-to-end QoS it uses RSVP based on the IntServ semantic; DiffServ is instead used for themanagement of the QoS in the IP backbone, from the GGSN to the remote access point and as oneof several possible options in the remote access network. (It should be recognised that DiffServprovides, at best, management of aggregated packet flows, based on various Classes of Service, incore networks and then, therefore, only offers specified QoS for that aggregate and not forindividual micro-flows where the latter could represent an individual call or service).

The QoS in the wireless access is provided using the PDP context; the information about the QoS isstored with the user profile in the HSS, and this information is also directly available to GGSN andP-CSCF.

• UMTS Attachment: As in the release 1999, after the Attach procedure, the MS requires a PDPContext Activation to obtain a private IP address; all the information is stored in the UMTSnetwork and in the MS. Now the set-up of a QoS session of UMTS is required to allow the MSto use the VPN with required parameters. In our scenario the MS must be able to negotiate theQoS parameters by means of SIP and to reserve the resources using RSVP.

• UMTS QoS session set-up: The session is controlled by the SIP proxy that is part of the P-CSCF. The request to verify if a session with specific characteristics can be activated is sent tothe P-CSCF. If the answer is positive the MS sends a SIP INVITE to the remote proxy

• UMTS QoS resource reservation: After the session set-up, it is necessary to reserve theresources to guarantee the end-to-end QoS. This phase involves the UE, the GGSN thatimplements functions of DiffServ Edge and the access node to the destination network.Considering that the dynamic QoS management in the Diffserv domain in the core network isaccomplished by the Load Control protocol, an interoperation between RSVP and this LoadControl protocol should be provided. During this phase, the resource managers located in allthese network regions and the two items of equipment located at the ends of the path, will haveto intercommunicate and reserve the negotiated resources. The UMTS PDP activation/modification procedures are used in the access network of the UE to reserve the requestedresources in the UMTS domain. At this point the applications located at the two end points canstart to send the IP packets containing user data.

3.3.3 Security/ IPSec

One of the motivations for subscribing to a VPN by an end user, is to have the best possibleprotection of end-to-end connection and data.

As the VPN is based on an IP network and the PS Domain is essentially in the Internet world and isimplemented on IP networks, the security problem is about the protection of the user data and thenetwork information, (like charging information, customers’ information and other technicalinformation on the network) in a IP network. This sub-section focuses on the implementation ofreliable and secure remote connections for accessing corporate Intranets.

The simplest solution to this problem is to have a dedicated connection from the GGSN of theUMTS network operator to the corporate Intranet, by-passing the public Internet. As the cost forproviding such connections is high, it is likely to be attractive only to large organisations. Thedata must be protected in transit on the UMTS IP backbone (between the access network to theGGSN of the HPLMN connected to the corporate network).

An alternative approach is to base the configuration on IPSec.

The IPSec mechanism has been developed to solve the security weakness of IP, protecting both theintegrity and confidentiality of IP packets, without changing the interface to IP.



Using IPSec, it is possible to define an end-to-end VPN in which the traffic is encrypted at theVPN client and decrypted at the corporate VPN server. The authentication is handled by thesubscriber organisation.

Using this approach it is possible to provide:

• confidentiality

• integrity

• authentication

• tunnelling to the corporate network using the ESP (Encapsulating Security Protocol)

In this configuration the data is sent on the GTP tunnel in the Intra-operator backbone network and,if the subscriber is roaming, in the Inter-operator backbone to reach the GGSN in the HPLMN ofthe terminal.

As described in the previous paragraph, during the subscription an IPSec tunnel is defined thatbegins at the home GGSN and ends at the CPE of the corporate.

To realise the authentication, the GGSN must contact a specific server, like a Radius server that canbe co-located with the GGSN or it can use the corporate Radius server.

With this configuration the APN provided to the MS must identify the home GGSN and thecorporate access point to which the MS can access. The APN is used by the GGSN to select thecorrect tunnel to use.

3.4 Layered description of Rel-5 QoS parameters

In this section we list the parameters involved in the definition of QoS for ToIP and IP VPNservices.

3.4.1 Application layer

SIP is a signalling protocol for the application session management in an IP network, which allowsactivation, modification and termination of sessions involving one or more participants. From aQoS point of view the originating UE sends SIP messages to the destination UE(s) in order to statethe level of QoS that can be supported during the session. The session is described through SDP(service description protocol) messages, which contain the necessary information to establish theconnection. In particular the information included is:

• Name and scope of the session;

• Time elapsed from the beginning of the session;

• Types of media (video, audio);

• Addresses, ports and formats of the media;

• Effective bandwidth;

• Transport protocol (RTP/UDP/IP, H.320,…);

• Media format and codecs (H.261 video, MPEG video,…);

• Multicast destination address;

• Multicast destination transport port.

A SDP message is made up by a number of text lines in the form <type>=<value>, where <type> isa char, which specify the syntax of the field <value>, and <value> is a string.



The session initiator includes a SDP in the SIP INVITE message that lists every codec that theoriginator is willing to support for this session. When the message arrives at the destination UE itselects, which codecs it will support and responds to the originator sending a SDP containing thesubset agreed. QoS authorisation is performed for this common subset.

A new aspect in the UMTS environment (as opposed to the Internet environment) is that when aSIP message passes through a CSCF its information may be read and used for resourceauthorisation and local policing. In fact the P-CSCF (PCF) should use the SDP contained in theSIP signalling to calculate the proper authorisation. The authorisation should include limits on IPlevel (which will be described in the next section) and an Authorisation Token. The last one is sentto the originating UE, which uses it for the inter-working (mapping) between QoS of differentlayers (RSVP, DiffServ, PDP Context Activation/Modification).

A typical SDP description is made up of a session-level description and several media-leveldescriptions. The four components that are used for mapping a SDP description into a QoSauthorisation are the following:

• Media announcement (m);

• Connection data (c);

• Attributes (a);

• Bandwidth (b).

The “m” field contains information about the type of media session and is of the form:

m=<media> <port> <transport> <fmt list>The “c” field contains information about the media connection, and is of the form:

c=<network type> <address type> <connection address>

The “a” field contains attributes of the preceding media session, and is of the form:

a=<attribute><value>

The optional “b” field contains information about the bandwidth required, and is of the form:

b=<modifier>:<bandwidth-value>

3.4.2 IP end-to-end layer

In the scenario that we are analysing UE and GGSN support DiffServ edge functions and thebackbone IP network is DiffServ enabled. Besides this the UE also supports RSVP signalling andIntServ functionalities, which allows inter-working between RSVP and DiffServ domains.

The application layer (SIP/SDP) identifies the end-to-end QoS requirements. These requirementsare mapped down to IP layer and if implemented, the IP BS functions in the originating UE enablesend-to-end QoS using IP layer signalling, e.g. RSVP towards the remote UE.

IP layer QoS is, therefore, performed by different QoS mechanisms:

The end to end QoS is controlled by RSVP signalling, which is not supported by allintermediate nodes;

Throughout the IP backbone, QoS for the aggregated packet flows is guaranteed by theDiffServ functionalities in each node.

This means that the UE controls the remote access network through RSVP messages and marksdata that will be routed through intermediate domains using DiffServ CodePoint (DSCP). TheGGSN may override the DSCP according to service-base local policy or PDP context signalling.RSVP signalling is carried transparently through the UMTS network and the intermediate DiffServdomains.

Besides when the authorisation token is included in the PDP Context Activation/Modification theGGSN may use its information to pull information from the PCF to configure the DiffServclassifier functionality or DiffServ class admission control.



3.4.3 UMTS bearer

In an UMTS network QoS requirements are handled by PDP context procedures. Therefore, inorder to assure the QoS that a user expects, it is necessary to map into UMTS network parametersQoS requirements of the higher layer protocols. This is done by the UMTS BS Managers in the UE(if implemented) and in the GGSN.

In this scenario the control of QoS over the UMTS access network (from UE to GGSN) may beperformed from the terminal using PDP context signalling. The characteristics for the PDP contextmay be derived from RSVP signalling information or from the SDP directly. Alternativelysubscription data accessed by the SGSN may override the QoS requested via signalling from UE.

In the same way GGSN may override the DiffServ setting from the UE and use informationregarding the PDP context in order to select the appropriate DiffServ class to apply.

Figure 8 summarises the main aspects of the scenario introduced.

RSVP Signalling

RSVP Signalling

QoS in backbone network controlled by DS. DS marking performed byUE, or by GGSN based on PDPcontext signalling.RSVP signalling carried transparently.

QoS in UMTS controlled by PDP context.UE DS marking and RSVPsignalling carried transparently.

Uplink Data

Downlink Data

DS

DS

GGSNUE RemoteAP

RemoteHost

The UE controlsthe QoS mechanismsfrom the UE.

The UE may controlthe QoS mechanismsfrom received information.

The UE performsDS edge functions and RSVP

QoS in UMTS controlled by PDP context selected byTFT.Remote DS marking/GGSNremarking and RSVPsignalling carried transparently.

QoS in backbone network controlled by DS. DS marking performed byRUE (or remarking by RAP).RSVP signalling carried transparently.

QoS on remote accesslink controlled byeither DS or RSVP.


PDP Flow

PDP Flow

Application Layer (eg. SIP/SDP)


Figure 8: Network architecture scenario for a ToIP service, case without service based policy

Inter-working between the GGSN and the application layer is shown as a vertical line whereenabled. This inter-working is for policy control and is between the GGSN and the PCF policyfunction located in the P-CSCF, as shown in figure 9.



RSVP Signalling

RSVP Signalling

QoS in backbone network controlled by DS. DS marking performed byUE, or by GGSN based on PDPcontext signalling.RSVP signalling carried transparently.

QoS in UMTS controlled by PDP context.UE DS marking and RSVPsignalling carried transparently.

Uplink Data

Downlink Data

DS

DS

GGSN/P-CSCF (PCF)

UE RemoteAP

RemoteHost

The UE controlsthe QoS mechanismsfrom the UE.

The UE may controlthe QoS mechanismsfrom received information.

The UE performsDS edge functions and RSVP

QoS in UMTS controlled by PDP context selected byTFT.Remote DS marking/GGSNremarking and RSVPsignalling carried transparently.

QoS in backbone network controlled by DS. DS marking performed byRUE (or remarking by RAP).RSVP signalling carried transparently.



PDP Flow

PDP Flow



Authorization token

Authorization token

Figure 9: Network architecture scenario for a ToIP service, case with service based policyapplied

3.4.4 QoS parameters for ToIP service

As a result of the mapping process, the QoS requirements that should be provided to the end userbetween the access points of the network architecture are presented in table 1. The QoS valuesrepresent end-to-end network performance and are commonly accepted values from an end-user’sviewpoint. Delay values are one way delay and should be kept to a minimum since the case study istelephony (values shadowed).

Key performance parameters and target values

Medium Application Degree ofsymmetry Data rate

End-to-end One-way

Delay

Delay

Variationwithin a call

Informationloss

AudioConversational voice,ToIP Two-way 4-25 kb/s

<150 msec

preferred

<400 msec limit Note 1

< 1 msec < 3% FER

Table 1: End-user Performance Expectations - Conversational / Real-time Audio Services,from 3GPP 22.105



3.4.5 QoS Parameters for IP VPN service

When a Corporate acquires an IP VPN service by a network provider, it can use this service to runa variety of different applications: Access to corporate databases, access to the corporate intranet,web browsing of the internal intranet, download or upload of file in a secure manner orvideoconferencing.

These applications fall in different classes of services: Conversational for videoconferencing orinteractive class for services like access to corporate intranet or web browsing or background classfor file transfer.

The QoS parameters depends on the type of service required and are summarised in the followingtables (2 - 4):



End-to-end One-way

Delay

Delay


Informationloss

DataWeb-browsing

- HTML

Primarily one-way

< 4 sec /page N.AZero

Table 2: End-user Performance expectations for Interactive Services



End-to-end One-way

Delay

Delay


Informationloss

Video

Videophone Two-way 32-384 kb/s

< 150 msec preferred

<400 msec limit

Lip-synch : < 100 msec

< 1% FER

Table 3: End-user performance expectations for Conversational and Real-Time Services



End-to-end One-way

Delay

Delay


Informationloss

Data Bulk datatransfer/retrieval

Primarily one-way < 10 sec N.A

Zero

Table 4: End-user Performance expectations for Streaming Services



3.5 Concluding remarks

The scenario analysis has handled ToIP and IP-VPN, which are regarded as two of the mostimportant services the UMTS network has to be able to support in the future market. For UMTS tobe successful, these services have to be supported in a secure and cost effective way, and the publicwill demand QoS support near the same level as on fixed access networks. The analysis conductedin this chapter has shown that very many pieces of functionality have to work together to make upthe end-to-end service the user perceives. Many layers are involved with their differentcharacteristics, ranging from SDP conveying the application level QoS to PDP context and RSVPfor resource allocation within the UMTS network and remote access respectively. The IP-VPN, e.g.demands strict security mechanisms and profound inter operator agreements in order to besuccessful.

The requirements from these two services have clearly shown that there is a need for manyinteractions regarding QoS information gathering and mapping. Many of these are not specified by3GPP. Firstly the P-CSCF/PCF has to be able to analyse the SDP content to perform theapplication level QoS resource authorisation and construct the IP level policy that will be passed tothe PEP in the GGSN. Exactly what information in the SDP has to be examined and if thisinformation is adequate, is not quite clarified yet. Thereafter, the P-CSCF/PCF constructs anauthorisation token linking the authorisation to the actual SIP session (IP flow). The SIP/SDP issent to the UE with the authorisation token and the SDP is analysed by the UE. The UE extracts theQoS parameters and these are mapped into RSVP flowspec and t-spec parameters and optionallyDSCP and further on to PDP context QoS parameters and radio channel allocation algorithms.Many of these mappings are not specified by 3GPP and will be equipment vendor and operatorspecific.

The next issue is the sending of the authorisation token from the UE to the GGSN. In our scenariothis has to be sent in the PDP context since RSVP is transparent to GGSN. The token would use thePDP configuration option field. The GGSN extracts the authorisation token from the PDP context,e.g. the ToIP IP flow, and pulls the policy data from the PCF that is linked to this specific IP flow.The exact handling of the authorisation token in the GGSN is not specified yet in 3GPP. The CNgroups are, however, working on the issue. If the GGSN receives the DSCP from the PCF (as itmost possible will do in our scenarios) it would not need to construct the DSCP from the PDPcontext QoS parameters. Nevertheless, if the GGSN constructs DSCP from the PDP context theDSCP from the PCF will override the DSCP constructed by the translation function in the GGSN ifthey are not similar.

The DiffServ enabled backbone will support a level of QoS related to the DiffServ implementationof the backbone network operator. The UMTS operator and the backbone network operator mustcome to an agreement about the meaning behind the DiffServ classes and what QoS the differentDSCP will ensure. There is no need to mark a packet with a DSCP if there is no agreement behindthe meaning of this marking across operator domains. This inter operator agreement construction isregarded a major task for efficient QoS support across multiple IPNDs. Therefore, before anytraffic is sent, inter domain SLA/SLS agreements have to be established so every operator speaksthe same language regarding the QoS support they deploy.

At the remote access RSVP should be deployed. Now the question is : Has the P-CSCF /PCFmapped the SDP parameters to the policy QoS parameters in the same way the UE has mappedthem to RSVP? If the UE has mapped the parameters differently, e.g. allocated more resources thanthe PCF has authorised, there will be a waste of resource at the remote access. This may happen ifthe SDP QoS parameters are not well specified, and today SDP is very poor regarding QoS



information. 3GPP has requested IETF to enhance SDP with better QoS support, and IETF isworking on it.

Another issue to mention is the UMTS QoS attribute values. Table 1, e.g. specifies a one-way delayof <150ms to be satisfactory. According to ETSI TIPHON specifications this is acceptable but notgood quality. When we further know that one way delay of the UMTS bearer is calculated to beapproximately 100ms, we can envisage that a UMTS mobile calling another UMTS mobile inanother PLMN will experience more that 200ms packet delay one way.

All together this analysis has shown that the UMTS network is very complex and very many issuesare still not covered in detail for an implementation phase to be carried out without further work.Many issues are still unsolved and questions are reaming, e.g. regarding the usage of IPv6 and QoSissues regarding the different mechanisms for mapping between IPv4 and IPv6. Nevertheless, eachUMTS operator is urged to elaborate on this first approach to capture the requirements for themany challenging implementation issues regarding ToIP and IP-VPN services. No operator shouldtry to offer these services and risk failure, due to poor investigation of the implementation issuesand general physical limitations for the radio access media. Radio based IP services are challengingand each network segment has to be optimised regarding QoS support to best support the end-to-end QoS provisioning. This situation has to be taken seriously and before any operator should dareto trust the IP network to support real time applications, thorough studies need to be conducted andpilot systems should to be built.



4 SLA

This chapter will briefly look into the challenge of constructing service level agreements (SLA) inmobile networks. SLAs are especially important for mobile networks due to frequent roamingsituations all round the world. In most cases the roaming traffic will traverse many intermediate IPnetworks. To support the business aspects and QoS requirements detailed SLAs are needed whereall parties have a common understanding of the QoS terminology and requirements from theservices provided. With the diverse spectre of QoS mechanisms developed for IP networks thework of constructing SLAs is quite challenging. Taking into account the ever-growing number ofservice providers, network providers and heterogeneous customer types the picture gets even morecomplicated. When we know that the UMTS network will interface to a multitude of serviceproviders and network providers we should clearly understand the urgency of getting started withthe work on SLAs for UMTS.

This chapter describes:

• possible alternative ways a customer can be associated to a QoS for a service

• the implication of each alternative on the service provision process

• the need, in the context of provisioning this service, for setting up agreements with otheroperators (roaming agreements, or other interconnections)

4.1 SLA definitions

A SLA is a contract, static or dynamic, that specifies the overall features and performance, whichcan be expected by the customer. We distinguish between two types of SLAs: a retail SLA and awholesale SLA. The former is negotiated between an end-user and a service provider on arelatively small time scale, involving generally small resource amounts. The latter, instead, isnegotiated between two different network domains less frequently than the retail SLA, in order tocreate a pipe, which merges one or more different flows relating to retail SLAs

In general there is no direct connection between the retail SLA and the wholesale SLAs. Inparticular the wholesale SLA might not be based on parameters related to a single service but mightfocus on statistical indicators related to the grade of service of the entire bundle provided by oneprovider to one of its neighbours.

Figure 10: Overview of different SLA for service provisioning in UMTS

As figure 10 depicts, there could be many parties involved in service provisioning in UMTS eachestablishing SLA with peering parties. The UA, e.g. may have an agreement with the service

UE

Service Provider

SLA UE - SP SLA

SP - NP

UMTS Network provider

Backbone Network Provider

Content Provider

SLA AP - NP

UE

Service Provider

SLA UE - SP SLA

SP - NP

UMTS Network provider

Backbone Network Provider

Content Provider

SLA AP - NP



provider, which has an agreement with the backbone network provider to transport the service, e.g.from a network SIP application server. This backbone network provider has an agreement with theUMTS operator to support the access to the roaming mobile user. The service provider may againhave an agreement with a content provider and so forth.

4.2 End-user View

4.2.1 QoS Subscription options

Bearer services provide the capability for information transfer between access points and involveonly low layer functions; the TS 22.105 3GPP technical specification describes the end-to-endcharacteristics for the bearer services with requirements on QoS.

The QoS requirements for the end user/applications are classified in TS 22.105 in terms of QoSrequirements (table 5).

Error tolerant Conversationalvoice and video

Voice messaging Streaming audioand video

Fax

Error intolerant Telnet,

interactive games

E-commerce,

WWW browsing

FTP, still image,paging

E-mail arrivalnotification

Conversational

(delay << 1 sec)

Interactive

(delay approx. 1 sec)

Streaming

(delay < 10 sec)

Background

(delay > 10 sec)

Table 5: QoS requirements for end user application

Note that in this classification only the delay parameter is used, a more detailed description of theend user/application QoS requirements is contained in tables 6, 7 and 8:



Medium Application Degree ofsymmetry

Data rate Key performance parameters and targetvalues

End-to-end One-way

Delay

Delay

Variationwithin acall

Informationloss

Audio Conversationalvoice Two-way 4-25 kb/s <150 msec

preferred

<400 msec limitNote 1

< 1 msec < 3% FER

Video Videophone Two-way 32-384kb/s

< 150 msecpreferred

<400 msec limit

Lip-synch : <100 msec

< 1% FER

Data Telemetry

- two-waycontrol

Two-way <28.8kb/s

< 250 msec N.A

Zero

Data Interactivegames

Two-way < 1 KB < 250 msec N.A Zero

Data Telnet Two-way

(asymmetric)

< 1 KB < 250 msec N.A Zero

Table 6: End-user performance expectations for Conversational and Real-Time Services



One-way

Delay

Delay

Variation

Informationloss

Audio Voicemessaging

Primarily

one-way 4-13 kb/s

< 1 sec forplayback

< 2 sec forrecord

< 1 msec

< 3% FER

Data Web-browsing

- HTML

Primarily one-way

< 4 sec /page N.A

Zero

Data Transactionservices – highpriority e.g. e-commerce, ATM

Two-way < 4 sec N.A

Zero

Data

E-mail

(server access)

Primarily

One-way

< 4 sec N.A Zero

Table 7: End-user Performance expectations for Interactive Services





One-way

Delay

Delay

Variation

Informationloss

Audio

High qualitystreaming audio

Primarily one-way

32-128kb/s

< 10 sec < 1 msec < 1% FER

Video One-way One-way 32-384kb/s

< 10 sec < 1% FER

Data Bulk datatransfer/retrieval

Primarily one-way

< 10 sec N.A

Zero

Data Still image One-way < 10 sec N.A Zero

Data Telemetry

- monitorino

One-way <28.8kb/s

< 10 sec N.A Zero

Table 8: End-user Performance expectations for Streaming Services

By the user perspective the parameters that could be present in the definition of class of servicesare:

• speed, that is influenced by the bandwidth, packet loss and Bit error network parameters

• immediacy, related to the delay variation (or jitter) and the delay

• availability, related to the delay

The availability is a basic requirement and is not negotiable and, therefore, only the speed and thedelivery time can be used as parameters for the definition of the class of service.

To simplify the definition of the contracts with the users, the operator should provide some Classesof Service, each of them defining the QoS parameters.

A contract subscribed by a user could include a SLA that defines the QoS; the QoS can be definedand provided in various ways:

• only one QoS across applications: In this case the QoS will be the same, regardless of theapplication used. In this case the user could use a high quality connection for an applicationadmitting a high delay

• different QoS selection based on Service or Application used: For example, the applicationsusing a corporate intranet can use a high quality Class of Service whilst ftp file transfer can usea lower Class Of Service. In this case the QoS and the charging rates will fit the differentapplications

• different QoS selection based on user choice: The user terminal must be able to select the QoSand the user could decide to use a QoS not adequate to the application

• no QoS is defined during the subscription and it is directly negotiated by the applications: Inthis case the user has no control on which Class of Service is selected by the application and itrequires the applications able to do it.



4.2.2 Architectural Considerations

In the HSS, directly or when accessing other servers, access is provided to two types ofinformation: Profile information associated with a user and information for tracking the location ofand means of access for its users.

The HSS controlling a user is located in the home network of that user.

The user profile information of a HSS is accessed by the S-CSCF during the session initiationprocedures; as defined for the Home Service Control solution the S-CSCF is located in the homenetwork and it acts as a call server even if the user that it controls is roaming in another operator’snetwork.

The user profile information should contain the SLA description subscribed for by the user with theQoS information; this information is stored in the SPD (Serving Profile Database) component ofthe CSCF that interacts with the HSS in the home network.

4.3 Interoperator View

The IP VPN mobile users should be able to use the service subscribed for wherever they are, forthis reason a fundamental component is the management of the roaming agreements betweenoperators.

The 3GPP TR 22.971 describes how the procedure for establishing agreements will be automaticbut nothing is said about the definition of the roaming agreements and the relation about theseagreements and the QoS provided to the user.

4.3.1 Roaming Agreements

A roaming agreement is a business agreement between two network operators to transfer itemssuch as call charges and subscription information back and forth, as their subscribers roam intoeach others areas.

A roaming agreement is defined between two service providers or can be established by means of aclearinghouse and must contain at least items regarding the tariff and pricing, the signalling fortraffic interconnection, the detail of the exchange format for data and problem handling.

The TeleManagement Forum TOM Application Note (GB910B) describes the roaming agreementmanagement for Mobile Services and it focuses on the definition of the information flows betweenthe Home Service Provider and the Serving Service Provider who owns the infrastructures used bya roaming user. This document does not define any item for the definition of specific SLAparameters in the roaming agreement but it seems very probable that with the services providedwith the 3rd Generation of mobile networks the roaming agreements will contain the Service LevelAgreement defined between operators.

4.3.2 Architectural Considerations/ Management

After the definition of a roaming agreement another important point is the enforcement of theconditions specified in the agreement.

The TeleManagement Forum TOM Application Note (GB910B) defines that in the Serving ServiceProvider a Customer QoS management component has to compile the service performance reports,that are negotiated in the roaming agreement. These reports are provided to the Home ServiceProviders with which the Serving Service Provider has an agreement.

If the Customer QoS management detects a violation of a negotiated SLA, it provides the violationinformation to the Problem Handling component.



The violations of a SLA and the troubles occurred during a roaming service execution are sent tothe Home Service Providers via notifications and reports and, if a SLA violation is detected, theRating and Discount component is notified.

Figure 10 describes the Roaming Agreement Management information flow, and is taken from theTeleManagement Forum TOM Application Note (GB910B) document.

It must be noted that in this figure the Customer is not the subscriber of the Home Service Provider,but is the Home Service provider itself.

Figure 10: Roaming Agreement management information flow



5 Open issues

Through the review of selected 3GPP specifications and the analysis of two important servicesToIP and IP-VPN, the project has revealed issues that need to be addressed either by the operatorsor by 3GPP. These issues are regarded necessary to get the system up running quickly, efficientlyand cost effectively while still incorporating the strategic business plans of each individualoperator’s choice. Most of the work within 3GPP has been focused on the overall functionality ofthe UMTS nodes and their internal interfaces. This specification work from 3GPP is vital to get thesystem functioning, and give the operators freedom in selecting vendors for different parts of thenetwork. Issues related to the specific implementation of the various functions within eachcomponent are, however, left to the vendors to specify, possibly in conjunction with the operators.

For an operator to get a better overview of the remaining issues that need operator influence ordirect implementation and technical descriptions from the vendors, this chapter will list the openissues revealed through the project work.

It may be hoped that this list of open issues may be helpful for operators when planning to roll outthe UMTS system in their environments. Different countries will deploy different physical networktopology, which may result in different problems. Most of the open issues, however, most operatorwill have to deal with in one or another way.

The issues may be characterised into two categories.

• Issues related to the specific tasks an operator has to take into account when implementingthe UMTS system

• Open issues that are regarded as a standardisation effort but have still not been worked on

The following list of open issues is grouped into three sections. The first (Ch. 5.1) contains issuesthat should be considered as a priority for future studies. Section 5.2 contains issues that aregenerally important for service provision and management. Section 5.3 contains a list of issues thatare expected to be elaborated on as a priority in 3GPP.

5.1 Open issues for high priority future studies

5.1.1 Dimensioning of the transport in UMTS

Different dimensioning issues need to be carried out by each operator, to be able to optimise thenetwork resources and to be able to support differentiation of services. The dimension work reliesheavily on the service portfolio and anticipated user behaviour regarding QoS demands, usageduration, mobility, time of day for usage, etc.

• User behaviour

o Regarding service selection

o QoS demands for the service perception

o Service mix to expect

o Mobility expectations and speed of movement (different handover situations etc)

• Description of mobile traffic models



• Dimensioning methods based on the traffic models for UMTS

o How this service mix will effect the loading of the links

o What error rates may be expected regarding retransmissions both on the radioaccess and throughout the core network

5.1.2 Network topology issues

• What network architecture would be most efficient and profitable? E.g. the physicaltopology of Node Bs, RNCs, SGSN and GGSN and the IP router networks connectingthem. Different topologies demand different link capacity, have diverse fault conditions,demand different management networks, policy functionality, etc.

• Architecture models

5.1.3 QoS implementation

Closely affecting the dimensions work is also the QoS support mechanisms on the variousinterfaces. In chapter 3 we described the QoS mechanisms on the interfaces as specified in 3GPP.Only the overall mechanisms to be deployed are specified in 3GPP, not the concreteimplementation. This is a vendor issue possibly implementing the mechanisms in co-operation withthe operators. The following issues need operator configuration and may impact the vendor’simplementation.

• How to configure the IP bearers for QoS differentiation

Related to IP it is need for:

o Selecting the number of priority queues

o Selecting the scheduling algorithm

o Dimensioning the queue length

o Dimensioning selected thresholds

o Selecting proper actions regarding queue overflow/threshold overflow

• If there is an IP router network between the RNC and SGSN and between the SGSN andGGSN traffic engineering issues as possible use of MPLS may be investigated. Also thepossibility of protection paths in case of link failures etc.

5.1.4 QoS parameter mappings:

QoS parameter mapping between different QoS mechanisms is regarded as an operator issue frommost vendors' points of view. This may put considerable burden on the operators and also thevendors, since the vendors nevertheless, have to comply with the specifications attribute values,e.g. regarding delay. There are many mappings needed, both horizontally and vertically. Thismapping is also quite crucial for the system to work as prescribed. As described in the QoS bearerframework the IP bearer level uses the services of the UMTS bearer level, which in turn uses theservice of the radio, Iu and core network bearer services. These different bearers may deploydifferent mechanisms to support QoS, which makes the mapping issues quite complex and verydemanding. In the following we will briefly describe the needed mappings in each UMTS node.

5.1.4.1 At the RNC and SGSN:

If the RNC and SGSN deploy IP QoS across the Iu and Gn interface we need to conduct thefollowing QoS mappings:



• The UMTS bearers QoS classes (conversational, streaming, interactive and background)need to be mapped to DiffServ code points, in the case of UMTS backbone Diffservenabled

• The DSCP need to be mapped to AAL5/ATM transport bearer, if IP over ATM is used

• The UMTS QoS classes need to be mapped to Radio bearers, which is the responsibility ofthe RNC to administrate.

5.1.4.2 At the GGSN:

At the GGSN the IP bearer level adds another mapping level.

In addition to the mapping between UMTS QoS classes to the IP connectivity layer below, theUMTS QoS classes need to be mapped to/from IP QoS mechanisms for the external backbonetransmission (and perhaps also to RSVP t.spec and f.spec parameters if implemented in the GGSNfor the backbone network) and used to allocate /reserve resources at the remote access.

It also has to conduct mapping to/from Diffserv for the UMTS core network. Note: the remoteaccess could be a variety of different technologies (LANs, PSTN/ISDN, 2G-PLMN, Internet).Different translation nodes in addition to the GGSN need to be configured..

5.1.4.3 At the terminal

In the terminal equipment still another parameter layer may be deployed, i.e. the QoS parametermapping between SIP/SDP and the IP bearer layer. At the terminal we may experience a QoSparameter mapping running from SIP/SDP -> RSVP or DiffServ Code point-> UMTS bearerservice QoS classes and radio access bearer attributes. The terminal issues are, however, not somuch influenced by operators. Nevertheless, the operator needs to be aware of this mapping toavoid waist of bandwidth due to poor mapping algorithms.

As seen, there are many QoS parameter mapping situations, which will not be standardised in3GPP. The vendors will implement something but it is up to the operators to manifest that theimplementation fits their usage and business strategy.

5.1.5 Policy control/policy enforcement.

Policy control is needed to be able to support charging and control, and hinder non-authorisedresource usage. Policy control is, therefore, very important in the network and we may need policyfunctionality both at the SGSN and the GGSN (and possibly also at the RNC). We may need it atthe SGSN due to situations where the GGSN is in another PLMN that the SGSN and the SGSNmay not trust the GGSN to be able to conduct the correct policy handling. With the upcoming Iu-flex alternatives, a RNC may be connected to SGSNs from different vendors. The RNC willthereby act as a boarder node between different operators. Also the situation where an operatordecides to deploy a common IP infrastructure as the Core IP network Policy control in the SGSNmay be needed.

Issue related to the policy control system and the authorisation of IP bearer resources may be:

o What policy is used to split traffic stream into conformant/non-conformant flowso What policy should be adopted for non-conformant flowso What kind of information, e.g. QoS parameters, are needed to conduct IP policy

controlo How does the policy control function transform this information into policy rules



5.1.6 Inter-domain QoS management.

This relates to the inter domain agreements (SLA) and what QoS information it contains and whatparticular QoS parameters the agreement maps into (the SLS). It may also deal with issuesconcerning how the policy information is transferred in the network/management/control signallingto update and configure the SLAs. Questions of the dynamics in this configuration and usage ofpolicy data is important, since the upcoming QoS enabled IP network will demand quite extensiveenhancement regarding policy and inter operator agreements. In this category we may discuss theSLA between operators and between operators and 3’rd party service providers. If there arespecific issues related to mobility, they should be highlighted and investigated, e.g. dynamicconfiguration of SLA based on mobility information

5.1.7 Inter domain SLA negotiation

This issue is linked to inter-domain QoS management. The issues added are more related to theprotocol specific issues of the transfer of policy data. In short we are looking at:

• What protocols are needed for policy data transfer?

• What information within the protocols is most essential?

5.1.8 Resource management

There will be a need for an operator to keep a consistent resource overview of the UMTS network.The mobility aspects put extra pressure on an efficient and flexible admission and resource controlsystem with a network wide aspect. If the admission control algorithm is poorly engineered it mayseverely jeopardise the performance and network resource efficiency. The radio system isespecially critical. The mobility aspects regarding inter system handovers and handovers betweendifferent technologies and generations puts extra burdens on the flexibility of the resourcemanagement. Management of resources, both internally in the UMTS network and for thebackbone network to support end-to-end QoS, should be considered.

Issues that need investigation are:

• What are the relevant parameters need for the admission control system

• What parameters are relevant for link control and how to update them

• How to manage (dynamic configure) the buffer capacity/allocation

• What parameters are relevant for the Radio access resource manger

• How to keep track of processor capacity

5.2 Open issues for additional future work

In this section we give an overview of additional issues that should be considered for future work.

5.2.1 Cell planning

This issue is very important to ensure full radio coverage of an area. Cell hierarchy architecture,cell overlapping architecture and overlapping depth is crucial since the W-CDMA cell widthdecreases with increasing traffic load. Cell planning for UMTS is a big task and is very time-



consuming since it demands lengthy simulations and mathematical calculations. Most operatorshave dedicated tools for this work or rent tools for the implementation phase of the system.

5.2.2 Transport network configuration

ATM is considered as the transport option in many networks since the IP QoS is still not matureenough that many operators dare to rely on it. ATM PVCs are, therefore, one option both for the Iuand the Gn interfaces. Issues that need to be clarified are:

• Selection of transport solution across the Iu and Gn interfaces. (ATM and/or IP)

• If ATM is deployed there is a need to:

o Select the proper switching network

o Select proper QoS classes

o Select the queue length and scheduling algorithm

5.2.3 Handover strategy

The UMTS system will have quite narrow and flexible cell structure. The increasing number andcategories of applications (voice, data, multimedia) will put an increasing challenge on the operatorhandling of handover cases. The questions that need to be answered are amongst other:

• How should the resource manager gather, select and allocate radio resources (and linkresources in the UTRAN).

• What cell strategy should be planned to ensure continuous and most efficient handover andresource optimisation (look ahead techniques, reservation)

• In cases where there are lack of resources, what would be the operators strategy regardingselected media transfer, priority regarding handover traffic versus new sessions, etc

• What triggers are needed and how should the operator configure the triggers to suit thebusiness strategy. (e.g. user priority, media priority, etc)

5.2.4 Charging and QoS

Charging is really important and each operator has to construct the charging mechanism to suit itsstrategy. 3GPP specifies charging functionality and monitoring of information transfer includingboth user traffic and signalling. The flexibility is quite extensive. Charging parameters could betime duration, resource consumption, QoS class deployment, etc. These may all be monitored foruse in the charging algorithms. How these parameters and charging algorithm are constructed is,however, up to the operator.

5.2.5 Transport efficiency

For all UMTS operators the radio spectrum will be the main resource bottleneck. Methods toefficiently deploy the scarce resources have been investigated in 3GPP, e.g. header compression,header stripping, unequal error protection mechanisms to protect the most vulnerable bits, andmulticast/ broadcast solutions to avoid sending the same information on different flows all the wayfrom the sender to the receivers. Also issues regarding transcoding may be incorporated under thispoint. This work is tedious and challenging. Poor developed compression technique, e.g. may have



severally impact on the perceived QoS. Work is ongoing in 3GPP on these issues but lots of workis still needed.

5.3 Issues that need further standardisation work within 3GPP or otherstandardisation fora.

The following issues related to QoS are seen important but are not covered in releases within the3GPP work.

• Consistent mapping of QoS parameters in the PCF (P-CSCF) and the UE to be able toperform the same mapping to IP bearer layer QoS parameters in the UE as those sent to theGGSN in the COPS protocol

• Information transferred in the authorisation token.

• Authorisation token handling at the GGSN.

• Transport efficiency. Including header compression, header stripping algorithms etc.

5.4 Summary table of open issues

The following table has been compiled to summarise the key issues that an operator has to solvebefore a successful and complete roll out of the UMTS system may be undertaken. There are stillseveral open issues remaining to be solved in the 3GPP specification, but these will be solvedaccording to the work plans of the respective 3GPP releases and are not included in this table. It isto be noted that the list is not exhaustive. The focus has been, to list work issues according to an IPbased UMTS network infrastructure in the direction the UMTS system is evolving through rel-4and rel-5. Even if ATM may be used across different interfaces, especially in the first phases of theUMTS roll out, it is envisioned that use of IP may be implemented gradually to harmonise thetransport infrastructures and deploy similar network components and management system supportamong interconnecting and competing operators. The key issue for extensive usage of IP in amultimedia transport environment is the stability and maturity of IP based QoS mechanisms.

Work issue Brief description

User behaviour analysis Conduct user surveys/analysis regarding service usage. E.g. service portfolio,mix of services, user movements, and service demands, i.e. QoS requirements,etc. It is a prerequisite for all dimensioning, and admission control work.

Network dimensioning(link capacity, bufferlengths, queueing handlingetc)

To efficiently utilise the link capacity and ensure the network is capable ofsupporting the services portfolio regarding, e.g. resource usage, QoSrequirements, handover situations, etc.

Network architectureplanning

Plan the network architecture (router network topology, location of UMTSnodes, link transport structure, etc) to efficiently, and cost effectively support theselected areas with UMTS infrastructure coverage.

Cell planning To efficiently and cost effectively ensure UMTS coverage according to thelicense stipulations or requirements. The planning would incorporate a graduallycovering density according to traffic density. (Optimal cell planning may becompromised by public objections or restrictions to the siteing of radio masts).

Router support of QoS Support of differentiated service capability. Queue dimensioning, schedulingalgorithms, queue thresholds, etc are needed to support differentiated services(DiffServ)

Admission control Algorithms conducting the admission control of new sessions and handover casesetc based on resource utilisation, QoS requirements, subscriber profile etc.



Resource management Radio resource management/ core network resource management. Whatresources are included, link capacity, buffer lengths, radio channel allocation,number of sessions, criteria list of priorities etc.

Transport efficiency Including header compression, header stripping, UEP, transcoding, etc.

Local Policy handling Agreement regarding policy information. What information is needed, how shallthe policy rules be enforced, where shall policy functionality be implemented,etc

SLA agreements(including BLAs andTLAs)

Development of BLAs, SLAs, TLAs (Retail and wholesale SLAs). Configure themapping between, e.g. SLAs and SLS, which all require a detailed and commonunderstanding of the services QoS demands.

QoS parameter mapping QoS parameter mapping needed in all UMTS nodes including P-CSCF/PCF.Mapping from SIP (SDP) to RSVP/Intserv and/or DSCP. Further on to PDPcontext QoS parameters and RLC/MAC parameters. Consistent mappingvertically and horizontally across the UMTS network

Charging and QoS Operators may choose to differentiate QoS parameter specifications for serviceoffers and charging purposes. Inter-operator charging agreements and QoSimplications remain a highly complex area for completion of specifications andinterconnection agreements.

Fault Management Link failure, protection routing, etc

Monitoring What QoS parameters shall be monitored, where shall monitoring be conducted,what time-scale, database storage, various trigger events (fault, charging,admission notification etc)

IPv4 to IPv6 IMS exclusively deploy IPv6. Different IPv4-IPv6 translation techniques need tobe deployed and how they impact the QoS.

Table 9: Summary of issues that need further development to support completion of theUMTS specifications.



6 Conclusions

The trend in the telecommunication environment is supporting transition towards new networkarchitectures, specialised for providing IP-based multimedia services. The evolution frameworkthat has been chosen for the scope is fully defined in 3GPP specifications and it’s envisaged as awhole IP environment (the UMTS PS domain) controlled by a SIP-based control layer (IMS).

This project report points out a variety of new challenges following the convergence raised fromstandardising towards a multi-service network (what UMTS pretends to be) using IP transport(preferred to initially proposed ATM). Current industry trends are supporting the IP transport withmechanisms for QoS, fully derived from the Internet environment. The adoption of DiffServ andRSVP/IntServ paradigm for QoS provisioning is leading to a whole IP network, QoS enabled, thatis expected to be able to manage the user mobility in spite of high bit rates and highly variabletraffic characteristics and requirements.

At any rate we can foresee a scenario based on the convergence between mobile network andInternet network in a unique context integrated in a layered system. In UMTS Rel-5 the mobility ishandled as in 2G mobile systems, though the multimedia control and the services logic is handledas in the Internet. It is anticipated that there will eventually be a move towards IP based mobilityschemes, e.g. based on Mobile IP or host based routing protocols.

The rel-5 of the UMTS system is at the forefront of specifying a mobile network based on IPtechnology supporting high bit rate multimedia applications. This report has, therefore, focused ondocumenting the challenges this system will put on the operators implementing the UMTS system.Since the system is IP based many of the issues are related to IP based multimedia transport ingeneral. The concrete mobility aspects focusing on the UMTS Radio access network, e.g. handoversituations, radio interference, etc, related to QoS support, have not been investigated in depth, butare very important and should be worked on as well. It may be concluded that operators and otherindustry players have major work ahead covering a lot of different aspects of network and serviceprovisioning, including all the QoS aspects, when rolling out the UMTS system. Chapter 5 haslisted many open issues that remain to be solved - and these add up to a considerable challenge.



References

[1] P1103 TI2 “UMTS Quality of Service Survey” (EDIN 0282-1103)

[22.105 Rel 4] 3GPP TS 22.105 v4.2.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; Service aspects;Service and Service Capabilities (Release 4)”

[22.105 Rel 5] 3GPP TS 22.105 v5.0.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects Service aspects;Services and Service Capabilities (Release 5)”

[23.002] 3GPP TS 23.002 v3.3.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; NetworkArchitecture (Release 1999)”

[23.060] 3GPP TS 23.060 v3.4.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; General PacketRadio Service; Service description - Stage 2 (Release 1999)”

[23.107] 3GPP TS 23.107 v5.1.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; QoS Concept andArchitecture (Release 5)”

[23.207] 3GPP TS 23.207 v5.0.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; End-to-End QoSConcept and Architecture; (Release 5)”

[23.221] 3GPP TS 23.221 v5.1.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; Architecturalrequirements; (Release 5)”

[23.228] 3GPP TS 23.228 v5.1.0: “3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; IP Multimedia (IM)Subsystem - Stage 2 (Release 5)”

[24.008] 3GPP TS 24.008 v4.3.0: “3rd Generation Partnership Project; TechnicalSpecification Group Core Network; Mobile radio interface layer 3specification; Core Network Protocols - Stage 3 (Release 5)”

[IDWitzel] Andreas Witzel, Control servers in the core network, Ericsson ReviewNo. 4, 2000

[IDRKH] Vlora Rexhepi , G. Karagiannis , G. Heijenk A Framework for QoS &Mobility in the Internet Next Generation. Paper to be presented atEUNICE 2000, Sixth EUNICE Open European Summer School,University of Twente, Enschede, the Netherlands, September 2000

[IDQoS] G. Karagiannis, G. Heijenk: QoS in GPRS. CTIT Technical ReportSeries, No 00-29, IISN 1381-3625, December 2000

[TMFGB910B] TeleManagement Forum Telecom Operations Map, NMF, GB910Bv1.1, September 2000

project report p1103 inter-operator ip qos framework...

Documents