Universal Mobile Telecommunications System (umts); Qos concept




Дата канвертавання27.04.2016
Памер140.16 Kb.






Tdoc S2-99223




UMTS 23.07 V0.3.0 (1999-04)


Technical Report


Universal Mobile Telecommunications System (UMTS);

QoS Concept

(UMTS 23.07 version 0.3.0)
















Reference



(lko00i04.PDF)

Keywords


ETSI


Postal address

F-06921 Sophia Antipolis Cedex - FRANCE




Office address

650 Route des Lucioles - Sophia Antipolis

Valbonne - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C

Association à but non lucratif enregistrée à la

Sous-Préfecture de Grasse (06) N° 7803/88

Internet


secretariat@etsi.fr

Individual copies of this ETSI deliverable


can be downloaded from

http://www.etsi.org






Copyright Notification

No part may be reproduced except as authorized by written permission.


The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1999.

All rights reserved.






Contents




Contents 3

Intellectual Property Rights 5

Foreword 5

Introduction 5

1 Scope 6

2 References 6

2.1 Normative References 6

2.2 Informative References 6

3 Definitions, symbols and abbreviations 7

3.1 Definitions 7

3.2 Abbreviations 7

4 High Level Requirements 8

4.1 End User QoS Requirements 8

4.2 General Requirements for QoS 9

4.3 Technical Requirements for QoS 9

5 QoS Capabilities of Radio Interface 9

6 QoS Architecture 10

6.1 Overview of Different Levels of QoS 10

6.1.1 The End-to-End Service and UMTS Bearer Service 10

6.1.2 The Radio Access Bearer Service and the Core Network Bearer Service 11

6.1.3 The Radio Bearer Service and the Iu Bearer Service 11

6.1.4 The Backbone Network Service 11

6.2 QoS Management Functions in the Network 11

6.2.1 Monitor 12

6.2.2 Translator 12

6.2.3 Mapper 13

6.2.4 Policer 13

6.2.5 Admission Controller 13

6.2.6 Resource Manager 13

6.3 UMTS QoS Classes 13

6.3.1 Conversational class 14

6.3.2 Streaming class 15

6.3.3 Interactive class 15

6.3.4 Background class 15

6.4 QoS Parameters 16

6.4.1 UMTS Bearer Service Parameters 16

6.4.2 Radio Access Bearer Service Parameters 16

6.4.3 Radio Bearer Service Parameters 16

6.4.4 Iu Bearer Service Parameters 16

6.4.5 Gn Bearer Service Parameters 16

7 QoS Parameter Mapping 17

7.1 From Application Parameters to UMTS Bearer Service Parameters 17

7.2 From UMTS Bearer Service Parameters to Radio Access Bearer Service Parameters 17

7.3 From UMTS Bearer Service Parameters to CN Bearer Service Parameters 17

7.4 From Radio Access Bearer Service Parameters to Radio Bearer Service Parameters 17

7.5 From Radio Access Bearer Service Parameters to Iu Bearer Service Parameters 17

8 QoS in Connection Setup 17

9 Interworking 17

9.1 UMTS-GSM CS/GPRS 18

9.1.1 UMTS-GSM CS 18

9.1.2 UMTS-GPRS 18

9.2 UMTS-PSTN 19

9.3 UMTS-ISDN 19

9.4 UMTS-Internet 19

9.4.1 UMTS-Integrated Services 20

9.4.2 UMTS-Differentiated Services 20



Annex 1 (informative):
Nokia Proposed Text for Different Chapters 20

6.4.1 UMTS QoS Parameters 20



Annex B (informative):
ATM 21

A.1 ATM Service Categories 21

A.2 Traffic and QoS Parameters 22

History 22




Intellectual Property Rights


IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.


Foreword


This draft Technical Report (TR) has been produced by the Special Mobile Group (SMG) of the European Telecommunications Standards Institute (ETSI).

This document is to define the basic issues related to the UMTS QoS concept.

The contents of this TR are subject to continuing work within SMG and may change following formal SMG approval. Should SMG modify the contents of this TR it will then be republished by ETSI with an identifying change of release date and an increase in version number as follows:

Version 1.x.y

where:

1 indicates sent to SMG for Information



x the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, updates, etc.

y the third digit is incremented when editorial only changes have been incorporated in the specification.


Introduction



1 Scope


Scope of this document is to provide the framework for Quality of Service in UMTS. The document shall be used as a living document which will cover all issues related Quality of Service in UMTS.

