The document summarizes the evolution of the PCC (Policy and Charging Control) architecture from releases R7 to R8 to R10 and R11 of 3GPP specifications. In R7, the PCC architecture consisted of PCRF, PCEF, AF, OCS, OFCS and SPR connected by Rx, Gx, Sp, Gy, and Gz reference points. In R8, the introduction of EPS led to adding a BBERF in the S-GW and a Gxx reference point between PCRF and BBERF. R10 and R11 added additional reference points to support new functions.
4. 2 Architecture Evolution
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
5. Policy and Charging Control
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
6. 2 Architecture Evolution
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
7. Policy and Charging Control
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;
8. 2 Architecture Evolution
•
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
9. Policy and Charging Control
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.
End-to-end bearer identification
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
10. 2 Architecture Evolution
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)
End-to-end bearer identification
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
11. Policy and Charging Control
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
QoS, delay, bitrate …
IP-CAN session No. 2
TFT
Protocol Type
Type Of Service (IPv4)
IP-CAN bearer No. 3
IPv4 or IPv6 prefix,
QoS, delay, bitrate …
APN, UE identity …
TFT
QoS, delay, bitrate …
IPv4 or IPv6 prefix,
IPSec Security Parameter
TFT
IP-CAN bearer No. 2
APN, UE identity …
QoS, delay, bitrate …
Traffic Class (IPv6)
Flow Label (IPv6)
IP-CAN bearer No. 1
IP-CAN session No. 3
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
12. 2 Architecture Evolution
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
Figure 2-9 PCC logical architecture R8
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
13. Policy and Charging Control
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
14. 2 Architecture Evolution
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
15. Policy and Charging Control
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).
16. 2 Architecture Evolution
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
17. Policy and Charging Control
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
18. 2 Architecture Evolution
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.
Reference points added in R10
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
19. Policy and Charging Control
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
20. 2 Architecture Evolution
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
Figure 2-19 PCC logical architecture R11
41
21. Policy and Charging Control
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
22. 2 Architecture Evolution
Reference points added in R11
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