End to End QoS in CDMA2000

Product Description White Paper ERICSSON

PROPRIETARY

END-TO-END QUALITY OF SERCDNET

W

Abstract:

As usage of wservices that rsensitive to traproper supporimportant. ThiQuality of Seras standardiz

VICE IN MA2000 WORKS

hite Paper

ireless packet data services increases and equires more bandwidth and/or are more nsmission delays becomes available, t for end-to-end Quality of Service becomes s document describes how end-to-end vice is provided for by CDMA2000 networks, ed by 3GPP2.

White Paper – End-to-End Quality of Service in CDMA2000 Networks Ericsson Proprietary

All data and information contained in or disclosed by this document are confidential and proprietary information of Ericsson Wireless Communications Inc., and all rights therein are expressly reserved. By accepting this material, the recipient agrees that this material and the information contained therein are held in confidence and in trust and will not be used, copied, reproduced in whole or in part, nor its contents revealed in any manner to others without the express written permission of Ericsson Wireless Communications Inc..

Information in this document is subject to change and does not represent a commitment on the part of Ericsson Wireless Communications Inc..

Trademarks and Permissions and other Ericsson trademarks are the trademarks or

registered trademarks of Telefonaktiebolaget LM Ericsson in the U.S. and certain other countries.

All trademarks or registered trademarks are properties of their respective owners.

The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing.

Ericsson shall have no liability for any error or damages of any kind resulting from the use of this document.

This technology is controlled by the United States Government. Diversion contrary to U.S. law is prohibited.

© 2002 Ericsson Wireless Communications Inc.. All rights reserved.

Ericsson Wireless Communications Inc.

6455 Lusk Boulevard

San Diego, California 92121-2779

USA

EWU/UT-01:1052 Uan B 2002-01-28 2 (22)


CONTENTS

1 Introduction 4

2 Important Concepts and Definitions 4

3 Access Independent Aspects 6 3.1 Introduction 6 3.2 User Plane Aspects 8 3.3 Control Plane Aspects 11

4 QoS in CDMA2000 Networks 13 4.1 Basic Concepts 13 4.2 Radio Bearer Service 14 4.3 IOS Bearer Service 16 4.4 PPP Link Service 17 4.5 External Bearer Service 20

5 Acronyms 21

6 References 22

EWU/UT-01:1052 Uan B 2002-01-28 3 (22)


1 Introduction As usage of wireless packet data services increases and services that require more bandwidth and/or that are more sensitive to transmission delays become available, proper support for end-to-end Quality of Service (QoS) becomes important.

This document will describe the architecture for supporting Quality of Service in CDMA2000 networks, as being defined by evolving 3GPP2 standards. Although the work in 3GPP2 has been focused on the CDMA2000 access technologies, the architecture has been developed to a very large extent to facilitate access independence, i.e. to easily support other access technologies.

After some definitions of important concepts, a description of an access independent architecture follows, which outlines the fundamental building blocks for Quality of Service enabled solutions. Later on, there is an in-depth view of how Quality of Service is supported in the CDMA2000 network, as defined by 3GPP2 specifications.

2 Important Concepts and Definitions The reader is assumed to be familiar with the CDMA2000 air interfaces and the overall 3GPP2/CDMA2000 architecture. Some basic understanding of how Quality of Service is provided in IP networks (as defined by standards such as the IETF) is also assumed. This section will provide some definitions of concepts used later in the document. For more detailed information, references are given to the appropriate standard documents.

CDMA2000. Suite of air interfaces specified within 3GPP2. See [4].

CDMA2000 Packet Data standards. The higher level functionality of CDMA2000 packet data, e.g. the connectivity to IP networks, as specified in [2].

Differentiated Services (DiffServ, DS). A framework defined by the IETF for implementing scalable service differentiation in the Internet (see [5]). In contrast to the IntServ framework, routers in a DiffServ domain are assumed to be stateless, only operating on relative priorities of packets. DiffServ operates within DiffServ domains. Inter-domain operation is governed by Service Level and Traffic Conditioning Agreements.