2 References


The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

- References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies.



  • A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same number.

2.1 Normative References


  1. UMTS 23.10 version 0.8.1, Universal Mobile Telecommunications System (UMTS), UMTS Access Stratum - Services and Functions

  2. UMTS 22.25 version 3.1.0, Universal Mobile Telecommunication System (UMTS), Quality of Service and Network Performance

  3. UMTS 22.01 version 3.2.1, Universal Mobile Telecommunications System (UMTS), Service aspects, Service principles

  4. UMTS 22.60 version 3.0.0, Universal Mobile Telecommunications System (UMTS), Service aspects, Mobile multimedia services including mobile Intranet and Internet services

  5. UMTS 21.06, Network and Service Management Requirements for UMTS

  6. UMTS 23.20 version 0.7.0, Evolution of the GSM platform towards UMTS


2.2 Informative References


  1. Working assumption on Radio Access Bearer Services, Version: 0.0.2, Date: 14 May 1998

  2. ETSI SMG12 TDoc 98s721, Rome, Italy, 14 - 18 September, 1998, Source: Editor (Ericsson), Draft 0.0.7 of Requirements Relevant for UTRAN Architecture

  3. ETSI SMG12 TDoc 98s767, Rome, Italy, 14 - 18 September, 1998, Source: Motorola, Change request No. A086 rev.1

  4. ETSI SMG12 TDoc 98s754, Rome, Italy, 14 - 18 September, 1998, Source: Lucent Technologies, Proposal for ETE UMTS QoS Control Principles

  5. ETSI SMG12 TDoc 98s790, Rome, Italy, 14 - 18 September, 1998, Source: Motorola, QoS Profile Parameters

  6. ATM Traffic Management Specification Version 4.0 [TM 4.0]

  7. ATM User-Network Intercafe (UNI) Signalling Specification Version 4.0 [UNI 4.0]

  8. ETSI SMG12 Tdoc 98s789, Rome, Italy, 14-18 September, 1998, Source: Motorola, Enhancements to Radio Bearer Parameters


3 Definitions, symbols and abbreviations

3.1 Definitions


For the purpose of this document the following definitions apply.

3.2 Abbreviations


For the purpose of this document the following abbreviations apply.

3G 3rd Generation

AAL2 ATM Adaptation Layer 2

AAL5 ATM Adaptation Layer 5

ABR Available Bit Rate

ATM Asynchronous Transfer Mode

CDMA Code Division Multiple Access

CBR Constant Bit Rate

CS Circuit Switched

GPRS General Packet Radio Service

GSM Global System for Mobile Communication

GTP GPRS Tunneling Protocol

HO Handover

IP Internet Protocol

ISDN Integrated Services Digital Network

L1 Layer 1, physical layer

L2 Layer 2, link layer

L3CE Layer 3 Compatibility Entity

LLC Logical Link Control

MAC Medium Access Control

MCR Minimum Cell Rate

MO Mobile Originating Call

MS Mobile Station

MT Mobile Terminating Call

nrt non-real time

NSAP Network layer Service Access Point

NT Non-Transparent

PCR Peak Cell Rate

PDP Packet Data Protocol

PSTN Public Switched Telephone Network

QoS Quality of Service

RAB Radio Access Bearer

RAN Radio Access Network

RLC Radio Link Control

RSVP Resource Reservation Protocol

rt real time

SAP Service Access Point

SDU Sevice Data Unit

UBR Unspecified Bit Rate

UDP User Datagram Protocol

T Transparent

TCP Transmission Control Protocol

TD-CDMA Time Division CDMA

TE Terminal Equipment

UMTS Universal Mobile Telecommunication System

VBR Variable Bit Rate



WCDMA Wideband CDMA

4 High Level Requirements

4.1 End User QoS Requirements


Generally, end users care only the issues that are visible to them. The involvement of the user leads to the following conclusions. From the end-user point of view:

  • Only the QoS perceived by end-user matter.

  • The number of user defined/controlled parameters has to be as small as possible.

  • Derivation/definition of QoS attributes from the application requirements has to be simple.

  • QoS attributes must be able to support all applications that are used.

  • QoS definitions have to be future proof.

  • QoS has to be provided end-to-end.


