LTE QoS: SDF and EPS Bearer QoS

SUMMARY
This document will describe LTE QoS at service level and at bearer level. First, the concept of
Service Data Flow (SDF) and EPS bearer, traffic flows at these two levels, will be explained,
followed by a description of their relationship. Then, it will explain the concept of QoS at each
level, and cover different types and characteristics of SDF QoS parameters and EPS bearer QoS
parameters. Finally, explanation on how QoS parameters are provisioned to Evolved Packet
System (EPS) entities and applied to user traffic, and how they work in UL and DL traffic will be
given.

Table of Contents
1. Introduction
2. SDF and EPS Bearer
3. QoS Parameters of SDF and EPS Bearer
4. QoS Provisioning and Enforcement
5. An Example for SDF and EPS Bearer QoS
6. Closing

1. Introduction

An LTE service provider should be able to make services with different QoS requirements
available to its users with different subscription levels. So, the service provider needs to be
aware of subscription levels of each user (e.g. premium, best effort, etc.) and requested
service types (e.g. Internet, voice, etc.) in order to assign radio and network resources to
the traffic of each user and manage them properly.

For this reason, the LTE network first classifies user traffic (IP flows) into different SDFs
having different QoS classes based on the type of the service that is being provided through
the SDFs, and then applies different QoS rules to each SDF. Since SDFs are delivered
through EPS bearers in the LTE network, EPS bearer QoS has to be controlled in a way that
SDF QoS is maintained.
In this document, QoS mechanisms for SDFs and EPS bearers are explained as QoS
mechanisms in LTE, and examples showing how they work are provided.
LTE QoS: SDF and EPS Bearer QoS
2. SDF and EPS Bearer
Figure 1 illustrates SDFs and EPS bearers, and their relationship. In an LTE network, user
traffic (IP flows or IP packets) is classified into SDF traffic (hereinafter referred to as “SDF”)
and EPS bearer traffic (hereinafter referred to as “EPS bearer”). An SDF refers to a group of
IP flows associated with a service that a user is using, while an EPS bearer refers to IP flows
of aggregated SDFs that have the same QoS class.

Figure 1. SDFs and EPS Bearers

The SDF and EPS bearer are detected by matching the IP flows against the packet filters
(SDF templates for SDFs or traffic flow templates (TFTs) for EPS bearers). These packet
filters are pre-configured by network operators in accordance with their policy, and each of
them typically consists of 5-tuple (Source IP address, Destination IP address, Source port
number, Destination port number, and Protocol ID).
In other words, in the LTE network, IP flows with the same service characteristics that
match the packet filters of a SDF template are designated a SDF. SDFs that match the
packet filters of a TFT are mapped to an EPS bearer, to be finally delivered to a UE. SDFs
with the same QoS class are delivered, as aggregated, through an EPS bearer, whereas
ones with different QoS class are delivered through different EPS bearers.

SDF
User traffic using different services (or applications) has different QoS class. A SDF is an IP
flow or an aggregation of IP flows of user traffic classified by the type of the service in use.
Different SDFs have different QoS class and hence an SDF serves as a unit by which QoS
rules1 are applied in accordance with Policy and Charging (PCC) procedure in the LTE
network (See “LTE PCC” technical document for detailed PCC procedure). In Figure 1, IP
flows heading to a UE are classified into different SDFs according to their service type by
using the SDF template. Then, appropriate QoS policies (e.g. priority, bandwidth control,
etc.) are applied to these SDFs before they are delivered to the UE. As QoS is provided by
EPS bearers when the SDFs are delivered over the LTE network, each SDF is mapped by the
P-GW to an EPS bearer that satisfies its QoS requirement, and then delivered to the UE.

EPS Bearer
There are two types of EPS bearers: default and dedicated (See [1]). When a UE attaches to
the LTE network, an IP address to be used in a PDN (Packet Data Network) is assigned,
connecting to a PDN2, and a default EPS bearer is established all at the same time. When a
user who has been using a service through a default bearer (e.g. Internet) attempts to use
a service which requires higher QoS that the current default bearer cannot provide (e.g.
VoD), a dedicated bearer is established on demand3. Thus, the dedicated bearer is
established with QoS different from the one already sent in the existing bearer. A UE can be
connected to more than one PDN, which has one mandatory default EPS bearer and none to
many optional EPS bearers. The number of EPS bearers a UE can have cannot exceed 11
(See [1]).

Once the default bearer is established at the initial attach of a UE to the network, the
establishment lasts even while no service is being used and until the UE detaches from the
network. The default bearer is established one per each PDN. When a UE initially attaches to
the network, the network (MME) needs information about how to establish a default bearer,
such as which QoS to use and to which PDN to connect. This information is already
provisioned to an HSS as subscription information. So, the MME can simply download the
subscription information (default APN, EPS subscribed QoS profile, etc.), select a P-GW to
connect a PDN from based on the APN, and activate a default bearer associated to the PDN
based on the subscribed QoS profile.

SDFs and EPS Bearers in Figure 1

Figure 1 shows EPS bearers and SDFs when downlink IP flows are delivered to a UE through
EPS. The IP flows arriving at a P-GW through a PDN are filtered to SDFs by using SDF
templates (kind of packet filters). In the figure, IP flows 1, 2 and 3 are filtered to SDFs 1, 2
and 3, respectively while IP flows 4 and 5 are filtered to SDF 4. Different QoS policies are
applied to each SDF and then the SDFs are mapped to EPS bearers as classified by using
Traffic Flow Template (TFT). SDFs 1 and 2 are mapped to the default bearer and SDFs 3 and
4 are mapped to the dedicated bearer, all destined to the UE. Upon arrival at the UE, the IP
flows are all sent to their destination applications.

Terms relating to EPS bearers and SDFs shown in Figure 1 are listed in Table 1. Out of the
IP Connectivity Access Networks (IP-CANs) covered in 3GPP standards, this document
discusses EPS only. So, all IP-CANs are referred to as EPS herein (e.g. IP-CAN Bearer = EPS
Bearer).
Table 1. Terms relating to SDFs and EPS Bearers

3. QoS Parameters for SDF and EPS Bearer

In Chapter 2, we have learned that user traffic is classified by using packet filters into either
SDFs or EPS bearers, and SDF QoS and EPS bearer QoS are respectively applied to the SDFs
and the EPS bearers. In Chapter III, we will study QoS parameters for SDFs and for EPS
bearers and explain their relationship.

In an LTE network, QoS parameters are defined at service level and at bearer level. SDF
QoS parameters are service-level QoS parameters while EPS bearer QoS parameters are
bearer-level QoS parameters. Service level and bearer level are also called as SDF level and
SDF aggregate level. An SDF aggregate refers to a group of SDFs which have the same QCI
(QoS Class Identifier) and ARP (Allocation and Retention Priority) values and belong to one
EPS session. Both QCI and ARP are the basic QoS parameters applied to all SDFs and EPS
bearers. The QCI is particularly important because it serves as a reference that indicates the
performance characteristics of SDFs and EPS bearers. In addition to these two basic
parameters, there are other QoS parameters, such as GBR, MBR and AMBR that specify the
bandwidth (or bit rate) characteristics of SDFs and EPS bearers. SDF and EPS bearer QoS
parameters are as follows:

 SDF QoS parameters: QCI, ARP, GBR and MBR

 EPS bearer QoS parameters: QCI, ARP, GBR, MBR, APN-AMBR and UE-AMBR

SDF QoS Parameters

QCI and ARP are applied to all SDFs. The QCI, in an integer from 1 to 9, indicates nine
different QoS performance characteristics of each IP packet, such as resource type (GBR or
Non-GBR), priority (1 ~ 9), packet delay budget (50 ms ~ 300 ms), and packet error loss
rate (10-2 ~ 10-6) [2].
Maximum Bit Rate (MBR) and Guaranteed Bit Rate (GBR) are also the SDF QoS parameters,
and they indicate the bandwidths (or bit rates) of SDFs. MBR specifies the maximum bit rate
of an SDF. If the network traffic is not congested, user traffic travelling as SDF can be
delivered at most at the specified MBR. However, GBR is the guaranteed bit rate of an SDF.
This means the SDF is guaranteed with a specified GBR no matter what. So, even when the
network traffic is congested, user traffic travelling as SDF is delivered at least at the
guaranteed GBR.

There are two types of SDFs: GBR SDF and non-GBR SDF. In case of a GBR SDF, dedicated
network resources are assigned according to the resource type specified by its QCI.
However, in case of a non-GBR SDF, dedicated network resources are not assigned (See
Table 3 for comparison between GBR and non-GBR types). A GBR SDF is assigned a GBR
and an MBR, whereas a non- GBR SDF is assigned an MBR only. QoS parameters for these
two SDFs are as follows:

 GBR SDF QoS parameters: QCI, ARP, GBR (UL/DL) and MBR (UL/DL)
 Non-GBR SDF QoS parameters: QCI, ARP and MBR (UL/DL)

A SDF that matches the packets filters of a TFT (DL TFT) is mapped to an EPS bearer in a P-
GW, and delivered to a UE through its mapped EPS bearer. An aggregate of SDFs with the
same QCI and ARP is mapped to one EPS bearer.

EPS Bearer QoS Parameters

QCI and ARP are applied to all EPS bearers. An EPS bearer is classified as a GBR bearer or a
non-GBR bearer depending on the resource type specified by its QCI (See Table 3 for
comparison between GBR and non-GBR types). A default bearer must be non-GBR while a
dedicated bearer can be either GBR or non-GBR.
Other than QCI and ARP, there are other QoS parameters for EPS bearers: MBR and GBR
indicating the bandwidth (or bit rate) of an EPS bearer, and AMBR (Aggregated Maximum
Bit Rate) indicating the total bandwidth of multiple EPS bearers. MBR and GBR are the
maximum and the guaranteed bandwidths of an EPS bearer respectively, and AMBR is the
maximum total bandwidth of multiple EPS bearers.
A GBR EPS bearer is assigned a GBR and an MBR, which means dedicated network
resources are allocated (i.e. a bandwidth in an amount of the specified GBR is guaranteed
and a bandwidth in an amount of the specified MBR is available) to the bearer. However, a
non-GBR EPS bearer is assigned an AMBR, which means dedicated network resources are
not allocated to the bearer, but a maximum bandwidth to share with other non-GBR bearers
is allocated. There are two types of AMBR: APN-AMBR, the maximum bandwidth that can be
shared by all non-GBR bearers in a PDN, and UE-AMBR, the maximum bandwidth that can
be shared in a UE. A UE can be connected to more than one PDN, in which case the total
APN-AMBR of all PDNs cannot exceed the UE-AMBR. QoS parameters for the two types of
EPS bearers are as follows:

 GBR bearer QoS parameters: QCI, ARP, GBR(UL/DL) and MBR(UL/DL)

 Non-GBR bearer QoS parameters: QCI, ARP, APN-AMBR(UL/DL) and UE-AMBR(UL/DL)

SDF and EPS Bearer QoS Parameters

Figure 2 illustrates QoS parameters applied to SDFs and EPS bearers.

Figure 2. QoS Parameters for SDF and EPS Bearer

In Figure 2, the UE is connected to two PDNs. The UE has two IP addresses: IP address 1
assigned by P-GW 1 for use in PDN 1, and IP address 2 assigned by P-GW 2 for use in PDN
2. And it has one default bearer and two dedicated bearers established for each PDN. User
traffic IP flows are filtered into SDFs in the P-GW by using SDF templates. There are two
groups of SDFs 1~5 each received from PDN 1 and PDN 2. For these SDFs, network
resources are allocated and packet forwarding is treated according to the QoS rules set in
the P-GW. And the SDFs are then mapped to EPS bearers based on their specified QCI and
ARP. In case of PDN 1 in the figure, SDFs 1 and 2 are mapped to the default bearer, SDFs 3
and 4 are mapped to the non-GBR dedicated bearer, and SDF 5 is mapped to the GBR
dedicated bearer, all heading to the UE, their final destination. Such traffic mapped from
SDF to EPS bearer is defined by using Traffic Filter Template (TFT). All the user traffic is
subject to the EPS bearer QoS while being delivered through the EPS bearers.
All non-GBR bearers associated with a PDN are controlled by the maximum APN-AMBR they
share while the ones associated with a UE are controlled by the maximum UE-AMBR they
share.
Table 2. QoS Parameters for SDF and EPS Bearer
Table 3. GBR vs. Non-GBR

4. QoS Provisioning and Enforcement

Section 4.1 discusses QoS provisioning that decides by which entity the QoS parameter
values set in EPS entities are provided. And Section 4.2 covers QoS enforcement that
determines to which EPS entities the SDF and EPS bearer QoS parameters defined in
Chapter 3 are set and to which user traffic the parameters are applied.

4.1 QoS Provisioning

Figure 3 shows by which entity the QoS parameters set in EPS entities are provided.

Figure 3. QoS Provisioning

SDF QoS Provisioning

All the QoS parameters for SDFs are provisioned by Policy and Charging Rules Function
(PCRF).
EPS Bearer QoS Provisioning
QoS parameters applied to a default bearer are provisioned to an HSS as subscription
information by a network operator. And then, when the default bearer is activated, an MME
downloads the QoS profile for the bearer from the HSS and sends it to EPS entities
appropriately. QoS parameters for the default bearer provided by the HSS can be modified
when QoS rules are authorized by PDRF upon creation of an EPS session. UE-AMBR
controlled by an eNB is provided by the HSS, but can be modified by the MME. In such case,
the MME can replace the existing UE-AMBR with the aggregated APN-AMBR of all active
PDNs, to the extent that the new value does not exceed the value provided by the HSS, UE-
AMBRHSS.

QoS parameters applied to a dedicated bearer are provisioned by PCRF. The PCRF
determines QoS parameters for the bearer based on the subscription information it received
from Subscriber Profile Repository (SPR) when the bearer is activated.

4.2 QoS Enforcement

During QoS enforcement, detection of user traffic (IP flows i.e., SDF and EPS bearer) is
performed and then QoS rules are applied to each of the detected SDFs and EPS bearers
accordingly.
Figure 4 is an illustration showing to which EPS entities the SDF and EPS bearer QoS
parameters are set and enforced. EPS bearer QoS parameters enforced to an S-GW are
same as in a P-GW except for APN-AMBR. However, only QCIs are displayed in this figure
for illustrative purposes.

Figure 4. QoS Enforcement

SDF QoS Enforcement

SDF QoS parameters (i.e. QCI, ARP, MBR and GBR) are installed in a P-GW. Table 4 shows
to which EPS entity the SDF QoS parameters are enforced. IP flows arriving at a P-GW are
filtered into different SDFs by using SDF templates, then these SDFs are controlled by SDF
QoS parameters installed in the P-GW.
Table 4. SDF QoS Enforcement

EPS Bearer QoS Enforcement

QoS parameters for EPS bearers are enforced in EPS entities (UE, eNB, S-GW and P-GW)
that deliver user traffic between UE and P-GW. Table 5 illustrates to which EPS entity each
of the QoS parameters is enforced.
APN-AMBR is applied to all the non-GBR EPS bearers activated in a PDN, by UE and P-GW,
the two endpoints of the bearers. The APN-AMBR is applied only for UL traffic in a UE, but
for both UL and DL traffic in a P-GW. Whereas UE-AMBR is applied to all the non-GBR EPS
bearers activated in a UE, by eNB from which all PDN traffic is sent. That is, APN-AMBR is
applied only to the PDN identified by its associated APN, while UE-AMBR is applied to a UE,
and thus to all PDNs associated with the UE.
MBR is applied only to GBR bearers, and only for UL traffic in a UE and an eNB, but only for
DL traffic in an S-Gw and a P-GW. GBR is also applied only to GBR EPS bearers and for UL
and DL traffic in all entities except for a UE.

Table 5. EPS Bearer QoS Enforcement

5. An Example for SDF and EPS Bearer QoS

In Chapter V, LTE QoS examples are provided based on the concept of the SDF and EPS
bearer QoS discussed in Chapters II and III. Through the examples, a description of how
the SDF QoS and EPS bearer QoS mechanisms work and what they do in each EPS entity
will be given. The scenario used for the purposes of this chapter is as follows:

 UE connected to one PDN (Internet)

 UE communicating with the Internet through three bearers, i.e. one default bearer,
one non-GBR dedicated bearer, and one GBR dedicated bearer.
 Their bearer IDs (EPS bearer ID (EBI)) are 5, 8 and 10, respectively.

5.1 QoS Operation in Downlink

Figure 5 shows an example of LTE QoS operation in DL. Their operation in each entity,
mainly in UE, eNB and P-GW, is described in details below. The traffic control applicable
herein includes traffic policing and shaping. Figure 5 and Figure 6 show examples of
applying traffic policing.

Figure 5. An Example for LTE QoS (Downlink)

❶ [P-GW] DL IP Flows Arrival

IP flows arrived at a P-GW. The flows 1 ~5 are voice data (RTP), video streaming, voice
signaling (SIP), two-way game, and best effort type Internet traffic, respectively.

❷ [P-GW] IP Packet Filtering (SDF Templates)

Upon arrival at the P-GW, the IP flows are filtered through IP packet filters (SDF
templates) into different SDFs. Here, 5-tuple (Source IP address, Destination IP
 address, Source port number, Destination port number, Protocol ID) values are used as
filtering rules for this purpose. IP flow 1 is classified as GBR SDF 1, IP flow 2 is
classified as GBR SDF 2, IP flows 3 and 4 are classified as non-GBR SDF 3, and IP flow
5 is classified as non-GBR SDF 4.

