VoLTE Policy Control Summary

In IT and particularly in Telco we are obsessed with abbreviations. My wife always loughs and tries to mimic me when she listens to my calls. Today we should be very careful as many of them start on ‘P’ – PCC, PCRF, PCEF, P-CSCF, PGW, PDN, PDG, PDB, PHB. But no worries, there will be abbreviations starting on other letters as well 🙂

In the IMS we have separated signalling and media data. However a full independence of control and user plane is not desirable. We want to control when the media starts and stops, we want to be sure about media routing, we want to ensure Quality of Service (QoS). And, of course, we want to accordingly charge the users.

In order to achieve these requirements we use two techniques in the VoLTE architecture:

• Policy and Charging Control (PCC)
• Differentiated Services (DiffServ)

Policy and Charging Control

PCC functionality comprises of Policy Control (e.g. QoS, media gating, ..) and Flow Based Charging. The ETSI TS 29.212, 29.213, 29.214 and 29.203 define Policy and Charging Control Architecture. There are many PCC functions defined. For us the main 3 PCC elements are:

• Application Function (AF)
• Policy Charging and Rules Function (PCRF)
• Policy Control Enforcement Function (PCEF)

Policy and Charging Control (PCC) Architecture

Application Function

In VoLTE is the AF incorporated within the Proxy-CSCF. The P-CSCF provides the information related to the control plane signaling. The information is taken from SIP/SDP session setup and it is forwarded to the PCRF via the Rx reference point. Each new SIP message that includes an SDP payload or session events (e.g. session termination, modification) can trigger a new request sent towards the PCRF. This ensures that the PCRF gets the proper information in order to perform reliable PCC.

PCRF

The PCRF povides Policy Control decisions which are enforced by PCEF, and flow based charging control functionalities. Based on the data received over the Rx interface from P-CSCF and operator defined policy rules, the PCRF forms authorized QoS data (e.g. maximum bandwidth or QoS class) and charging rules that sends to the PCEF functionality via the Gx reference point.  The PCRF also provides a feedback about user plane events to the P-CSCF (AF) – for example in case of a bearer loss.

PCEF

This functional entity is located at the Access Gateway (e.g. GGSN in the GPRS case, PGW in the ePC case).  The PCEF provides a control over the user plane traffic handling at the Access Gateway and its QoS, and provides service data flow detection and counting as well as online and offline charging interactions. For a service data which is controlled by the PCC rules the PCEF allows the data flow to pass through the Access Gateway only if the corresponding gate is open.

Similarly in case of online charging, the PCEF allows the service data flow to pass through the Access Gateway only if the Online Charging System (OCS) has authorized the applicable credit.

In VoLTE the PGW supports flow gating, rate limiting, policing, traffic shaping, DiffServ and other features. The control and application of the PCC rules is done on a per-subscriber basis and is dependent on the PCC rules received from the PCRF. The PWG also supports Deep Packet Inspection (DPI), QoS controls, volume-based reporting etc.

We have simplified the PCC matter a lot. It is not easy to understand all the principals and all the subtleties of PCC. Hence in this post we can focus only on a tiny part related to VoLTE basic definition.

Rx, Gx interfaces

The procedure in PCC which allows to associate a service data flow (defined in a PCC and QoS rules), to the IP-CAN bearer, is called binding mechanism.

The binding mechanism includes three steps:

1. Session binding.
2. PCC rule authorization and QoS rule generation, if applicable.
3. Bearer binding.

The TS 23.203 standardizes a set of QoS Class Identifiers (QCI) for different services with the relared QoS parameters defined:

QCI

NOTE 1:    A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is located “close” to the radio base station (roughly 10 ms) and the case where the PCEF is located “far” from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual packet delays – in particular for GBR traffic – should typically be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.

NOTE 2:    The rate of non congestion related packet losses that may occur between a radio base station and a PCEF should be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station.

NOTE 3:    This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate’s uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified.

NOTE 4:    If the network supports Multimedia Priority Services (MPS) then this QCI could be used for the prioritization of non real-time data (i.e. most typically TCP-based services/applications) of MPS subscribers.

NOTE 5:                This QCI could be used for a dedicated “premium bearer” (e.g. associated with premium content) for anysubscriber / subscriber group. Also in this case, the SDF aggregate’s uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for “premium subscribers”.

NOTE 6:    This QCI is typically used for the default bearer of a UE/PDN for non privileged subscribers. Note that AMBR can be used as a “tool” to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer.

