2 Nortel Confidential Information

Quality of ServiceThe Key Enabler for Real-Time Services in HRPD Networks

Sanket S. Nesargisanket@nortel.com

3

Intent

> Provide an overview of QoS support in the 3GPP2 network• Components and interactions needed to support QoS in the air-

interface, access and core networks• Interaction of QoS with Service Based Bearer Control

> Provide Nortel’s view of evolving QoS in the 3GPP2 network• Evolving towards an End-to-End QoS model in a converged

network• Enhancing QoS support at individual 3GPP2 network components

> HRPD Rev A network used as illustrative example to identify defined QoS solutions

4

VoIP Session

Real Time ApplicationsThe Key Drivers for QoS

VoIPApplication

Calling Party

VoIPApplication

Called Party

Connection for SIP signaling

Connection for voice bearer

InternetInternetcdma2000 Packet Data

Network

QoS facilitated by IETF defined

mechanisms such as DiffServ or IntServ

• QoS mechanisms defined in 3GPP2• Focus of current presentation• Evolution needed for QoS to work seamlessly end-to-end

5

cdma2000 Packet Data Network Architecture

PDSNPCFAN

HA

3GPP2 Packet Core Network

3GPP2 Radio Access Network

CSCF

HSS

PCRF

MMD Domain

HRPD Air Interface

Signaling Path

Bearer Path

AAA

6

Network ArchitectureAcronyms

AN Access Network

PCF Packet Control Function

PDSN Packet Data Serving Node

HA Home Agent

AAA Authentication, Authorization and Accounting

MMD Multi-Media Domain

CSCF Call Session Control Function

HSS Home Subscriber Server

7

IP

PPP

RLP

MAC

HRPDPHY

IP

IP

GRE

PPP

IP

Enet

100BT

100BT

Enet

Application QoS (End-to-end QoS)

Interconnection Points & Protocol Stacks

PDSNPCFAN

Signaling Path

Bearer Path

Internet

Internet

HRPD Air Interface Protocols A9

A8

A11

A10

HRPD Air-InterfaceQoS Negotiation

Relay

GRE

IP

GRE

IP

Enet

100BT

Enet

100BT

Relay

RLP

MAC

HRPDPHY

GRE

IP

Enet

100BT

Access QoS(Local Policy or RAN signaled)

8

Decomposing the InterfacesBetween the AT and the AN (1 of 2)

Concepts:> Reservations:

• Represent an “IP Flow” or “application flow”• Identified by an 8-bit ReservationLabel• Unidirectional in nature i.e., {0x02, fwd} not related to {0x02, rev}• Have associated Requested and Granted QoS

• QoS parameters specified via blobs in attributes

• Two states: “open” and “close”• Default reservation 0xff

• assumed to be for best effort traffic• state set to “open” by default

> Link Flows:• Represent RLP flows across air-interface• Unidirectional in nature• Identified by Link Flow ID• Two states: “activated” and “deactivated”• Can support protocol-stack characteristics such as PPP/HDLC removal, ROHC-

framing, etc.

9

Decomposing the InterfacesBetween the AT and the AN (2 of 2)

AN

Link Flow {0x01, fwd}

Link Flow {0x01, rev}

Resv (0xff, fwd}

Resv (0xff, rev}

Link Flow {0x02, fwd}

Link Flow {0x03, rev}

Resv (0x04, fwd}QoS for fwd Flow 0x04

Resv (0x05, fwd}QoS for fwd Flow 0x05

Resv (0x08, rev}QoS for rev Flow 0x03

Link Flows:• Individual RLP connections• Unidirectional• States: Activated, Deactivated

Reservations:• Individual IP Flows• Unidirectional• States: Open, Closed• Default reservation: 0xff always open

Requested and Granted QoS Blobs

associated with Reservations

Link flows{0x02, fwd} & {0x03, rev}•Upper layer protocol set to PPP• PPP-encapsulated and HDLC-framed packets exchanged on these link flows

Link Flow {0x04, fwd}

Link Flow {0x08, rev}