4.2 General Requirements for QoS


  • QoS parameters (or mapping of them) should not be restricted to one or few external QoS control mechanisms but the QoS concept should be capable of providing different levels of QoS by using UMTS specific control mechanisms (not related to QoS mechanisms in the external networks).

  • All parameters have to have unambiguous meaning.

  • QoS mechanism have to allow efficient use of radio capacity.

  • Allow independent evolution of Core and Access networks

  • Allow evolution of UMTS network, (i.e., eliminate or minimise the impact of evolution of transport technologies in the wireline world)

  • All parameter combinations have to have unambiguous meaning.


4.3 Technical Requirements for QoS


This chapter presents the general high-level technical requirements for the UMTS QoS. QoS will be defined with a set of parameters. These parameters should meet the following criteria:

  • UMTS QoS control mechanisms shall provide QoS parameter control on a peer to peer basis between MS and 3G gateway node.

  • The UMTS QoS mechanisms shall provide a mapping between application requirements and UMTS services.

  • The UMTS QoS control mechanisms shall be able to efficiently interwork with current QoS schemes. Further, the QoS concept should be capable of providing different levels of QoS by using UMTS specific control mechanisms (not related to QoS mechanisms in the external networks).

  • A session based approach needs to be adopted for all packet mode communication within the 3G serving node with which UMTS QoS approach must be intimately linked, essential features are multiple QoS streams per address.

  • The UMTS shall provide a finite set of QoS definitions.

  • The overhead and additional complexity caused by the QoS scheme should be kept reasonably low, as well as the amount of state information transmitted and stored in the network.

  • QoS shall support efficient resource utilisation.

  • Applications (or special software in MS or 3G gateway node) should be able to indicate QoS values for their data transmissions.

  • QoS behaviour should be dynamic , i.e., it shall be possible to modify QoS parameters during an active session.

  • Number of parameters should be kept reasonably low (increasing number of parameters, increase system complexity).


5 QoS Capabilities of Radio Interface


[Editor note: This chapter shall describe the L1 from the QoS point of view. The intent of the chapter is to provide backgroud to compare e.g. RAB parametrisations against L1 i.e. is L1 capable of utilising developed QoS concept.]

6 QoS Architecture

6.1 Overview of Different Levels of QoS


Network Services are considered end-to-end, this means from a Terminal Equipment (TE) to another TE. A End-to-End Service may have a certain Quality of Service (QoS) which is provided for the user of a network service. It is the user that decides whether he is satisfied with the provided QoS or not.

To realise a certain network QoS a Bearer Service with clearly defined characteristics and functionality is to be set up from the source to the destination of a service.

A bearer service includes all aspects to enable the provision of a contracted QoS. These aspects are among others the control signalling, user plane transport and QoS management functionality. A UMTS bearer service layered architecture is depicted in Figure 1, each bearer service on a specific layer offers it’s individual services using services provided by the layers below.

Figure 1: UMTS QoS Architecture

6.1.1 The End-to-End Service and UMTS Bearer Service


On its way from the TE to another TE the traffic has to pass different bearer services of the network(s). A TE is connected to the UMTS network by use of a Mobile Termination (MT). The End-to-End Service on the application level uses the bearer services of the underlying network(s). As the End-to-End Service is conveyed over several networks (not only UMTS) it is not subject for further elaboration in this document.

The End-to-End-Service used by the TE will be realised using a TE/MT Local Bearer Service, a UMTS Bearer Service, and an External Bearer Service.



TE/MT Local Bearer Service is not further elaborated here as this bearer service is outside the scope of the UMTS network.

Having said that the End-to-End Bearer Service is beyond the scope of this document it is however the various services offered by the UMTS Bearer Service that the UMTS operator offers. It is this bearer service that provides the UMTS QoS.

The External Bearer Service is not further elaborated here as this bearer may be using several network services, e.g. another UMTS Bearer Service.

6.1.2 The Radio Access Bearer Service and the Core Network Bearer Service


As described in the previous chapter it is the UMTS Bearer Service that provides the UMTS QoS. The UMTS Bearer Service consists of two parts, the Radio Access Bearer Service and the Core Network Bearer Service. Both services reflects the optimised way to realise the UMTS Bearer Service over the respective cellular network topology taking into account such aspects as e.g. mobility and mobile subscriber profiles.

The Radio Access Bearer Service provides confidential transport of signalling and user data between MT and CN Iu Edge Node with the QoS adequate to the negotiated UMTS Bearer Service or with the default QoS for signalling. This service is based on the characteristics of the radio interface and is maintained for a moving MT.