NOTE 7:    For Mission Critical services, it may be assumed that the PCEF is located “close” to the radio base station (roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence delay of 10 ms for the delay between a PCEF and a radio base station should be subtracted from this PDB to derive the packet delay budget that applies to the radio interface.

NOTE 8:    In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed (but not to a value greater than 320 ms) for the first packet(s) in a downlink data or signalling burst in order to permit reasonable battery saving (DRX) techniques.

NOTE 9:    It is expected that QCI-65 and QCI-69 are used together to provide Mission Critical Push to Talk service (e.g., QCI-5 is not used for signalling for the bearer that utilizes QCI-65 as user plane bearer). It is expected that the amount of traffic per UE will be similar or less compared to the IMS signalling.

NOTE 10: In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.

NOTE 11: In RRC Idle mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.

NOTE 12:   This QCI value can only be assigned upon request from the network side. The UE and any application running on the UE is not allowed to request this QCI value.

Long reading, isn’t it? Then just remember that VoLTE utilizes QCI=5 for IMS Signalling on the default bearer and QCI=1 for conversational voice on dedicated bearers. Thanks to the PCC (P-CSCF, PCRF, PGW/ePDG, Rx and Gx interfaces) we can, based on the SIP/SDP content, allocate the necessary resources and set-up priorities which are needed for a particular type of communication.

To explain everything related to QCI this post would have hundreds of pages. Simply put the QCI is a value used as a reference to node specific parameters. The parameters define how to control the packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.) and have been pre-configured within the access network (e.g. on eNodeB).

Most of the parameters in the table above are at least a little self-explaining. Just a few words about the Resource Types.

• Guaranteed Bit Rate (GBR) – An IP‑CAN bearer with reserved (guaranteed) bitrate resources.
• Non-Guaranteed Bit Rate (non-GBR) – An IP‑CAN bearer with no reserved (guaranteed) bitrate resources.

The Resource Type determines if dedicated network resources related to a service or bearer level are permanently allocated (e.g. GBR provided by an admission control function in eNB) or not (non-GBR).

Using a Non-GBR QCI it is possible that we will experience congestion related packet drops.  98 percent of the packets that have not been dropped due to congestion should not experience a delay exceeding the QCI’s Packet Delay Budget (PDB).

Using a GBR QCI and sending at a rate smaller than or equal to GBR we can in general assume that congestion related packet drops will not occur, and 98 percent of the packets should not experience a delay exceeding the QCI’s PDB.

Differentiated Services

DiffServ is used to differentiate between different services utilizing the same IP bearer and also to enable IP-routers and other network nodes to handle specific traffic in a differentiated way. DiffServ relies on a mechanism which classifies and marks packets as belonging to a specific class. DiffServ-aware routers implement per-hop behaviors (PHBs). The PHB defines the packet-forwarding properties associated with each class of traffic. Different PHBs can offer, for example, low-loss or low-latency. In our case e.g. for a Mission-Critical communication the network nodes will allocate larger buffers in priority queues.

The class of service is referred to as the DiffServ Code Point (DSCP). The DSCP is widely deployed within the industry, mobile and fixed networks, and forms a basis for base IP-routing network components (i.e. IP switches and routers). The DSCP support is directly a part of IPv4 and IPv6 design.

List of the commonly used DSCP values described in RFC 2475:

Commonly Used DSCP Values

DSCP Value	Decimal Value	Meaning	Drop Probability	Equivalent IP Precedence Value
101 110	46	High Priority Expedited Forwarding (EF)	N/A	101 Critical
000 000	0	Best Effort	N/A	000 – Routine
001 010	10	AF11	Low	001 – Priority
001 100	12	AF12	Medium	001 – Priority
001 110	14	AF13	High	001 – Priority
010 010	18	AF21	Low	010 – Immediate
010 100	20	AF22	Medium	010 – Immediate
010 110	22	AF23	High	010 – Immediate
011 010	26	AF31	Low	011 – Flash
011 100	28	AF32	Medium	011 – Flash
011 110	30	AF33	High	011 – Flash
100 010	34	AF41	Low	100 – Flash Override
100 100	36	AF42	Medium	100 – Flash Override
100 110	38	AF43	High	100 – Flash Override

Mapping between DiffServ and QCI

The QCI and the associated parameters are also linked to the relevant DSCP marking. GSMA PRD IR.34 provides the mapping between the QCI and DiffServ:

	QoS Information				IP transport
QCI	Traffic Class		THP	Signalling indication	Diffserf PHB	DSCP
1	Conversational	N/A		N/A	EF	101110
2
3
4	Streaming	N/A		N/A	AF41	100010
5	Interactive	1		Yes (see note)	AF31	011010
6				No	AF32	011100
7		2		No	AF21	010010
8		3		No	AF11	001010
9	Background	N/A		N/A	BE	000000

The next time we should take a look in more detail on the Rx reference point and the related call flows.

Related posts:

• Rx Interface