❸ [P-GW] SDF QoS Enforcement: MBR Rate Policing

MBR rate policing is performed against each SDF, and any traffic exceeding the
specified DL MBR is discarded.

❹ [P-GW] SDF – EPS Bearer Mapping: IP Packet Filtering (Traffic Flow Templates; TFT)
SDFs are filtered by using IP packet filters (TFT) into different EPS bearers. SDF 1 and
SDF 2 are mapped to the GBR dedicated bearer (EBI=10), SDF 3 is mapped to the non-
GBR dedicated bearer (EBI=8), and finally SDF 4 is mapped to the non-GBR default
bearer (EBI=5).

❺ [P-GW] EPS Bearer QoS Enforcement: MBR/APN-AMBR Rate Policing

EPS bearer QoS is applied to each bearer. For GBR bearers, MBR rate policing is
performed using DL MBR value, and any IP packets exceeding the specified DL MBR are
discarded. For non-GBR bearers, APN-AMBR rate policing is performed. That is, for all
the IP flows heading to EBI 8 and EBI 5, rate policing with is performed and any IP
packets exceeding the specified DL APN-AMBR are discarded.

❻ [eNB] EPS Bearer QoS Enforcement: UE-AMBR Scheduling

The eNB performs UE-AMBR rate policing against the non-GBR bearers and also
scheduling over radio link. That is, for all the IP flows heading to EBI 8 and EBI 5, DL
UE-AMBR rate policing is performed. In Figure 5, because there is one PDN, DL UE-
AMBR has the same value as DL APN-AMBR.

5.2 QoS Operation in Uplink

Figure 6 shows an example of LTE QoS operation in UL. Unlike in DL, controlling of MBR and
APN-AMBR is performed both in the UE and the P-GW.
 Figure 6. An Example for LTE QoS (Uplink)

❶ [UE] UL IP Flows Arrival

IP flows from user applications arrive at a UE. Here, the applications are the same as in
DL.

❷ [UE] IP Packet Filtering (TFT)

IP flows in UL are filtered by using IP packet filters (TFT) into EPS bearers
appropriately. A 5-tuple in IP and TCP/UDP headers is used as the filtering rule for this
purpose. IP flows 1 and 2 are mapped to the GBR dedicated bearer (EBI=10), IP flows
3 and 4 are mapped to the non-GBR dedicated bearer (EBI=8), and finally IP flow 5 is
mapped to the default bearer (EBI=5).

❸ [UE] EPS Bearer QoS Enforcement: MBR/APN-AMBR Rate Policing

EPS bearer QoS is applied to each EPS bearer. For the IP flows to the GBR dedicated
bearer (EBI=10), rate policing is performed using UL MBR, and for all the IP flows to
the non-GBR dedicated bearers (EBI=8 and EBI=5), rate policing is performed using UL
APN-AMBR.

❹ [eNB] EPS Bearer QoS Enforcement: MBR/UE-AMBR Rate Policing

The eNB performs rate policing/scheduling using UL MBR for the GBR bearer (EBI=10),
and rate policing/scheduling using UL UE-AMBR for non-GBR bearers (EBI=8 and
EBI=5). Because there is one PDN, UL UE-AMBR has the same value as UL APN-AMBR.

❺ [P-GW] Bearer Traffic Arrival

Bearer traffic arrives at a P-GW through a S-GW.
❻ [P-GW] EPS Bearer QoS Enforcement: APN-AMBR Rate Policing
APN-AMBR rate policing is performed against all IP flows received through non-GBR
bearers (EBI=8 and EBI=5), and any IP packets exceeding the specified UL APN-AMBR
are discarded.

❼ [P-GW] IP Packet Filtering (SDF Templates)

EPS bearers are filtered through IP packet filters (SDF templates) into different SDFs.
IP flows 1 and 2 from the GBR dedicated bearer (EBI=10) are mapped to SDFs 1 and 2,
IP flows 3 and 4 from non-GBR dedicated bearer (EBI=8) are mapped to SDFs 3 and 4,
and finally IP flows 5 from the default bearer (EBI=5) is mapped to SDF 5.

❽ [P-GW] SDF QoS Enforcement: MBR Rate Policing

MBR rate policing is performed against each SDF), and any IP packets exceeding the
specified UL MBR are discarded.

6. Closing
We have studied LTE QoS mechanisms at service level and at bearer level. We have learned
that user IP traffic flows at service level are classified into SDFs, to which different QoS
classes are defined, and that user IP traffic flows at bearer level are classified into EPS
bearers, each of which is an aggregation of SDFs with the same QoS class (QCI and ARP).
We discussed the relationship between SDFs and EPS bearers and the way they are mapped
to each other.

MAC layer in an eNB assigns radio resources to UEs and performs packet scheduling based
on their EPS bearer QoS parameters. eNB packet scheduling was not covered in this
document. Detailed procedure of deciding and authorizing QoS parameter values will be
later described in the “LTE PCC” technical document.

LTE AMBR
What does this have to do with LTE? Well, amber isn’t really a gemstone, it is a fossilized
tree resin. That means it takes a long time (like 10s of millions of years in time) for it to
become amber. That amount of time sounds like Long Term Evolution to me!

Back to LTE AMBER...this AMBER doesn’t take as long to explain and define so no evolution
required. So we can remove the “e” (for evolution), and it is just AMBR or more commonly
known as Aggregate Maximum Bit Rate.
As LTE becomes more popular and the number of LTE users increase, there has to be some
way to control the bandwidth allowed to individual users. That’s where AMBR comes in. The
majority of LTE services right now are still “best effort”, a lot faster best effort than 3G but
still best effort. AMBR defines the maximum possible bit rate allowed for a particular LTE
user for all of their best effort (or non-guaranteed bit rate) services so they can’t hog all the
available bandwidth from the other LTE users. AMBR values are not used for any services
that are guaranteed bit rate services.

There are 3 AMBR values used in LTE:

Subscribed UE-AMBR

This is the maximum possible bit rate configured by the LTE operator for a particular LTE
user for all of their best effort services. The key word here is “possible”. This is the
maximum possible if bandwidth is available and also dependent on what and how many
services the user is using. It is a configured value by the LTE operator and does not change.
(unless the user changes their services or stops paying their wireless bill!)

Subscribed APN-AMBR

This is the maximum possible bit rate configured by the LTE operator for a particular LTE
user for all of their best effort services on one particular Packet Data Network (as defined by
the APN). Again, the key word here is “possible”. This is the maximum possible if
bandwidth is available. This value should never be larger than Subscribed UE-AMBR value.
An LTE user will have one Subscribed APN-AMBR value for each APN that they subscribe to
for services.

And the third AMBR of interest is Used UE-AMBR.

Used UE-AMBR is the calculated UE-AMBR value that will be used to define the current
working value for UE-AMBR for the active LTE user. In other words, this is the actual UE-
AMBR value in effect for an active LTE user based on how many PDN connections (or APNs)
they are actually using. It is calculated by summing together the Subscribed APN-AMBR
values for all of the active PDN connections of the LTE user. The total value cannot exceed
the Subscribed UE-AMBR value. This value is recalculated each time the LTE user starts
another service (connects to another APN) or disconnects from a service (the UE actually
disconnects from the PDN; the LTE user closing an internet web browser window does not
disconnect a connection to an APN).

All of the AMBR values each have separate uplink and downlink values that can be different
to reflect the different bandwidth needs in both directions.

Let’s look at an example:

Chris is lucky enough to have his LTE service provided by RTWI*. Chris has a Subscribed
UE-AMBR value of 44 Mbps. He subscribes to Internet service (APN
NETRAYSM with Subscribed APN-AMBR = 18 Mbps), Streaming Video service (APN
STREAMRAYSM with APN-AMBR=30 Mbps) and Weather reporting service (APN
STORMRAYSM with Subscribed APN-AMBR = 1 Mbps). All of these services are non-
guaranteed bit rate services.
Early in the morning, Chris logs in to his NETRAYSM Internet service to check on his favorite
blog site LTEUniversity.com. His smartphone makes a connection to the NETRAYSM packet
data network. His smartphone is connected to only one APN.

Chris’ Used UE-AMBR = 18 Mbps (Subscribed APN-AMBR for APN NETRAYSM)

Chris looks outside and sees storm clouds and wants to check the weather. He logs in to his
STORMRAYSM service to check the weather, so his smartphone makes a connection to the
STORMRAYSM packet data network. Now that Chris has connected to a second APN, his Used
UE-AMBR value will be recalculated.

Chris’ new calculated Used UE-AMBR = 19 Mbps.

18 Mbps (Subscribed APN-AMBR for APN NETRAYSM) + 1 Mbps (Subscribed APN-AMBR for
APN STORMRAYSM).

Chris lives in Texas. The weather reporting service indicates that a tornado is imminent. He
is scared to drive in to work. So he stays home to watch a video. He logs in to his
STREAMRAYSM video service to watch videos all day long at home. In this case, his
smartphone makes a connection to the STREAMRAYSM APN.

His smartphone now has 3 APN connections. His new calculated Used UE-AMBR value is now
the sum of the Subscribed APN-AMBR values for all of the 3 APN connections.

18 Mbps (Subscribed APN-AMBR for APN NETRAYSM) + 1 Mbps (Subscribed APN-AMBR for
APN STORMRAYSM) + 30 Mbps (Subscribed APN-AMBR for APN STREAMRAYSM) = 49
Mbps. But the Used UE-AMBR cannot be greater than his Subscribed UE-AMBR. So Chris’
new calculated Used UE-AMBR value is 44 Mbps (equal to his Subscribed UE-AMBRvalue)
when connected to all 3 APNs that Chris is subscribed to.

Since Chris is taking a break, we’ll take a break also and return in a later blog with the
conclusion of this discussion when we will explain where these values are used in the LTE
network.

Ray

*RayTel Wireless Inc.

For information on all of RayTel’s service plans and state-of-the-art smartphones, send cash
(preferably large bills) and I’ll respond with information about RayTel’s possible high speed
data services.

Last time we talked about the 3 AMBR values: Subscribed UE-AMBR, Subscribed APN-
AMBR and Used UE-AMBR.

Where and how are they used?

The two subscribed values are stored in the LTE user’s subscriber profile in the Home
Subscriber Server (HSS). The LTE user has one Subscribed UE-AMBR value and has one
Subscribed APN-AMBR for each APN that they can connect to. Each of the AMBR values has
a separate value for uplink and downlink. For simplicity of the discussion here, we won’t
distinguish between uplink and downlink since the concepts are the same.

These values will be provided to the Mobility Management Entity (MME) when the LTE
smartphone attaches to the LTE network. The MME will use these values when it creates the
traffic bearers to carry the LTE user’s IP data packets.

When a LTE user connects to an APN, the APN-AMBR value will be provided to both the LTE
user’s smartphone and the P-GW. The calculated Used UE-AMBR value will be generated at
the MME whenever the LTE user connects to a new APN or disconnects from an APN. The
Used UE-AMBR value will be provided to the eNB that the UE is currently connected to.

Here is a picture illustrating the Subscribed AMBR values for Chris and two of the APNs that
he is subscribed to. All of the subscribed AMBR values are in Chris’ subscription profile
stored at the HSS. All of Chris’ services are non-guaranteed bit rate services. In this case,
Chris is sleeping and his smartphone is powered off.

Figure 1. Chris’ smartphone not attached to the LTE network

After Chris wakes up, he powers on his smartphone, it attaches to the LTE network and all
of the subscribed AMBR values are provided to the MME. (See figure below) The smartphone
also connects automatically to the NETRAYSM APN so Chris can surf the Internet. When this
connection occurs, the MME sends the NETRAYSM Subscribed APN-AMBR value to both the
P-GW and the smartphone. It also calculates the Used UE-AMBR value and provides that to
the eNB.
Figure 2. Chris’ smartphone attaches to LTE network and connects to Internet service

The eNB will use the Used UE-AMBR value to limit the maximum data rate in both the UL
and DL directions for all of Chris’ non-guaranteed bit rate services on the airlink. In this
case, his Internet service is a non-guaranteed bit rate service.

The P-GW will use the NETRAYSM Subscribed APN-AMBR value to limit the IP data traffic to a
maximum rate of 18 Mbps in and out of the LTE network for Chris’ connection to the
NETRAYSM PDN. The smartphone will use the APN-AMBR value to allocate UL airlink
resources at the appropriate amount to each APN connection. In this case, Chris has only
one APN connection so all UL data traffic resources will be assigned to the NETRAY SM APN
traffic path.

Chris decides to stay home and watch a video using his LTE service. (See figure below) He
selects Video service on his smartphone and the smartphone will initiate a connection to the
STREAMRAYSM APN to access video services. The MME will send the STREAMRAY SM Subscribed
APN-AMBR value to both the P-GW and the smartphone, and send an updated Used UE-
AMBR value to the eNB.
Figure 3. Chris’ smartphone connects to Video service and still has Internet service
connection

The eNB will use the updated Used UE-AMBR value to limit the maximum data rate in both
the UL and DL directions for all of Chris’ non-guaranteed bit rate services on the airlink. In
this case, the maximum combined data rate for both the Internet and Video connections will
be limited to a maximum rate of 44 Mbps in both directions.

The P-GW will use the STREAMRAYSM Subscribed APN-AMBR value to limit the video IP data
packets to a maximum rate of 30 Mbps in and out of the LTE network for Chris’ connection
to the STREAMRAYSM PDN. The smartphone will use both the STREAMRAYSM Subscribed APN-
AMBR value and the NETRAYSM Subscribed APN-AMBR value to allocate UL airlink resources
(allocated by the eNB) at the appropriate amount to each APN connection. Other QoS
parameters (not discussed in this blog article) are also used to make this allocation using a
standards-defined algorithm.

Thus ends our story about LTE AMBRs and Chris’ day off at home watching videos

LTE QoS - EPS Bearers

QoS functions provided by any network, whether wired or wireless, are all based on
standards (IETF RFC, IEEE 802, 3GPP TS, etc.). They may work differently using different
standards depending on whether the network is wired (Ethernet/IP/MPLS) or wireless
(LTE/WiBro/Wi-Fi). But, basically what the QoS is about is that traffic quality is guaranteed
(i) if you pay more, or (ii) for high-priority traffic (e.g. voice or video traffic that is more
sensitive to delay in its nature than Internet traffic).

Practically, (i) does not sound very likely because no network operator offers a service plan
that guarantees certain level of QoS to those who pay more. But, (ii) sounds like a more
practical and sensible reason for most network operators to have QoS functions. In a wired
network, the most common usage of QoS would be for VoIP or IPTV services. I've been
using KT IPTV. KT provides a higher QoS level for its IPTV (Live & VoD) traffic than for its
Internet traffic (with differentiated treatment, e.g. 802.1p for L2, DSCP for IP, and EXP field
of MPLS header for MPLS), guaranteeing the quality of the IPTV traffic even when there is
very high Internet traffic. So, I can watch PSY dancing without any service interruption,
which makes me a very satisfied subscriber of KT.

Now, we will look into QoS in LTE, a wireless network. We will go over the basic features of
the LTE QoS only this time, and will revisit it for a more in-depth description in the later
posts.

As you may recall, when a UE attaches to an LTE network, an EPS bearer connecting from
the UE to a PGW (UE - eNB - S-GW - P-GW) is created as a combination of one logical
channel and two GTP tunnels. Each UE can have more than one EPS bearer depending on
the services in use (e.g. three if using Internet, IPTV and VoIP. The number of bearers will
be determined according to the policy of the network operator.). There are two types of EPS
bearers, default and dedicated, depending on when they are created.

Default EPS Bearer

When a UE attaches to an LTE network, at least one EPS bearer has to be created. This EPS
bearer is called the "default EPS bearer", and remains activated until the UE detaches from
the network.
The QoS of the default EPS bearer is Non-Guaranteed Bit Rate (Non-GBR), which means
support of best effort (no guaranteed quality) delivery.

Dedicated EPS Bearer

Additional EPS bearers that may be created after the default one are called "dedicated EPS
bearers". Generally, Internet and voice services are separately provided through two
different PDNs. However, we will use an example of using one PDN for both services here.
When a UE attaches to an LTE network, only a default EPS bearer for Internet service is
created. Later when the UE attempts to use a voice (VoIP) service, a higher QoS level than
the Internet service is required. Since the default EPS bearer set for the Internet service
cannot meet the QoS level required for the voice service, a dedicated EPS bearer for voice
service can be created on demand.
The dedicated EPS bearers can be either GBR or Non-GBR. If for the voice service as in the
foregoing example, it has to be GBR for guaranteed QoS.
An EPS bearer is a pipe (delivery path) connecting from a UE to a P-GW. Through this pipe
(i.e. EPS bearer), various types of traffic classified by 5-tuple are delivered. These types of
traffic are called IP flows, and each IP flow is classified by the 5-tuple (Source IP,
Destination IP, Protocol ID, Source Port, and Destination Port). For example, when a UE
connects to Google, it would have a 5-tuple, which would be defined as IP flow, as follows:
Source IP = UE IP address
Destination IP = Google server IP address
Protocol ID = 6 (refers to TCP)
Source Port = Random number (Ephemeral port number)
Destination Port = 80 (refers to WWW)

IP Flow and Service Data Flow (SDF)

