Policy and charging_control_chapter_02_architecture_evolution

2 Architecture Evolution

Chapter 2
Architecture Evolution
Topic

Page

PCC Architecture R7 .................................................................................... 25
Reference points R7 ................................................................................ 26
PCC Architecture R8 .................................................................................... 29
Reference points added in R8................................................................ 36
PCC Architecture R10 .................................................................................. 37
Reference points added in R10 ............................................................. 39
PCC Architecture R11 .................................................................................. 39

23

Policy and Charging Control

This page is intentionally left blank

24


PCC Architecture R7
As already mentioned in the Introduction chapter, prior to R7 the following
features have been specified separately:
•

Flow based charging, including charging control and online credit
control;

•

Policy control (e.g. gating control, QoS control, etc.).

[X,3GPP 23.203] R7 for the first time enables the full harmonisation and
merger of these functions. Thanks to that, real-time interactions in the PS CN
may be optimised.
In R7 the PCC architecture consists of the following functions:
•

PCRF;

•

PCEF;

•

AF;

•

OCS and OFCS;

•

Subscription Profile Repository (SPR).

The PCC architecture is an extension of the IP Connectivity Access Network
(IP-CAN) architecture. As defined in [X, 3GPP 21.905], IP-CAN is the
collection of network entities and interfaces that provide the underlying IP
transport connectivity between the UE and the IMS entities. An example of an
IP-CAN is GPRS. The PCEF is a functional entity in the Gateway node
implementing the IP access to the Packed Data Network (PDN). For example
the functionality of a Gateway in GPRS is handled by the GGSN. The
architecture model and reference points are shown in Fig. 2-1.

OCS

SPR
Gy

Sp

GW

Gx

PCRF

Rx

AF

PCEF
Gz

OFCS

Figure 2-1 PCC logical architecture R7

25


Reference points R7
Rx reference point
The Rx reference point resides between the AF and the PCRF. This interface
enables transport of application level session information from AF to PCRF.
Such information includes, but is not limited to:
•

IP filter information to identify the service data flow for policy control
and/or differentiated charging;

•

Media/application bandwidth requirements for QoS control.

AF may subscribe to notifications on the IP-CAN bearer level events via Rx
interface. Example of such event is a change in the signalling path status of
AF session. The IP-CAN bearer is an IP transmission path of defined
capacity, delay and bit error rate. [X, 3GPP 21.905] In GPRS the IP-CAN
bearers are synonymous to PDP Contexts.

Gx reference point
The Gx reference point resides between the PCEF and the PCRF. This
interface enables the PCRF to have dynamic control over the PCC behaviour
at the PCEF. The Gx reference point enables the signalling of PCC decision,
which governs the PCC behaviour, and it supports the following functions:
•

Request for PCC decision from PCEF to PCRF;

•

Provision of PCC decision from PCRF to PCEF;

•

Negotiation of IP-CAN bearer establishment mode (UE-only or
UE/NW);

•

Termination of Gx session (corresponding to an IP-CAN session) by
PCEF or PCRF (It should only occur in rare situations, e.g. the
removal of a UE subscription).

IP-CAN session is defined as the association between a UE and an IP
network. The association is identified by one IPv4 and/or an IPv6 prefix
together with UE identity information, if available, and a PDN represented by
a PDN ID (e.g. an APN). Using EPS as an example IP-CAN session is
synonymous to the PDN connection, IP-CAN bearer to EPS bearer. It is
depicted in Fig. 2-2.

26


IP-CAN bearer

EPS bearer #1
EPS bearer #2
EPS bearer #3

IP-CAN session

PDN Connection ”Internet” – IP CAN SESSION #1

eNodeB

S-GW

P-GW

UE
EPS bearer #1
EPS bearer #2

Internet

IMS
PDN Connection ”IMS” – IP CAN SESSION #2

IP-CAN bearer

Figure 2-2 IP-CAN session and IP-CAN bearers in EPS