The Core Network Bearer Service of the UMTS core network connects the UMTS CN Iu Edge Node with the CN Gateway to the external network. The role of this service is to efficiently control and utilise the backbone network in order to provide the contracted UMTS bearer service.

6.1.3 The Radio Bearer Service and the Iu Bearer Service


The Radio Access Bearer Service is realised by a Radio Bearer Service and an Iu-Bearer Service.

The role of the Radio Bearer Service is to cover all the aspects of the radio interface transport. This bearer service uses the UTRA FDD/TDD, which is not elaborated further in this document.

The Iu-Bearer Service together with the Physical Bearer Service provides the transport between UTRAN and CN.

6.1.4 The Backbone Network Service


The Core Network Bearer Service uses a generic Backbone Network Service.

The Backbone Network Service covers the layer 1/Layer2 functionality and is selected according to operator’s choice in order to fulfil the QoS requirements of the Core Network Bearer Service. The Backbone Network Service is not specific to UMTS but may reuse an existing standard.


6.2 QoS Management Functions in the Network


[Editor note: Most of these functions are coming from [9]. They have not been agreed yet but this set can be used as starting point for discussions]

QoS management functions allow UMTS network to provide different levels of QoS. To be able to provide QoS efficiently at least following functions are needed:



  • QoS monitor,

  • QoS translator,

  • mapper,

  • QoS policer,

  • admission controller and

  • resource manager.

These functions (or part of them) can be combined to look like one entity if that will be seen feasible during standardisation. The tasks and functionality of these functions will be presented in following chapters. Further study is required to determine which of these funcions must be standardized. Locations of the QoS management functions is presented in the Figure 2. The functions that are obvious from the layered structure of the protocols are not drawn in the figure. One example of those can be e.g. mapper between different protocol layers. There might be e.g. parameter mapping between layers but that is manufacturer specific implementation issue thus there is no need to standardise them.

F
igure 2 Location of QoS management functions

6.2.1 Monitor


'Monitor' monitors the amount and characteristics of the traffic. Other QoS functions can use the output data of the monitoring function as their input. The role of the monitoring function varies according to its location. In MS it can monitor only the traffic of that particular user. In e.g. 3G serving node it/them monitors all the traffic. It is implementation dependent if RNC contains one or several monitor(s). If there is only one, it should monitor all traffic, but if there are several each one of them can monitor traffic from/to one user.

6.2.2 Translator


Translator function locates in the MS and in 3G gateway node (there might be a need to have translator functions in other network elements, too). The main task of the translator function is to convert external QoS requirements to the form understandable to the UMTS network. The input for the translator function is a set of parameters from the 'external world'. The translator function derives parameters related to

  • UMTS QoS,

  • bearer service,

  • radio access bearer,

  • radio bearer,

  • Iu bearer and

  • Gn bearer

The translator function has to be designed to be capable of converting e.g. RSVP, ATM and differentiated services parameters to different parameters in UMTS. However, the function may not be restricted only to mentioned QoS mechanisms.

6.2.3 Mapper



6.2.4 Policer


Policer function locates at the edge nodes (MS and 3G gateway node) of the UMTS network. Its main task is to control the traffic such that it will meet (or be 'less' than) the requested traffic characteristics e.g. traffic may not exceed the maximum negotiated bitrate. Policer drops or marks the packets that are determined to be non-compliant.

Policer function at 3G gateway node performs downlink data policing. In MS policer function performs uplink data policing.


6.2.5 Admission Controller


The purpose of admission control function is to calculate which network resources are required to provide requested QoS, determine if those resources are available, and reserve those resources. Admission control is performed in association with radio resource management functions in order to estimate the radio resource requirements within each cell.

The admission controller receives requests to allocate resources for a data flow. Each data flow is characterised by:



  • its traffic characteristics (e.g. maximum bit rate, minimum bit rate) and

  • requested QoS parameters (e.g. error rate).

The admission controller maintains:

  • a record of all currently active data flows and

  • a record of the total available resources available

Using above information the admission control function determines if the demands of a data flow request can be satisfied. Note that the resource scheduling policies being used by the resource scheduler must be taken into account by the admission controller.

The admission controller can be regarded as a mathematical function that takes as input traffic characteristics, requested QoS, current network element states, total resources available and resource scheduling policy and returns a yes or no answer.


6.2.6 Resource Manager