Resv (0x06, fwd}QoS for fwd Flow 0x06

Resv (0xa2, rev}QoS for rev Flow 0xa2

Link flows{0x04, fwd} & {0x08, rev}•Upper layer protocol set to ROHC• link flow configured as ROHC channel• Raw ROHC packets exchanged on these link flows• Link flows tied together for purposes of ROHC feedback

AT

Multi Flow Packet Application

10

Decomposing the Interfaces The Access Interface

ANPCF PDSN

Resv (0xff, fwd}

Resv (0xff, rev}

Resv (0x02, fwd}

Resv (0x05, fwd}

Resv (0x03, rev}

Resv (0x06, fwd}

Resv (0xa2, rev}

Flow ID {0xff, fwd}

Flow ID {0xff, rev}

Flow ID {0x02, fwd}

Flow ID {0x05, fwd}

Flow ID {0x03, rev}

Flow ID {0x06, rev}

Flow ID {0xa2, rev}

A8 #0, SO 59 A10 #0, SO 59

A8 #1, SO 64 A10 #1, SO 64

A8 #2, SO 64 A10 #2, SO 64

A8 #3, SO 67 A10 #3, SO 67

Main A10 connection • always carries{0xff, fwd} and {0xff, rev}•Service Option 59

Auxiliary A10 connection •Service Option 64• PPP-encapsulated & HDLC framed traffic

Auxiliary A10 connection •Service Option 67• raw IP or ROHC packets

11

Signaling Interactions Flow Setup Example

1. Establish HRPD Session and default reservation 0xFF

2. A8/A10 Established for main service instance(SO 59)

3. PPP Established

6. Reservations with requested QoSparameters

7. QoS-based Admission

Control

8. IP-flow mapping information conveyedA8/A10 Established – SO 64/67 (if needed)

9. RSVP-like exchange to establish Non-specific TFT for flow at PDSN

5. Subscriber-QoS Profile Transferred

8. Granted QoS parameters provided RLP Established (if needed)

4. Retrieve subscriber-QoSprofile from Home AAA

AT ANPCF PDSN

Admission control is performed based on available radio

resources and subscriber profile received from PDSN

AT initiates establishment of IP flows based on

application needs

Subscriber QoS profile contains user specific

information such as allowed DSCP, SOs

New A8/A10 connections and link flows are established

based by AN based on local resource constraints/policies

TFT’s define packet filters to enable PDSN identify Flow ID of incoming packets

AAA

12

Signaling Interactions Flow Setup Example with Service Based Bearer Control (SBBC) (1 of 3)

1. Establish HRPD Session and default reservation 0xFF

2. A8/A10 Established for main service instance

(SO 59)

3. PPP Established

5. Subscriber-QoS Profile Transferred

4. Retrieve subscriber-QoSprofile from Home AAA

AT ANPDSN PCRF P-CSCF

SIP InviteSIP Invite

183 Progress

183 Progress

6. SIP signaling to initiate call setup

AAA

13

Signaling Interactions Flow Setup Example with Service Based Bearer Control (SBBC) (2 of 3)

AT ANPDSN PCRF P-CSCF

10. Granted QoS parameters provided and link flow Established (if needed)

8. Request for bearer flow based on step 6 with QoS

parameters

9. QoS Flow AdmissionControl based

on Subscriber Profile

11. IP-flow mapping information conveyed. A8/A10 Established

(if needed)

12. TFT Establishment - Flow information included

(Resv)

7. Download session charging and Authorized QoS information

13. Flow informationrequested from PCRF

13. Flow informationretrieved from home PCRF

(if not available locally)

14

18. Remainder SIP signaling to set up the call and establish the bearer

ATPDSN PCRF P-CSCF

Signaling Interactions Flow Setup Example with Service Based Bearer Control (SBBC) (2 of 3)

AN

14. QoS comparison between Granted and

Session QoS

15. TFT Establishment Ack

(ResvConf)

16. Updated Granted QoS conveyed to AN based

on Step 14

17. Updated Granted QoS conveyed to AT