So, depending on how many applications/services a UE is using (or depending on the

incoming and outgoing traffic), there can be quite a lot of IP flows (e.g., Google, Yahoo,
chatting, games, VoIP, YouTube, etc.). These IP flows are mapped to Service Data Flow
(SDF) by the classifier based on 5-tuple in a P-GW. The classifier is called as ACL in
conventional IP router, and as SDF Template in LTE. Once they are mapped to SDF, the P-
GW processes QoS at SDF level (Detailed QoS process will be discussed next time) so that
the SDF can be mapped to the EPS bearer and delivered to the UE.

Once the P-GW processes QoS at SDF level and has each SDF mapped to the EPS bearer, it
processes QoS at EPS bearer level from the P-GW to the UE where SDF remains
undisclosed.

We will look a little bit further into LTE QoS that we discussed last time, and learn what QoS
parameters are for.
There are two types of EPS bearers: default and dedicated. In the LTE network, the EPS
bearer QoS is controlled using the following LTE QoS parameters:

▶ Resource Type: GBR or Non-GBR

▶ QoS Parameters
QCI
ARP
GBR
MBR
APN-AMBR
UE-AMBR
Every EPS bearer must have QCI and ARP defined. The QCI is particularly important
because it serves as reference in determining QoS level for each EPS bearer. In case of
bandwidth (bit rate), GBR and MBR are defined only in GBR type EPS bearers, whereas
AMBR (APN-AMBR and UE-AMBR) is defined only in Non-GBR type EPS bearers.

Below, we will explain the LTE QoS parameters one by one.

Resource Type = GBR (Guaranteed Bit Rate)

For an EPS bearer, having a GBR resource type means the bandwidth of the bearer is
guaranteed. Obviously, a GBR type EPS bearer has a "guaranteed bit rate" associated (GBR
will be further explained below) as one of its QoS parameters. Only a dedicated EPS bearer
can be a GBR type bearer and no default EPS bearer can be GBR type. The QCI of a GBR
type EPS bearer can range from 1 to 4.

Resource Type = Non-GBR

For an EPS bearer, having a non-GBR resource type means that the bearer is a best effort
type bearer and its bandwidth is not guaranteed. A default EPS bearer is always a Non-GBR
bearer, whereas a dedicated EPS bearer can be either GBR or non-GBR. The QCI of a non-
GBR type EPS bearer can range from 5 to 9.

QCI (QoS Class Identifier)

QCI, in an integer from 1 to 9, indicates nine different QoS performance characteristics of

