Chapter 10 - Quality of Service in the IMS ppt

Chapter 10
Quality of Service in the IMS
The IMS supports several end-to-end QoS models (described in 3GPP TS 23.207 [13]).
Terminals can use link-layer resource reservation protocols (e.g., PDP Context Activation),
RSVP, or DiffServ codes directly. Networks can use DiffServ or RSVP. The most common
model when cellular terminals are involved is to have terminals use link-layer protocols and to
have the GGSN map link-layer resource reservation flows to DiffServ codes in the network.
As mentioned in Chapter 8, the PCC (Policy and Charging Control) architecture includes
QoS control. That is, PCC can be used to enforce QoS-related policy decisions such as how
much bandwidth is allocated to a given session.
10.1 Policy Control and QoS
Section 8.1 describes how the PCC architecture can be used to enforce policies. The PCRF
makes policy decisions based on the information received from the AF. Those decisions are
enforced by the PCEF (which in a cellular network can be located at the GGSN). Policy
decisions can be related to QoS and, thus, the PCC architecture is used to enforce them.
Therefore, the message flows shown in this chapter are a simplified version of those in
Figures 8.2, 8.3, 8.4, and 8.5.
10.2 Instructions to Perform Resource Reservations
Terminals need to be able to map the media streams of a session into resource reservation
flows. A terminal that establishes an audio and a video stream may choose to request a single
reservation flow for both streams or to request two reservation flows, one for video and one
for audio. Requesting a reservation flow may consist of creating a secondary PDP context or
sending RSVP PATH messages, for instance.
The PCC architecture supports instructing terminals on how to perform resource reser-
vations. To do so the P-CSCF (acting as an AF) uses the SRF (Single Reservation Flow)
semantics (specified in RFC 3524 [104]) of the SDP grouping framework. (Note that the
entity making the decision as to how to perform resource reservations is the P-CSCF, not the
PCRF as some readers could have expected given that it is a policy-related decision.)
The SDP grouping framework (specified in RFC 3388 [101]) allows us to group media
streams and to describe the semantics of the group. For example, LS (lip synchronization)
semantics indicate that the play-out of media streams in the group needs to be synchronized.

´ıa- M ar t´ın
The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition
Gonzalo Camarillo and Miguel A. Garc
© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1
272
CHAPTER 10. QUALITY OF SERVICE IN THE IMS
LS semantics are typically used to group an audio and a video stream, as shown in
Figure 10.1. The a=group line carries the semantics o f the group (LS in this case) and
the identifiers of the streams (the a=mid line in the streams).
v=0
o=- 289083124 289083124 IN IP6 1080::8:800:200C:417A
t=0 0
c=IN IP6 1080::8:800:200C:417A
a=group:LS 1 2
m=audio 20000 RTP/AVP 0
a=mid:1
m=video 20002 RTP/AVP 31
a=mid:2
Figure 10.1: Grouping streams using LS semantics
SRF semantics indicate that all the streams in the group should use the same resource
reservation flow. Consequently, the two audio streams of the session description in
Figure 10.2 would use the same PDP context (assuming a GPRS access), while the v ideo
stream would use its own PDP context.
v=0
o=- 289083124 289083124 IN IP6 1080::8:800:200C:417A
t=0 0
c=IN IP6 1080::8:800:200C:417A
a=group:SRF 1 2
a=group:SRF 3
m=audio 20000 RTP/AVP 0

