Documente Academic
Documente Profesional
Documente Cultură
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.
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.
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
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:
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.
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
Figure 3 shows by which entity the QoS parameters set in EPS entities are provided.
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.
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 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.
❹ [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).
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)
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.
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.
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.
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 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.
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
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.
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.
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
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.
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:
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.
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 = 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)).
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.
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:
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.
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.
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.
■ 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.
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.
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
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.
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).
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.
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.
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
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
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.
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.
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.
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.
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 MME is in charge of all the Control plane functions related to subscriber and session
management. From that perspective, the MME supports the following:
The MME is linked through the S6 interface to the HSS which supports the database
containing all the user subscription information.
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:
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.
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).
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 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:
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.
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:
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.
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:
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.
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.
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.
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.
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.
Legends:
PCEF: Policy and Charging Enforcement function
TDF: Traffic Detection Function
AF: Application Function
BBERF: Bearer Binding and Event Reporting Function
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
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.
(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 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
(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.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 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
(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.
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
With the ability to push policy control beyond the network core to its edge, operators can
develop creative strategies to:
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.
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
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.
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
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
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.
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 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.
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.
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.
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
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
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
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?
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).
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.
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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: 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.
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:
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.
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).
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'.
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.
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 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.
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.
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).
Finally, we will enumerate some of the main advantages and disadvantages (or pros and
cons) of each alternative.
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?
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.
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.
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).
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.
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.
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).
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.
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.
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.
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.
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.
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).
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.