The resource manager is in charge of determining if the QoS requirements of a data flow can be satisfied and allocating resources to incoming packets. Occasionally, one or more packets will have to be discarded due to either lack of buffer capacity or excessive delays. The resource manager takes into account the QoS associated with various packets.

6.3 UMTS QoS Classes


When defining the UMTS QoS classes the restrictions and limitations of the air interface have to be taken into account. It is not reasonable to define complex mechanisms as have been in fixed networks due to different error characteristics of the air interface. The QoS mechanisms provided in the cellular network have to be robust and capable of providing reasonable QoS resolution. Table 1 illustrates proposed QoS classes for UMTS. UMTS offers these QoS classes to UMTS user (UMTS user defined in Figure 3).

[Editor note: Protocols that are presented in figure are not agreed but they are used for simplifying illustration of different levels of QoS.]

Figure 3 The interface to which UMTS user is attached

In the proposal there are four different QoS classes (or traffic classes):



  • Conversational class,

  • Streaming class,

  • Interactive class and

  • Background class.

The main distinguishing factor between these classes is how delay sensitive the traffic is: Conversational class is meant for traffic which is very delay sensitive while Background class is the most delay insensitive traffic class.

Conversational and Streaming classes are mainly intended to be used to carry real-time traffic flows. The main divider between them is how delay sensitive the traffic is. Conversational real-time services, like video telephony, are the most delay sensitive applications and those data streams should be carried in Conversational class.

Interactive class and Background are mainly meant to be used by traditional Internet applications like WWW, Email, Telnet, FTP and News. Due to looser delay requirements , compare to conversational and streaming classes, both provide better error rate by means of channel coding and retransmission. The main difference between Interactive and Background class is that Interactive class is mainly used by interactive applications, e.g. interactive Email or interactive Web browsing, while Background class is meant for background traffic, e.g. background download of Emails or background file downloading. Responsiveness of the interactive applications is ensured by separating interactive and background applications. Traffic in the Interactive class has higher priority in scheduling than Background class traffic, so background applications use transmission resources only when interactive applications do not need them. This is very important in wireless environment where the bandwidth is low compared to fixed networks.

6.3.1 Conversational class


The most well known use of this scheme is telephony speech (e.g. GSM). But with Internet and multimedia a number of new applications will require this scheme, for example voice over IP and video conferencing tools. Real time conversation is always performed between peers (or groups) of live (human) end-users. This is the only scheme where the required characteristics are strictly given by human perception.

Real time conversation scheme is characterised by that the transfer time must be low because of the conversational nature of the scheme and at the same time that the time relation (variation) between information entities of the stream must be preserved in the same way as for real time streams. The maximum transfer delay is given by the human perception of video and audio conversation. Therefore the limit for acceptable transfer delay is very strict, as failure to provide low enough transfer delay will result in unacceptable lack of quality. The transfer delay requirement is therefore both significantly lower and more stringent than the round trip delay of the interactive traffic case.

Real time conversation - fundamental characteristics for QoS:


  • preserve time relation (variation) between information entities of the stream

  • conversational pattern (stringent and low delay)


6.3.2 Streaming class


When the user is looking at (listening to) real time video (audio) the scheme of real time streams applies. The real time data flow is always aiming at a live (human) destination. It is a one way transport.

This scheme is one of the newcomers in data communication, raising a number of new requirements in both telecommunication and datacommunication systems. It is characterised by that the time relations (variation) between information entities (i.e. samples, packets) within a flow must be preserved, although it does not have any requirements on low transfer delay.

The delay variation of the end-to-end flow must be limited, to preserve the time relation (variation) between information entities of the stream. But as the stream normally is time aligned at the receiving end (in the user equipment), the highest acceptable delay variation over the transmission media is given by the capability of the time alignment function of the application. Acceptable delay variation is thus much greater than the delay variation given by the limits of human perception.

Real time streams - fundamental characteristics for QoS:



  • preserve time relation (variation) between information entities of the stream


6.3.3 Interactive class


When the end-user, that is either a machine or a human, is on line requesting data from remote equipment (e.g. a server), this scheme applies. Examples of human interaction with the remote equipment are: web browsing, data base retrieval, server access. Examples of machines interaction with remote equipment are: polling for measurement records and automatic data base enquiries (tele-machines).

Interactive traffic is the other classical data communication scheme that on an overall level is characterised by the request response pattern of the end-user. At the message destination there is an entity expecting the message (response) within a certain time. Round trip delay time is therefore one of the key attributes. Another characteristic is that the content of the packets must be transparently transferred (with low bit error rate).

