LTE . 3GPP RELEASE 8


Policy and Charging Control in the


Evolved Packet System


Jose-Javier Pastor Balbas, Ericsson, Spain
Stefan Rommer and John Stenfelt, Ericsson, Sweden

ABSTRACT

Policy and charging control provides operators
with advanced tools for service-aware QoS and
charging control. PCC for the evolved packet system,
defined as part of the 3GPP Release 8 specifications,
has evolved significantly from previous
releases to support multiple-access technologies,
roaming, and mobility. Within the PCC framework,
a number of protocols have been specified
to implement these functions. This article
describes key PCC concepts and explains additional
amendments to support PCC in the EPS.

INTRODUCTION

Over the years, policy control in the Third Generation
Partnership Project (3GPP) has evolved
with different features and different architectures.
This article provides an overview of the
Release 8 policy and charging control (PCC)
architecture [1] as it applies to the evolved packet
system (EPS) [2, 3]. The target date for the
completion of Release 8 was December 2008.

This section contains a brief background on
the evolution of PCC in 3GPP. The next section
provides an overview of the PCC framework and
presents the architecture and enhancements
required to support multiple-access technologies
in the EPS. Then, we introduce basic PCC concepts,
such as how rules are used to make PCC
decisions, how these decisions are bound to the
access network bearers, how they are renewed,
and how they are enforced. The following section
provides an overview of PCC roaming and different
roaming scenarios. We then describe the protocols
defined within the PCC framework. The
article concludes with a short summary.

The requirement for resource reservation and
access control for individual Internet Protocol
(IP) flows arose with the introduction of the IP
multimedia subsystem (IMS) in 3GPP Release 5
(completed in 2002). This requirement was
addressed by service-based local policy (SBLP)
functionality within the IMS domain [4], which
provided bearer-level QoS control and service-
level access control. The SBLP architecture was
influenced by the policy control framework
defined by the Internet Engineering Task Force
(IETF) [5] and efficiently connected the IMS and
the general packet radio service (GPRS) domains.

SBLP was enhanced further in Release 6 (completed
in 2005) by separating it from IMS, thus
allowing SBLP to be used by generic services.

Meanwhile, market demand for increasingly
sophisticated charging models, for example,
those based on application-layer services and
content, resulted in the introduction of the flow-
based charging (FBC) architecture in Release 6
[6]. FBC enables charging on a per-service basis
for both offline (charging data record [CDR]based)
and online (e.g., pre-paid) models. FBC
provides operators with a centralized mechanism
for controlling access to pre-defined services and
content, for example, access to a certain Web
page or a movie. In addition to pre-defined services,
the FBC architecture also provides access
control and charging for dynamically defined
services, for example, IMS-based services.

SBLP and FBC architectures were very similar.
This resulted in mutual interference because
both architectures were based on a central node
capable of making decisions, and both had the
same anchor points: the application function
(AF) in the control plane and the gateway GPRS
support node (GGSN) in the user plane. This
problem was addressed in 3GPP Release 7 (completed
in 2007) where SBLP and FBC were
merged into a common solution called PCC.
PCC is a service-aware control architecture providing
operators with a standardized mechanism
for QoS and charging control applicable to both
IMS and non-IMS based services.

THE PCC ARCHITECTURE

OVERVIEW

Release 8 enhances the basic PCC architecture
developed in 3GPP Release 7 by adding new
functionality, reference points, and functional
entities.

The evolved packet core (EPC) defines a single
core network for multiple heterogeneous
accesses. Because PCC was designed to be
access-agnostic in Release 7, it is easily adaptable
to EPS. However, amendments are required
in Release 8 to accommodate new EPS architectural
requirements. These requirements include:
support for mobile IP-based protocols in the
EPC, roaming, and mobility between heterogeneous
accesses.

0163-6804/09/$25.00 ⓒ 2009 IEEE IEEE Communications Magazine . February 2009


