2 Nortel Confidential Information
Quality of ServiceThe Key Enabler for Real-Time Services in HRPD Networks
Sanket S. [email protected]
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