Interactive traffic - fundamental characteristics for QoS:


  • request response pattern

  • preserve payload content


6.3.4 Background class


When the end-user, that typically is a computer, sends and receives data-files in the background, this scheme applies. Examples are background delivery of E-mails, SMS, download of databases and reception of measurement records.

Background traffic is one of the classical data communication schemes that on an overall level is characterised by that the destination is not expecting the data within a certain time. The scheme is thus more or less delivery time insensitive. Another characteristic is that the content of the packets must be transparently transferred (with low bit error rate).



Background traffic - fundamental characteristics for QoS:

  • the destination is not expecting the data within a certain time

  • preserve payload content

Table 1 UMTS QoS classes

Traffic class

Conversational class
conversational RT



Streaming class
streaming RT



Interactive class
Interactive best effort



Background
Background best effort

Fundamental characteristics

  • Preserve time relation (variation) between information entities of the stream

  • Conversational pattern (stringent and low delay )

  • Preserve time relation (variation) between information entities of the stream

  • Request response pattern

  • Preserve payload content

  • Destination is not expecting the data within a certain time

  • Preserve payload content

Example of the application

- voice

- streaming video

- Web browsing

- background download of emails


6.4 QoS Parameters



6.4.1 UMTS Bearer Service Parameters



6.4.2 Radio Access Bearer Service Parameters



6.4.3 Radio Bearer Service Parameters



6.4.4 Iu Bearer Service Parameters



6.4.5 Gn Bearer Service Parameters



7 QoS Parameter Mapping


[Editor note: This chapter shall contain information of parameter mapping i.e. how parameter in different levels of QoS (from external world and within UMTS network) shall be mapped. Current sub-chapter division is based on an assumption that levels of QoS presented in chapter 6, but they are open to discussions.]

7.1 From Application Parameters to UMTS Bearer Service Parameters



7.2 From UMTS Bearer Service Parameters to Radio Access Bearer Service Parameters



7.3 From UMTS Bearer Service Parameters to CN Bearer Service Parameters



7.4 From Radio Access Bearer Service Parameters to Radio Bearer Service Parameters



7.5 From Radio Access Bearer Service Parameters to Iu Bearer Service Parameters



8 QoS in Connection Setup


[Editor note: This chapter shall contain information of QoS parameters when setting up a PDP context, bearer, etc.]

9 Interworking


The model for the UMTS QoS classes and parameters may not be any existing network or QoS protocol/mechanisms as such. The main goal of the specification is not to copy existing QoS mechanisms but rather to create a future proof concept that will provide means to transport different types of data with different QoS requirements. Thus the interworking of UMTS and existing network technologies has to be ensured. This chapter presents the most common technologies that UMTS shall be capable to interwork with.

9.1 UMTS-GSM CS/GPRS


The development of the GSM/GPRS QoS classes and parameters is going on.

9.1.1 UMTS-GSM CS


The mapping between UMTS-GSM CS is easy because in GSM CS services only channel type (NT/T) and bandwidth (number of used time slots) can vary. During handover between UMTS-GSM only reliability, delay and bandwidth are meningful parameters.

HO from UMTS to GSM:

Reliability and delay together determines if NT or T service is used. Bandwidth is mapped to the next higher possible step.



HO from GSM to UMTS:

Type of service determines the required reliability. Bandwidth is mapped to the next higher possible step.


9.1.2 UMTS-GPRS


[Editor note: Part of GPRS phase 1 QoS are vaguely defined. This chapter has to be updated according to CRs to GPRS phase 1 QoS parameters. Definition of GPRS phase 2 is starting and it has to be taken into account in here and vice versa.]

GPRS has more QoS parameters than GSM CS thus requiring more complex mapping rules. Below an example of mapping GPRS phase 1 QoS parameters to UMTS traffic classes is presented.



Conversational Class

Conversational class services are mainly for conversational real time use. An example of conversional real time application is video telephony.

An appropriate use of GPRS parameters:


  • Mean Throughput Class = Peak bit rate (constant bit rate)

Or Mean Throughput Class < Peak bit rate (variable bit rate)

  • Reliability: 4 or 5 (no retransmissions)

  • Precedence:1-3

  • Delay Class: 1 (real time)

Streaming Class

Streaming class services are mainly appropriate for streaming real time applications, e.g. video downloading. Some variation in delay can be tolerated because of application level buffering.

