Policy and charging_control_chapter_02_architecture_evolution

2 Architecture Evolution

23

Chapter 2Chapter 2Chapter 2Chapter 2

Architecture EvolutionArchitecture EvolutionArchitecture EvolutionArchitecture Evolution

Topic Topic Topic Topic PagePagePagePage

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

Policy and Charging Control

24

This page is intentionally left blank


25

PCC Architecture R7PCC Architecture R7PCC Architecture R7PCC 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.

Figure 2-1 PCC logical architecture R7

PCRFGW

PCEF

OCS

OFCS

AF

SPR

Gy

Gz

Gx

Sp

Rx


26

Reference points R7

Rx reference pointRx reference pointRx reference pointRx 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 pointGx reference pointGx reference pointGx 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.


27

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

Sp reference pointSp reference pointSp reference pointSp 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 pointGy reference pointGy reference pointGy 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.

S-GWeNodeB P-GW

IP-CAN bearer

IP-CAN session Internet

IMS

PDN Connection ”Internet” – IP CAN SESSION #1

UEPDN Connection ”IMS” – IP CAN SESSION #2

EPS bearer #1

EPS bearer #2

EPS bearer #3

EPS bearer #1

EPS bearer #2

IP-CAN bearer


28

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 pointGz reference pointGz reference pointGz 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:

• Real-time transactions;

CS-NE

Service-NE

SIP-AS

MRFC

MGCFBGCFIBCF

P-CSCFI-CSCF

S-CSCF

WLAN

SGSN

ePDG

S-GW

MME

P-GW

PCEF

IMS GWF

PCRF AF

OCS

CDFCGF

CAP

Ro

Ro

Ro

ISC Ro

Wo

CAP

Gy

Rf

Rf

Rf

Rf

Rf

Wf

Rf

Rf

Rf

Rf

Rf

Ga

Gz

Billing

Domain

Online Charging

Offline Charging

Bx

Bx


29

• 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.


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.


30

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.

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

GTP-U

RANAP

GTP-U

GTP-C

RANAP

GTP-U

GTP-U

GGSNRNCGTP-C

IP-CAN bearer(PDP context)

End-to-end bearer identification

IP-CAN session

PDNSGSNGTP-U

GTP-U

DL

TF

T

UL

TF

TU

L T

FT

UL

TF

T

DL

TF

T

DL

TF

T

SGSNRANAP

GTP-U

GTP-C

RANAP

GTP-U

GTP-U

GGSN

RNC

GTP-C

IP-CAN bearer(PDP context)


IP-CAN session

PDNUL

TF

T

UL

TF

T

UL

TF

T

DL

TF

T

DL

TF

T

DL

TF

T


31

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.

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

GTP-U

S1-AP

GTP-U

GTP-C


MMEGTP-C

GTP-U GTP-US-GWeNodeB

P-GW

IP-CAN bearer(EPS bearer)

IP-CAN session(PDN connection)

DL

TF

T

DL IP

DL

TF

T

UL

TF

T

UL

TF

T

UL IP


32

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.

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.

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

IPv4 or IPv6 prefix,

APN, UE identity …

IP-CAN session No. 1

UE or

P-GW







QoS, delay, bitrate …

IP-CAN bearer No. 1


IP-CAN bearer No. 2


IP-CAN bearer No. 3


IP-CAN bearer No. 1


IP-CAN bearer No. 2

TFT

TFT

TFT

TFT

TFT

Local IP v4 or 6 + Mask

Remote IP v4 or 6 + Mask

Local, Remote port range

Protocol Type

Type Of Service (IPv4)

Traffic Class (IPv6)

Flow Label (IPv6)

IPSec Security Parameter

Index - (SPI)

Filter No. 1 Precedence

Parameters …

Filter No. 2 Precedence

GTP-UPMIP

GTP-U

S-GW

eNodeB

P-GW

DL

TF

T

DL IP

DL

TF

TU

L T

FT

UL

TF

T

UL IP

DL

PF

DL

PF

All IP-CAN session traffic sent in one tunnel

Additional filters required for mapping of DL IP packets to bearers

Filters still required for PCC functions


33

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.


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

PCRF

P-GW

PCEF