each IP packet. QCI values are standardized to reference specific QoS characteristics, and
each QCI contains standardized performance characteristics (values), such as resource type
(GBR or non-GBR), priority (1~9), Packet Delay Budget (allowed packet delay shown in
values ranging from 50 ms to 300 ms), Packet Error Loss Rate (allowed packet loss shown
in values from 10-2 to 10-6. For more specific values, search on Google for "3GPP TS
23.203" and see Table 6.1.7 in the document. For example, QCI 1 and 9 are defined as
follows:

QCI = 1
: Resource Type = GBR, Priority = 2, Packet Delay Budget = 100ms, Packet Error Loss Rate
= 10-2 , Example Service = Voice
QCI = 9
: Resource Type = Non-GBR, Priority = 9, Packet Delay Budget = 300ms, Packet Error Loss
Rate = 10-6, Example Service = Internet

QoS to be guaranteed for an EPS bearer or SDF varies depending on the QCI values
specified.
QCI, though a single integer, represents node-specific parameters that give the details of
how an LTE node handles packet forwarding (e.g. scheduling weights, admission thresholds,
queue thresholds, link layer protocol configuration, etc). Network operators have their LTE
nodes pre-configured to handle packet forwarding according to the QCI value.

By pre-defining the performance characteristics of each QCI value and having them
standardized, the network operators can ensure the same minimum level QoS required by
the LTE standards is provided to different services/applications used in an LTE network
consisting of various nodes from multi-vendors.

QCI values seem to be mostly used by eNBs in controlling the priority of packets delivered
over radio links. That's because practically it is not easy for S-GW or P-GW, in a wired link,
to process packets and also forward them based on the QCI characteristics all at the same
time (As you may know, a Cisco or Juniper router would not care about delay or error loss
rate when it processes QoS of packets. It would merely decide which packet to send first
through scheduling (WFQ, DWRR, SPQ, etc.) based on the priority of the packets
(802.1p/DSCP/MPLS EXP)).

ARP (Allocation and Retention Priority)

When a new EPS bearer is needed in an LTE network with insufficient resources, an LTE
entity (e.g. P-GW, S-GW or eNB) decides, based on ARP (an integer ranging from 1 to 15,
with 1 being the highest level of priority), whether to:
remove the existing EPS bearer and create a new one (e.g. removing an EPS bearer with
low priority ARP to create one with high priority ARP); or
refuse to create a new one.
So, the ARP is considered only when deciding whether to create a new EPS bearer or not.
Once a new bearer is created and packets are delivered through it, the ARP does not affect
the priority of the delivered packet, and thus the network node/entity forwards the packets
regardless of their ARP values.
One of the most representative examples of using the ARP is an emergency VoIP call. So,
an existing EPS bearer can be removed if a new one is required for a emergency 119 (911
in US, 112 in EC, etc) VoIP call.

GBR (UL/DL)

This parameter is used for a GBR type bearer, and indicates the bandwidth (bit rate) to be
guaranteed by the LTE network. It is not applied to a non-GBR bearer with no guaranteed
bandwidth (UL is for uplink traffic and DL is for downlink traffic).

MBR (UL/DL)

MBR is used for a GBR type bearer, and indicates the maximum bit rate allowed in the LTE
network. Any packets arriving at the bearer after the specified MBR is exceeded will be
discarded.

APN-AMBR (UL/DL)

As you read the foregoing paragraph, you may wonder why a non-GBR type bearer does not
have a "bandwidth limit"? In case of non-GBR bearers, it is the total bandwidth of all the
non-GBR EPS bearers in a PDN that is limited, not the individual bandwidth of each bearer.
And this restriction is controlled by APN-AMBR (UL/DL). As seen in the figure above, there
are two non-GBR EPS bearers, and their maximum bandwidths are specified by the APN-
AMBR (UL/DL). This parameter is applied at UE (for UL traffic only) and P-GW (for both DL
and UL traffic).

UE-AMBR (UL/DL)

In the figure above, APN-AMBR and UE-AMBR look the same. But, please take a look at the
one below.
A UE can be connected to more than one PDN (e.g. PDN 1 for Internet, PDN 2 for VoIP using
IMS, etc.) and it has one unique IP address for each of its all PDN connections. Here, UE-
AMBR (UL/DL) indicates the maximum bandwidth allowed for all the non-GBR EPS bearers
associated to the UE no matter how many PDN connections the UE has. Other PDNs are
connected through other P-GWs, this parameter is applied by eNBs only.

Inter-Cell Interference Coordination (ICIC)

As mobile communication technology has evolved dramatically, from LTE (10 MHz) to LTE-A
(10+10 MHz), and then to wideband LTE (20 MHz), South Korea's mobile market is hotter
than ever with its big 3 operators competing fiercely in speed and quality (see Netmanias
Report, LTE in Korea UPDATE - May 1, 2014). Operators can offer different maximum
speeds depending on how wide frequency bandwidths they can actually use. All three, with
pretty much same amount of LTE frequency bandwidths obtained, practically support the
same maximum speeds.

However, these theoretical maximum speeds are not available to users in real life. What
users experience, i.e., Quality of Experience (QoE) is affected by various factors, and so the
actual QoE is far from the maximum speeds. One of the biggest factors that causes such
quality degradation is Inter-cell Interference.

In 2G/3G networks, it was base station controllers, i.e., upper nodes of base stations, that
control inter-cell interference. In 4G networks like LTE/LTE-A, however, inter-cell
interference can be controlled through coordination among base stations. This was made
possible because now LTE networks have X2 interfaces defined between base stations. By
exchanging interference information over these X2 interfaces, base stations now can
schedule radio resources in a way that avoids inter-cell interference.1
There are several Interference Coordination technologies in LTE and LTE-A:

 LTE: Inter-Cell Interference Coordination (ICIC)

 LTE-A: Enhanced ICIC (eICIC) which is an adjusted version of ICIC for HetNet, and
Coordinated Multi-Point (CoMP) which uses Channel Status Information (CSI) reported
by UE

In this and next few posts, we will learn more about these Interference Coordination
technologies. First, let's find out ICIC, the most basic interference coordination
technology.

Inter-Cell Interference Coordination (ICIC)

What causes inter-cell interference?
The biggest cause of lower mobile network capacity is interference. Interference is caused
when users in different neighbor cells attempt to use the same resource at the same time.
Suppose there are two cells that use the same frequency channel (F, e.g., 10MHz at 1.8GHz
band), and each cell has a UE that uses the same frequency resource 2 (fi, fi∈F). As seen in
the figure below, if the two UEs are located in cell centers like A2 and B2, no interference is
caused because they use low power to communicate. However, if they are at cell edges like
A1 and B1, their signals cause interference for each other because the two use high power
to communicate.

Interference is caused because cells only know what radio resources their own UEs are
using, and not what other UEs in the neighbor cells are using. For example, in the figure
above, Cell A knows what resources A1 is using, but not about what B1 is using, and vice
versa. And the cells independently schedule radio resources for their own UEs. So, to the
UEs at cell edges (A1 in Cell A and B1 in Cell B), same frequency resource can be allocated.
ICIC Concept
ICIC is defined in 3GPP release 8 as an interference coordination technology used in LTE
systems. It reduces inter-cell interference by having UEs, at the same cell edge but
belonging to different cells, use different frequency resources. Base stations that support
this feature can generate interference information for each frequency resource (RB), and
exchange the information with neighbor base stations through X2 messages. Then, from the
messages, the neighbor stations can learn the interference status of their neighbors, and
allocate radio resources (frequency, Tx power, etc.) to their UEs in a way that would avoid
inter-cell interference.

For instance, let's say a UE belonging to Cell A is using high Tx power on frequency resouce
(f3) at the cell edge. With ICIC, Cell B then allocates a different frequency resource (f2) to
its UE at the cell edge, and f3 to its other UE at the cell center, having the one at the center
use low Tx power in communicating.

Interference Information used in ICIC

Basic ICIC Behavior

eICIC (enhanced ICIC)

Enhanced Inter-Cell Interference Coordination (eICIC)
As noted in the previous post about ICIC, we will find out about enhanced Inter-Cell
Interference Coordination (eICIC), an interference control technology in LTE-A in this
post. In LTE/LTE-A, one key challenge for operators is that they have to increase network
capacity to keep up with fast-growing traffic. Especially, crowded areas in metropolitan
cities have hotspots with extremely high traffic. For these hotspots, just reducing the size of
macro cells is not quite enough to handle the high traffic. So, network operators want to
increase the network capacity in a more economical way - by installing small cells.

Networks consisting of the same type of cells (e.g. existing macro networks), as presented
in the previous post, are called homogeneous networks while ones with different types of
cells are called heterogeneous networks (HetNet). So, HetNet is a network where small cells
are deployed within a macro cell coverage. From Release 10 on, HetNet environments are
also considered when discussing LTE-A standards.

Figure 1. Homogeneous network and heterogeneous network (HetNet)

■ What is eICIC?
eICIC is an interference control technology defined in 3GPP release 10. It is an advanced
version of ICIC, previously defined in 3GPP release 8, evolved to support HetNet
environments. To prevent inter-cell interference, ICIC allows cell-edge UEs in neighbor cells
to use different frequency ranges (RBs or sub-carriers). On the other hand, eICIC allows
them to use different time ranges (subframes) for the same purpose. That is, with eICIC, a
macro cell and small cells that share a co-channel can use radio resources in different time
ranges (i.e. subframes).

Two main features of eICIC are: Almost Blank Subframe (ABS) technology defined in
Release 10 and Cell Range Expansion (CRE) technology defined in Release 11. ABS can
prevent cell-edge UEs in small cells from being interfered with by the neighboring macro cell
by having both cells still use the same radio resources, but in different time ranges
(subframes). CRE expands the coverage of a small cell so that more UEs near cell edge can
access the small cell. In this post, we will discuss ABS only.

Figure 2. eICIC technology: ABS

■ Problems with ICIC
First, you may wonder what issues ICIC had that made HetNet choose eICIC over ICIC.
ICIC enables cell-edge UEs to use different frequency resources (RBs) in communicating, by
having neighboring base stations exchange interference information with each other over X2
interface. This is effective in reducing inter-cell interference in an existing macro cell-based
homogeneous network, but causes interference between control channels in a HetNet.

When a base station communicates with a UE, each DL subframe of 1 msec consists of two
periods - one for delivering control channel and the other for delivering data channel. ICIC
can allocates different frequency resources to cell-edge UEs only when delivering data
channels (Physical Downlink Shared Channel; PDSCH). Resource information allocated to
UEs is delivered through control channels (Physical Downlink Control Channel; PDCCH).
Here the thing is, unlike data channels, control channels are not delivered through different
frequency ranges, but distributed across the entire channel bandwidth first and then
delivered. This may cause UEs in neighbor cells to share the same frequency resources.

Figure 3. Control channel (PDCCH) and data channel (PDSCH)

In a homogeneous network, this is not a big problem because there isn't much difference in
Tx power from neighbor cells' antenna, and hence no significant inter-channel interference
by control channels is caused between neighbor cells at cell edge. On the other hand,
in HetNet where a macro cell has much higher Tx power than a small cell 1, the
small cell's control channel is inevitably interfered with by the macro cell's,
making ICIC applied to the data channel ineffective.
 Figure 4. Issues with ICIC in HetNet: Interference by macro cell's control channel

■ eICIC Concept: Problems with ICIC solved by having cells use radio resources in
different time
■ eICIC Operation: Delivering ABS pattern information over X2 interface

CoMP : CS, CB, JT and DPS

Today, we will learn about CoMP, an inter-cell cooperation technology in LTE-A, since we
learned about ICICand eICIC in the previous posts. At an early stage of LTE/LTE-A, offering
high speed is the most important marketing point for operators. However, as LTE
subscribers and traffic grow, satisfying users with high Quality of Experience (QoE), for
example, by improving user throughputs at cell edge areas where data transmission speed
drops drastically becomes far more important than just supporting the highest speed.

Increased radio network capacity can be achieved by improving spectral efficiency. Spectral
efficiency (bit/sec/Hz) is the transmission rate measured in bps per Hz. The higher spectral
efficiency, the more data can be transmitted with the same amount of bandwidth. By
default, LTE networks provide broadband radio links by obtaining higher spectral efficiency
through using at least 2x2 MIMO antennas. At cell centers, installing more antennas at a
base station improves spectral efficiency, leading to higher UE throughputs. At cell edge
areas, however, only insignificant throughput improvement can be expected. So, we should
find another way to gain the same effect.

■ Definition of CoMP
Coordinated Multi-Point (CoMP) is a new inter-cell cooperation technology specifically aiming
to enhance throughputs of UEs at cell edge. CoMP mitigates inter-cell interference and
increases throughputs of a UE at cell edge by allowing not only the UE's serving cell, but
also other cell(s) to communicate with the UE, through cooperation with one another.

Traditionally, a UE accesses only one cell (serving cell) for communication. But, a CoMP-
enabled UE can communicate with more than one cell located in different points, and this
group of cells works as a virtual MIMO system. Cells that are in charge of directly or
indirectly transmitting data to UE are called "CoMP cooperating cells" ("CoMP cooperating
set" in 3GPP terms*), and specifically those actually responsible for transmitting data to UE
are called "CoMP transmission cell(s)" ("CoMP transmission points" in 3GPP terms *).

In summary, CoMP is an inter-cell cooperation technology that enables more than one
transmission cell to communicate with a UE to achieve better throughputs at cell edge areas
by reducing inter-cell interference. CoMP cooperating cells share channel information of a
UE, and based on the information, transmission cell(s) are decided.

■ Why CoMP? – Problems with ICIC and eICIC

As discussed in the previous posts, ICIC (defined in Release 8) reduces inter-cell
interference by allocating different frequency resources (RBs or sub-carriers) to UEs at cell
edge. On the other hand, eICIC (defined in Release 10) does the same task in time domain,
by allocating different time resources (subframes) through cooperation between a macro
cell and small cells in a HetNet.

ICIC and eICIC, both aiming to reduce inter-cell interference, can help UEs at cell edge to
communicate, but neither can actually improve their throughputs. That's because they
restrict radio resource usage in frequency domain (ICIC) and time domain (eICIC) to
mitigate interference. And interference information between neighbor cells is shared on a
relatively long term basis. As a result, fast-changing channel conditions of UE (e.g. when UE
is traveling fast, or entering a shadowing area) are not reflected in inter-cell cooperation
promptly in time, inevitably impeding dynamic allocation of resources.

CoMP, recognized as the most advanced inter-cell cooperation technology so far, was first
standardized in Release 11, and further standardization is still taking place in Release 12. It
uses radio resources not just in frequency/time domain, but also in spatial domain, to
enhance spectral efficiency. That is, it performs beamforming using a smart antenna, or
works as a virtual MIMO system. With CoMP, cooperating cells can share UE's channel
information every time scheduling is performed, and hence UE's instantaneous channel
conditions can be reflected in time. This sharing makes joint scheduling possible. CoMP can
be used either in a homogeneous or heterogeneous network (HetNet), and features various
types of inter-cell cooperation: CS, CB JT, and DPS (see CoMP Types below).

■ Channel Information used in CoMP

Channels are transmission routes for data, i.e. between Tx antenna and Rx antenna across
air. If base stations know UE's channel information beforehand, they can transmit precoded
data so that UE can get better reception. For this purpose, UEs measure their channels, and
report the resulting Channel State Information (CSI) to their base stations.

Base stations give their UEs an instruction on how and which cell's CSI are to be measured
by sending a CSI-RS (CSI Reference Signal) configuration message. Upon this instruction,
UEs measure CSI and report to their serving cells. In general, CSI information includes
Channel Quality Indicator (CQI), Precoding Matrix Indicator (PMI), and Rank Indicator (RI).

CQI: An indicator of channel quality. Displayed as a highest modulation and coding rate
(MCR) value that satisfies the condition of 'channel block error rate (BLER) < 0.1'. It is set
as a value ranging 0 ~ 15 (4 bits). The better channel quality, the higher MCR is used.
Subband CQIs indicate the quality for specific frequency ranges (subrange) while wideband
CQIs indicate that for the entire channel bandwidth.

PMI: Base stations deliver more than one data stream (layer) through Tx antenna.
Precoding matrix shows how individual data streams (layers) are mapped to antennas. To
calculate precoding matrix, UEs obtain channel information by measuring the channel
quality of each DL antenna. Because providing feedback on all channel information results in
significantly increased overheads, generally a code book is pre-configured at base stations
and UEs. Using this code book, UEs send the index of a corresponding precoding matrix
only. Base stations, by referring the reported precoding matrix, calculate its own precoding
matrix, and use the optimal value from it.

RI: Indicates the number of data stream(s) being delivered in DL. For instance, with 2 X 2
MIMO, this value is 1 in case of transmit diversity MIMO where two antennas at a base
station are sending the same data stream, and it is 2 in case of spatial multiplexing MIMO
where the antennas are sending different data streams.

■ CoMP Types (CoMP Categories in 3GPP Terms*)

Specific CoMP types can be categorized in many ways depending on the criteria used for
categorization - whether backhaul is ideal or non-ideal, whether CoMP between eNBs is
supported or not, whether MIMO antennas support one user or multiple users, whether it is
to be applied to DL or UL, etc.
This post will discuss DL CoMP. CoMP is designed to reduce inter-cell interference and
enhance throughputs of cell-edge UEs. When cell(s) send data to UEs, they can use one of
the following CoMP types depending on the extent of coordination among cells and traffic
load. Although different types of CoMP can be used together, we will explain the specific
types one by one below for easier understanding.

Coordinated Scheduling/Coordinated Beamforming (CS/CB)

As an effort to minimize interference among cell-edge UEs, CS and CB CoMP select one of
the cooperating cells as a transmission cell, and use it in communicating with UE.

1. Coordinated Scheduling (CS)

The basic idea of CS CoMP is pretty similar to ICIC in that it reduces inter-cell interference
by allocating different frequency resources (RBs or sub-carriers) to cell-edge UEs. But from
technical perspective, CS CoMP is a more advanced technology that requires a much shorter
operation period, more complicated signal processing and more elaborate algorithm,
compared to ICIC. In ICIC, cooperating cells share interference information of each cell, but
in CS CoMP they can share channel information of each user.
  First, cooperation periods in CS CoMP are a lot shorter than in ICIC. In ICIC, each
cooperation period is tens ~ hundreds of msecs long. So, once ICIC coordination
results are updated, schedulings are based on the result for a long time. On the other
hand, in CS CoMP, with a cooperation period as short as 1 msec, new CS coordination
results are applied every time scheduling is performed. So, resources can be
dynamically allocated even with instantaneous changes of UE's channel condition.
 Second, in CS CoMP, cooperating cells share greater amount of more elaborate
information, compared to those in ICIC. In ICIC, pretty simple information like
interference level by radio block is shared (see ICIC) while user-detailed channel
information (CQI, PMI, RI, SINR, etc.) between UEs and their cooperating cells is
shared in CS CoMP.

Figure 1. Coordinated Scheduling (CS)

In Figure 1, A1 and B1 at cell edge, each with a different frequency resource allocated (f3
and f2), can avoid interference, and hence have improved throughputs. Both UEs do receive
signals from the other UE. These signals do not cause interference with the other's, but may
cause degraded reception of their own signals.
2. Coordinated Beamforming (CB)
CB CoMP allocates different spatial resources (beam patterns) to UEs at cell edge by using
smart antenna technology. Without CS, A1 and B1 may end up being allocated the same
frequency resource (f3 in Figure 2). CB CoMP allows Cell A and Cell B to cooperate with each
other, and allocate different spatial resources (beam pattern 1, beam pattern 2) to A1 and
B1 at cell edge. These two cells can prevent interference by allocating main beam to their
own UE, and null beam to the other neighbor UE.

Figure 2. Coordinated Beamforming (CB)

Generally, CB is more often used with CS, than alone. Figure 3 shows a case where CS and
CB are used together. Cell A and Cell B cooperate with each other to allocate different
frequency resources (f3, f2) and different spatial resources (beam pattern 1, beam pattern
2) to A1 and B1, respectively. This cooperation is pretty effective because, CS alone can
easily take care of interference issues, and besides CB can even ensure better reception
quality. If used with CB, CS can achieve better cell-edge throughputs because CB helps A1
and B1 to avoid signals sent to the other, and better receive those destined for themselves.
 Figure 3. CS/CB

Joint Processing (JP): Joint Transmission/Dynamic Point Selection (JT/DPS)

In JT/DPS CoMP, multiple cells are selected among cooperating cells as transmission cells
for better reception of UEs at cell edge.

3. Joint Transmission (JT)

4. Dynamic Point Selection (DPS)
 Policy and Charging Rules Function (PCRF) in
LTE EPC Core Network Technology

Table of Contents
1. LTE EPC Technology Essentials
2. 2G/3G vs LTE Roadmap
3. Evolved Packet Core (EPC) and its Component
4. Introduction of PCRF
5. Definition of PCRF & Need
6. How does policy control and charging works in LTE?
7. PCRF - The Architecture
8. Deployment of PCRF in Telecom Network
9. Call Flow with PCRF
10. Advantages of Policy Server
11. Conclusion
12. GLOSSARY
13. References

1. LTE EPC Technology Essentials

LTE (both radio and core network evolution) is now on the market. Release 8 was frozen in
December 2008 and this has been the basis for the first wave of LTE equipment. LTE
specifications are very stable, with the added benefit of enhancements having been
introduced in all subsequent 3GPP Releases.

The motivation for LTE

Need to ensure the continuity of competitiveness of the 3G system for the future
User demand for higher data rates and quality of service
Packet Switch optimized system
Continued demand for cost reduction (CAPEX and OPEX) Low complexity
Avoid unnecessary fragmentation of technologies for paired and unpaired band operation
1.1 LTE Overview

LTE (Long Term Evolution) or the E-UTRAN (Evolved Universal Terrestrial Access Network),
introduced in 3GPP R8, is the access part of the Evolved Packet System (EPS). The main
requirements for the new access network are high spectral efficiency, high peak data rates,
short round trip time as well as flexibility in frequency and bandwidth.

Figure 1.1: Network Solutions from GSM to LTE

GSM was developed to carry real time services, in a circuit switched manner (blue in figure
1), with data services only possible over a circuit switched modem connection, with very low
data rates. The first step towards an IP based packet switched (green in figure 1) solution
was taken with the evolution of GSM to GPRS, using the same air interface and access
method, TDMA (Time Division Multiple Access).

To reach higher data rates in UMTS (Universal Mobile Terrestrial System) a new access
technology WCDMA (Wideband Code Division Multiple Access) was developed. The access
network in UMTS emulates a circuit switched connection for real time services and a packet
switched connection for datacom services (black in figure 1). In UMTS the IP address is
allocated to the UE when a datacomservice is established and released when the service is
released. Incoming datacom services are therefore still relying upon the circuit switched
core for paging.
1.2 EPC Core Overview

The EPC is the latest evolution of the 3GPP core network architecture.
In GSM, the architecture relies on circuit-switching (CS). This means that circuits are
established between the calling and called parties throughout the telecommunication
network (radio, core network of the mobile operator, fixed network). This circuit-switching
mode can be seen as an evolution of the "two cans and a string". In GSM, all services are
transported over circuit-switches telephony principally, but short messages (SMS) and some
data is also seen.

In GPRS, packet-switching (PS) is added to the circuit-switching. With this technology, data
is transported in packets without the establishment of dedicated circuits. This offers more
flexibility and efficiency. In GPRS, the circuits still transport voice and SMS (in most cases).
Therefore, the core network is composed of two domains: circuit and packet.

In UMTS (3G), this dual-domain concept is kept on the core network side. Some network
elements have evolved but the concept remains very similar. When designing the evolution
of the 3G system, the 3GPP community decided to use IP (Internet Protocol) as the key
protocol to transport all services. It was therefore agreed that the EPC would not have a
circuit-switched domain anymore and that the EPC should be an evolution of the packet-
switched architecture used in GPRS/UMTS.

This decision had consequences on the architecture itself but also on the way that the
services were provided. Traditional use of circuits to carry voice and short messages needed
to be replaced by IP-based solutions in the long term.

Figure 1.2: Circuit and Packet Domains

2. 2G/3G vs LTE Roadmap

Adopt the user requirements for high speed data and efficient quality:

2G GPRS Mobile Technology was the first step to provide data services over the mobile
networks.

3G Technology provides a higher data rates support with better integrity.

LTE has the biggest challenge to overcome over the later technologies.

LTE is compatible with the current 2G/3G Network as it is counted as the next step of 3G
HSPA Network.
LTE have been developed by the same standard group of 2G/3G (3gpp).

Release 13, IOT and M2M integration and Customization of RAN plus major enhancement
for LTE feature (SRVCC, power reduction).
Release 14, Introduction of 5G Networks "Next Generation".

Following table compares various important Network Elements & Signaling protocols used in
2G/3G and LTE.
3. Evolved Packet Core (EPC) and its Component

The EPC (Evolved Packet Core) is composed of several functional entities:

 The MME (Mobility Management Entity)

 The HSS (Home Subscriber Server)
 The Serving Gateway
 The PDN Gateway (Packet Data Network)
 The PCRF (Policy and Charging Rules Function) Server

The following sub-sections discuss each of these in detail:

3.1 MME (Mobility Management Entity)

The MME is in charge of all the Control plane functions related to subscriber and session
management. From that perspective, the MME supports the following:

 Security procedures – this relates to end-user authentication as well as initiation and

negotiation of ciphering and integrity protection algorithms.
 Terminal-to-network session handling – this relates to all the signaling procedures
used to set up Packet Data context and negotiate associated parameters like the
Quality of Service.
  Idle terminal location management – this relates to the tracking area update process
used in order for the network to be able to join terminals in case of incoming sessions.

The MME is linked through the S6 interface to the HSS which supports the database
containing all the user subscription information.

3.2 HSS (Home Subscriber Server)

The HSS (Home Subscriber Server) is the concatenation of the HLR (Home Location
Register) and the AuC (Authentication Center) – two functions being already present in pre-
IMS 2G/GSM and 3G/UMTS networks. The HLR part of the HSS is in charge of storing and
updating when necessary the database containing all the user subscription information,
including (list is non exhaustive):

 User identification and addressing – this corresponds to the IMSI (International Mobile
Subscriber Identity) and MSISDN (Mobile Subscriber ISDN Number) or mobile
telephone number.
 User profile information – this includes service subscription states and user-subscribed
Quality of Service information (such as maximum allowed bit rate or allowed traffic
class).

The AuC part of the HSS is in charge of generating security information from user
identity keys. This security information is provided to the HLR and further
communicated to other entities in the network. Security information is mainly used
for:

 Mutual network-terminal authentication.

 Radio path ciphering and integrity protection, to ensure data and signaling transmitted
between the network and the terminal is neither eavesdropped nor altered.
3.3 The Serving GW (Serving Gateway)

From a functional perspective, the Serving GW is the termination point of the packet data
interface towards E-UTRAN. When terminals move across eNodeB in E-UTRAN, the Serving
GW serves as a local mobility anchor, meaning that packets are routed through this point
for intra E-UTRAN mobility and mobility with other 3GPP technologies, such as 2G/GSM and
3G/UMTS.

3.4 The PDN GW (Packet Data Network Gateway)

Similarly, to the Serving GW, the PDN gateway is the termination point of the packet data
interface towards the Packet Data Network. As an anchor point for sessions towards the
external Packet Data Networks, the PDN GW also supports Policy Enforcement features
(which apply operator-defined rules for resource allocation and usage) as well as packet
filtering (like deep packet inspection for virus signature detection) and evolved charging
support (like per URL charging).

3.5 The PCRF (Policy and Charging Rules Function) Server

The PCRF server manages the service policy and sends QoS setting information for each
user session and accounting rule information. The PCRF Server combines functionalities for
the following two UMTS nodes:

 The Policy Decision Function (PDF)

 The Charging Rules Function (CRF)

The PDF is the network entity where the policy decisions are made. As the IMS session is
being set up, SIP signaling containing media requirements are exchanged between the
terminal and the P-CSCF. At some time in the session establishment process, the PDF
receives those requirements from the P-CSCF and makes decisions based on network
operator rules, such as:

 Allowing or rejecting the media request.

 Using new or existing PDP context for an incoming media request.
  Checking the allocation of new resources against the maximum authorized.

The CRFs role is to provide operator-defined charging rules applicable to each

service data flow. The CRF selects the relevant charging rules based on
information provided by the P-CSCF, such as Application Identifier, Type of Stream
(audio, video, etc.), Application Data Rate, etc.

Figure 3: Evolved Packet Core (EPC) and its Component

4. Introduction of PCRF

The convergence of broadband access, virtually unlimited content and smart mobile devices
has permanently altered the telecommunications market. Demand for mobile Internet
services is rapidly increasing day by day as customers want to receive their content, media
and applications on any device at any time. For the last few years, the telecom industry is
radically transforming the revenue streams, business models and value chains.

To remain relevant in this rapidly changing environment, telecom operators must address
critical challenges to create new business models and reinvent themselves.

Therefore, Service Provider must have some statistics that determine how and under what
conditions subscribers and applications use network resources for formulation of the
policies. The Policy Server manages policy rules between applications and policy
enforcement points like access devices. It can easily add and re-configure policies to
dynamically manage and control Quality of Service (QoS), charging, quota, optimization and
admission control. A wide variety of interfaces make it easy to integrate the PCRF with any
type of mobile or fixed broadband network.

Since operators will be migrating from 2G to 3G to 4G networks in years to come, existing

networks must operate concurrently with newer networks. As subscribers travel between
mobile networks, and also the fixed network, operators must be able to maintain session
visibility. As a result, policy solutions must be able to dynamically control sessions per
subscriber.

PCRF can provide a network agnostic solution (wire line and wireless) and can also enable
multi-dimensional approach which helps in creating a lucrative and innovative platform for
operators. PCRF can also be integrated with different platforms like billing, rating, charging,
and subscriber database or can also be deployed as a standalone entity.
5. Definition of PCRF & Need

Policy and Charging Rules Function (PCRF) is a node which functions in real-time to
determine policy rules in a multimedia network. As a policy tool, the PCRF plays a central
role in next-generation networks/LTE. It is a component that operates at the network core
and accesses subscriber databases and other specialized functions, such as a charging
system, in a centralized manner. The PCRF has an increased strategic significance and
broader potential role, than traditional policy engines, due
to its working in real time.

The PCRF is the part of the network architecture that aggregates information to and from
the network, operational support system and other sources (such as portals) in real time,
supporting the creation of rules and then automatically making policy decisions for each
subscriber active on the network. Such a network might offer multiple services, quality of
services (QoS) levels, and charging rules.

It provides:

 The ability to manage network and subscriber policy in real time.

 The ability to efficiently and dynamically route and prioritize network traffic.
 Unified view of subscriber context based on a combination of device, network, location
and billing data.
 Key inputs to revenue assurance and bandwidth management.

Policy and Charging Rules Function (PCRF) is the part of the Evolved Packet Core (EPC) that
supports service data flow detection, policy enforcement and flow-based charging.

PCRF plays a key role in VoLTE as a mediator of network resources for the IP Multimedia
Systems network for establishing the calls and allocating the requested bandwidth to the
call bearer with configured attributes. This enables an operator to offer differentiated voice
services to their user(s) by charging a premium. Operators also have an opportunity to use
PCRF for prioritizing the calls to emergency numbers in the next-gen networks.
Dedicated policy equipment standardized in 3GPP that enables the policy function for
bandwidth and charging on multimedia networks.

PCRF is a fairly new term, introduced in September 2007 when standards for the 3GPP
Policy Charging Control (PCC) architecture were published. The PCRF function is part of the
larger PCC architecture, which also includes the Proxy Call Session Control Function (P-
CSCF) and the Policy and Charging Enforcement Function (PCEF). Combined, the elements
of the PCC provide access, resource, and quality-of-service (QoS) control.

PCRF is often referred to as policy server or -- formerly -- a Policy Decision Function (PDF).

PCRF is an important element in Service Provider Information Technology (SPIT). The PCRF
interfaces with the main packet gateway and takes charging enforcement decisions on its
behalf. The centralized device can act as a policy decision point (PDP) for the wireless
operator and gets as granular as individual subscribers.

For example, service providers can use PCRF to charge subscribers based on their volume of
usage of high-bandwidth applications, charge extra for QoS guarantees, limit app usage
while a user is roaming, or lower the bandwidth of wireless subscribers using heavy-
bandwidth apps during peak usage times.

5.1 The Policy and Charging Challenge

Policy and Charging rules are driven by the PCRF (Policy Charging and Rules Function), PCEF
(Policy Control Enforcement Function) and the Charging Functions in the IMS and EPC core
networks. These elements provide carriers with the ability to differentiate services while
maximizing revenue.

Every carrier service has unique bandwidth requirements. Policy control within the PCRF and
PCEF ensures that appropriate amounts of bandwidth are dynamically allocated to each
service in real time, thus making the most efficient use of network resources. Prior to
launching a new service like VoLTE, carriers need to test and validate their policy rules
within the PCRF and PCEF to ensure the services are delivered with integrity and to ensure
that there is sufficient capacity to provide the requested services. Charging rules are very
similar and also must be validated. A service provider may implement a multitude of
charging rules for each service; and these rules may differ based on a variety of conditions,
for example: Customer Service Level Agreement, time of day, or network conditions.

5.2 Need for PCRF - Following two cases describe the need of PCRF in telecom
network:

5.2.1 Changing Revenue Streams

In many developed telecom markets, voice revenue has gained a peak and has declining
trends. Messaging is expected to increase globally significantly in coming years. New IP
message services like iMessage and WhatsApp are beginning to attract consumers’
attention, particularly those with smart phones. As the IP messaging phenomena takes off,
SMS messaging revenues will also decline.

Data access is still a growth engine for operators and is helping in compensating the decline
in voice and messaging revenues. In major markets, data demand is doubling each year,
but margin pressure is intense. At present, expenditure incurred in building network
capacity to handle the increasing load is more than the revenue earned by data access.

In view of above, operators need to plan new revenue streams. For implementation of this
operators need a PCRF type entity in their telecom network.

5.2.2 Business Transformation Starts with the Network

Existing telecom networks are not built with the DNA (Dynamic Network Administration) to
foster innovation and respond quickly to dynamic markets to meet the demands of the
subscribers. To reinvent themselves, operators need to redesign their legacy infrastructure
into a highly evolved, completely software-defined network (SDN) – the thinking network.
The thinking network is analogous to the human body.
The memory is the subscriber database. The language is the Diameter protocol, the central
nervous system is the new product category of Diameter Signaling Controller (DSC), and
the brain is policy.

Figure 5.2.2: Thinking Network

6. How does policy control and charging works in LTE?

An important component in LTE network is the policy and charging control (PCC) function
that brings together and enhances capabilities from earlier 3GPP releases to deliver dynamic
control of policy and charging on a per subscriber and per IP flow basis.
LTE Evolved Packet Core (EPC) EPC includes a PCC architecture that provides support for
fine-grained QoS and enables application servers to dynamically control the QoS and
charging requirements of the services they deliver. It also provides improved support for
roaming. Dynamic control over QoS and charging will help operators monetize their LTE
investment by providing customers with a variety of QoS and charging options when
choosing a service.

The LTE PCC functions include:

 PCRF (policy and charging rules function) provides policy control and flow based
charging control decisions.
 PCEF (policy and charging enforcement function) implemented in the serving gateway,
this enforces gating and QoS for individual IP flows on the behalf of the PCRF. It also
provides usage measurement to support charging.
 OCS (online charging system) provides credit management and grants credit to the
PCEF based on time, traffic volume or chargeable events.
 OFCS (off-line charging system) receives events from the PCEF and generates
charging data records (CDRs) for the billing system.

7. PCRF - The Architecture

PCRF was introduced in September 2007 when standards for the 3GPP Policy Charging
Control (PCC) architecture were published. The PCRF function is part of the larger PCC
architecture, which also includes the Proxy Call Session Control Function (P-CSCF) and the
Policy and Charging Enforcement Function (PCEF). Combined, the elements of the PCC
provide access, resource, and quality-of-service (QoS) control.

PCRF is an important part of IMS architectures, although it is not exclusive to the 3GPP-
based network in which it was certified. It works across wireless networks and can be
deployed on carrier grade/ATCA (Advanced Telecommunications Computing
Architecture)/COTS (Commercial off the shelf) hardware.
The PCRF interfaces with the main packet gateway and takes charging enforcement
decisions. The centralized device can act as a policy decision point (PDP) for the wireless
operator and goes down to the individual subscribers.

Service providers can use PCRF to facilitate for charging of subscribers based on their
volume of usage of high-bandwidth applications and charging based on QoS guarantees,
limit app usage while a user is roaming, or lower the bandwidth of wireless subscribers
using heavy-bandwidth apps during peak usage times.

PCRF Server is carrier grade platform used to implement the convergent policy
management, real-time policy decision solutions across core network domain and content
application domain for the network service providers.

PCRF Server includes a 3GPP-compliant implementation of Policy and Charging Rules

Function to provision, manage and execute the Quality of Service policies, Bandwidth
control policies, Subscriber-aware policies, and Application gating policies in the 2G/3G and
LTE networks.
 Figure 7: as per 3GPP TS 23.203

Legends:
PCEF: Policy and Charging Enforcement function
TDF: Traffic Detection Function
AF: Application Function
BBERF: Bearer Binding and Event Reporting Function

PCRF is comprised of the following components/subsystems

 a. One or more policy servers which provides the policy and charging management
functions
 b. Subscriber Profile Repositories (SPR)
 c. A Configuration Central Management Subsystems for centralized provisioning and
management of the policy servers
7.1 Policy Server

The PCRF SERVER is the main server engine that processes the policy requests from the
core network elements or B/OSS (Business/Operations Support System) systems at real-
time. The main components of the PCRF Server are the Diameter-based 3GPP Gx, Rx, Sy,
Gxx, Sp and Sd Connectors, Policy and Charging Rules Server, Policy Decision Platform,
Subscriber Profile Cache and Subscription Management Service.

The Policy Server has a rules engine and acts as the standards based Policy Charging and
Rules Function (PCRF) in the network. The rules engine operates on triggers, processes
conditions, and then performs appropriate action(s) based on the conditions. The rules
engine can be invoked based on any interface trigger. The rules engine can be triggered by
a message from either the GGSN or DPI via either the Gx interface, the SPR via the Sp or
SOAP/XML interface, as well as the application function via the Rx interface. The rules
engine can also be triggered by internal timers which can be used to support a variety of
time of day based applications/use cases. Policies can be developed quickly using Policy
Rules wizard.
 Figure 7.1: PCRF’s Subsystems

7.2 SPR - Subscriber Profile Repository

SPR is the repository to store all business assets, technical assets and configuration items
used by the PCRF Server, Central Management Server. This is a mandatory component to
run PCRF Server.

Policy’s SPR should act as the policy solution database to store subscriber profile, quota,
and state information of the Policy Server to use in its policy execution. The SPR should be
deployed in networks to store subscriber profile information and inter-session state
information (e.g. usage and quota tracking). The SPR should be deployed in a variety of
configurations according to the customer needs and requirements e.g. in a standalone
redundant HW configuration or together with the other PCRF components within the same
platform.
7.3 Policy Management Platform/Central Management Subsystem

Central Management Subsystem is the centralized server node to monitor and manage the
PCRF Server and Repository Server. It’s the core component for PCRF Server to provide the
OA&M functions. The Management Platform provides a consolidated view of system alarms
and logs and has SOAP/ XML API to interface to external systems.

In addition to above, PCRF server may also have following Components/functionalities:

 (a) SPR Proxy subsystem - It is a component that exposes the Web Services API
within PCRF Server for management of the internal Subscriber Profile Repository (that
is, subscriptions and subscribers).
 (b) Load Balancer – It is the key component in the distributed deployment
environment for PCRF Server. It provides the Diameter application level load
balancing capability.
8. Deployment of PCRF in Telecom Network

Following are the architecture of telecom network with PCRF.

8.1 PCRF with 2G/3G Network

Figure 8.1: PCRF with 2G/3G Network

8.2 PCRF with 4G/LTE Network

Figure 8.2: PCRF with 4G/LTE Network

8.3 PCRF in converged network

Figure 8.3: PCRF in converged network

8.4 PCRF Supported Interfaces

Following are the description of used external interfaces supported by PCRF Server:

(i) Gx Interface – PCRF Server supports the Gx interface as defined in 3GPP Release 7, 8,
9 and 10. It is used for provisioning service data flow based on charging rules. It is located
between the PCRF and the Policy and Charging Enforcement Function (PCEF). In most
cases, PCEF is based inside PDN GW (Packet Data Network Gateway) or in short PGW, as in
above diagram.

PCRF Server is very flexible and can be configured to support any specific AVPs in the
network element and accommodate customer specific scenarios.
(ii) Gy Interface – PCRF Server supports the Gy interface and acts as DCCA proxy
between PCEF and OCS (Online Charging System). This interface allows online credit control
for service data flow based charging.

(iii) Gz Interface – This is used for offline (CDR based) charging interface between the
PCEF/PDN GW and OFCS (Offline Charging system).

(iv) Rx Interface – PCRF Server supports the Rx interface as defined in 3GPP Release 10.
This reference points are used to exchange application level session information & media
related information between the PCRF & Application function/Application Server. This
information is the part of the inputs used by the PCRF for the Policy and Charging Control
Decisions.

(v) Sy Interface – PCRF Server supports the Sy interface as defined in 3GPP Release 11.
It is used between PCRF and OCS for sending limits reports.

(vi) Sp Interface – PCRF Server supports the Sp interface between the PCRF and the SPR.
This interface allows the PCRF to request subscription information related to transport level
policies from the SPR based on a subscriber ID, a PDN identifier and possible further IP CAN
session attributes, as specified in 3GPP TS 23.203 v9.x. This interface allows the SPR to
notify the PCRF when the subscription information has been changed if the PCRF has
requested such notifications. The SPR shall stop sending the updated subscription
information when a cancellation notification request has been received from the PCRF.

(vii) Ud Interface – PCRF Server supports the Ud interface between the PCRF and the
UDR. This interface allows the PCRF to create, read, modify and delete user data stored in
the UDR using the access interface. It is based in LDAP. This interface supports
subscriptions/notifications functionality to allow the PCRF being notified about specific
events that may occur on specified user data in the UDR. The events can be changes on the
existing user data, addition of user data, and so on. PCRF Server supports the Ud interface
based on LDAP protocol, as defined in 3GPP TS 23.335 v9.x and TS 29.335 v9.x.
(viii) RADIUS Interface – PCRF Server provides a RADIUS based AAA interface which is
connected with external AAA server. It receives the AAA-Start and AAA-Stop radius
message forwarded from AAA server when IP-CAN session is established or terminated. It
works with AAA management (component that provides the mapping between the IP
Address and the MSISDN) to manage the mapping between IP address and MSISDN.

(ix) RADIUS CoA Interface – Radius Change of authorization (CoA) features provides a
mechanism to change the attributes of an authentication, authorization and accounting
(AAA) session after it is authenticated. When a policy changes for a user or user group in
AAA, administrators can send the Radius CoA packets from the AAA server to reinitialize
authentication and apply the new policy. PCRF Server also provides the connector and the
processing flow used to provision policy rules to a non-3GPP enforcement point via RADIUS
/ RADIUS CoA interface.

(x) Gxx Interface – This reference point resides between the PCRF and the BBERF (Bearer
Binding and Event Reporting Function). The Gxx reference point enables a PCRF to have
dynamic control over the BBERF behavior. The PCRF PCC rule decisions may be based on
information obtained from the BBERF via the Gxx interface. BBERF generally resides in the
SGW.
9. Call Flow with PCRF

9.1 In 2G/3G Network

Figure 9.1: PCRF Call Flow in 2G/3G Network

Call Flow Procedures:

 (1) User equipment (Mobile Station) wishes to establish a data application (data
access/internet), so it requests to BTS/Node B.
 (2) Node B forward its request to BSC/RNC.
 (3) After all queries and procedure related to authentication, IMEI check & subscriber
static information(HLR), BSC/RNC forward subscriber request to SGSN. Some of the
queries are performed by SGSN.
 (4) SGSN requests to GGSN for PDP context/data access.
 (5) GGSN signals/query to PCRF (Policy & Charging Rule Function) about UE/MS data
session establishment over Gx interface.
 (6) PCRF queries the Subscriber Profile Repository(SPR) for dynamic information of
subscriber over Sp interface.
  (7) SPR sends all information about the subscriber policy/quota/rules to PCRF over Sp
interface.
 (8) PCRF installs policies for subscriber on GGSN (by PCEF) (per access point
name[APN] and per bearer quota grants).
 (9) If required, over Gx interface, Deep Packet Inspection(DPI) intimates PCRF on
traffic detection. (Ud interface in the case of TDF [Traffic Detection Function])
 (10) PCRF installs policies for application control on DPI and DPI begins tracking
usage.
 (11) Now data session is established and the subscriber starts consuming the data.
 (12) Over Gy interface GGSN/PCEF talks to OCS (Online Charging System) for
charging/credit.
 (13) GGSN receives the information from OCS about balance/quota.
 (14) GGSN signals policy server(PCRF) that device has exceeded data/quota grant or
credit is low.
 (15) Over Sy interface OCS also sends the credit limit report to PCRF.
 (16) Policy server may grant additional grant, after consulting with subscriber by
sending SMS notification over SMPP.

9.2 Call flow LTE EPC & PCRF

Network-Initiated IP-CAN Session Modification

9.2.1 Interactions between GW and PCRF (PCC Rule Provisioning in PUSH mode)

This flow shows the provisioning of PCC Rules and/or authorized QoS triggered by an event
in the PCRF.
 Figure 9.2.1: Interactions between GW and PCRF for PCRF-Initiated IP-CAN Session
Modification

 (1) The PCRF receives an internal or external trigger to re-evaluate PCC Rules and
policy decision for an IP-CAN Session. Possible external trigger events are described in
clause 4.3.1.2.
  (2) The PCRF selects the PCC Rule(s) to be installed, modified or removed for the IP-
CAN Session. The PCRF may also update the policy decision by defining an authorized
QoS and enable or disable the service flow(s) of PCC Rules. If the PCEF controls the
binding of IP-CAN bearers, PCRF may add or change QoS information per QCI
applicable to that IP-CAN session.
 (3) The PCRF stores the updated PCC Rules.
 (4) Step 4 is only applicable if the Bearer Control Mode (BCM) selected is UE-only and
the PCRF receives an external trigger from the AF.

The PCRF may start a timer to wait for an IP CAN bearer initiation, modification or removal
procedure initiated by the UE, as depicted in figure 9.2.1 or figure 9.2.2 in the following
cases:
- If the authorized QoS for an IP-CAN bearer is changed, or
- If One or more Flow Descriptions need to be added, deactivated or removed in any of the
PCC rules bound to an IP-CAN bearer, or
- If as a result of policy decisions in step 2, new PCC rules need to be installed and the PCRF
requires additional filter information from the UE to execute the bearer binding.

If an IP-CAN bearer initiation, modification or termination procedure initiated by the

terminal is received for the affected PCC rules while the timer is running, all subsequent
steps in the present figure shall not be executed and the steps in figure 9.2.1 or figure 9.2.2
(on provisioning based on PULL procedure at UE-initiated IP-CAN bearer establishment,
modification or termination) shall be executed instead.

If the timer expires and the PCRF still requires additional filter information coming from the
UE in order to decide on bearer binding for new PCC rules to be installed, all subsequent
steps in the present figure shall not be executed, and further reactions of the PCRF are left
unspecified. As a possible option, the PCRF could abort the AF session.
Otherwise, the PCRF shall proceed with the subsequent steps (provisioning based on PUSH
procedure) in the present figure after timer expiry.

 (5) The PCRF sends a Diameter RAR to request that the GW installs, modifies or
removes PCC Rules and updates the policy decision. For types of IP-CAN, where the
PCRF controls IP-CAN Bearers, e.g. GPRS, the PCRF identifies the IP-CAN Bearer for
 each of the PCC Rules and the authorized QoS. The PCRF may provision PCC Rules
and authorized QoS for several IP-CAN Bearers within the same RAR.
 (6) The GW installs, modifies or removes the identified PCC Rules. The GW also
enforces the authorized QoS and enables or disables service flow according to the flow
status of the corresponding PCC Rules. If QoS information is received per QCI, PCEF
shall set/update the upper limit for the MBR that the PCEF assigns to the non-GBR
bearer for that QCI.
 (7) The GW sends RAA to acknowledge the RAR. The PCEF informs the PCRF about the
outcome of the PCC rule operation. If network initiated procedures apply for the PCC
rule and the corresponding IP-CAN bearer cannot be established or modified to satisfy
the bearer binding, then the PCEF rejects the activation of a PCC rule.

For GPRS, the subsequent steps are executed separately for each IP-CAN bearer under the
following conditions:
- If all PCC rules bound to a PDP context have been removed or deactivated (PDP Context
deactivation is applicable)
- If one or more PDP contexts have to be modified
- If in NW-Only Bearer Control Mode, the GGSN needs to establish a new PDP context (PDP
Context establishment is applicable)

 (8) For GPRS, the GGSN initiates the procedure to Create/Update or Terminate PDP
Context Request message to the SGSN. If in the case of updating the PDP Context the
authorized QoS for the bearer has changed, the GGSN will modify the UMTS QoS
parameters accordingly.
 When the procedure in step 8 is completed and requires of notifications from the GW
to the PCRF the following steps are additionally executed:
 (9) The GW sends the notifications needed to the PCRF. The notification is made by
using a CCR messages with the needed AVPs. For an IP-CAN Bearer termination in
UE-Only Bearer Control Mode, the GGSN sends a Diameter CCR with the Bearer-
Identifier and Bearer-Operation AVPs to indicate "Termination".
 (10) The PCRF stores the information coming in the notification.
 (11) The PCRF acknowledge the CCR with a CCA command.
9.2.2 Interactions between PCRF, AF and SPR

AF Session Establishment

Figure 9.2.2: AF session establishment triggers PCRF-Initiated IP-CAN Session Modification

 (1) The AF receives an internal or external trigger to set-up of a new AF session and
provide Service Information.
 (2) The AF identifies the Service Information needed (e.g. IP address of the IP flow(s),
port numbers to be used, information on media types, etc.).
 (3) The AF provides the Service Information to the PCRF by sending a Diameter AAR
for a new Rx Diameter session.
 (4) The PCRF stores the received Service Information.
 (5) If the PCRF requires subscription-related information and does not have it, the
PCRF sends a request to the SPR in order to receive the information.
  (6) The SPR replies with the subscription related information containing the
information about the allowed service(s), QoS information and PCC Rules information.

NOTE:
For steps 5 and 6: The details associated with the Sp reference point are not specified in
this Release. The SPR"s relation to existing subscriber databases is not specified in this
Release.

 (7) The PCRF identifies the affected established IP-CAN Session(s) using the
information previously received from the GW and the Service Information received
from the AF.
 (8) The PCRF sends a Diameter AAA to the AF.
 (9) The PCRF interacts with the GW according to figure 9.2.1.

10. Advantages of Policy Server

In the intelligent network model, policy is the engine for innovation and differentiation. Its
role evolves dramatically from its current usage, expanding both in application and scope.

To succeed as digital lifestyle providers, service providers require advanced tactics and tools
that enable them to:

 Create a policy foundation that scales as the number of applications, use cases and
network demands grow;
 Leverage network assets and analytics to gain a granular view of subscriber,
application and network behavior from the handset to the core;
 Focus squarely on the subscriber with a rich service experience that’s tuned to each
consumer’s behavior and provides direct personal benefit;
 Expand traditional, one-sided business models to engage and partner in new markets
- machine-to-machine (M2M), over-the-top (OTT), mobile advertising, and cloud;
 Develop flexible, dynamic pricing strategies that address multiple market segments
and offer end users more choices that reflect their usage patterns and lifestyles;
and

 Respond dynamically, often in real-time, to changing market and network dynamics.

With the ability to push policy control beyond the network core to its edge, operators can
develop creative strategies to:

10.1 Optimize and personalize each subscriber’s experience

Operators can create a service experience that is related to each subscriber based on
preferences, location, access network, device type, and network conditions. They can
provide a relevant mobile advertisement, or inform the subscriber when a usage threshold is
reached to prevent bill shock. Or, a service provider can zero rate social networking usage
so it doesn’t count against the subscriber’s data bucket. Operators can offer service plans
that guarantee bandwidth for certain high-value customers
like corporate accounts, create flexible pricing plans that match a subscriber’s preferences
and budget, or allow subscribers to share one quota across multiple devices.

10.2 Create lucrative, two-sided business models with third-party, OTT and cloud
providers

Operators hold a number of valuable assets – QoS, security, billing relationships, subscriber
profiles, context, usage, and device awareness – that can be used to create profitable
commercial relationships. They can enable targeted third party advertising. Operators can
offer identity as a service, enabling subscribers to use their network identity as a single-
sign-on for third-party applications. Or, they can leverage the trusted relationship they’ve
established with subscribers to provide secure, consolidated billing for OTT and cloud
applications.

10.3 Maximize resources and Manage QoS

Operators can implement creative solutions to manage network congestion. Advanced Wi-Fi
offload use cases based on preferential network access, subscriber tier or type, device,
application, quota, or network conditions can be implemented to relieve congestion on
licensed spectrum and improve subscribers’ data experience. A device can be moved to the
best available network to ensure that the subscriber application usage receives the best
available QoS based on current network conditions. The impact of high bandwidth
applications can be minimized by offering subscribers incentives to shift their usage to a
different time of day or less congested location. With advanced policy tools, operators can
reduce the effect of the excessive signaling generated by “chatty” apps that constantly
query the network.

11. Conclusion

Policy and Charging Rules Function (PCRF) - supports service data flow detection, policy
enforcement and flow-based charging. It offers a comprehensive solution that allows a new
generation service provider to offer multiple use cases that allows them to better control
their services and align their revenue with their resources.

PCRF Server provides a flexible and scalable software platform for the development and
management of any type of policy solutions specialized for telecom industry. PCRF Server
also offers flexibility in integration with various core network equipment or B/OSS systems
using industry standard (e.g. 3GPP) or non-standard interfaces/protocols. PCRF Server
enables the rapid prototyping and provisioning of new policies or products for innovative
and unique services/applications to the subscribers.

As operators transition to LTE, policy will play a critical network role and become a strategic
component in the quest to manage and monetize LTE networks. Virtually every LTE session
and subscriber will need to be managed or charged in some fashion, which will require the
involvement of a policy server in each transaction. From prioritization to personalized
service plans, the coupling of LTE with policy promises to help resolve key LTE operational
and business challenges and support a new generation of revenue generating services.
Equipped with intelligent policy management, operators can shape and manage network
demand, revenue contributions from differing classes of customers, capital expenditures,
and overall growth of the LTE, mobile broadband market.
12. GLOSSARY

3GPP: 3rd Generation Partnership Project

AF: Application Function
ATCA: Advanced Telecommunications Computing Architecture
BBERF: Bearer Binding and event reporting function
B/OSS: Business/Operations Support System
COTS: Commercial off the shelf
DCCA: Diameter Credit Control Application
DPI: Deep Packet Inspection
DSC: Diameter Signaling Controller
GGSN: Gateway GPRS Serving Node
IMS: IP Multimedia Subsystem
LDAP: Lightweight Directory Access Protocol
LTE: Long Term Evolution
OMC: Operation & Maintenance Center
OTT: Over the Top Platform
PCC: Policy & Charging Control
P-CSCF: Proxy Call Session Control Function
PCEF: Policy and Charging
PCRF: Policy & Charging Rule Function
PDF: Policy Decision Function
PGW: Packet Gate way
QoS: Quality of Service
SDN: Software Defined Network
SMS: Short Message Service
SMTP: Simple Mail Transfer Protocol
SMPP: Short Message Peer to Peer
SNMP: Simple Network Management Protocol
TDF: Traffic Detection Function
UDR: User Data Repository
13. References

(1) ITU-T (www.itu.int/en/ITU-T)

(2) 3GPP (www.3gpp.org)
(3) ETSI (www.etsi.org)
(4) Policy Charging & Control Architecture (3GPP TS 23.203)
(5) Survey of Research Organization
(6) http://broabandtrafficmanagement.blogspot.in/p/dpi-market-size-forecast.html
(7) http://tec.gov.in/pdf/Studypaper/
(8) http://www.tutorialspoint.com/lte/lte_network_architecture.htm

PCRF is an important Entity in LTE Network

Table of Contents
1. PCRF in LTE Network
2. Policy Principle
2.1 PCC rules
2.2 Parameters in PCC rule
2.3 LTE HSI
2.4 VoLTE
3. PCRF Call Model

1. PCRF in LTE Network

A important component in LTE network is the policy and charging control (PCC)
function that brings together and enhances capabilities from earlier 3GPP releases to
deliver dynamic control of policy and charging on a per subscriber and per IP flow
basis.

The Policy Control and Charging Rules Function is responsible for policy control
decision-making, as well as for controlling the flow-based charging functionalities in
the Policy Control Enforcement Function (PCEF), which resides in the P-GW. The PCRF
provides the QoS authorization (QoS class identifier [QCI] and bit rates) that decides
how a certain data flow will be treated in the PCEF and ensures that this is in
accordance with the user’s subscription profile.

PCRF provides service management and control of the 4G service. It dynamically

manages and controls data sessions, enables new business models. Apart from this,
PCRF LTE also has the functionality to make it easy for other devices out of the 3GPP
network- like WiFi or fixed broadband devices- to access the 4G LTE network.

In other words, PCRF LTE is the policy manager of the new 4G LTE technology. All the
quality of service (QoS) rules and regulations are distributed to the packet data
network gateway by the PCRF LTE, making it a very valuable aspect of any
organization’s policy and security management system.

The policy server or PCRF is a key component in the NDN. It provides the critical link
between the service and transport layers and is the central decision point – the brain
– of LTE networks. The PCRF provides the granular control of service quality, which is
critical for managing resources, enabling seamless roaming, establishing new business
models, and monetizing services.

A fundamental LTE concept is the ability to recognize and differentiate traffic flows.
The degree and granularity with which that flow can be dynamically influenced largely
determines the extent to which an operator can shape bandwidth, implement QoS,
manage resource allocation, and create new applications. That’s where policy comes
into play. The PCRF is the key network element that enables that fine-grained control,
which is essential to successfully managing and monetizing LTE networks. As such, it
is a strategic component and consideration in LTE network design.

The diagram shown below represents the PCRF reference architecture in LTE/IMS
network

Figure 1: LTE PCRF reference network architecture

PCRF solution shall provide the following key capabilities as listed below:
1. Network Control:The PCRF provides network control regarding the service data flow
detection, gating, QoS and flow based charging (except credit management) towards
the PCEF (e.g., SAE-GW, PDN GW). The PCRF receives session and media related
information from the AF and informs AF of traffic plane events.
2. QoS Based on Subscription Information: The PCRF may use the subscription
information as basis for the policy and charging control decisions. The subscription
specific information for each service may contain e.g. max QoS class and max bit rate.
3. PCC Rule: The PCRF shall inform the PCEF through the use of PCC rules on the
treatment of each service data flow that is under PCC control, in accordance with the
PCRF policy decisions.
4. Gating Control: The PCRF makes the gating decisions which are then enforced by the
PCEF. The PCRF could, for example, make gating decisions based on session events
(start/stop of service) reported by the P-CSCF via the Rx reference point.
5. Support for emergency services: Policy management solution fully supports
emergency service calls with and without subscription information. The PCRF
“upgrades” the user voice flow with appropriate priority when an IMS emergency call
is placed. In the absence of the subscription information, it uses the assigned IP
address to identify the user’s IP-CAN session and install appropriate rules.
6. Access point name (APN)-specific policy control: With Policy Server, operators
can set up APNs to segregate traffic, apply specific controls to optimize that traffic or
experience, and create service-specific charging for each. For example, an operator
can set up an Internet protocol multimedia subsystem (IMS) APN dedicated to VoLTE
and video and another APN for the Internet. Different controls and pricing can be
applied to each. The IMS APN can be set up with a dedicated bearer that provides the
more stringent QoS controls required for real-time applications, while the Internet
APN delivers “best effort” and is charged based on bandwidth consumption. As
another example, the operator can create a content-filtering APN to which user’s
subscriber to restrict the services accessible their children can access.
7. Application-driven QoS: Policy Server enables operators to dynamically boost QoS
to improve a subscriber’s application experience and create two-sided business
models. For instance, a customer watching a Netflix video receives a prompt asking if
she would like to have better resolution. The Netflix application server (AS) gets this
request and sends it to the PCRF over a Diameter interface. The PCRF applies a real
time upgrade to that user’s particular video stream. The operator generates additional
revenue by adding value to the OTT provider with which it has a volume or wholesale
agreement.
8. Enhancement for location-based services (LBSs): LTE identifiers such as location
and network control and location change triggers provide the increased level of
granularity required to support the complex delivery of LBSs in LTE networks.

2. Policy Principle
PCRF will send the PCC rules based on subscriber profile and plan. There are two
types of services.

 LTE HSI
 VoLTE

2.1 PCC rules

 The purpose of the PCC rule is to:

 Detect a packet belonging to a service data flow.

 The service data flow filters within the PCC rule are used for the selection of downlink
IP CAN bearers.
 The service data flow filters within the PCC rule are used to enforce that uplink IP
flows are transported in the correct IP CAN bearer.
 Identify the service data flow contributes to.
 Provide applicable charging parameters for a service data flow.
 Provide policy control for a service data flow.
 The PCEF shall select a PCC rule for each received packet by evaluating received
packets against service data flow filters of PCC rules in the order of the precedence of
the PCC rules. When a packet matches a service data flow filter, the packet matching
process for that packet is completed, and the PCC rule for that filter shall be applied.

There are two different ways of applying/implementing PCC rules:

 Dynamic PCC rules: Dynamically provisioned by the PCRF to the SAE-GW via the Gx
interface. Dynamic PCC rules can be activated, modified and deactivated at any time.
 Predefined PCC rules: These rules are preconfigured in the SAE-GW. Predefined PCC
rules can be activated or deactivated by the PCRF at any time. Predefined PCC rules
within the SAE-GW may be grouped allowing the PCRF to activate a set of PCC rules
over the Gx reference point.

2.2 Parameters in PCC rule

A PCC rule consists of:

 A rule name;
 Service identifier;
 Service data flow filter(s);
 Precedence;
 Gate status;
 QoS parameters;
 Rating group;
 Other charging parameters;
 Monitoring key;
 Application service provider identity.

The rule name shall be used to reference a PCC rule in the communication between
the PCEF and the PCRF.
The service identifier shall be used to identify the service or the service component
the service data flow relates to.
The service flow filter(s) shall be used to select the traffic for which the rule applies.
The gate status indicates whether the service data flow, detected by the service data
flow filter(s), may pass (gate is open) or shall be discarded (gate is closed) in uplink
and/or in downlink direction.
The QoS information includes the QoS class identifier (authorized QoS class for the
service data flow), the Allocation and Retention Priority (ARP) and authorized bitrates
for uplink and downlink.
The 3GPP standards provide mechanisms to drop or downgrade lower-priority bearers
 in situations where the network become congested. Each bearer has an associated
allocation and retention priority (ARP). The network looks at the ARP when
determining if new dedicated bearers can be established through the radio base
station.

 GBR Bearer: For GBR Bearer’s MBR UL, MBR DL and GBR UL, GBR DL AVP’s are
present along with the QCI value. QCI Value informs the type bearer that needs to be
created. GBR bearers are used for real-time services, such as conversational voice
and video. A GBR bearer has a minimum amount of bandwidth that is reserved by the
network
 Non GBR Bearer: For Non GBR Bearer APN AMBR UL and APN AMBR DL AVP’s are
present. Non-GBR bearers, however, do not have specific network bandwidth
allocation. Non-GBR bearers are for best-effort services, such as file downloads,
email, and Internet browsing. These bearers will experience packet loss when a
network is congested

The QCI specifies the treatment of IP packets received on a specific bearer.

QCI values impact several node-specific parameters, such as link layer configuration,
scheduling weights, and queue management.

The 3GPP has defined a series of standardized QCI types, which are summarized in
the below Table
Based on QCI values different services can be treated differently. Like some services
will require a dedicated bearers while some may work via a non-dedicated bearers.
Also the priority to these services has been defined.

Table 1: Quality of Class Indicator

The charging parameters define whether online and offline charging interfaces are
used, what is to be metered in online/offline charging, at what level the PCEF shall
report the usage related to the rule, etc.
For different PCC rules with overlapping service data flow filter, the precedence of the
rule determines which of these rules is applicable. PCC rule also includes Application
Function record information for enabling charging correlation between the application
and bearer layer if the AF has provided this information via the Rx interface. For IMS
this includes the IMS Charging Identifier (ICID) and flow identifiers.

2.3 LTE HSI

For LTE HSI service, any one of the PCC rule (Dynamic or Predefined) will be installed
according to the requirement.
PCRF uses the subscriber profile in the SPR and install the rule based on subscriber
profile.

Input for policy decision:

The following important parameters will be considered by PCRF. There may be other
parameters in the SPR which will be used by PCRF. But these parameters will be
decided based on use case.

Table 2: SPR Parameters

Output given by PCRF:

Any one of the PCC rule (Dynamic or Predefined) will be installed according to the
customer requirement.

Table 3: PCC Rule Name

The below call flow explains about interaction of PCRF with SAE-GW using dynamic
PCC rule in LTE.
 Figure 2: LTE Call Flow – Dynamic Rule

The below call flow explains about interaction of PCRF with SAE-GW using predefined
PCC rule in LTE.
 Figure 3: LTE Call Flow – Predefined Rule

2.4 VoLTE

For VoLTE service, Dynamic rule will be installed based on any one of the following.

 Codec – Based
 AF-Application-id
 Requested Bandwidth AVP from P-CSCF
 Operator Defined Policy

Table 4: PCC Rule for VoLTE

PCRF will install the rule without any charging details for the IMS call to the SAE-GW.
IMS node will interact with charging server for the IMS call. SAE-GW will use the
default configuration regarding IMS call for charging server interaction.The below call
flow explains about interaction of PCRF, SAE-GW and OCS based on dynamic rule sent
by PCRF in CCA message for the IMS call.
 Figure 4: VoLTE Call Flow

3. PCRF Call Model

The following call model needs to be considered in calculating the TPS in each
interface. This is Standard Call Model.

 UE Attach
 UE Detach
 Internet Access using DPI in the network
 Internet Access using L4L7 Optimizer in the network
 Bandwidth Boost
 VoLTE – Outgoing Call
 VoLTE – Incoming Call

Call Model 1: UE Attach

Please find the below call flow for UE attach using SAE-GW and corresponding TPS
calculation.
 Figure 5: UE attach

Call Model 2: UE Detach

Please find the below call flow for UE detach using SAE-GW and corresponding TPS
calculation.
 Figure 6: UE detach

Call Model 3: Internet Access using DPI in the network

Please find the below call flow for UE accessing the internet and DPI in the network
and corresponding TPS calculation. Assume, UE is already attached in the network.
Figure 7a: UE accessing internet and DPI
 Figure 7b: UE accessing internet and DPI

Call Model 4: Internet Access using L4L7 Optimizer in the network

Please find the below call flow for UE accessing the internet and L4L7 Optimizer in the
network. Assume, UE is already attached in the network.
 Figure 8: UE accessing internet and L4L7 Optimizer

Call Model 5: Bandwidth Boost

Please find the below call flow for Bandwidth boost and corresponding TPS calculation.
Assume, UE is already attached in the network.
 Figure 9: Bandwidth Boost

Call Model 6: VoLTE – Outgoing Call

Please find the below call flow for VoLTE (Outgoing Call) and corresponding TPS
calculation. Assume UE is already attached in the network.
 Figure 10: VoLTE – Outgoing Call

Call Model 7: VoLTE – Incoming Call

Please find the below call flow for VoLTE (Incoming Call) and corresponding TPS
calculation. Assume UE is already attached in the network.
 Figure 11: VoLTE – Incoming Call

What happens when a user performs a voice call

from an LTE/4G network?
Overview
While making a voice call may seem simple, largely depends on the scenario where the
user is, and alternatives available for its completion. So it is necessary to understand well
what are all the possibilities and the most important concepts of these key scenarios.

In the first generation of cellular networks, the communication through voice calls was the
main goal, and was based on a circuit switched topology or 'Channels' (CS Circuited
Switched).

Over time, the need for data services has emerged. Voice calls also have come into
existence with these new services. As demand increased, these new services were
supported by a new domain, the IP-based Packet-Switched (PS). The following figure
shows how these two domains work.
In LTE (4G) system we had another great change: the CS domain has been extinguished!
(Ruled Out/ No CS domain). LTE networks are based exclusively only on the PS domain,
and voice services should be carried out in other ways (as we shall see).

But as we mentioned, regardless of network topologies, voice services are still needed. (Of
course, they slightly decreased compared to a few years ago, but are still significant, i.e.
their demand continues).

With the continued growth of LTE networks, let's try to understand a little more the
concepts, alternatives and solutions for any user to make a voice call on an LTE network?

How, When and Where?

First of all, we need to understand how, when and where voice calls can occur.

In the 2G legacy networks, voice calls are made practically only on circuits - for each call
(CS domain).

In 3G legacy networks, voice services can use the CS domain, but can also be made
through OTT (Over The Top) solutions, applications that encapsulate the voice and
transport via an IP domain (PS), but who lack the QoS requirements needed to ensure good
communication - with the Non-GBR type of services (no bit rate guarantee).

For Example: Skype.

Note: It is very unusual, but it is also possible to make OTT voice calls on 2G networks.
In fact, there may be OTT solutions in any technology - it can be used in legacy networks,
and also in others such as Wi-Fi - which are already commonly used for VoIP.
And in LTE networks, voice calls can be fully IP-based, can use OTT solutions via 4G, or be
transferred to the legacy 2G/3G.

As we begin to see, there are many alternatives. As usual, we will easily see each one.

Note: We will always refer to voice calls (Mobile Originating (MO) and/or Mobile
Terminating (MT));
However, SMS services are also included.

Alternative to voice calls in a generic 2G-3G-4G

Network Topology
And the best way to understand the alternatives or possibilities of making voice calls in LTE
network (4G), it is to start from a 2G-3G-4G network topology very simplified - considering
only the main elements involved.

As we can see in the following figure, the LTE (EPC) has no direct 'link' to the CS network -
as we have seen, it is designed to take care of purely IP (PS) calls. It has no Media
Gateway directly connected, so no CS call is supported by the MME.
In other words, if the user or UE (User Equipment) is on a LTE network, as shown in the
topology above, we cannot make a voice call.

Note: As mentioned before and according to the topology above, the only way to have voice
services in LTE would be through OTT services such as Skype. However, this solution is
not discussed here.

If we understand this, it is also easy to realize that in order to have voice services in LTE,
changes need to be made. There are some alternatives, and below we have the main ones:

 VoLGA (Voice over LTE via Generic Access): Use legacy 2G/3G as a generic
access, 'packaging' voice services, and delivering via LTE.

 CSFB (CS Fall Back): Whenever the UE need to place a call, make it revert
(fallback) for legacy networks 2G or 3G.

 VoLTE (Voice over LTE): Make voice over LTE itself. In this case, the voice is pure
IP - VoIP LTE.

 SRVCC (Single Radio Voice Call Continuity): Ensure that purely LTE (VoLTE)
calls are transferred (via handover) to the legacy networks in a transparent manner.

Note: Notice that the SRVCC is an option when the voice call has been established in
LTE.
I.e. it is a conditional alternative - considering that VoLTE option has been used.
Even without knowing very well the options presented, it is easy to imagine that the 'best'
solution would carry voice over their own LTE network. But like everything in life, it also has
the other side, the pros and cons.

To deliver voice services in LTE network is necessary to have an infrastructure that support
it. In other words, there needs to be exist an IMS (IP Multimedia Subsystem or IP
Multimedia Core Network Subsystem). If an IMS is available, then the voice over LTE may
be provided as long as a minimum set of IMS functionality and entities also are present.

Note: IMS is much more complete, and have more other purposes than the voice.
The voice is just one of the 'applications' of IMS, as we'll see soon.

This minimum set of features and entities of the IMS (called VoLTE or One Voice) was
standardized to enable LTE operators to provide voice services without having to make very
radical changes in the network (without having to invest in a complete IMS, with all entities
and functionality).

In any case, it requires investment.

And therefore the first two alternatives become attractive based on legacy network CS
infrastructure. But if on the one hand such alternatives require less investment in LTE
network, these alternatives depend on the existing 2G/3G networks.

Let's talk a little more about each of these possibilities, but always trying to maintain the
overview, in the simplest possible way to understand. Remember that our goal is to learn
the concept, in order to enable a deepening on the subject, if desired, more easily.

1. VoLGA - Voice over LTE via Generic Access

The first implementation alternative that emerged was the VoLGA, tried to use what are
already available, with minimal changes required.

To use the infrastructure of legacy 2G/3G networks, VoLGA introduces a new network
entity, the VNC (VoLGA Network Controller), which basically functions as a 2G BSC,
communicating with a GSM MSC (Mobile Switching Center) and as one 3G RNC
communicating with a UMTS MSC (Mobile Switching Center).
When we have a new call (be it originated or terminated), it is managed by the MSC of
legacy network. VNC is who mediates the voice signal and its related messages between
the MSC and the LTE network.

Although it is possible to carry out the delivery of voice and SMS services to users of LTE,
the VoLGA was unsuccessful. This is because, as we have seen, exclusive investments are
needed for this purpose. At the same time however, global efforts to VoLTE increased (eg
investments in IMS), and thus this alternative eventually failed into disuse.

2. CSFB - Circuit Switched Fall Back

On one hand operators follow seeking a complete LTE infrastructure (with full IMS) to meet
multimedia services and also purely LTE voice, this is not a topology that is available in the
short and even medium term.

While that reality doesn't come, we must use the legacy network when there is the need of
voice and SMS delivery to LTE users.

And the most common alternative to this is the CSFB (CS Fall Back), an interim solution
until we have full support for voice over LTE.

At CSFB scheme, whenever there is a demand for a new voice call, the LTE user is
'backed' for a CS legacy network, assuming that this provides an overlapping coverage. In
other words, with CSFB, a voice call is never active in LTE, but in legacy networks.

At the end of the call in the legacy network, the UE can re-register the LTE network.

It goes something like this: the UE is registered (also) in the legacy network. When it got a
call, the legacy network tells to LTE network: 'I have a call to the UE, can you ask it to come
here and make the call?'
To CSFB be possible, users must be using dual mode devices, i.e. able to operate both in
LTE network and in the legacy network.

To support CSFB, a new interface is introduced: the SGs, connecting the MME to the
legacy MSC.

As the CSFB is currently the most widely used option by several operators, let's see some
basic scenarios of it (CSFB).

2.1. CSFB - Registration and Location

When the CSFB UE is turned on, it registers itself in the two networks: LTE and legacy
network (CS). And to allow quick transfer to the legacy network either 2G or 3G when
necessary, the LTE network needs to know the location of the UE.

For this, the MME, which tracks the location of the UE in the LTE network, continuously
provides location information to the legacy MSC, using the new SGs interface.

The set of SGs messages then supports management of mobility, paging and SMS.

2.2. CSFB - Originated Call

We will continue, and assume that the UE is initially covered by the LTE network, and that
there is an active IP connection.

When the UE decides to originate a voice call, it sends an SRM (Service Request Message)
to the MME (more specifically the ESR - Extended Service Request).

The MME checks whether the UE is CSFB capable, and notifies the eNodeB to transfer the
UE to the legacy network.
Before performing the UE transfer, the eNodeB can ask it to make RF measures on
neighboring 2G/3G network. The eNodeB then decides the best network for the UE and
performs the transfer.

Once the UE camp in 2G/3G network, it starts the call procedure as usual - the UE starts
the call control procedures in legacy network.

2.3. CSFB – Call + Data Connection in LTE

And what happens if I have an active data connection in the IP LTE network, and decide to
make a voice call?

There are two options:

 The data are also transferred to the legacy network, or

 The data are temporarily suspended, until I return to the LTE network.

Although the first option seems the best, we must take into account that the transmission of
IP data is also transferred: it can operate at much lower speeds (legacy systems). In
addition, it may be that the legacy networks deny the IP session due to lack of resources or
for not being able to process it.

The S3 interface is used to carry out the PS session handover for 3G (in this case, the DTM
- Dual Transfer Mode must exist, but this details escapes form our theme).

There are no 4G data handover supported to 2G - in this case, the data is suspended.

The eRABs 4G are released when the UE performs the CSFB.

An important information is that the S3 is a 'new' interface between MME and SGSN on
GTPCv2. And to support it, the SGSN needs to be updated (most carriers do not want to do
this without a strong justification).

And Gn interface is already on GTPCv1, which is the native GTP version for 3G networks.
So in this case only the MME needs to be updated, and as it is a relatively new node, it is
probably easier to do. Not to mention that the new SGSN may have native support for S3.

2.4. CSFB - Terminated Call

Finally, we have the case of a terminated call for LTE user.

The call request arrives first to the MSC where the UE was previously registered.

When the MSC receives call request, it sends paging messages to the related MME via
SGs interface.

This message is forwarded to the UE, which is still connected to the LTE network.

If the user accepts the call, it sends an SRM (Service Request Message) to the MME.
The then MME notifies the eNodeB to transfer the UE for the legacy network, and the
eNodeB then decide the best network for the UE to make the call.

2.5. CSFB – What happens after the end of the CS call?

We have seen that the 4G eRABs are released when the UE performs the CSFB. But what
happens when the UE ends the CS call?

About what should follow next (if the UE should return or not to LTE as soon end the call
CS), there is no specific rule.

Anyway, the main possibilities are:

 The upper layers forcing the 'reselection' to LTE so that the UE enters idle mode in
legacy network.

 The operator send LTE 'redirection' information in RRC connection release message
of legacy 3G network after the call is finished. This will result again in reselection to
LTE.

The lower layers (AS - Access Stratum in this case URRC or GRR) reselect to LTE if the
reselection criterion is satisfied. In most cases, operators have their parameters set such
that the reselection to LTE happens if there is a good LTE coverage area overlapping the
legacy network.

3. VoLTE – Voice over LTE

Everything we have seen so far is based on the making of voice call in the legacy network.
But as we have seen these are 'temporary' solutions until the 'final' solution - VoLTE - is
available.
And the final LTE voice solution (Voice over IP, or more specifically VoLTE) uses the IMS
backbone. An example of network topology supporting VoLTE is shown in the following
figure.
To make voice calls, LTE networks need to have an IMS. When the first LTE networks
appeared, they had no IMS, and without IMS, it was not possible to make any calls to any
PSTN or CS.

We have spoken of the IMS before, but let's remember.

3.1. IMS – IP Multimedia Subsystem

IMS is a backbone (network) at the application level, which works on top of other wireless
networks and not just the LTE (as 3G, 2G, Wi-Fi and others).

Its concept is quite broad, and to understand it with all its entities, possibilities, interfaces,
protocols, and possibilities is an extremely difficult task, even for the most experienced in
the subject.

The IMS is not new: it already existed before the LTE (as well as other entities, such as the
EPC PRCF, which also is not new!).

Its complete specification consists of thousands and thousands of 3GPP standards. But
let's try to understand in a simpler way than that found there.

As its name suggests (IP Multimedia Services), IMS offers several multimedia IP services,
including VoIP (Voice over IP). In IMS, voice is just 'another' service!

IMS brings together voice features such as authentication, service authorization, call
control, routing, and interoperability with PSTN, billing, additional services and VAS.
None of these exist in the EPC: this is the reason why the pure EPC without IMS cannot
process a voice call.

In other words, for VoLTE, access is made by the SAE (eUTRAN + EPC), while voice
service lies in the IMS.
An analogy we can do is to consider the IMS being a car. And the LTE voice, as our shuttle
service (to go from one place to another).

 We can buy a very basic car - Basic 1.0 engine, wheels, steering wheel and other
minimum parts: yes, we can go from one place to another.

 Or we can buy a 'connected' car - ultra modern, powerful, tetra-fuel, with all the
safety features, ABS, Air bag, connected to the Internet, etc. we also go from one
place to another ... but we can make several other things as well!

That's more or less what happens with the IMS. It is used in conjunction with the LTE
network to support voice: both full IMS implementation and also the minimum IMS
suggested implementation for Voice over LTE.

But the telecommunications industry would rather not invest in a full IMS, or at least did not
have sufficient reason to do it immediately. And for the adoption of the simpler IMS voice
solution, appear the VoLTE initiative, which specifies a minimum set of features, and selects
a simple choice when multiple options exist for certain features.

However, not all of these features are required for delivery of basic voice services by the
LTE network.

So let's illustrate with a diagram (extremely simple) the implementation of a voice in IMS
(VoLTE).

 Let's assume that we will make a VoLTE call with a CS network whatsoever, for
example the PSTN (Public Switch Telephony Network).

 And consider in the IMS only two simple elements, one for the control plane (with
signaling) and one for the user plane (with voice).
  And the entry being the SAE, or LTE network.

 In IMS, the control element would be a SIP server (soon we will talk about SIP - for
now just understand that when we have a call request to this server, it sets up the
call.); and the user element would be a Media Gateway.

In comparison with the legacy networks, the SIP Server is equivalent to the MSC in the
mobile network topology and the media gateway is equivalent to a typical Media Gateway
on any network topology, which is common in virtually any voice network to handle calls.

The above concept is valid, but in practice the IMS consists of much more entities, as seen
below.

Note: Not all possible/existing entities and interfaces

are shown in the figure.
Let's quickly see a little about these key elements.

Note: Do not worry or try to understand everything now about these elements.
Remember that our goal here is not that.
Anyway, it's worth a read.

The MGCF (Media Gateway Controller Function) is the control element that
communicates with other PSTN networks. It is significant because it has to inter-networking
function: can speak SIP, can speak ISUP, and can speak other signaling protocols.

The IM-MGW (IM Media Gateway) is the element that takes care of voice functions for
example making protocol translation required to support the call. More specifically between
the Real Time Transport Protocol (RTP) to analog format or basic PCM in the CS network
and vice versa.

The HSS (Home Subscriber Server) is an element that also exists in the LTE EPC (although
appeared first in IMS), and its functions are similar.

The MRF (Media Resource Function) provides many services related to voice, such as
conferences, announcements, voice recognition and so on. It is always divided into two
parts, the MRFP (Media Resource Function Processor), for media streams, and the
MRFC (Media Resource Function Controller) that functions basically as an RTP 'mixer'.

An important concept, and that's worth stand out here is the Proxy, for example to make
filters, identify where the users come from, the cases of roaming, etc. Remember that we
are talking about an IP network. Instead of the users to speak directly with the SIP server,
they use the proxy.
The CSCF (Call Session Control Function) has some variations.

 Proxy-CSCF (P-CSCF) among other tasks provides QoS information related to the
LTE network. Access an AF to voice service, and provides the control functions
'policy' and 'charging' to the PCRF.

 Interrogator-CSCF (I-CSCF) is an interrogator and the

 Serving-CSCF (S-CSCF): the CSCF server acts as a central node.

The BGCF (Border Gateway Control Function) functions as a routing table and acts to help
the S-CSCF. It has basically routing decisions.

As we speak, the IMS voice is a 'service' - the IMS is a services 'facilitator'. The IMS
services are provided through AS (Application Servers).

One such application is the voice. And there are also video services, conference, etc.

In fact, sometimes the AS are not considered as part of IMS (when we understand the IMS
as a CORE).

And in IMS, the standard AS for voice is the MMTel (Multimedia Telephony Service),
sometimes called MTAS (Multimedia Telephony Application Server).

The SBC (Session Border Controller) is an element of the edges of the IMS to control
signaling and often the media streams involved in calls.

The S-CSCF will be responsible for call routing depending on where the other user (the
other party) are:

 A SBG (Session Border Gateway) if the other party is in IP domain;

 A MGC/MGW if the other party is in the CS domain (PSTN/PLMN).

IBCF and TrGW are not shown in our figure, but are respectively the control and user plane
for other IMS networks, other SIP networks in general. They are similar to the MGCF/IM-
MGW - the requirements for reaching one or another type of network are different, so also
have separate parts for performing the same functions but with different networks.

3.2. SIP – Session Initiation Protocol

To support telephone signaling between the LTE network and telephone networks, the IMS
uses SIP (Session Initiation Protocol). SIP is a standard protocol for establishing voice calls
over IP networks.
The code is open, and uses the 'request-response' model to allow communication sessions.

There is a set of standard commands that can be used to initiate, manage and terminate
calls between two SIP devices.

The SIP has been adopted by IMS standardization as the protocol to allow signaling
between telephone networks and VoIP networks.
SIP is text-based and was developed - in the 90s - in order to be simple and efficient, just
like the HTTP protocol (in fact, was inspired by HTTP and other protocols such as SMTP).

A good analogy is to compare the SIP with HTTP.

You probably can understand well the HTTP interaction principle, which allows audio
connection, text, video and other elements on a web page. With SIP is pretty much the
same thing: it allows the establishment, management and calls endings (or sessions) for IP
multi-users without knowing the content of the call. A session can be a simple telephone call
between two users, or a multi-user multimedia conference.

Both (SIP and HTTP) take the control of the application to the end user, regardless of the
transport protocol (SIP is a control protocol in the application layer), so there is no need for
switching centers/servers.

The SIP however is not a resource reservation protocol, and has nothing to do with QoS.

To try to understand it better, let's see a simplified example for a voice call establishment
process using IMS platform and SIP signaling.
 Initially, the UE sends a SIP message like 'Invite', containing the description of one
or more measures for the voice session (Initial SDP - Session Description Protocol -
Offer).

 Then the P-CSCF forwards this same message to the S-CSCF (which has been
identified during the registration process).

 All going well, the termination network will have sent a message of type 'offer
response' to the S-CSCF, and this sends this message to the P-CSCF, authorizing
the allocation of the resources necessary for this session.
  Finally, the P-CSCF forwards the 'offer response' message back to the UE, which
confirms the receipt of the 'offer response' message and the resource reservation is
started.

This is a very simplified example of how you can be getting (origination) of a voice service
by the UE, via IMS.

Several other diagrams exist, with far more complex scenarios, but the basic idea can be
seen above, and extended if necessary.

Now seeing the case where an initially established call on IMS has to be 'transferred'.

4. SRVCC - Single Radio Voice Call Continuity

Finally, we come to our last alternative listed at the beginning of this SRVCC (Single Radio
Voice Call Continuity).

The SRVCC however is not an alternative for delivery, but a rather a handover process of a
voice call previously started in the LTE (whether One Voice - VoLTE LTE or IMS Full
Voice).

It is a call transfer method (handover), in a simplified and reliably way, when an LTE user
has an active voice session in IMS and is moving to areas without LTE coverage, but with
legacy 2G/3G coverage.

The main advantage is that the call will not drop - will only be transferred to the CS domain
of the legacy networks.

If in the above case the UE moves out of LTE coverage area with an active call (but goes to
legacy 2G/3G coverage), we must maintain the continuity of this active voice call. In this
case, the SRVCC is used: the procedure where the context of an active voice call on the
IMS is transferred to the CS legacy network (e.g. IMS node context transfer to the MSC).
The challenge with SRVCC is to perform the handover while the UE is connected to only a
single radio at any given moment.

There are two versions of SRVCC:

 SRVCC handover to GSM or UMTS, defined by 3GPP;

 SRVCC Handover to 1xRTT networks defined by the 3GPP2.

To allow SRVCC both the UE and LTE networks, as also the legacy, must support SRVCC.
For this, a new special SV interface is introduced between the MME and the MSC, which
runs on GTPv2 protocol.
To support SRVCC, the IMS network should also include an application server, called SCC
AS (Server Centralization and Continuity Application Server).

This application server is who manages the signaling required for the process.

Let's see a simplified example of some SRVCC procedures from LTE to GSM.

 When an UE that supports VoLTE is in an LTE coverage area, it starts voice

sessions via the IMS network, which will host the session and provide applications
and session control based on SIP.

 When the UE moves from an LTE coverage area for a CS 2G/3G coverage area,
with the active IMS session, the IMS switches the session to the CS domain,
maintaining both parts aware of the handover session.

4.1. Example of SRVCC Handover

Realizing that its LTE signal level begins to decrease, the UE with an active IMS voice
session signals it to the eNodeB, initiating the SRVCC handover.

The eNodeB then identifies the best available network to receive the service, and sends the
handover request (specifying that it is the SRVCC type) to the MME.

The new voice call request is then sent to the IMS, using a SR STN (Session Transfer
Number for SRVCC) - a unique number that is generated by each UE, and is stored in HSS.

This unique number is sent by the MME to the HSS when the UE first comes into contact
with the network.
Upon receiving the STN SR number, the SCC AS believes that the corresponding call
should be transferred to a different network, and starts the redirecting process for the
transfer point (handover) to the legacy network.

After resource preparation is completed, the MME confirms the handover request,
previously provided by the eNodeB.

The eNodeB then transmits this acknowledgment to the UE, while still providing the
required information about the target network.

In the final stages, the UE is detected in legacy networks, and the call is re-established in it.

Thus we have the completion of the SRVCC handover.

Voice packets and also packets that are not voice can be transferred using this method, but
the data rates will be limited by the capabilities of the legacy networks.

Once the SRVCC is a procedure for inter-RAT handover based on IMS LTE network to the
CS legacy network 2G/3G, it is much more complex than that of handovers legacy networks
3G / 2G. The question is how to maintain a handover performance comparable to or better
acceptable.

In order to improve the performance of the SRVCC handover, one WI (Work Item) called
eSRVCC (SRVCC enhancement) was established in the 3GPP SA2 in Release 10. The
anchoring solution is based on the IMS, and introduces new entities ATCF (Transfer Control
Access Function) and ATGW (Transfer Access Gateway).

Again, the deepening of this subject escapes from our goal.

Finally, we will enumerate some of the main advantages and disadvantages (or pros and
cons) of each alternative.

5. Advantages and disadvantages of each alternative

Call setup time: When operators use CSFB, one of the biggest problems faced (and one of
the major disadvantages of CSFB) is the increase in call setup time due to retuning
procedures in 2G/3G radios.

An efficient CSFB solution requires the TAC -> LAC mapping is so that the fallback to an
external MSC/LAC be avoided, since this will further increase the call setup time.

Call quality: call quality in LTE is better when compared with the same third-party
applications (OTT). This is due to specific QoS allocated to the call IMS, which may not be
present in common data applications.

Resource limitations for VoLTE: AMR-NW LTE requires much less resources and data
rate than GSM, and we will have many more users on the same bandwidth (spectral
efficiency).
Investment x Current Network: if everything is 'working well', what would be the reason for
investment, since surely such investments generate resistance from commercial and
business areas?

The comparison that must be done is: Investment versus (all) Benefits of IMS/MGW/BGCF.

Future: In any way all that discussion hereafter will more significance. Currently we still
have extensive legacy networks, capable of supporting these voice calls.

In this case, it is no problem to continue using this available infrastructure. Resistance will
only decrease when such capacity also decrease. But in an LTE network, if the IMS is
supported can make a VoIP call. So why would we need to make a CS voice call?

CSFB v/s SRVCC:

 It is not necessary to implement both solutions (CSFB and SRVCC) at the same
time, if the network has a wide LTE coverage and a complete IMS backbone.

 If we implement CSFB, it means we will not make the call setup using existing IMS
Core, and that could take care of that call in LTE.

 In respect to the SRVCC: assuming the Backbone IMS is available. In this case, if the
register in the IMS is successful, the users do not need to do CSFB - A voice call can
be simply initiated in LTE network using IMS.

 CSFB is a service handover procedure while SRVCC is a coverage handover

procedure.

6. Case Studies and Analogies

With all that we have seen, let's imagine some scenarios.

First, imagine that you are in a network that does not have LTE IMS. Then the only way to
make a voice call, whether originated or terminated, is through using legacy 2G/3G.

You need to be redirected /released from LTE to legacy 2G/3G network to make a voice
call. Like a 'reselection' from cell LTE to the 2G/3G. Once the legacy network, you can
make the call normally, as you're already used to.

And so, you just saw the CSFB in practice!

Now suppose you are watching a video stream on 4G network, and receive a voice call. In
this case, you need to go to the 3G network (in idle mode), and get the resources for to
make that call in 3G.

After you end your voice call, you keep watching the video stream, but now in the 3G
network (the handover from 3G to 4G is not yet defined).

You just saw the CSFB with an active data call!

Now let's imagine that you are in another LTE network, this time with IMS. In this case, you
can make a voice call using IP packets.

We have just seen a VoLTE call!

Further, imagine that you are in one of these voice calls using packets in 4G. Suppose
further you reach your 4G cell coverage edge. So the only option to keep your call is to
handover it to the 3G (assuming this is the existing coverage). Your call will then continue
on the 3G network, but now as one CS voice call. SRVCC!

If the SRVCC is not supported, the call is dropped as soon as it leaves the LTE coverage
area.

If the SRVCC is supported, a set of messages are exchanged, and the voice call is
transferred (handover) from LTE IMS to CS domain of the 2G/3G network.

And so, we have just seen an example of SRVCC handover!

I hope this information has managed to be useful for you that somehow are interested voice
in LTE networks.

7. Conclusion
We saw in this in a very general way, the main ways to make voice calls (and SMS) in LTE
networks.

The options or alternatives depend on several factors, such as available network topology
and the operator's strategy.

Depending on the situation, the call can be originated in LTE via data applications (OTT
VoIP), be purely originated on LTE IMS (VoLTE), sent to be performed on other networks
through mechanisms developed for this purpose (CSFB) or transferred via handover - if
active VoLTE call - to a legacy network (SRVCC).

So, for a user who is a LTE coverage area, a number of considerations should be checked,
as the type of device that it uses (whether supports CSFB), if the LTE network has an IMS
that allows outgoing calls, if the cells supports SRVCC, etc.

Based on the concepts seen here, I hope you have a position to fully understand what
happens when a user performs a voice call from an LTE network.
What is HSS?
Subscribe Server is the main IMS database which also acts as database in EPC. The HSS is a super HLR that

combined legacy HLR and AuC functions together for CS and PS domains. In the IMS architecture, the HSS
connects to application servers as well as the Call Session Control Function (CSCF) using the DIAMETER protocol.

What is MME?
The Mobility Managemnet Entity is the main signaling node in the EPC. It is responsible for initiating paging and

authentication of the mobile device. It also keeps location inforamtion at the Tracking Area level for each user and is

involved in choosing the right gateway during the initial registration process. MME connects to eNBs through the S1-

MME interface and connects to S-GW through the S11 interface. Multiple MMEs can be grouped together in a pool to

meet increasing signaling load in the network. The MME also plays an important part in handover signaling between
LTE and 2G/3G networks.

What is eNB?
Evolved Node B (eNB) is the only mandatory node in the radio access network (RAN) of LTE. The eNB is a complex

base station that handles radio communications with multiple devices in the cell and carries out radio resource
management and handover decisions. There is no need for a centralized radio network controller in LTE.

What is P-GW?
The PDN Gateway is the link between the mobile device and the services that reside in an external packet network

such as IMS. An important task of P-GW is the allocation of user IP-address. The user may be connected to multiple
P-GWs depending on the types of services being used. Other important function in P-GW are support for charging,
packet filtering and lawful interception. A key responsibility of P-GW is to act as mobility anchor between 3GPP and
non-3GPP networks such as WiMAX.

What is S1?
S1 is a standardized interface between eNB and the Evolved Packet Core (EPC). S1 has two flavors, S1-MME for

exchange of signaling messages between the eNB and the MME and S1-U for the transport of user datagrams
between the eNB and the Serving Gateway (S-GW)

What is S-GW?
The Serving Gateway is the main packet routing and forwarding node in EPC. It also plays the role of a mobility

anchor in inter-eNB and inter-RAT handovers. Charging (based on Quality of Service for example) and packet

marking are other functions within this node. The S-GW connects to the MME via S11 interface and to eNB via the
S1-U interface. The interface between the S-GW and P-GW is S5/S8.

What is X2?
X2 is the designated name of a standardized interface between two eNBs in E-UTRAN. The X2 can be seen as a

logical connection between two eNBs over which user data and signaling messages are exchanged. The physical
implementation of X2 is vendor specific.

What are FFT, IFFT and DFT?

The practical implementation of OFDM and SC-FDMA in LTE is achieved by use of the Discrete Fourier Transforms.

The Inverse Fast Fourier Transform is used to convert the symbols from frequency domain to time domain in the

transmission chain and the Fast Fourier Transform is used to convert the time domain signal back into frequency

components (subcarriers). Channel estimation and equalization can be performed in the (easier to do) frequency
domain.
How does LTE increase spectral
efficiency?
LTE will use a number of techniques to achieve an efficient use of the available spectrum, measured in

bits/seconds/Hertz. Among these techniques we find Higher-Order-Modulation (up to 64QAM), Multiple Antenna
Techniques such as MIMO and using OFDMA on variable spectrum bandwidth (up to 20MHz).

What cell sizes are supported in

LTE?
LTE cell sizes may range from the femto-cell range for indoor/home coverage, to over 100km ( 62 miles). However, a
typical LTE cell size will be 1 to 5km (0.6 - 3 miles), and generally congruent with 2G/3G cell deployments.

What type of Radio Access

Technology does LTE use?
The RAT of LTE is based on OFDMA- Orthogonal Frequency Division Multiple Access with the possibility of using

multiple antenna techniques such as MIMO. Although OFDMA has been used in telecommunications for a long time,

it is only recently that advances in hardware have allowed it to become an economical solution in the wireless cellular
domain. A variation on OFDMA technique is used in the uplink direction known as SC-FDMA.

What is meant by a Flat

architecture?
In a flat or distributed radio network architecture, the base stations play a much greater role in Radio Resoure

Management (RRM) and other higher layrer functionalities thus eliminating the need for a centralized node such as
the Radio Network Controller (RNC). In LTE, RRM is located in the Evolved Node B (eNB) and there are RNCs. A flat
architecture reduces latency in the network.

What is the purpose of a default

bearer in LTE?
In LTE a default bearer is established after the initial registration procedure. This default bearer exists between the

mobile device (UE) and the P-GW. As a result, a session can be set up immedeatly without the need to "find" a P-GW
and allocate an IP address. Bearer characteristics can be modified at any time using reconfiguration messages.

What QoS classes exist in LTE?

LTE supports "End-to-End" QoS, meaning that bearer characteristic are defined and controlled throughout the

duration of a session between the mobile device (UE) and the P-GW. QoS is characterised by an index, QCI (QoS

Class Identifier), and the parameter ARP (Allocation and Retention Priority). Bearer types belong to two main classes

with guaranteed and non-guaranteed rates and LABELs will specifiy in more detail what values of packet delay and
loss can be tolerated for any given bearer.

What release is LTE?

A feasibility study for LTE as evolution of 3G UMTS standard was initiated in Release 7 (see Technical Report TR

25.912 and TR25.913). Today the LTE standards are part of 3GPP release 8 specifications, comprising the 36 series
as well as other release 8 specifications.

What is OFDM?
Orthogonal Frequency Division Multiplexing is a multi-carrier technique used in LTE and other advanced wireless

systems. In OFDM a high-rate bit stream is multiplexed into a number of narrow band subcarriers and transmitted in

parallel on different subcarriers which do not interfere with any other subcarrier in the cell. The orthogonality of
subcarriers allows many of them to exist in a given band without the need for in-between guardbands.
What types of channels are
defined in LTE?
The channel structure in LTE is modelled after UMTS. There are Logical, Transport and Physical channels defined in

LTE. Unlike UMTS however, there are no dedicated Physical Channels in LTE for transmission of user information,
since physical resources are shared.

What is MIMO?
Multiple Input Multiple Output is a multiple antenna technique where spatial multiplexing is used to increase data

rates over the air, in proportion to the number of antennas used. In MIMO, multiple transmitting antennas will carry

parallel bit streams thus creating multiple channels over the air. The receiver will use multiple antennas to extract

each "air stream" by cancelling the interference from other antennas when certain conditions are satisfied such as
good signal-to-noise ratio and a multipath-rich environment.

What is a radio resource in LTE?

A radio resource in LTE is a two-dimensional quantity with the dimensions of time and frequency. The time

component is measured in units of OFDM symbols and the frequency component corresponds to a number of

subcarriers each of which carries a modulation symbol. In LTE the smallest unit of radio resource allocatio is called a
Resouce Block (RB).

Is network sharing possible in

LTE?
Yes, LTE R8 does allow sharing of the E-UTRAN among multiple PLMNs. Network sharing was already a Release 6

feature in the 3GPP specifications.

What is SC-FDMA?
Single Carrier FDMA or DFT-Spread OFDMA is the uplink transmission method in LTE. The main benefit of SC-

FDMA in uplink is to reduce the high Peak to Average Power Ratio (PAPR) of the OFDM signal and this allows a

cheaper and easier implementation in the mobile devices. The lower PAPR is achieved by sending symbols
effectively in series and not in parallel as is done in OFDMA.