Sp reference point
The Sp reference point resides between the SPR and the PCRF. It allows the
PCRF to request subscription information related to the IP-CAN transport
level policies from the SPR based on a subscriber ID (e.g. IMSI), a PDN
identifier and possible further IP-CAN session attributes. PCRF may request
notifications about subscription information changes from the SPR. The SPR
shall stop sending the updated subscription information when a cancellation
notification request has been received from the PCRF.

Gy reference point
The Gy reference point resides between the OCS and the PCEF. It allows
online credit control for service data flow based charging. It is a part of the
common charging architecture framework specified in [X, 3GPP 32.240]. Fig.
2-3 depicts the complete logical charging architecture, including the Gy
interface.

27


Rf

CS-NE

CAP

Rf

Service-NE

Ro

Rf

SIP-AS

Ro

MRFC

Offline
Charging

Ro

Rf

CGF

Ga

CDF

Online
Charging

Bx

MGCF
BGCF
IBCF
P-CSCF
I-CSCF

Rf

S-CSCF

Wf

WLAN

Wo

Rf

SGSN

Rf

IMS GWF

ePDG

Billing

Ro

CAP

Rf
Rf

ISC

OCS

Bx

Domain

Gy

S-GW
MME
P-GW

Gz

Rf

PCEF
PCRF

AF

Figure 2-3 Logical charging architecture
The Gy reference point is functionally equivalent to Ro. Charging events are
forwarded to the OCS and acknowledgements are received. The
acknowledgement grants or rejects the network resource usage requested in
the charging event, according to the decision taken by the OCS. The
following capabilities should be supported:
•

Real-time transactions;

•