OCS

OFCS AF

SPR

Gy

Gz Gx

Sp

Rx

Gxx

S-GW

BBERF

S5


34

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.

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.

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

H-PCRF

P-GW

PCEF

OCS

OFCS AF

SPR

Gy

Gz Gx

Sp

Rx

GxxS-GW

BBERF

S8

V-PCRF

S9

Home network

Visited network

H-PCRF

P-GW

PCEF

OCS

OFCS AF

SPR

Gy

Gz Gx

Sp

Rx

S-GW

S8

Home network

Visited network


35

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 P-GW in the visited network, H-PCRF interacts only with the PCEF in the visited network via V-PCRF. Fig. 2-12 shows this scenario.

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.

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

H-PCRFOCS

OFCS

AF

SPR

Gz

Sp

Rx

P-GW

PCEF

V-PCRF

S9

Home network

Visited network

S-GW

Gx

AF

Gy

Rx

S5

H-PCRFOCS

OFCS

AF

SPR

Gz

Sp

Rx

P-GW

PCEF

V-PCRF

S9

Home network

Visited network

S-GW

BBERF

GxGxx

AF

Gy

Rx

S5


36

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 pointS9 reference pointS9 reference pointS9 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.

GxxGxxGxxGxx referencereferencereferencereference pointpointpointpoint

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:

• Establishment of Gxx session by BBERF;

• 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;

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


37

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

Figure 2-14 Gxa Gxb and Gxc interfaces


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.

P-GW

PCEF

PCRF

S-GW

BBERF

GxGxcAF

Rx

S5 Operator’s IPservices (e.g. IMS)

SGi

ePDG

Trusted non-3GPPIP access

Untrusted non-3GPP IP access

S2b

SWn

S2aGxa Gxb


38

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.

Figure 2-16 User Data Repository vs. old databases

User Data Repository

ApplicationFront End



Ud

UDC

UE, Network Elements

UE ref points (e.g. OMA

DM based S14, Ut )

Diameter based ref points

(e.g. Cx, Sh, S6a/S6d)

MAP based ref

points (e.g. C, D, Gr)

SIP based ref

pointsOther ref points

UDR

Other network elements

HLR

Database

PCRF

SPR

HSS

Database

AUC

Database

HLRFE

Duplicatedinformation

Customer Care System

Sp

Many provisioninginterfaces

AUCFE

HSSFE

PCRF

Ud

Customer Care System

No duplicationSingle provisioninginterface


39

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.


UdUdUdUd reference pointreference pointreference pointreference 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.


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


40

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.

Figure 2-17 PCEF-integrated Application Detection and Control

Figure 2-18 TDF-based Application Detection and Control

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

PCRF

Gx

GW

PCEF

ADC

PDNSGi

PCRF

Gx

SGi

Sd

GW

PCEFTDF

ADC PDN


41

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.


PCRF

P-GW

PCEF

OCS

OFCS AF

SPR/UDR

Gy

Gz Gx

Sp/Ud

Rx

Gxx

S-GW

BBERF

S5

Sy

ADC

TDF

SGi

Sd

ADC


42

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

Figure 2-20 PCC Roaming architecture R11 - Home Routed

The visited access alternative is presented in Fig. 2-21.

Figure 2-21 PCC Roaming architecture R11 – Visited Access

H-PCRF

OCS

OFCS AF

SPR/UDR

Gy

Gz Gx Rx

GxxS-GWBBERF

S8

V-PCRF

S9

Home network

Visited network

P-GW

PCEF ADC

TDF

ADC

SGi

Sp/UdSd

Sy

H-PCRF OCS

OFCS

AF

Gz

Rx

P-GW

PCEF

V-PCRF

S9

Home network

Visited network

S-GW

BBERF

GxGxxAF

Gy

Rx

S5ADC

Sy

SPR/UDR

Sp/Ud

TDF

ADCSGi

Sd


43


SdSdSdSd reference pointreference pointreference pointreference 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.

SySySySy reference pointreference pointreference pointreference 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.

Date post:	05-Dec-2014
Category:	Education
Upload:	leliwa
View:	730 times
Download:	2 times

Policy and charging_control_chapter_02_architecture_evolution

Education