DiffServ CodePoint (DSCP). A specific value of the DSCP portion of the DS field, used to select a Per Hop Behavior (PHB). A Per Hop Behavior is the observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate. The DS Field is part of every IP packet transmitted.

Integrated Services (IntServ). A framework developed by the IETF, where QoS is guaranteed by reserving resources along the path of a specific IP flow. Because of the reservation, all routers become stateful. The Resource Reservation Protocol (RSVP) is the signaling protocol used to reserve resources. IntServ can also be used in combination with DiffServ, removing the necessity of all routers being stateful. The IntServ framework is described in [6].

EWU/UT-01:1052 Uan B 2002-01-28 4 (22)


Interoperability Specification (IOS). A 3GPP2 specification, defining the interfaces between certain elements within the 3GPP2 architecture, especially the core network to radio access network interfaces. See [3].

IP Flow. In IETF DiffServ referred to as a microflow. IETF defines a microflow as a single instance of an application-to-application flow of packets which is identified by source address, source port, destination address, destination port, and protocol ID.

Marking. The process of setting the DiffServ codepoint (DSCP) in a packet based on defined rules (pre-marking, re-marking).

Metering. The process of measuring the temporal properties (such as rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes.

Policing. The process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile.

Policy Control. The application of rules to determine whether or not access to a particular resource should be granted. The IETF has defined a framework for policy control, see for example [9].

Resource Reservation Protocol (RSVP). A signaling protocol defined by the IETF in [7], used to signal the need for reservation of resources along the path of an IP flow.

Service Level Agreement (SLA). A service contract between a customer and a service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another DS domain (upstream domain). A SLA may include traffic conditioning rules which constitute a TCA in whole or in part.

Shaping. The process of delaying packets within a traffic stream to cause it to conform to a defined traffic profile.

Traffic Conditioning. Control functions performed to enforce rules specified in a TCA, including metering, marking, shaping, and policing

Traffic Conditioning Agreement (TCA). An agreement specifying classifier rules Agreement and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules that are to be applied to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy.

EWU/UT-01:1052 Uan B 2002-01-28 5 (22)


3 Access-Independent Aspects

3.1 Introduction The QoS-related work in the 3GPP2 has so far been done within the context of CDMA2000 access technologies only. It is however fair to say that the model has been developed so that a clear separation between access-dependent and access-specific parts has been achieved. The 3GPP2 has also developed an All-IP architecture (see [1]) that is highly access-independent. That architecture has inspired the descriptions in this section.

Figure 1 illustrates the architecture for how end-to-end QoS can be provided independently of the access technology used.

AccessGW/Router

Access Bearer Service

End-to-End Service

AAAL Policy Mgr

Access Network External/Core Network

AAAH

Mobile Station CorrespondentNode

End to end QoS - Generic model

Access Network

External Bearer Service Access Bearer Service

Figure 1. End-to-End Quality of Service – Access-Independent Architecture

The goal is to establish an End-to-End Service (for QoS) between a mobile and the network using a specific access technology and a Correspondent Node, which could be a mobile connected to another access technology. The end-to-end service is requested by the endpoints (mobile) and their characteristic corresponds to the needs of the application triggering the request.

The task of establishing the end-to-end service may be divided into three subtasks:

• Establishing an Access Bearer service. This could, for example, mean establishing and configuring the necessary radio channels. This part is typically specific to each access technology.

EWU/UT-01:1052 Uan B 2002-01-28 6 (22)


• Establishing the External Bearer Service. This bearer service spans across networks and is typically based on IETF technologies such as DiffServ and IntServ.

• Establishing the End-to-End service. It is built on top of the other two services and involves mapping the needs of the Application into a request for an Access Bearer Service as well as mapping between the Access Bearer Service and the External Bearer Service.

The paradigm for building the External Bearer Service would typically be based on the IETF DiffServ standards. Another (future) possibility is to use IETF IntServ and/or RSVP standards.

The Access Gateway/Access Router is the point where mapping between the Access Bearer service and the External Bearer Service takes place. The tasks of the Access Gateway would typically include:

• Map IP flows to some kind of Access bearer/links. The exact way of doing this is unique to each access technology.

• Receive Access Bearer requests from the Mobile Station and authorize these requests (e.g. using AAA).

• Conditioning of up-link traffic, on an aggregate level.

• Conditioning of down-link flows, if that is required for the access technology in question.

• Apply DiffServ marking/re-marking on the up-link IP flows based on user/network policies.

• Consult a Policy Manager for core network policy decisions.

Access Bearer Service requests are authorized by the AAA (subscriber policy in the home network AAA – the AAAH). Accounting records are generated by the Access Gateway and sent to the AAA.

The External Bearer service would typically be built up by:

• Using DiffServ marking at the end points, or in the access gateway

• DiffServ operation on a traffic aggregate level (no operation on a per flow level)

• Service Level agreements between network providers

• The necessary Traffic conditioning at network borders

• Policy Control, using Policy Manager

Future implementation may also contain IntServ/RSVP support. The End-to-End service is created by a combination of

EWU/UT-01:1052 Uan B 2002-01-28 7 (22)


• Access Bearer Service

• External Bearer Service

• The necessary mapping between the two, for example, flows mapped to traffic aggregates at the edges (Access Gateway)

3.2 User Plane Aspects In order to facilitate a working end-to-end QoS model, it is important to use the concept of an end-to-end flow (or as in DiffServ: Microflow). Both DiffServ and IntServ rely on this kind of concept, although the implementations of these flows are fundamentally different. The 3GPP2 model assumes that DiffServ is the default choice although it could also work with an IntServ model.

The flows goes from one peer (e.g. mobile) to another (end-to-end) and are typically identified by parameters such as source/destination IP address and source/destination (UDP/TCP) port and also possibly other parameters. For example, in a SIP Session between two parties, each media component (e.g., video, audio, chat) would typically map to one flow each, at least when the QoS requirements differ.

QoS requirements are associated with each flow. These requirements could be expressed in terms of parameters such as required bandwidth, delay, jitter, priority The purpose of providing end-to-end QoS is to insure that these requirements are fulfilled for each flow.

In a DiffServ scenario, such as is assumed in this document, it is not relevant to speak about “guaranteeing” the QoS. The DiffServ approach is however believed to give a far better tradeoff between the service offered and the cost of equipment/management than is the case with the IntServ approach. A DiffServ-enabled network does not operate on individual end-to-end flows. Instead, it relies on the classification of traffic into aggregate classes at the edges, and on well-defined “Per Hop Behaviors” for each of these classes.

By carefully engineering the network, the end-to-end QoS can be reasonably “guaranteed” assuming traffic behaves according to expectation. If an even stricter control of the traffic inside the network is required, DiffServ mechanisms may be combined with the use of Policy Servers and/or IP networking technologies such as Multi Protocol Label Switching (MPLS).

Figure 2 illustrates the task of mapping the QoS requirements per flow to the different components/domains of the network.

EWU/UT-01:1052 Uan B 2002-01-28 8 (22)


Access Network

MS CorrespondantNode(s)

e2e flow1

e2e flow 2e2e flow 3

End-toEnd service

BR

Logical link conn 1

Logical link conn 2Logical link conn 3

Logical link conn 4

AccessGateway

BRBR BR

Access Bearer Service

Operation on trafficaggregate level (DiffServ)

Figure 2. Bearer plane - overview

In this example, the packets are assumed to pass through one access network, one carrier’s core network, and a number of IP networks (domains) on their way to their destination. It is assumed that these networks have Service Level Agreements (SLAs) and Traffic Conditioning Agreements (TCAs) governing the flow of traffic between the networks.

Below follows a description for each entity on how they participate in the provisioing of end-to-end QoS for the:

Mobile Station. The mobile’s behavior will obviously be different depending on access technology. Typically the mobile needs to establish some kind of logical link connections with the network using the access bearer service. Associated with these connections are QoS requirements specific to the access technology.

The mobile needs to classify the outgoing traffic, that is, identify the flows (for example: based on destination IP address and port number). Based on this classification, each packet will be sent on the appropriate logical link connection to the network. Multiple flows may be mapped to a single logical link connection. The mobile may also do a pre-marking of the packets (i.e. setting the DiffServ DSCP in the appropriate header field).

Associated with each logical link connection and/or with each flow is also a profile controlling other aspects of how to treat the packets, e.g. what kind of header compression

EWU/UT-01:1052 Uan B 2002-01-28 9 (22)


to apply. The logical link connections are then mapped to access specific links, such as logical/physical air interface channels. Header compression/decompression is performed whenever required.

The mobile will have to deduce information about what kind of logical link connections and/or treatments (e.g. header compression) that are required through information at the application level (e.g. a Voice-over-IP application requiring header compression and a low delay logical link). The methods to do this are not standardized within the 3GPP2. The mobile is also responsible for conditioning the outgoing traffic (i.e. ensuring that the traffic is within the agreed limits).

Access Network. The access network (including the air interface in the case of CDMA2000) is responsible for implementing the logical link connections between the mobile and the access gateway. The actual implementation of the logical link connections will be different depending on the access technology used. The purpose of the logical link connections is to transport packets between the mobile and the access gateway according to the QoS characteristics that has been negotiated between the mobile and the access network. The access network itself may be implemented using technologies such as DiffServ, but DiffServ is in such a scenario only used as a technology to fulfil the requirements of the logical link connections themselves, and this usage of DiffServ is independent from the core network/end-to-end usage of DiffServ.

Access Gateway. The main purpose of the Access Gateway is to hide any access-specific features from the surrounding networks, enabling the use of generic access-independent technologies, such as DiffServ.

On the up-link, the access gateway may map from the logical link connections to external bearer service, typically by assigning DSCPs to the packets, mapping them into traffic aggregates appropriate for the end-to-end QoS required for the flow. In case the mobile didn’t mark the packets (assign DSCP), the access gateway may do the marking and it would be, in any case, allowed to perform a remarking based on a user/network policy. The access gateway may also condition the aggregate traffic based on policies as well as performing filtering functions, such as allowing only certain destination IP addresses for a particular flow.

On the down-link, the access gateway would map the individual flows to logical link connections. To do this, the access gateway needs to do a classification of packets identifying to which flow a particular packet belongs. Typically, the Access Gateway would use filter specifications received from the mobile station, possibly combined with static profiles/policies. Before mapping the identified flows to the selected logical connection, the access gateway can, if necessary, condition the traffic of the flow to make sure that it is not off limits. For some access technologies (such as CDMA2000) traffic conditioning would be performed by other nodes (such as Radio Access Network)

The access gateway would also perform header compression/decompression on a per flow basis or per service instance, whenever appropriate/requested.

Border Routers. The border routers behave as any DiffServ border routers connecting DiffServ regions/domains. They would do traffic conditioning according to SLA/TCAs, as well as classification on an aggregate level and possibly remarking of packets (to match the usage of DSCPs for a particular region)

EWU/UT-01:1052 Uan B 2002-01-28 10 (22)


3.3 Control Plane Aspects Figure 3 gives an overview of the signaling involved in providing end-to-end Quality of Service in a scenario with two communicating mobile stations.

AccessFunctions

QoSClient

Application

QoSAPI

Mobile Station

AccessNetwork

Application

QoSAPI

Mobile Station

AccessNetwork

(e2e QoS signaling, e.g RSVP )

Application signaling (e.g SIP)

AGWAGW"Access Bearer

Signaling"

QoSClient

AccessFunctions

BR"SLA"

Figure 3. End-to-end QoS Signaling

There is a clear separation between the functions/signaling used for QoS setup/negotiation and those used by the applications themselves (for example, SIP signaling). The reason for this is service flexibility:

• Applications executing on the terminal side should only need to have a minimum knowledge of its access environment. This makes applications more universally applicable and encourages global economies of scale and reusability, while facilitating the development of applications.

• Applications executing on the network side (e.g. SIP servers and associated services/applications) should only need to have a minimum knowledge (expressed in generic parameters) of the access technology used. The reasons are the same as above.

• Services deployed in the subscriber’s home network of should not require any direct knowledge of the access technology used by the subscriber in a visited carrier’s network. This enables network operators to develop new services independently, without a need for complex inter-carrier agreements and standardization.

EWU/UT-01:1052 Uan B 2002-01-28 11 (22)


The applications interact with the lower layers through a QoS API. Through this API, the applications may request/negotiate QoS using generic (access independent) parameters and they may receive notifications of changes due to reasons such as forced change of access technology or changed radio conditions.

The QoS client will, based on the application requests, interact with the network to assign the requested resources. This includes:

• The request for an “Access Bearer” to fulfil the overall QoS request. A typical example would be radio bearers with specific characteristics (e.g. Service Option). This negotiation is typically unique to each access technology and the details are on the network side hidden by the Access Gateway.

• The QoS client may also initialize RSVP signaling to the network in order to allocate the needed resources. If RSVP is used, the QoS client does not need to do any DiffServ marking of the packets. Early deployments of end-to-end QoS and initial standard releases will not support RSVP.

Application layer signaling is in many situations also necessary, either through standardized mechanisms, such as SIP, and/or through application specific/proprietary signaling. This signaling would for example include negotiation of which types of media streams to use and which codecs to apply to the streams. The application in the mobile will have to translate from the required media streams to QoS requests, using the generic QoS API.

EWU/UT-01:1052 Uan B 2002-01-28 12 (22)


4 QoS in CDMA2000 Networks

4.1 Basic Concepts Figure 4 illustrates the overall architecture for end-to-end QoS for CDMA2000 networks. It is built on the generic architecture presented earlier but refined to fit into the CDMA2000 architecture and with the CDMA2000 air interfaces.

DiffServ/MPLS (LER/LSR) enabled IP-backbone (1)

Per aggregate IP-QoS

HAPDSNCRANMS

End-to-end QoS

PPP Link Service

RadioBearer

IOSBearer

MSCRANPDSNHA

PPP Link Service

RadioBearer

IOSBearer

Appl. Appl.

IPIP IP IP IP

Q oS -profile acco r-d ing to on e o f fourQ oS -c lasses:• C onversa tiona l• S tream ing• In te ractive• B ackground

IP

External BearerService (DiffServ)

End-to-end QoS - 3GPP2 QoS-model

Figure 4. End-to-End QoS architecture for CDMA2000

The Packet Data Serving Node, PDSN, acts as Access Gateway (as defined in the previous section) for the CDMA2000 family of access technologies. The Mobile IP Home Agent, HA, is also introduced here as an entity involved in the external service. Although Mobile IP can also be used with other access technologies, it is a mandatory function in CDMA2000 networks.

The Access Bearer Service in the CDMA2000 access technologies can further be divided into a Radio Bearer Service, an IOS Bearer Service and a PPP Link service, each of which will be described in separate sections. Together these will provide the logical link connections. Logical link connections have a one-to-one mapping to Service Instances

The following differences exist compared to the generic access independent model:

• The PDSN will not do any conditioning of down-link user data traffic.

EWU/UT-01:1052 Uan B 2002-01-28 13 (22)


• The methods for classification/marking of up-link user data traffic have not (yet) been standardized.

• The exact methods for marking of down-link user data traffic has not (yet) been standardized.

4.2 Radio Bearer Service The basic abstraction used to describe the Radio Bearer service is the concept of a Service Instance. A mobile requests service instances that have certain qualities attached to it, such as QoS requirements.

A service instance may be (but doesn’t have to be) assigned to a physical radio channel. The assignment/multiplexing is controlled by the CDMA2000 multiplexing layers.

A service instance is a logical construct that exists even if there are no physical resources assigned to it (e.g. the Dormant State). Each mobile may have up to 6 active service instances. These are identified by a reference parameter SR_ID.

Service instances

CH CH CH

MultiplexingRLPIS-2000

Service Instances (max 6 per user)Circuit Packet

Service Optionsfor CS voice and data

Non-assured mode

Assured mode

Mapped to

Relative priorityQoS parameters (BLOB)

Physical channels

Not applicable to QoS discussion

Figure 5. Radio Bearer Service -service instances

Service Instances are activated through Service Options, which are parameters describing the type of service instance that is requested. Some Service Options correspond to circuit-switched services (outside the scope of end-to-end QoS), while other invoke Packet-

EWU/UT-01:1052 Uan B 2002-01-28 14 (22)


Switched services (e.g. Service Option 33). Quality of Service for Packet-switched service options can be offered at two levels:

• Non-assured mode. The service instance is only given a relative priority compared to others (statically provisioned subscriber parameter).

• Assured mode. QoS can (to some degree) be assured. QoS requirements are described by a parameter called BLOB, which contains entities such as minimum and expected bitrate.

The IS-2000 air interface will map from the higher level abstraction of service instances to physical channels, as illustrated by Figure 5. The mobile requests the establishment of new service instances using IS-2000 signaling messages carrying the necessary parameters.

Apart from the concept of service instances, and the associated parameters (e.g. QoS BLOB) used to describe these, there are also other more high level ways to classify service instances. One such classification is according to the type of end-to-end services they would support, whereby service instances can be mapped into the four following classes:

• Background class. Destination is not expecting the data within a certain time. Examples of applications include background download of emails.

• Interactive class. The destination is expecting the data within a certain time. Round trip delay time is one of the key attributes. Example of applications includes web browsing, data base retrieval, server access.

• Streaming class. The time relation between information entities within a flow is preserved but may tolerate some fixed transfer delay. Examples of application include video and audio streaming.

• Conversational classThe time relations between information entities within a flow are preserved and require low transfer delay. Examples of applications include voice over IP, video conferencing, etc.

Yet another way to classify service instances is into the following three types, depending on the mode in which the Radio Link Protocol (RLP) operates and the synchronicity with air interface framing:

EWU/UT-01:1052 Uan B 2002-01-28 15 (22)


• SI_TYPE_1. Uses retransmitting RLP. Used for Background, Interactive and possibly also Streaming classes.

• SI_TYPE_2. Bypasses RLP (and PPP framing). Used for the Conversational class service, when packet transmission is synchronized with air interface framing, e.g. Voice-over-IP with 0-byte header compression.

• SI_TYPE_3. Uses non-retransmitting RLP (and PPP framing). Used for the conversational class of services and possibly also the Streaming class. Transmission is asynchronous with air interface framing.

Both the traffic classes and the service instance types are abstractions useful for describing the characteristics of end-to-end services and air interface service instances and will therefore be used in this document. They however do not have any direct correspondences in the standards, i.e. they are not used for parameterization.

4.3 IOS Bearer Service The Interoperability Specification (IOS) Bearer Service maps service instances to IOS A8 and A10 connections, as shown in Figure 6.

Every active Service instance will be mapped to an A8 connection and one A10 connection. Every dormant Service instance will be mapped to one A10 connection. The setup of A8 and A10 connections is signaled through the A9 and A11 interfaces respectively.

The BSC will map incoming up-link/down-link user data from an air interface Service instance onto an A8 connection and vice versa. The PCF will map incoming up-link/down-link user data from an A8 connection onto an A10 connection and vice versa.

If down-link user data is incoming on an A10 connection for which there is no A8 connection, an A8 connection must be established and the air interface service instance must be reactivated.

Incoming down-link user data to the BSC/PCF on the A10 link may have a DiffServ DSCP marking set by the PDSN. The BSC/PCF may use this for scheduling packets that are to be transmitted over the same air interface service instance. This scheduling is a simple non-preemptive priority scheduling.

EWU/UT-01:1052 Uan B 2002-01-28 16 (22)


IOS Bearer Service

PDSNPCFBSC

ServiceInstance

ServiceInstance

MS

ServiceInstance

ServiceInstance

Dormant ServiceInstance

A8 link

A8 link

A10 link

A10 link

A10 link

ServiceInstance

ServiceInstance

Dormant ServiceInstance

MSC

A9 sign.

A11 sign.

A1 sign.

Figure 6. IOS Bearer Service

Establishment of packet data services may be authorized by the MSC, but the MSC does not need to be involved in QoS authorization, nor does it need to authorize every packet service instance. The establishment of new service instances is authorized through the PDSN.

The IP network over which the A10 connections are set up (the RP network) can be either over-provisioned or use DiffServ. If DiffServ is used, it is completely unrelated to the end-to-end usage of DiffServ since the A10 link transports PPP frames, not IP packets, and has no knowledge of end-to-end flows.

4.4 PPP Link Service In order to provide a full CDMA2000 access bearer service, a PPP link service is needed between the Mobile and the PDSN. This service provides the mapping between end-to-end IP flows and CDMA2000 service instances, as well as the necessary support for air interface scheduling.

Figure 7 provides an overview of the mapping that takes place in the forward direction (down-link). The PDSN will do a packet classification based on the filter specifications it is receiving from the mobile using the Multi-Channel Flow Treatment Protocol (MCFTP). Using this protocol, the mobile provides the PDSN with Traffic Flow Templates (TFTs) containing the filter specifications defining the flows as well as Flow treatments specified for each flow. Thus the PDSN knows to which A10 link/service instance to map each packet, and for instance whether to apply header compression. It may also set the DSCP

EWU/UT-01:1052 Uan B 2002-01-28 17 (22)


value on packets sent over A10 (e.g. by copying the DSCP of the “inner”/end-to-end IP header), so that the BSC/PCF can properly schedule the transmission of packets.

The PCF will forward the packets over the corresponding A8 connections, and the BSC will map the packets to be sent over the corresponding service instance.

QoS mapping - Forward direction

PDSN PCF BSC MS

Classification(mappingto flows)

IOSA10links

IOSA8links

AirinterfaceServiceInstances

Scheduling

DSCP 1 DSCP 1

DSCP 2 DSCP 2

Packet filter-> linkref

linkref SR_ID

matches Assigned/multiplex to physical channels

Figure 7. QoS mapping - forward direction

Figure 8 shows the mapping that takes place in the reverse direction (up-link). The QoS client in the mobile would map packets onto the appropriate service instance, as well as applying other special treatments such as header compression. The mobile may also mark the packets (set the DSCP value).

Upon reception, the BSC will send the packet onto the corresponding A8 connection to the PCF. The PCF will forward the packet on the corresponding A10 connection. The PDSN may mark (or re-mark) the packets (set the DSCP value) based on network/subscriber policies before forwarding the packet to the IP network.

EWU/UT-01:1052 Uan B 2002-01-28 18 (22)


QoS mapping - Reverse direction

BSC PCF PDSN

Mappingto flows

IOSA10links

IOSA8links

AirinterfaceServiceInstances

Scheduling/multiplexing

Packet filter-> SR_ID

SR_ID linkref

matches

Policing/marking

MS

Assigned/multiplex to physical channels

Figure 8. QoS mapping - reverse direction

In Figure 9, the internal mapping of an MS or PDSN is shown. There is always one service instance called the Primary service instance and zero to many auxiliary/secondary service instances.

The primary service instance, which typically would be of SI_TYPE1, is the one over which any PPP-related signaling takes place. This includes the PPP signaling extension called the Multi-Channel Flow Treatment Protocol (MCFTP) defined by 3GPP2. The primary service instance would typically also be the default choice for packet transmission (e.g. best effort packets).

In addition to the primary service instance there may be any number of auxiliary/secondary service instances of each of the three service instance types (up to the maximum allowed 6 instances). PPP/HDLC framing is used to delimit the packets (through framing) in those cases where this is required, i.e. for all service instances except those of SI_TYPE2 (which has a natural air interface framing). Header compression can be applied to any service instance and sometimes to individual flows sent over a service instance.

EWU/UT-01:1052 Uan B 2002-01-28 19 (22)


Mapping to service instances

IP

PrimaryService Instance(type 1)

AuxiliaryService Instance(type 1)



PPPsignaling

MCFTP

PPP/HDLCpayloadprocessing&headercompression



0-byteheadercompression

RLP RLP “Null” RLP

Non-retransmitting

RLP

PDSN/MS

PPPinstance

Control of mapping

Figure 9. Mapping to service instances

It is important to understand that there is a single PPP instance per mobile stations even if multiple service instances have been activated (some of which not even use PPP/HDLC framing). The PPP control signaling (IPCP, CHAP etc.) is always sent over the primary service instance. The MCFTP protocol is used to control how the user data of this single PPP connection is mapped onto individual service instances.

On the mobile side, the mapping is entirely controlled by the mobile itself. The PDSN receives control information from the mobile giving instructions such as on which IP flow to map to which service instance and whether to use header compression. The MCFTP protocol is used for this purpose.

4.5 External Bearer Service The external bearer service works exactly like in the access independent model, i.e. it is based on DiffServ. It may be complemented with for example Policy Servers and MPLS-based IP backbones.

For CDMA2000 where Mobile IP is used (see for example [8]), the Home Agent needs to be taken into account. For the forward direction, the Home Agent sets the DSCP value of the outer packet in the tunnel to be the same as the DSCP value of the inner (tunneled) packet when tunneling packets to the PDSN. If reversed tunneling is used, the PDSN will have to mark the outer packet, for example by setting the same DSCP as for the inner (tunneled) packet.

EWU/UT-01:1052 Uan B 2002-01-28 20 (22)


5 Acronyms

3GPP2 Third Generation Partnership Project 2 AAA Authorization, Authentication, Accounting AGW Access Gateway BSC Base Station Controller DSCP DiffServ Code Point DiffServ Differentiated Services FA Foreign Agent HA Home Agent HLR Home Location Register IETF Internet Engineering Task Force IntServ Integrated Services IOS Interoperability Specification IP Internet Protocol MCFTP Multi Channel Flow Treatment Protocol MPLS Multi Protocol Label Switching MS Mobile Station MSC Mobile Switching Center PDSN Packet Data Switching Node PPP Point-to-Point Protocol QoS Quality of Service RLP Radio Link Protocol RSVP Resource Reservation Protocol SIP Session Initiation Protocol SLA Service Level Agreement TCA Traffic Conditioning Agreement TCP/IP Transfer Control Protocol / Internet Protocol TIA Telecommunications Industry Association VoIP Voice-over-IP

EWU/UT-01:1052 Uan B 2002-01-28 21 (22)


6 References [1] IP Network Architecture Model for cdma2000 Spread Spectrum Systems, 3GPP2

SC.P000X [2] Wireless IP Network Standard, 3GPP2 P.S0001 (TIA IS-835) [3] Interoperability Specification, 3GPP2 A.S0001 (TIA IS-2001) [4] cdma2000 Standards for Spread Spectrum Systems, 3GPP2 C.S0001 –

C.S0006 (TIA IS-2000) [5] An Architecture for Differentiated Services, IETF RFC2475 [6] Integrated Services in the Internet Architecture: An Overview, IETF RFC1633 [7] Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification,

IETF RFC2205 [8] IP Mobility Support, IETF RFC2002 [9] A Framework for Policy-based Admission Control, IETF RFC2753

EWU/UT-01:1052 Uan B 2002-01-28 22 (22)

End to End QoS in CDMA2000

Documents

service level

ericsson trademarks

cdma2000 access technologies

cdma2000 packet data

ip networks

cdma2000 air interfaces

ip packet

definitions of concepts