Stateless mode ('event based charging') and statefull mode ('session
based charging') of operation;

•

Own reliability mechanisms, e.g. retransmission of charging events, to
run also on an unreliable transport.

•

Changeover to a secondary destination (alternate OCF(s)) in case of
the primary OCF not being reachable.

Gz reference point
The Gz reference point resides between the PCEF and the OFCS. It enables
the transport of a service data flow based offline charging information. [X,
3GPP 32.240] The Gz reference point is functionally equivalent to Ga for
legacy PS domain and to Ga or Rf for evolved PS domain, what is presented
in Fig. 2-2. Rf interface enables interaction between Charging Trigger
Function (CTF) located in different nodes and Charging Gateway Function
(CGF). Charging events for offline charging are transported in real-time from
CTF to CGF. Acknowledgements are sent in opposite direction. Similarly to
Ro reference point, the following capabilities shall be supported:
•
28

Real-time transactions;


•

Stateless mode ('event based charging') and statefull mode ('session
based charging') of operation;

•

Own reliability mechanisms, e.g. retransmission of charging events, to
run also on an unreliable transport.

•

Changeover to a secondary destination (alternate OCF(s)) in case of
the primary OCF not being reachable.

CDF is responsible for the creation of CDRs based on information received
via Rf interface. Subsequently CDRs are forwarded to CGF via Ga interface.
Reception of CDRs is acknowledged by CGF. Protocol used on this interface
should have the following capabilities:
•

Near real-time transactions;

•

Send one or more CDRs in a single request message;

•

Changeover to secondary destinations (alternate CGFs) in case of the
primary CGF not being reachable;

•

Provide its own reliability mechanisms, e.g. retransmission of
charging events, to run also on unreliable transport.

PCC Architecture R8
There are several modifications to PCC architecture in the R8 release vs. R7.
They are a result of the introduction of EPS. In order to clarify them, let us
briefly revise the differences between EPS and earlier UMTS and GSM
systems. Prior to R8 the particular IP-CAN bearers (PDP contexts) are
controlled by the GTP protocol. Thanks to the use of GTP it is possible to
maintain all QoS-related information and bearer identification throughout the
whole CN. The classical scenario, when SGSN handles both signalling and
payload packets exchanged between the user and the external PDN is
presented in Fig. 2-4.

29


End-to-end bearer identification

GTP-U

RANAP

GTP-C

GGSN
GTP-U

GTP-U

UL TFT

GTP-U

GTP-U

IP-CAN session

PDN

DL TFT

SGSN

DL TFT

UL TFT

RNC

DL TFT

GTP-C

GTP-U

UL TFT

RANAP

IP-CAN bearer
(PDP context)

Figure 2-4 IP-CAN bearers before EPS, classical scenario
For each bearer two tunnels are required. The first tunnel is setup between
SGSN and RNC. The second tunnel spans between SGSN and GGSN. All
payload packets thus have to pass the SGSN which has to terminate one
tunnel, extract the packet and put it into another tunnel. This process
consumes processing resources in the SGSN. As the UMTS system evolves
the throughput of the air interface increases. Consequently, SGSN has to
process more user traffic. In order to solve this problem, a new functionality
referred to as one-tunnel option a.k.a. direct tunnelling is proposed. As both
RNC and GGSN nodes support GTP-U protocol, SGSN can remove itself
from the payload processing chain by creation of a direct tunnel between
RNC and GGSN. As a result the SGSN processing load is significantly
reduced. Mobility management and session management signalling is still
controlled by the SGSN. This concept is presented in Fig 2-5.

GTP-C

GTP-U

GTP-C

GGSN

UL TFT

GTP-U

UL TFT

GTP-U

IP-CAN session

DL TFT

UL TFT

RNC

SGSN

PDN
DL TFT

RANAP

DL TFT

RANAP

IP-CAN bearer
(PDP context)

Figure 2-5 IP-CAN bearers before EPS, one-tunnel option

30


One-tunnel option has some limitations though. It cannot be applied to the
earlier 2G system, because BSC uses a different protocol for the payload
transport towards SGSN. Also in case of roaming a SGSN has to count the
payload for the inter-operator billing purposes and one-tunnel option cannot
be used. Finally in the prepaid charging based on CAMEL SGSN interacts
with the OCS and must control the user traffic.
In EPS two alternative tunnelling methods are available on the S5/S8 interface
between S-GW and P-GW:
•

Evolved GPRS Tunnelling Protocol (eGTP);

•

Proxy Mobile IP (PMIP).

eGTP consists of two protocols. GTP-Cv2 is used for tunnel control and
GTP-Uv1 is utilised for payload handling. In earlier GSM/UMTS systems
GTP-Cv1 is used instead, while the user traffic is transported by the same
GTP-Uv1. The principles of both control protocols are identical. The
difference between them is mainly in the new EPS-specific parameters added
to the signalling messages.
In case of using GTP, an end-to-end IP-CAN bearer identification is
preserved. P-GW has full control of each bearer including QoS
characteristics. It is shown in Fig 2-6.

S1-AP

MME

IP-CAN session
(PDN connection)

GTP-C

P-GW

GTP-U

GTP-U

S-GW

eNodeB
GTP-U

DL TFT

UL TFT
UL TFT

UL IP

DL TFT

GTP-C

GTP-U

DL IP

IP-CAN bearer
(EPS bearer)

Figure 2-6 IP-CAN bearers in EPS - GTP
Each bearer is associated with a pair of Traffic Flow Templates (TFT) located
in the UE and P-GW. TFT is a collection of filters for the bearer. Typically
each filter is a IP 5-tuple containing source and destination IP address, source
and destination port as well as protocol identifier. Other filters, using
additional parameters may also be defined. Uplink (UL) packets are mapped
to the particular bearers using UL TFT located in the UE. P-GW is

31


responsible for mapping of Downlink (DL) IP packets to the appropriate
bearers using DL TFT. Relation among IP-CAN session, IP-CAN bearer and
TFT is clarified in Fig. 2-7.
IP-CAN session No. 1
UE or
P-GW

IP-CAN bearer No. 1
QoS, delay, bitrate …

IPv4 or IPv6 prefix,

TFT

Filter No. 1

Precedence

Local IP v4 or 6 + Mask
Remote IP v4 or 6 + Mask

APN, UE identity …

IP-CAN bearer No. 2


TFT

Protocol Type
Type Of Service (IPv4)

IP-CAN bearer No. 3




TFT



IPSec Security Parameter

TFT

IP-CAN bearer No. 2



Traffic Class (IPv6)
Flow Label (IPv6)

IP-CAN bearer No. 1

Local, Remote port range

Index - (SPI)

Filter No. 2
TFT

Precedence

Parameters …

Figure 2-7. IP-CAN session, IP-CAN bearer and TFT relation
When PMIP is used instead of GTP it is not possible to maintain individual
bearers of the particular user in the whole core network. Instead, they are only
defined between UE and S-GW. On S5/S8 interface all traffic for the whole
IP-CAN session is sent in only one PMIP tunnel. Information about particular
bearers is lost. As a result S-GW uses additional filters for mapping of DL IP
packets to the corresponding bearers. TFT filters are still kept in P-GW for
PCC functionality.
Filters still required
for PCC functions

GTP-U

Additional filters required for
mapping of DL IP packets to bearers

PMIP

All IP-CAN session traffic
sent in one tunnel

Figure 2-8 IP-CAN bearers in EPS – PMIP

32

DL TFT

eNodeB

P-GW
DL TFT

GTP-U

DL PF

UL TFT
UL TFT

UL IP

DL PF

S-GW

DL IP


Selection of PMIP protocol for the tunnelling of user traffic between S-GW
and P-GW has an impact on the PCC mechanisms. As mentioned earlier,
PMIP does not support QoS-related signalling. P-GW does not have the
possibility to control the particular bearers anymore. Another functional
component named Bearer Binding and Event Reporting Function (BBERF) is
added to PCC. The allocation of the BBERF is specific to each IP-CAN. In
case of 3GPP EPS it is added to the S-GW, because the bearers are terminated
in this node. Other PCC functions, like charging are still handled by PCEF.
The resulting modification of PCC architecture in R8 [X, 3GPP 23.203] is
presented in Fig. 2-9. BBERF is not required for GTP.

OCS

SPR
Gy

Sp

P-GW
OFCS

Gz

PCEF
S5

Gx

PCRF

Rx

AF

Gxx

S-GW
BBERF

R8 also adds a roaming functionality to the PCC architecture. The two
alternative roaming scenarios are proposed:
•

Home Routed scenario;

•

Visited Access scenario, also referred to as Local Breakout.

The difference lies in the location of the PCEF. For home routed roaming the
PCEF is located in the home network. All traffic must be routed to the home
gateway that provides access to the external PDN. For this purpose an
intermediate IP exchange (IPX) network is often used. IPX is a third-party
operator providing interconnection services among different mobile operators.
When PMIP is used on S8 interface the BBERF is required. BBERF is always
located in the visited network. PCC decisions are always controlled by the
Home PCRF (H-PCRF). It applies to both cases, when the subscriber is in the
home network or roams in the visited network. H-PCRF communicates with
BBERF via Visited PCRF (V-PCRF). New S9 reference point is defined
between H-PCRF and V-PCRF. In this way the operator of the visited
network controls the usage of the local resources, and ensures that roaming
33


agreements are met. V-PCRF may reject decisions from H-PCRF, but is not
allowed to change them. This is depicted in Fig. 2-10.

Home network

OCS

SPR
Gy

Sp

P-GW
OFCS

Gz

PCEF

Gx

H-PCRF

S8

Rx

AF

S9

S-GW
Gxx

V-PCRF

BBERF

Visited network
Figure 2-10 PCC Roaming architecture R8, Home Routed - PMIP
For the GTP-based S8, PCEF has the full control of the QoS parameters of all
bearers. BBERF is not required. As a result there is no interaction with the
visited network. Charging interfaces are not affected by the home routed
roaming scenario. This is illustrated in Fig. 2-11.

Home network

OCS

SPR
Gy

Sp

P-GW
OFCS

Gz

PCEF

Gx

H-PCRF

Rx

AF

S8

S-GW

Visited network
Figure 2-11 PCC Roaming architecture R8, Home Routed, GTP

34


In the visited access a.k.a. local breakout roaming scenario, the P-GW is
located in the visited network. S9 reference point is mandatory independent of
the protocol used on the S5 interface. If GTP is used between S-GW and PGW in the visited network, H-PCRF interacts only with the PCEF in the
visited network via V-PCRF. Fig. 2-12 shows this scenario.

Home network

SPR
Sp

AF

Rx

OCS

H-PCRF
S9

Rx

AF

Gy

OFCS

V-PCRF
Gz

Gx

S-GW

P-GW

Visited
network

S5

PCEF

Figure 2-12. PCC Roaming architecture R8, Visited Access - GTP
Situation complicates for PMIP-based S5 interface. In this case the H-PCRF
must control both BBERF and PCEF within single S9 session. The V-PCRF
is responsible for proper mapping of signalling operations on Gx and Gxx
interfaces on one side and S9 interface on the other, as shown in Fig. 2-13.

Home network

SPR
Sp

AF

Rx

OCS

H-PCRF
S9

AF

Rx

OFCS

V-PCRF
Gxx

Gx

S-GW

Visited
network

Gy

Gz

P-GW
S5

BBERF

PCEF

Figure 2-13 PCC Roaming architecture R8, Visited Access - PMIP
35


Visited access enables the use of AFs located in the visited network. In this
case AF communicates with the H-PCRF via V-PCRF. Charging information
is also generated in the visited P-GW. For online charging PCEF must
communicate with the OCS in the home network. Offline charging is carried
out locally in the visited network.

Reference points added in R8
S9 reference point
The S9 reference point resides between the H-PCRF and the V-PCRF. It
enables the following functionality to the H-PCRF in case of a local breakout:
•

Dynamic PCC control, including both the PCEF and, if applicable,
BBERF, in the VPLMN;

•

Delivery or reception of an IP-CAN-specific parameters from both the
PCEF and, if applicable, BBERF in the VPLMN;

•

Serving Rx authorizations and event subscriptions from an AF in the
VPLMN.

For home routed scenario, if applicable, H-PCRF may provide dynamic QoS
control policies to the BBERF via V-PCRF.

Gxx reference point
The Gxx reference point resides between the PCRF and the BBERF. It
corresponds to Gxa and Gxc reference points as defined in [X, 3GPP 23.402].
PCRF has dynamic QoS control over BBERF. The following functions are
supported:
•
•

Termination of Gxx session by BBERF or PCRF;

•

Establishment of Gateway Control Session by the BBERF;

•

Termination of Gateway Control Session by the BBERF or PCRF;

•

Request for QoS decision from BBERF to PCRF;

•

Provision of QoS decision from PCRF to BBERF;

•

Delivery of IP-CAN-specific parameters from PCRF to BBERF or
from BBERF to PCRF;

•

36

Establishment of Gxx session by BBERF;

Negotiation of IP-CAN bearer establishment mode (UE-only and
UE/NW).


Gxa and Gxc interfaces are depicted in Fig. 2-14. Gxb is also shown, but this
interface is not standardised in this specification release.

PCRF

Rx
Gx

Gxc
S-GW

P-GW

S5

BBERF

Gxa
S2a

AF

PCEF

Gxb

SGi

Operator’s IP
services (e.g. IMS)

S2b

ePDG
Trusted non-3GPP
IP access

SWn
Untrusted
non-3GPP
IP access

Figure 2-14 Gxa Gxb and Gxc interfaces

PCC Architecture R10
It should be noted that there are no changes in R9 architecture compared to
R8. All functional components and interfaces are the same. The new
functionalities added in R9 (e.g. Usage Reporting) will be discussed later in
the book. Let us now focus on R10. The main change is the introduction of
User Data Register (UDR) instead of SPR. A new Ud interface as specified
between PCRF and UDR as an alternative to Sp. It is a consequence of the
new User Data Convergence (UDC) architecture described in [X, 3GPP
23.335]. Let us have a closer look at UDC. It proposes an innovative approach
to the user database implementation in telecommunication nodes. In this new
layered architecture the user data is separated from the application logic. The
subscriber profiles are stored in a logically unique repository referred to as
User Data Repository (UDR) allowing access from entities handling an
application logic, named Application Front Ends (FE). UDR is a functional
entity that acts as a single logical repository of user data and is unique from
Application Front End’s perspective. The protocol used on Ud interface is the
Lightweight Directory Access Protocol (LDAP) [X, 3GPP 29.335]. This new
UDC architecture is depicted in Fig. 2-15.

37


UE, Network Elements
UE ref points (e.g. OMA
DM based S14, Ut )

MAP based ref
points (e.g. C, D, Gr)

Diameter based ref points
(e.g. Cx, Sh, S6a/S6d)

SIP based ref
points

Other ref points

UDC
Application
Front End

Application
Front End

Application
Front End

Ud

User Data Repository

Figure 2-15 User Data Convergence
There are two main benefits of UDC, compared to the old user database
implementation. Before the UDC subscriber profiles were distributed over
many independent nodes. As a result parameters were often duplicated, as
each node used the local database. The modification of user data was
complicated as well. Each node required a separate provisioning interface,
which made the integration with customer care systems very complicated.
Thanks to the use of a centralised UDR all redundant information can be
removed from the database. Also only a single provisioning interface is
required. Comparison of the old architecture with the UDC is presented in
Fig. 2-16.

Other network elements

HLR

AUC

HSS

PCRF

Database

Database

Database

Sp

HLR
FE

AUC
FE

HSS
FE

PCRF

Ud

SPR
UDR
Many provisioning
interfaces

Customer Care System

Duplicated
information

Single provisioning
interface

No duplication

Customer Care System

Figure 2-16 User Data Repository vs. old databases

38


When Sp interface is used, the PCC architecture for non-roaming and roaming
scenarios is identical to R8, as depicted in Fig. 2-9, 2-10, 2-11, 2-12 and 2-13.
For the UDC alternative added in R10, the Sp interface and SPR in the above
figures should be replaced with Ud interface and UDR accordingly.

Ud reference point
The Ud reference point resides between the UDR and the PCRF, acting as an
Application Frontend. It is used by the PCRF to access PCC related
subscription data when stored in the UDR. More detailed and general
description of the Ud interface can be found in [X, 3GPP 23.335]. The main
functions are listed below:
•

FEs should be able to create, read, modify and delete a user data in the
UDR;

•

FEs shall support subscription/notification about changes to subscriber
data in the UDR;

•

Each FE shall only access/modify the data relevant to its function, and
not be impacted by other data that UDR stores for other applications.

PCC Architecture R11
Further enhancements to the PCC architecture are added in R11. In previous
releases the PCC rules use an IP 5-tuple for SDF identification. Alternatively
dynamic service information could be provided to the PCRF via the Rx
interface by an AF that takes part in the service signalling with the UE (e.g.
P-CSCF in IMS). R11 adds a new Application Detection and Control (ADC)
functionality. It enables the detection of any application traffic without AF
controlling the service via Rx interface. For example ADC may be used to
detect VoIP call on the Internet. Servers involved in the call setup cannot
communicate with the PCRF via Rx. It is also difficult to describe this SDF
using an IP 5-tuple, because server addresses are not known. In order to detect
this application a more detailed analysis extending beyond the basic IP header
is required. It is also referred to as Deep Packet Inspection (DPI). It typically

39


includes analysis of the application layer protocols (e.g. RTP or RTCP for
VoIP). Upon detection of a VoIP call the operator can1 for example block that
traffic as competing with its own service offerings. Alternatively Internet
VoIP calls may be allowed for premium category subscribers and in this case
higher QoS may be requested. Another application example is a peer-to-peer
(p2p) file sharing. Due to its nature it is very difficult to specify traffic filters
describing this service. On the other hand operators want to completely block
or at least limit the bitrate for this application as p2p users usually consume
huge bandwidth generating large volumes of data.
ADC functionality can be integrated with the PCEF or implemented in a
separate Traffic Detection Function (TDF) element. In the latter case a new
reference point Sd is defined between TDF and PCRF. Both alternatives are
described in Fig. 2-17 and Fig. 2-18.

PCRF
Gx

GW
PCEF

SGi

PDN

ADC

Figure 2-17 PCEF-integrated Application Detection and Control

PCRF
Gx

Sd

GW
TDF
PCEF

ADC

SGi

PDN

Figure 2-18 TDF-based Application Detection and Control

1 In some countries the blocking of user traffic may be legally prohibited.

40


Another feature added in this specification release allows the policy decisions
based on subscriber spending limit. This functionality requires a new Sy
interface between the PCRF and OCS. It enables the PCRF to make policy
decisions based on spending limits maintained in the OCS. A spending limit is
controlled by a dedicated counter and represents a usage limit (monetary,
volume, time, events) the subscriber is allowed to consume during a
predefined period. PCRF is informed about changes in the status of a policy
counter (e.g. the volume of downloaded data passed a certain threshold) and
can take appropriate actions (e.g. modify QoS, decrease bandwidth, block the
service). Let us take an example of the operator offering a service with cost
control for young subscribers. After consuming 8$ all services are blocked
until the end of the day. The counter is reset at midnight and access to
services is granted again for another day. PCRF is not aware of the actual
value of the policy counters. It is only notified about the status changes. The
counters are located in the OCS, because all rating functionality resides there.
The rating process enables generation of monetary amounts related to
subscriber payment based on the service usage. PCRF on the other hand still
handles PCC decisions, because these aspects are not known to the OCS. A
clear distinction between the functional areas of PCRF and OCS is
maintained, however due to the interaction between these two elements an
enhanced functionality is available.
The charging architecture for a non-roaming scenario including new features
described above is presented in Fig. 2-19 As explained earlier subscriber
profiles may be located in the SPR dedicated to PCC solution or a
consolidated UDR. Both alternatives are presented in the picture.
S-GW
SPR/UDR

BBERF
Gxx

S5

Sp/Ud

P-GW
OFCS

Gz

PCEF

ADC
Sd

Gx

Gy

PCRF

Rx

AF

Sy

TDF
ADC

OCS

SGi


41


Similar changes may be observed in the PCC architecture for a roaming
scenario. The home routed alternative is presented in Fig. 2-20.
SGi

Home
network

OCS

TDF
ADC

Sd

SPR/UDR

Gy

Sy

Sp/Ud

P-GW
OFCS

Gz

Gx

PCEF ADC

H-PCRF

S8

Rx

AF

S9

S-GW
BBERF

Gxx

V-PCRF

Visited network

Figure 2-20 PCC Roaming architecture R11 - Home Routed
The visited access alternative is presented in Fig. 2-21.

Home network

SPR/UDR
Sp/Ud

AF

Rx

H-PCRF

OCS

Sy

S9

AF

Rx

Sd

Gx

S-GW

P-GW
S5

BBERF

OFCS

V-PCRF
Gxx

Visited
network

Gy

PCEF

Gz

TDF
SGi

ADC

ADC

Figure 2-21 PCC Roaming architecture R11 – Visited Access

42


Sd reference point
Sd reference point resides between the PCRF and the TDF. The PCRF has
dynamic control over the application detection and control behaviour at a
TDF. The following functions are enabled through the Sd interface:
•

Establishment and termination of TDF session between the PCRF and
the TDF;

•

Provision of ADC decision from the PCRF for the purpose of
application's traffic detection and enforcement at the TDF;

•

Request for ADC decision from the TDF to the PCRF;

•

Reporting of the start and the stop of a detected applications and
transfer of service data flow descriptions and application instance
identifiers for detected applications from the TDF to the PCRF;

•

Reporting of the accumulated usage of network resources on a per
TDF session basis from the TDF to the PCRF;

•

Request and delivery of IP-CAN session specific parameters between
the PCRF and the TDF.

Sy reference point
The Sy reference point resides between the PCRF and the OCS. It enables a
transfer of the policy counter status information related to subscriber spending
from OCS to PCRF. The following functions are supported on this interface:
•

Request for reporting of policy counter status information from PCRF
to OCS and a mechanism to subscribe to or unsubscribe from spending
limit reports (i.e. notifications of policy counter status changes);

•

Report of policy counter status information upon a PCRF request from
OCS to PCRF;

•

Notification of spending limit reports from OCS to PCRF;

•

Cancellation of spending limit reporting from PCRF to OCS.

43

Policy and charging_control_chapter_02_architecture_evolution

More Related Content

What's hot

Viewers also liked

Similar to Policy and charging_control_chapter_02_architecture_evolution

Recently uploaded

Policy and charging_control_chapter_02_architecture_evolution