n Figure 1. 3GPP Release 8 PCC non-roaming architecture for EPS. Note that only a subset of the EPS ref-
erence points and EPS network entities are shown.
GERAN
UTRAN
Operator’s
IP services
PCEF
BBERF
Access GW
BBERF
Serving GW
Non-3GPP
access
E-UTRAN
AF
Rx
PCRF
OCS OFCS
S2a
Gxa
S5
Sp
Gxc
SPR
Gx
SGiPDN
GW
GyGz
MME
SGSN
PCC control plane interface applicable to both “on-path” and “off-path” models
PCC control plane interface applicable to “off-path” model only
Contol plane interface for charging
User plane interfaces
GERAN
UTRAN
Operator’s
IP services
PCEF
BBERF
Access GW
BBERF
Serving GW
Non-3GPP
access
E-UTRAN
AF
Rx
PCRF
OCS OFCS
S2a
Gxa
S5
Sp
Gxc
SPR
Gx
SGiPDN
GW
GyGz
MME
SGSN
PCC control plane interface applicable to both “on-path” and “off-path” models
PCC control plane interface applicable to “off-path” model only
Contol plane interface for charging
User plane interfaces
The evolved packet
core (EPC) defines a
single core network
for multiple
heterogeneous
accesses. Because
PCC was designed to
be access-agnostic in
Release 7, it is easily
adaptable to EPS.
However, amendments
are required
in Release 8 to
accommodate new
EPS architectural
requirements.

The reference network architecture for PCC in
EPS is shown in Fig. 1.

The AF interacts (or intervenes) with applications
that require dynamic policy and charging
control. It extracts session information and provides
this to the policy and charging rules function
(PCRF) over the Rx reference point. The
AF also can subscribe to certain events that
occur at the traffic plane level (i.e., events
detected by either the policy and charging
enforcement function [PCEF] or bearer-binding
and event-reporting function [BBERF]). Those
traffic plane events include events such as IP
session termination or access technology-type
change. When the AF has subscribed to a traffic
plane event, the PCRF informs the AF of its
occurrence.

The PCRF is the policy engine of PCC. It
combines the session information received over
the Rx reference point and the input received
from the Gx and Gxa/Gxc reference points with
user-specific policies and data from the subscription
profile repository (SPR) to form session-
level policy decisions and provides those to the
PCEF and the BBERF. The PCRF also forwards
events between the BBERF, the PCEF,
and the AF.

The PCEF enforces policy decisions received
from the PCRF and also provides the PCRF
with user- and access-specific information over
the Gx reference point. It interacts with the
online charging system (OCS), which is a credit
management system for pre-paid charging and
reports usage of resources to the offline charging
system (OFCS).

In the PCC architecture for EPS, there are
two main architecture alternatives: with and

without BBERF in access gateway (e.g., serving
gateway [S-GW] or high-rate packet data
[HRPD] serving gateway [HSGW]). In this article
the two alternatives also are referred to as
“off-path” and “on-path” models, respectively.
The details regarding these two alternatives are
discussed below.

MULTI-ACCESS AND THE
OFF-PATH PCC MODEL


This section begins with a brief explanation of
why two architecture alternatives (with and without
BBERF) were defined for Release 8.

EPS allows for different mobility protocols
depending on which access technology is used
[2]. For the 3GPP family of accesses (global system
for mobile communications-enhanced data
rates for GSM evolution [GSM-EDGE] radio
access network [GERAN], universal mobile
telecommunications system [UMTS ] terrestrial
radio access network [UTRAN], and evolved[
E]-UTRAN), either the GPRS Tunneling Protocol
(GTP) or Proxy Mobile IPv6 (PMIPv6) can
be used. For connecting other accesses to the
EPC, any of PMIPv6, Dual Stack Mobile IPv6
(DSMIPv6) or Mobile IPv4 (MIPv4) can be
used. These different protocols have different
properties, which results in different requirements
for PCC.