a=mid:1
m=audio 20002 RTP/AVP 0
a=mid:2
m=video 20004 RTP/AVP 31
a=mid:3
Figure 10.2: Grouping streams using SRF semantics
The P-CSCF adds a=mid and a=group:SRF lines to the session descriptions before
relaying them to the terminals (as d escribed in 3GPP TS 24.229 [37]). The terminals use
this information to perform resource reservation. Figures 10.3 and 10.4 illustrate this point.
The P-CSCF may or may not use the mechanism we have just described in this section.
It may happen, therefore, that the SDP that the IMS terminal receives does not contain any
instructions to perform resource reservation. In that case the IMS terminal is free to decide
how to group media streams into reservation flows.
10.2.1 Proxy Modifying Bodies
The mechanism just described assumes that the P-CSCF can both understand and modify
the session descriptions exchanged by the terminals. This implies that terminals can only
use SDP as their session description format and that end-to-end integrity protection or
10.2. INSTRUCTIONS TO PERFORM RESOURCE RESERVATIONS
273
(2) INVITE
SDP with SRF info
(3) PDP Context Activation
P-CSCF
(1) INVITE
SDP
GGSN
Figure 10.3: P-CSCF adds SRF info to an incoming INVITE request
(1) INVITE
SDP
(5) PDP Context Activation

P-CSCF
(2) INVITE
SDP
(3) 183 Session Progress
SDP
(4) 183 Session Progress
SDP with SRF info
GGSN
Figure 10.4: P-CSCF adds SRF info to an incoming 183 response
274
CHAPTER 10. QUALITY OF SERVICE IN THE IMS
encryption mechanisms like S/MIME (described in Section 11.4) are no t allowed in the IMS.
Section 8.1.3 provides further reasons for these restrictions.
The IETF is working on extensions to allow proxy servers to communicate information,
such as resource reservation instructions to user agents without accessing end-to-end bodies
such as session descriptions (see the Internet-Draft “A Framework for Session Initiation
Protocol (SIP) Session Policies” [166]). As mentioned in Section 8.1.3, these extensions will
not be ready for some time. So, we do not expect the IMS to adopt them in the immediate
future.
10.3 Reservations by the Terminals
Terminals use the SRF information received in session descriptions to determine the number
of resource reservation flows that need to be established. When the access network is GPRS,
a resource reservation flow is a PDP co ntext. Let us see how the terminals establish PDP
contexts (this is described in 3GPP TS 24.008 [47]).
A terminal establishes a PDP context to exchange SIP signaling right after performing a
GPRS attach, as shown in Figure 10.5. The information stored by the network regarding this
PDP context includes the terminal’s IP address and the PDP context’s QoS characteristics,
including its traffic class. There exist four traffic classes: best effort, interactive, streaming,
and conversational. The PDP contexts used for SIP signaling are always conversational.
IMS

Terminal
(3) Activate PDP
Context Request
SGSN
(6) Activate PDP
Context Accept
GGSN
(4) Create PDP
Context Request
(5) Create PDP
Context Response
(1) GPRS attach
(2) GPRS attach
Figure 10.5: PDP context activation
IMS terminals establish additional PDP contexts to send and receive media, as shown in
Figure 10.6. The number of additional PDP contexts, referred to as secondary PDP contexts,
depends on the instructions received from the P-CSCF in the form of a=group:SRF lines.
Secondary PDP contexts use the same IP address as the primary PDP context, but may have
different QoS characteristics.
10.4. QOS IN THE NETWORK
275
IMS
Terminal
(1) Activate Secondary
PDP Context Request
SGSN
(4) Activate Secondary
PDP Context Accept
GGSN
(2) Create PDP

Context Request
(3) Create PDP
Context Response
Figure 10.6: Secondary PDP context activation
10.4 QoS in the Network
The GGSN receives traffic from a given terminal over a PDP context, assigns it an appropriate
DSCP (Differentiated Services Codepoint), and sends it out into a DiffServ-enabled network,
as shown in Figure 10.7. In short, the GGSN implements the DiffServ edge function.
PDP Context
DiffServ Network
GGSN
Figure 10.7: Mapping PDP context information to DSCPs by the GGSN
The DSCP that corresponds to a p articular PDP context is typically assigned based on
statically configured rules in the GGSN. Still, when RSVP is used, the GGSN may use the
information carried in RSVP signaling to decide which DSCP to use.