An appropriate use of GPRS parameters:


  • Mean Throughput Class = Peak bit rate (constant bit rate)

Or Mean Throughput Class < Peak bit rate (variable bit rate)

  • Reliability: 3 (light retransmissions)

  • Precedence: 1-3

  • Delay Class: 1 (real time)

Interactive Class

Interactive class services are mainly for interactive services requiring a variable guaranteed throughput: specialized applications (banking, plane reservation, …), interactive WWW, Telnet etc.

An appropriate use of GPRS parameters:


  • Reliability: 1-2

  • Precedence: 1-3

  • Delay class: 2-4

Background Class

Background services are mainly for best effort services: background download, emails, calendar, event etc.

An appropriate use of GPRS parameters:


  • Mean Throughput Class has no meaning in UMTS

  • Reliability: 2

  • Precedence: 1-3

  • Delay class: 4 (best effort)


9.2 UMTS-PSTN


PSTN does not have QoS mechanisms thus QoS parameter interworking/mapping is not needed. However, means for determining required bandwidth, delay and reliability has to be developed. It is simple in MO cases but in MT cases the mechanisms (or in worst case defaults) have to be developed.

9.3 UMTS-ISDN


ISDN does not have QoS mechanisms thus QoS parameter interworking/mapping is not needed. However, means for determining required bandwidth, delay and reliability has to be developed. It is simple in MO cases but in MT cases the mechanisms (or in worst case defaults) have to be developed.

9.4 UMTS-Internet


In the case of Internet applications, the selection of the class and appropriate traffic attribute values is made according to the Internet QoS parameters. Internet applications do not directly use the services of UMTS but they use Internet QoS definitions and attributes, which are mapped to UMTS QoS attributes at API. Currently there are two main Internet QoS concepts, namely Integrated Services and Differentiated Services. The mapping between Internet QoS and UMTS QoS is presented in following chapters.

IP based QoS models must be supported for PDP contexts, meaning both Integrated Services (IntServ) signalled by RSVP [RFC2205] and Differentiated Services (6-bit QoS parameter on each IP packet, DiffServ). Both mechanisms are controlled by applications residing in the TE, allowing different application specific QoS levels for the same PDP context. Application level IP based QoS must be mapped to UMTS packet core QoS by a network element at the border of the network, such as the 3G gateway node. RSVP support would require flow establishment, and possibly aggregation of flows, within the UMTS packet core network. Differentiated services would require that there is either one QoS profile for each traffic type or alternatively the priority and traffic type information is included in the data packets.


9.4.1 UMTS-Integrated Services


RSVP is an end-to-end control protocol for Integrated Services Architecture and requires (soft) connection state maintenance in each network element along the data path.

9.4.2 UMTS-Differentiated Services


Work in IETF focuses on Differentiated services where the plan is to specify the details of IP header bit usage for QoS differentiated classes of service. Proposals in the IETF include varying number of pre-defined bits for delay and dropping priorities allowing each packet to be handled independently based on the header bits. The main objective is to specify only a QoS mechanism into header fields rather than end-to-end flow management.

Annex 1 (informative):
Nokia Proposed Text for Different Chapters


[Editor note: Text proposed for different chapters should be discussed separately from the skeleton of the document. Further, the proposed text for different chapters should be discussed, accepted or rejected chapter by chapter]

6.4.1 UMTS QoS Parameters


One of the key issues mentioned in the previous chapters is that parameter set has to be kept as small and simple as possible. Following set of parameters have been identified meet the criteria mentioned previously.

  1. Delay, gives an indication of the type of the traffic. It gives an indication of the needed resource requirements i.e. strict delay classfixed reservation of resources and describes means for achieving requested error rate. It also sets the limits to the error rate i.e. if strict delay class is requested e.g. retransmission cannot be used. Delay class parameter will be more dominating over error rate.

  2. Error rate, effects to the selection of the channel coding method, retransmission and/or power control.

  3. Maximum bitrate, indicates the maximum requested capacity. If this parameter has the same value as minimum bitrate the service will be constant rate and resources according to maximum bitrate are guaranteed. This parameter does not have meaning in Interactive and Background classes.

  4. Minimum bitrate, indicates the reserved capacity and the resources are guaranteed. If this parameter has same value as maximum bitrate the service will be constant rate service. This parameter does not have meaning in Interactive and Background classes. (FFS)

  5. Priority, has effect to the admission control, to the retention control and to the traffic handling.