The GTP, as defined by 3GPP in earlier
releases, not only supports functions related to
packet routing and mobility, but also the functions
that handle QoS, bearer signaling, and so
on. When the GTP is used in the EPC between
the S-GW and the packet data network gateway
(PDN GW), the PDN GW can control the QoS

IEEE Communications Magazine . February 2009


Another EPS requirement
on PCC is
handover within and
between
heterogeneous
accesses, for example,
to support the
scenario where the
terminal moves
between different
access GWs (BBERFs).
In this case, the PCRF
must handle the
BBERF relocation and
provide the authorized
QoS to the
new BBERF.

through the bearer procedures toward the serving
GW. The term “bearer” refers to a logical IP
transmission path between the terminal and the
network with specific QoS properties (capacity,
delay, packet loss error rate, etc.). The bearer
procedures are used to set up, modify, or remove
the bearers.

Because bearer procedures are supported by
the GTP and the PDN GW, the PCRF can control
the QoS through the Gx interface. Such a
model is referred to in this article as on-path. It
is so named because the QoS/bearer signaling
takes place (using the GTP) on the same path as
the user plane. The BBERF and Gxa/Gxc have
no role here.

Unlike the GTP, mobile IP protocols
(PMIPv6, DSMIPv6, MIPv4) are defined by
IETF for the express purposes of packet routing
and IP-level mobility. They are not used to set
up, modify, or tear down bearers or to signal
QoS parameters. When a mobile IP protocol is
used between an access GW (e.g., the S-GW)
and the PDN GW, the PDN GW has no knowledge
of the bearers. The BBERF was introduced
into the architecture to handle this situation.
The PCRF provides the authorized QoS to the
BBERF over the Gxa and Gxc reference points.
This model is referred to as the off-path because
QoS signaling takes place (through Gxa/Gxc) on
a path different from that of the user plane.

For EPS, the PCEF always is located in the
PDN GW. The BBERF location, however,
depends on the particular access technology. For
example, for the 3GPP family of accesses, the
BBERF (if applicable) is located in the serving
GW, whereas for eHRPD access, the BBERF is
located in the HSGW [7].

The architectural aspects discussed above
were added to PCC in Release 8 to support the
requirement for multiple accesses. Another EPS
requirement on PCC is handover within and
between heterogeneous accesses, for example, to
support the scenario where the terminal moves
between different access GWs (BBERFs). In this
case, the PCRF must handle the BBERF relocation
and provide the authorized QoS to the new
BBERF.

BASIC PCC CONCEPTS

POLICY AND CHARGING CONTROL DECISIONS

Policy control consists of gating control and QoS
control. Gating control is the capability to block
or to allow IP packets belonging to a certain IP
flow, based on decisions by the PCRF. The
PCRF could, for example, make gating decisions
based on session events (start/stop of service)
reported by the AF through the Rx reference
point. QoS control allows the PCRF to provide
the PCEF with the authorized QoS for a given
IP flow. The authorized QoS can, for example,
include the authorized QoS class and the authorized
bit rates.

Charging control not only implies service access
control by means of online credit management,
but it also contains important redirect functionality
that is used, for example, for advice of charge
and top-up of pre-paid accounts. The OCS may
authorize access to individual services or to a
group of services by granting credits for autho


rized IP flows. Usage of resources is accredited
on the form of a limited amount of time, traffic
volume, or chargeable events. If a user is not
authorized to access a certain service, for example,
in the case of an empty pre-paid account,
then the OCS may deny credit requests and, additionally,
instruct the PCEF to redirect the service
request to a specified destination (for account
top-up). As already mentioned, PCC also incorporates
service-based offline charging. However,
this functionality does not provide any means for
access control in itself. Instead, policy control
must be used to restrict access and then service-
specific usage can be reported to the OFCS.

The PCRF is the central entity in PCC-making
policy and charging-control decisions. The
decisions can be based on input from a number
of different sources, including:

. Operator configuration in the PCRF that
defines the policies applied to given services
. Subscription information/policies for a given
user, received from the SPR
. Information about the service received from
the AF
. Information from the access network about
what access technology is used and so on
An example use case for the on-path model is
illustrated in Fig. 2 and further described below:
1 The subscriber initiates a service, for exam


ple, an IMS voice call, and performs IMS
session signaling through the AF (proxy-call
server-control function [P-CSCF] in the
case of IMS).

2 Based on the service description information
contained in the application signaling,
the AF provides the PCRF with the service-
related information over the Rx interface.
This information typically includes traffic
parameters (e.g., IP addresses and port
numbers), as well as QoS information (type
of service, bit rate requirements).

3 The PCRF can request subscription-related
information from the SPR.

4 The PCRF takes the operator-defined service
policies, subscription information, and
other data into account when building policy
decisions. The policy decisions are formulated
as PCC rules and typically contain
information about the user-plane traffic
(packet filters in the form of IP five-tuple).
All IP packets matching the packet filters
of a PCC rule are designated a service data
flow (SDF). PCC rules also can contain the
authorized QoS (QoS class and bit rates)
and charging information, as well as an
indication of whether traffic is allowed
(gate open) or not allowed (gate blocked).
A subset of the available parameters in the
PCC rule is shown in Table 1.

5 The PCC rules are sent by the PCRF to the
PCEF for enforcement of the policy decision.
The PCEF is located in an edge node
where all the user-plane traffic for a given
subscriber and the IP connection passes.
For EPS, the PCEF is located in the PDN
GW.

6 The PDN GW/PCEF installs the PCC rules
and performs bearer binding to ensure that
the traffic for this service receives appropri-

IEEE Communications Magazine . February 2009


n Figure 2. High-level use case for PCC in the EPS for the on -path model.
AF
(P-CSCF)
PCRF
PCEF
PDN GW
4. Policy decision
6. Bearer binding
SPR
Access network
Appli-
cation
1. Application signaling (e.g. IMS)
2. Application information3. Subscription
information
5. PCC rule
6. Activate / modify bearer
7. Service data flow
detection
Access
interface
UE
AF
(P-CSCF)
PCRF
PCEF
PDN GW
4. Policy decision
6. Bearer binding
SPR
Access network
Appli-
cation
1. Application signaling (e.g. IMS)
2. Application information3. Subscription
information
5. PCC rule
6. Activate / modify bearer
7. Service data flow
detection
Access
interface
UE
Apart from
dynamically
provisioned rules
(based on IP five-
tuple filters) the PCEF
may be instructed by
the PCRF to take
predefined charging
rules into account in
the evaluation
process. The definition
of filters for
predefined rules is
not standardized.

ate QoS. This may result in the establish


ment of a new bearer or a modification of

an existing bearer. More details on bearer

binding are presented later in this section.
7 The PCEF performs SDF detection to

detect the IP flow for this service. This IP

flow is transported over the appropriate

bearer. More details on SDF detection can

be found later in this section.

For the off-path model, the PCRF also provides
the information about the authorized QoS
by sending so called QoS rules to the BBERF
over the Gxa/Gxc reference points. The QoS
rules contain the information required for the
BBERF to ensure that bearer binding (see
below) can be performed. Thus, the QoS rules
contain only a subset of the information of a
corresponding PCC rule and do not include any
charging-related information.

The policy and charging enforcement in
PCEF comprises several different aspects as discussed
below.

BEARER BINDING IN THE ACCESS NETWORK

PCC is responsible for the successful interaction
with the QoS procedures in the access network.

The PCC rule must be mapped to a corresponding
QoS conduit or bearer in the access
network to ensure that the packets receive the
appropriate QoS treatment. This mapping (i.e.,
bearer binding) function is one of the central
components of PCC. The mapping is performed
by the bearer-binding function (BBF) that is
located in the PCEF (for on-path) or in the
BBERF (for off-path). When the PCEF (or
BBERF) receives new or modified PCC or QoS
rules, the BBF evaluates whether or not it is
possible to use the existing bearers. If one of the
existing bearers can be used (e.g., if a bearer of
the corresponding QoS class already exists) the
BBF may initiate bearer modification procedures
to adjust the bit rates of that bearer. If it

is not possible to use the existing bearers, the
BBF must initiate the establishment of a suitable
new bearer. In particular, if the PCC rule contains
guaranteed bit-rate (GBR) parameters, the
BBF also must ensure the availability of a bearer
that can accommodate the GBR traffic for that
PCC rule. Therefore, the BBF must trigger
resource reservation in the access network to
ensure that the authorized QoS of the PCC rule
can be provided. Further details on the bearer
concept can be found in [8].

SERVICE DATA-FLOW DETECTION

The PCEF and the BBERF use the packet filters
of installed PCC and QoS rules to classify IP packets
to authorized SDFs. This process is referred to
as SDF detection. Incoming packets are matched
against the available filters of the installed rules in
order of precedence. If a packet matches a filter
and the gate of the associated rule is open, then the
packet can be forwarded to its destination (note
that online charging can prevent this in the PCEF).
For the downlink part, the classification of an IP
packet to an SDF also determines which bearer
should be used to transfer the packet (Fig. 3).

Apart from dynamically provisioned rules
(based on IP five-tuple filters) the PCEF may be
instructed by the PCRF to take predefined charging
rules into account in the evaluation process. The
definition of filters for predefined rules is not
standardized. These filters can take parameters of
higher layers into account; in that case they are
referred to as deep packet inspection (DPI) filters.

RENEWED POLICY DECISIONS DURING A
SESSION . EVENT TRIGGERS

During the lifetime of a session, the conditions in
the access network may change. For example, the
user may move between different access technologies.
There also may be situations where the authorized
QoS can no longer be maintained over the

IEEE Communications Magazine . February 2009


Type of element PCC rule element Comment
Rule identification Rule identifier Used between PCRF and PCEF for referencing PCC rules.
Items related to service data
flow detection in PCEF
Service data flow template List of packet filters for the detection of the service data flow.
Precedence Determines the order, in which the service data flow templates are
applied at PCEF.
Gate status Indicates whether a SDF may pass (gate open) or shall be discarded
(gate closed).
Items related to policy control
(i.e., gating and QoS
QoS class identifier (QCI) Identifier that represents the packet forwarding behavior of a flow.
control)
UL and DL maximum bit rates The maximum bitrates authorized for the service data flow.
UL and DL guaranteed bit rates The guaranteed bitrates authorized for the service data flow.
Charging key The charging system uses the charging key to determine the tariff
to apply for the service data flow.
Items related to charging
control Charging method Indicates the required charging method for the PCC rule. Values:
online, offline, or no charging.
Measurement method Indicates whether the SDF data volume, duration, combined
volume/duration or event shall be measured.