15

IP

PPP

RLP

MAC

HRPDPHY

IP

IP

GRE

PPP

IP

Enet

100BT

100BT

Enet

Applying QoS Treatments on the BearerForward Path

PDSNPCFAN

Internet

Internet

HRPD Air Interface Protocols A9

A8

A11

A10

Relay

GRE

IP

GRE

IP

Enet

100BT

Enet

100BT

Relay

RLP

MAC

HRPDPHY

GRE

IP

Enet

100BT

Packet arrives from the Internet

- PDSN uses packet filters in TFT to identify Flow ID corresponding to packet- PDSN places packet on A10 connection for the Flow ID specified by AN

PDSN marks outer IP header of packet with DSCP based on:- local policy OR- copying inner IP DSCP to outer header OR-using DSCP marking for Flow ID specified by RAN

PCF copies DSCP marking from incoming packet to outgoing packet

AN uses QoS treatment established for Flow ID to forward packet across air interface

16

IP

PPP

RLP

MAC

HRPDPHY

IP

IP

GRE

PPP

IP

Enet

100BT

100BT

Enet

Applying QoS Treatments on the BearerReverse Path

PDSNPCF

AN

Internet

Internet

HRPD Air Interface Protocols A9

A8

A11

A10

Relay

GRE

IP

GRE

IP

Enet

100BT

Enet

100BT

Relay

RLP

MAC

HRPDPHY

GRE

IP

Enet

100BT

Packet arrives from the AT

AN marks outer IP header of packet with DSCP based on:- local policy OR- copying inner IP DSCP to outer header

PCF copies DSCP marking from incoming packet to outgoing packet

AT uses QoS treatment established for Flow ID in reverse direction across the air interface

PDSN forwards packets to the Internet based on DSCP associated with inner IP header

17

Bearer Path Protocol Stacks for Real-time Services

ROHCIP

RLP

MAC

HRPD Phy

RLP

MAC

HRPDPhy

GRE

IP

Enet

100BT

Relay Relay

GRE

IP

GRE

IP

Enet

100BT

Enet

100BT

GRE

IP

Enet

100BT

Enet

100BT

ROHCIP

AT AN PCF PDSN

Header Compression at the PDSN

IP

RLP

MAC

HRPD Phy

GRE

IP

GRE

IP

Enet

100BT

Relay

Enet

100BT

GRE

IP

Enet

100BT

Enet

100BT

IP

AT AN PCF PDSN

Header Compression at the RNC

RLP

MAC

HRPDPhy

GRE

IP

Enet

100BT

IPROHC ROHC

No PPP encapsulation or HDLC-like framing on the bearer path

• No PPP encapsulation or HDLC-like framing on the bearer path

• ROHC compression done at PDSN, AT• Raw ROHC packets exchanged between PDSN and AT

• ROHC compression done at AN, AT• Raw ROHC packets exchanged between AN and AT

18

Facilitating End-to-End QoS

BTS

HRPD RNC

AAA, AN-AAA,

DNS, DHCP

ApplicationServers

OAM

PDSN(FA)

HA

Private IP network

Intranet

Internet

ApplicationServers

ApplicationServers

backhaultransportserviceedgeAT

IPhost

FW/BG

Wireless Operator’s IP QoS Domain

DSDomain

Edge DSDomain

Edge

MMD

IPhost

Application IP QoS

RAN QoSDomain

Edge

Support needed to facilitate end-to-end QoS:

1. Consistent packet treatments•access edge and service provider boundaries

•general packet filtering (DSCP/ToS, IP address, port number)

• traffic conditioning: policing, shaping, marking, dropping

•congestion avoidance•scheduling

2. Admission control - based on local and network conditions

3. Signalling - to convey information regarding network conditions

4. Security - to prevent unauthorized access to network resources

5. OA&M, including policy based management

19

Current QoS Approaches in the Internet> Integrated Services (IntServ)

• QoS requirements for individual IP flows reserved at each hop • explicit signaling protocols (e.g., RSVP) to establish QoS state at

intermediate routers• Scalability issues due to soft state storage requirements• Not widely deployed across the Internet – both in routers and at end hosts

> Differentiated Services (DiffServ)• Per-hop Behaviors (PHBs) defined for multiple flows with similar QoS

characteristics (Behavior Aggregate – BA)• PHBs identified by Differentiated Services Code Points (DSCPs)• QoS tasks distributed across network nodes – enhanced scalability

• complex tasks viz., packet classification, traffic conditioning done at network edge• simple tasks viz., packet forwarding based on per hop behavior (PHB) performed

at network core

• Service Level Agreements (SLAs) established across DiffServ enabled domains

20

Limitations of Current QoS Approaches

> PHBs only define characteristics of the forwarding behaviours

• queuing disciplines (categories of queuing and scheduling algorithms) not defined

> Additional mechanisms needed to ensure that traffic conditions required to provide PHBs are maintained

> Consistent DSCP marking is far from pervasive in the application space

For optimal application and service performance, QoS technologies must be implemented consistently across different networking technologies.

Embodiment of any end to end QoS offering needs to completely define the collection of traffic conditioning rules and IP forwarding mechanisms required for each class

21

Network Service Classes (NSCs)

> A set of Network Service Classes (NSCs) has been defined in draft-ietf-tsvwg-diffserv-service-classes-00 which define:• traffic management• performance management parameters for the most popular applications, including IP telephony, video, messaging,

transaction processing, etc.

> The IP host (client or server) has access to the QoS requirements for resident user applications. • Thus, IP host should mark the DSCP field of the IP packets appropriately

> However, DSCP marking is far from pervasive in the application space• Standardization of draft-ietf-tsvwg-diffserv-service-classes-00 may help

change this situation.

Network Service Classes may provide a means to facilitate End-to-End QoS in 3GPP2 networks

22

Network Service Classes - OverviewService Class Name Application Examples DSCP Name DSCP Value

Network Control Network routing CS6 110000

Telephony IP Telephony bearer (VoIP) EF 101110

Signaling IP Telephony signaling CS5 101000

Multimedia Conferencing

H.323 / V2 video AF41, AF42 100010, 100100

Conferencing (adaptive) AF43 100110

Real-time Interactive Video conferencing & interactive gaming CS4 100000

Multimedia Streaming Streaming video &audio on demand AF31, AF32, AF33 011010, 011100, 011110

Broadcast Video Broadcast TV & live events CS3 011000

Low Latency Data Client / server transactions AF21, AF22 010010, 010100

Web-based ordering AF23 010110

OAM OAM&P CS2 010000

High Throughput Data Store &forward applications AF11, AF12, AF13 001010, 001100, 001110

Standard Undifferentiated applications DF, (CS0) 000000

Low Priority Data Any low that has no BW assurance CS1 001000

Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DS codepoint '000000'.

CS -> Class Selector; DF -> Default Behaviour (e.g. Best Effort); AF -> Assured Forwarding; EF -> Expedited Forwarding;

23

Network Service Classes - Characteristics

Service Class Name Tolerance to Traffic Characteristics Loss Delay Jitter

Network Control Variable size packets, mostly inelastic short messages, but traffic can also burst (BGP)

Low Low Yes

Telephony Fixed size small packets, constant emission rate, inelastic and low rate flows

Very Low Very Low Very Low

Signaling Variable size packets, some what bursty short lived flows

Low Low Yes

Multimedia Conferencing Variable size packets, constant transmit interval, rate adaptive, reacts to loss

Low to Medium

Very Low Low

Real-time Interactive RTP/UDP streams, inelastic, mostly variable rate Low Very Low Low

Multimedia Streaming Variable size packets elastic with variable rate Low to Medium

Yes Medium

Broadcast Video Constant and variable rate, inelastic, non bursty flows Very Low Medium Low

Low Latency Data Variable rate, bursty short lived elastic flows Low Low to Medium

Yes

OAM Variable size packets, elastic & inelastic flows Low Medium Yes

High Throughput Data Variable rate, bursty long lived elastic flows Low to High

Medium Yes

Standard A bit of everything Not Specified

Low Priority Data Non real-time and elastic High High Yes

> IETF TSVWG Draft Configuration Guidelines for DiffServ Service Classes, J. Babiarz, K. Chan, F. Baker, February 11, 2005. draft-ietf-tsvwg-diffserv-service-classes-00

24

NSC IP QoS Support Mechanisms

Service Class Name DSCP Name

Per HopBehavior

Conditioning at the Edge Scheduler/Shaper

Network Control CS6 RFC 2474 none rate based e.g. RFC 2963

Telephony EF RFC 3246 sr+bs (RFC 2697) priority e.g. RFC 2963

Signaling CS5 RFC 2474 sr+bs (RFC 2697) rate based e.g. RFC 2963

Multimedia Conferencing AF4n RFC 2597 trtcm RFC 2698 rate based e.g. RFC 2963

Real-time Interactive CS4 RFC 2474 sr+bs (RFC 2697) rate based e.g. RFC 2963

Multimedia Streaming AF3n RFC 2597 trtcm RFC 2698 rate based e.g. RFC 2963

Broadcast Video CS3 RFC 2474 sr+bs (RFC 2697) rate based e.g. RFC 2963

Low Latency Data AF2n RFC 2597 srtcm RFC 2697 rate based e.g. RFC 2963

OAM CS2 RFC 2474 sr+bs (RFC 2697) rate based e.g. RFC 2963

High Throughput Data AF1n RFC 2597 trtcm RFC 2698 rate based e.g. RFC 2963

Standard DF, (CS0) RFC 2474 not specified rate based e.g. RFC 2963

Low Priority Data CS1 RFC 3662 not specified rate based e.g. RFC 2963

>IETF TSVWG Draft Configuration Guidelines for DiffServ Service Classes, J. Babiarz, K. Chan, F. Baker, February 11, 2005.

>draft-ietf-tsvwg-diffserv-service-classes-00

sr + bs -> single rate + burst size; srtcm -> single rate three color marking; trtcm -> two rate three color marking;

25

If NSCs were to be supported in 3GPP2 Networks...

> Ability to identify NSC corresponding to individual IP Flows needs to be defined

• Need to map QoS Profile IDs into appropriate NSCs

• Need to update “verbose” mode in QoS Blob to include traffic classes based on NSCs

> Consistency needs to be maintained between allowed DSCPs from subscriber QoS profile and DSCPs required by NSCs

> To manage consistent End-to-End QoS behavior, NSC based treatment also needs to be used for packets across the RAN

26

NSC Support needed at cdma2000 Network Nodes

> Forward direction:• PDSN should identify NSC corresponding to incoming packet

based on QoS information received from the RAN

• Prior to metering a flow PDSN may re-mark inner packet headers to NSC recommended DSCPs

• PDSN should mark outer packet header with based on NSC recommended values

> Reverse direction:• AT should use DSCP values recommended for NSC into which

application can be categorized• AN may identify NSC corresponding to flow based on QoS

information signaled apriori (QoS Blob)• AN may mark packet with DSCP corresponding to appropriate NSC

27

Supporting QoS in conjunction with Mobility

> Application level QoS needs to be accounted for during handoffs• Essential to use information requested and granted QoS for application at

source access network to determine resource allocation in target network

> Air-interface QoS for applications needs to adapt to local conditions during handoffs• Granted QoS for application may either be upgraded or downgraded at

target network subject to local radio resource conditions

> Consistent mapping between application QoS requirements and NSCs required across access networks to minimize impact to End-to-End QoS• Network Service Class of application should not change across handoffs• Hence, consistent DSCP markings can be maintained for application across

source and target access networks

28

Conclusions

> Current 3GPP2 architecture to facilitate QoS in cdma2000 access and core networks introduced

> Enhancements needed to existing QoS architecture to support true End-to-End QoS identified

> Nortel’s recommended path to facilitate evolution to end-to-end QoS based on Network Service Classes (NSCs) described