The usage of different parameters has been defined in Table 2.

Table 2 UMTS QoS classes and required parameters

Traffic class

Conversational class
conversational RT


Streaming class
streaming RT


Interactive class
Interactive best effort


Background
Background best effort



Delay class

X

X

X

X

Error Rate

X

X

X

X

Max
bitrate


X

X

-

-

Min
bitrate, FFS


X

X

-

-

Priority

X

X

X

X


Annex B (informative):
ATM


ATM relies on a homogenous network with a unified data unit – ATM cell – and QoS guarantees are achieved with a statistical multiplexing.

The current set of ATM service categories and relevant parameters as defined by the ATM Forum is introduced below.

The relevant ATM Forum documents are [12] and [13].

A.1 ATM Service Categories


ATM networks offer a specific set of service categories which define the service characteristics and related parameters for different types of connections. At connection set-up, the user must request a specific service category for the connection from the network. The current set of service categories defined by the ATM Forum in the Traffic Management Specification 4.0, are:

  • Constant Bit Rate (CBR): The CBR service category is used by connections that require a static amount of bandwidth during the whole time of the connection. CBR service is intended to support real-time applications requiring tightly constrained delay variation. CBR is typically used for circuit emulation.

  • Real-Time Variable Bit Rate (rt-VBR): The rt-VBR service category is intended for real time applications which require small delay and a fixed timing relationship between samples. Therefore, rt-VBR service category is appropriate, e.g., for transmission of voice and video.

  • Non-Real-Time Variable Bit Rate (nrt-VBR): The nrt-VBR service category is intended for non-real-time applications which have bursty traffic characteristics. No delay bounds are associated with this service category.

  • Available Bit Rate (ABR): ABR supports variable bit rate traffic and does not provide any timing relationship between source and destination. Therefore, ABR is not intended to support real-time applications. in ABR, the network provides a “best effort” service, in which feedback (using a flow control mechanisms) is used to adjust the user bandwidth to the appropriate value which can vary between Minimum Cell Rate (MCR) and Peak Cell Rate (PCR).

  • Unspecified Bit Rate (UBR): The UBR service category does not specify traffic related service guarantees. The user is free to send any amount of data while the network makes no guarantees on the cell loss rate, delay or delay variation that might be experienced. Thus, UBR is intended for non-real-time applications, such as file transfer and email.

The service categories can be distinguished as being either real-time or non-real-time. For real-time traffic, there are two categories: CBR and rt-VBR, distinguished by the degree to which the delay variation between the cells is expected and preserved by the network.

The three non-real-time categories, nrt-VBR, ABR and UBR, differ as to the nature of the service guarantees provided by the network (regarding cell loss and delay) and the mechanisms which are implemented in end-systems and networks to realise them.

The requirements imposed by real-time and non-real-time services are different. The main difference between the two types is in terms of delay tolerance. Real-time services will have stringent requirements on delay and/or delay variation while non-real-time services may experience longer transfer delays. This in turn means that the buffers used for real-time services must be kept small in order to avoid long buffering delays and cells for real time connections must therefore be given high priority, i.e. routed quickly through the switches. On the other hand, buffers for non-real-time services have to be large so that non-real-time cells can be queued during the transmission of higher priority real-time service cells.

A.2 Traffic and QoS Parameters


In addition to the service category a user must, at connection set-up, inform the network of both the expected nature of the traffic that will be sent along the connection, as well as the quality of service (QoS) required for the connection. The former is described by a set of traffic parameters, while the latter is specified by a set of QoS parameters.

The way in which these parameters are agreed upon depends on the used specification. According to the ATM Forum UNI 3.1 specification [UNI 3.1], the user informs the network of desired traffic parameters and the service category (e.g. CBR). For UNI 3.1, the service category implicitly defines a set of (network operator selected) QoS parameters, each having a predefined value. Therefore, all connections having same service category will have the same QoS parameters.



UNI 4.0 [UNI 4.0], on the other hand, provides means to negotiate individual values also for the different QoS parameters. This makes it easier to adapt mobile systems into ATM networks, because it enables the possibility to take the varying quality of the air interface and the varying requirements of the applications into account in a more detailed manner.

History





Document History




October 1998




Scope agreed

November 1998

0.1.0

ToR agreed

January 1999

0.2.0

Parameters, traffic classes and management functions added

April 1999

0.3.0

Moved to template










































































База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка