Policy and charging_control_chapter_02_architecture_evolution


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Policy and charging_control_chapter_02_architecture_evolution

  1. 1. 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
  2. 2. Policy and Charging Control This page is intentionally left blank 24
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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;
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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).
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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