n Table 1. A subset of the elements that may be included in a PCC rule.
radio link. In these cases, the PCRF may re-evalu-ROAMING WITH PCC
ate its policy decisions and provide new or updated
PCC rules to the PCEF. The PCRF defines the PCC in 3GPP Release 8 supports roaming for
conditions when the PCEF (and BBERF, if appliboth
on-path and off-path scenarios. The sub-
cable) interact with the PCRF again. It does this by scriber can connect through a PDN GW in the
setting event triggers in the PCEF/BBERF. When home network or in the visited network. Howevan
event occurs, and the corresponding event triger,
control of enabled services and authorized
ger is set, the PCEF/BBERF reports the event to resources always are handled by a PCRF in the
the PCRF and allows the PCRF to revisit its previhome
network. A new reference point, S9, is
ous policy decisions. defined between PCRFs in the home and visited
When mobile IP-based protocols are used in networks to support certain roaming scenarios.
the EPC, the access-specific bearers terminate in For those roaming scenarios when S9 is used,
the BBERF instead of the PCEF. This implies the PCRF in the visited network can reject but
that much of the information about the access net-not change policy decisions coming from the
work (e.g., information regarding available QoS home network.
on the radio link, information on access type, etc.) The two main roaming scenarios are home-
is available only to the BBERF. This being the routed access and visited access (also known as
case, the BBERF detects events and reports them local breakout or LBO) (Fig. 5). In the home-
over the Gxa/Gxc reference points. In the off-path routed roaming scenario, an IP connection is
model, the Gxa/Gxc and Gx interfaces also are established through a PDN GW in the home-
used for more generic information transfer. For public-land mobile network (H-PLMN). Because
example, some of the information provided by the the PCEF is controlled by the home operator,
BBERF also is required in the PDN GW/PCEF to service-aware charging and control of both
enable proper charging in the PCEF. In particular, dynamically defined (e.g., IMS) and PCEF-prethe
PDN GW might be required to know which defined services can be used: The PCEF con3GPP
radio technology is used (GERAN, nects (as usual) to the home-PCRF (H-PCRF)
UTRAN, or E-UTRAN), and this information is through Gx, and online charging is performed (if
not necessarily provided through the mobile IP-applicable) through Gy to the OCS.
based protocol. It then must be provided by the If the EPC in the visited-PLMN (V-PLMN)
BBERF to the PDN GW/PCEF through the is based on mobile IP (i.e., PMIPv6, DSMIPv6,
PCRF, as illustrated in Fig. 4. or MIPv4), then the BBERF in the V-PLMN is
As seen above, most functions of the PCEF connected through a visited-PCRF (V-PCRF) to
are common to both on-path and off-path mod-the H-PCRF over the S9 reference point. For
els. For example, service-level charging, gate this case, the H-PCRF is responsible for control
control, and QoS enforcement is performed in of the gateway in the V-PLMN. Consequently,
the PCEF for both models. However, as also the H-PCRF provides policy decisions (QoS
seen above, the bearer-related functions and cerrules)
to the BBERF in the V-PLMN and also
tain event reporting must be performed by the forwards information from the BBERF to the
BBERF in the off-path case. PCEF in the H-PLMN.

IEEE Communications Magazine . February 2009


For certain scenarios, home-routed access
may not be desired, for example, if the H-PLMN
and the V-PLMN are geographically distant
and/or if dynamically provisioned rules are sufficient
(i.e., no DPI is required in the PCEF). For
those cases, visited access can be more suitable.
In visited access, a PDN connection is established
directly through a PDN GW in the VPLMN.
If a GTP-based EPC is used in the
V-PLMN, then the PDN GW in the V-PLMN is
connected through a V-PCRF to the H-PCRF
through S9. On the other hand, if a mobile IP-
based EPC is used in the V-PLMN, then the S9
reference point and also the role of the V-PCRF
become more complex for the visited-access
case. This is due to the fact that both Gx and
Gxa/Gxc procedures are handled using the same
S9 session. The V-PCRF must be able to handle
splitting and combining of messages to and from
S9 on one side and Gx and Gxa/Gxc on the other
side. However, certain Gxa/Gxc interactions in
the V-PLMN may be hidden from the H-PCRF
by the V-PCRF.

For the visited-access case, it is possible to
use AFs located in the V-PLMN. In this situation,
Rx signaling is proxied through the VPCRF
to the H-PCRF.

In the visited-access case where online charging
is used, a proxy OCS can be used in the VPMLN
to connect to the OCS in the home
network.

PROTOCOLS

PCC has defined protocols for the Gx, Gxa, Gxc,
Rx, Gy, S9, and Gz reference points in Release

8. The protocol over the Sp reference point is
not specified and is left as an implementation
option.
All the protocols specified within the PCC
framework (except for Gz when the GTP is used)
are based on Diameter [9]. The main advantage
of using Diameter is the easy reusability, extensibility,
and flexibility. The Rx protocol is based on
the Diameter network access-server application
[10]. The Gx, Gxx, Gy, and S9 protocols are
based on the Diameter Credit-Control Application
(DCCA) [11]. The fact that these protocols
are based on existing applications means that
they inherit message types (called commands in
Diameter) and mandatory parameters (so-called
attribute-value pairs, or AVPs, in Diameter), but
they own new application identifiers, add new
AVPs, and modify the protocol state machines
according to their own procedures.

The Gx protocol (specified in [12]) is used
over the Gx reference point, which is located
between the PCRF and the PCEF. It was introduced
in 3GPP Release 6 and since then has
evolved further. Only minor changes were introduced
in Release 8.

The Gxx protocol (specified in [12]) is new in
Release 8 and is used over the Gxa/Gxc reference
points. The Gxa/Gxc reference points are
located between the PCRF and the BBERF.
The Gxx protocol is based on Gx but reuses only
those parameters that are not related to charging.
Indeed, instead of using the PCC rules as
the main set of parameters, the Gxx protocol
uses QoS rules. QoS rules include the same poli-

Filter
Filter
Filter
FilterPrecedence
value
No match
No match
No
match
MatchMatch
Match
Incoming DL
packets
Filter
evaluation
order

Discard

Bearer
#1
Bearer
#2
Bearer
#3
n Figure 3. Example of SDF detection and downlink bearer binding.
n Figure 4. Information flow for the off-path model. Only the 3GPP family of
accesses are shown in the figure for simplicity.
PCC
rulesQoS rules
Event reportsGxc
Gx
Event
reports
Access
network
info
PMIP-based S5
PCRF
PDN GW
(PCEF)
Serving GW
(BBERF)
GERAN
UTRAN
E-UTRAN
SGSN
MME
cy-related parameters as the PCC rule, but the
charging-related information is left out.

The Rx protocol (specified in [13]) is used
over the Rx reference point, which is located
between the PCRF and the AF. The main goal
for the Rx protocol is transferring the session
information from the AF to the PCRF and the
bearer events from the PCRF to the AF.

The S9 protocol (specified in [14]) is used
over the S9 reference point, which is located
between the PCRF in the V-PLMN and the
PCRF in the H-PLMN. The S9 was conceived to
minimize the number of message exchanges
across the roaming interface.

The Gy protocol (specified in [15]) is defined
over the Gy reference point, which is located
between the OCS and the PCEF. It is a 3GPPspecific
variant of the IETF DCCA [11]. As
such, it implements the DCCA state machines
for session and event-based charging. However,
not all functionality of DCCA is used for Gy,
and some 3GPP-specific additions (AVPs) also
are introduced. The main goal is credit management
for online charging.

For offline charging, either the GTP or Diameter
base accounting can be used to report usage
of resources over the Gz reference point [16]. In
addition file transfer protocol (FTP) can be used
to transfer CDRs to the billing domain.

IEEE Communications Magazine . February 2009


The PCC architecture
provides both IMS
and non-IMS services
with the right
framework to
successfully control
the media plane in
all scenarios. With its
support for multiple
accesses, this is an
important step
toward a fixed-
mobile convergence.

n Figure 5. PCC architecture for home routed and visited access roaming cases.
Rx
Gx
AF
H-PCRFPCEF
(PDN-GW)
BBERF
V-PCRF
S9
Gxa/Gxc
H-PLMN
V-PLMN
Home routed access
Rx
Rx
AF
H-PCRF
BBERF
PCC control plane interfaces
User plane interfaces
V-PCRF
PCEF
(PDN-GW)
AF
S9
Gxa/Gxc
H-PLMN
V-PLMN
Visited access
(local breakout)
Gx
CONCLUSIONS

The PCC architecture for EPS is an evolution of
the PCC architecture defined in 3GPP Release 7.
It is a consolidated architecture for access-agnostic
policy control, and as such, it can be applied
to a number of accesses such as E-UTRAN,
UTRAN, GERAN, eHRPD, and WiMAX.

PCC was updated with the new functional
entity, BBERF, and new reference points, Gxa
and Gxc, to support new mobility protocols in
the access network. This is a step toward service
control continuity where a user can move
between heterogeneous accesses and have policy
and charging control seamlessly applied.

Furthermore, the introduction of a complete
roaming model for PCC enables operators to have
the same dynamic policy and charging control and
provide the same access to services independently
of whether a user is making this access through a
gateway in their home or visited network.

The PCC architecture provides both IMS and
non-IMS services with the right framework to
successfully control the media plane in all scenarios.
With its support for multiple accesses,
this is an important step toward a fixed-mobile
convergence.

REFERENCES

[1] 3GPP Tech. Spec. 23.203, “Policy and Charging Control
Architecture.”
[2] 3GPP Tech. Spec. 23.401, “GPRS Enhancements for EUTRAN
Access.”
[3] 3GPP Tech. Spec. 23.402, “Architecture Enhancements
for Non-3GPP Accesses.”
[4] 3GPP Tech. Spec. 23.207, “End-to-End Quality of Service
(QoS) Concept and Architecture.”
[5] IETF RFC 2753, “A Framework for Policy-Based Admission
Control.”
[6] 3GPP Tech. Spec. 23.125, “Overall High Level Functionality
and Architecture Impacts of Flow-Based Charging.”
[7] 3GPP2 Spec. X.P0057-0, “E-UTRAN . eHRPD Connectivity
and Interworking: Core Network Aspects.”
[9] IETF RFC 3588, “Diameter Base Protocol.”
[8] H. Ekstrom, “QoS Control in the 3GPP Evolved-Packet
System,” IEEE Commun. Mag., vol. 47, no. 2, Feb.
2009.
[10] IETF RFC 4005, “Diameter Network Access Server
Application.”
[11] IETF RFC 4006, “Diameter Credit-Control Application.”
[12] 3GPP Tech. Spec. 29.212, “Policy and Charging Control
over Gx Reference Point.”
[13] 3GPP Tech. Spec. 29.214, “Policy and Charging Control
over Rx Reference Point.”
[14] 3GPP Tech. Spec. 29.215, “Policy and Charging Control
(PCC) over S9 Reference Point.”
[15] 3GPP Tech. Spec. 32.299, “Telecommunication Management;
Charging Management; Diameter Charging
Applications.”
[16] 3GPP Tech. Spec. 32.240, “Charging Architecture and
Principles.”
BIOGRAPHIES

JOSE-JAVIER PASTOR BALBAS (j.javier.pastor@ericsson.com)
received his M.S. degree in telecommunications engineering
from the University of Valladolid, Spain. He joined Ericsson,
Spain, in 1997. In 2000 he started working with the
IETF, where he published several RFCs. Since 2004 he has
devoted his time to 3GPP standards, and now specializes in
QoS and policy control from an end-to-end perspective.

STEFAN ROMMER (stefan.rommer@ericsson.com) received an

M.S. in engineering physics and a Ph.D. in theoretical
physics, both from Chalmers University of Technology,
Sweden. Currently, he is working as a systems manager at
Ericsson, Sweden. Since joining Ericsson in 2001, he has
worked in different areas of telecommunications, primarily
with packet core network standardization and development.
He has been involved in 3GPP EPS standardization
from the start.
JOHN STENFELT (john.stenfelt@ericsson.com) received his

M.S. degree in electrical engineering with an emphasis on
telecommunications/signal processing from the Blekinge
Institute of Technology, Sweden. He also holds a B.S.
degree in mathematics from Stockholm University, Sweden.
He has been working in the telecommunication industry
since 2000 and joined Ericsson, Sweden, in 2007. He is currently
working as a systems manager focusing on 3GPP
standardization.
IEEE Communications Magazine . February 2009