A REVIEW ON 3GPP PCC ARCHITECTURE EVOLUTION FROM RELEASES 7 TO 14.

M. Dossou 1 , S. Chede 1 , M. Agbomahena 1 , F. N yaba 2 , M. K. Assogba 1 and A. Vianou 1 . 1. Polytechnic of Abomey-Calavi, University of Abomey-Calavi (Benin). 2. Benin Telecoms Services (Benin). ...................................................................................................................... Manuscript Info Abstract ......................... ........................................................................ Manuscript History Received: 18 October 2018 Final Accepted: 20 November 2018 Published: December 2018


ISSN: 2320-5407
Int. J. Adv. Res. 6 (12), 1056-1065 1057 To better understand the 3GPP PCC framework, and its advantages to operators, this article proposes a survey of the architecture history and its evolution from releases 7 to 14. The relevant features of this architecture are highlighted and described.
The next section gives a brief review on the IP Multimedia Subsystem architecture. The third section gets to the heart of the matter by retracing the history of 3GPP PCC framework, its evolution and then the important features introduced in the latest releases of the architecture.
IP Multimedia Subsystem review:-IMS definition:-Many definitions of IP Multimedia Subsystem (IMS) are found in the literature according to each author's viewpoint. IMS can be defined as a network architecture consisting of an IP-based core network connected to multiple access networks to provide a converged service to wireless, wireline and cable subscribers [3]. IMS is suitable for Fixed Mobile Convergence (FMC) and offers a more effective and secure means of providing multimedia services to subscribers, ubiquitously from any (wireless or wireline) devices, utilizing an all-IP core [4,5].
IMS framework was designed by 3GPP to meet the following requirements [6,7]:-1. Support for establishing IP Multimedia sessions 2. Support for a mechanism to negotiate Quality of Service 3. Support for inter-working with Internet and circuit-switched networks 4. Support for roaming 5. Support for strong control imposed by the operator with respect to the services delivered to the end-user 6. Support for rapid service creation without standardization.
Thereafter, support for other (non-3GPP) access networks was added to IMS requirements.
IMS architecture:-IMS architecture is divided into separate functions linked by standardized interfaces. Each interface is, in fact, a reference point which specifies the protocol used and the functions between which it operates. A simplified architecture (without charging system) of an IMS core network is shown in figure 1. It is composed of five (5)   SBLP, as defined in 3GPP Release 5, is shown in figure 2. The PDP was carried out by the Policy Decision Function (PDF) which was a logical entity integrated to the P-CSCF. The PDF could elaborate the policy rules based on static information (such as the subscription profile), dynamic information, and the available resources. The combination of such policy rules, once met for a service request, could trigger a desired action (such as allowing the service with the requested bandwidth) [12]. The PEP which is in charge of enforcing the policy rules is located at the transport/user plane and more precisely in the Gateway GPRS Support Node (GGSN). The GGSN used the policy rules to install packet filters in its routing logic so that if a user agent tries to do something which it is not authorized to do, the packet filters discard the user agent's traffic. The interface used between the P-CSCF and the GGSN was the Go interface and it was based on the COPS protocol.
1059 SBLP was enhanced further in Release 6 (completed in 2005) by separating it from IMS, thus allowing SBLP to be used by generic services [13]. As shown in figure 3, the PDF was a standalone entity connected to the P-CSCF using the DIAMETER-based Gq interface and still used the COPS Go interface with the GGSN. This architecture enabled one PDF to serve more than one Application Functions (AF) and one given AF (e.g., P-CSCF) to interact with different PDFs over a generic IP Connectivity Access Network (IP-CAN) [14]. Beyond the need for individual IP flow access control, IMS required more sophisticated charging models. In Release 5, the charging was simply based on the volume of packet data. Therefore, there was a demand for multiple charging models based on the volume, the duration, the service content, the type of service, the subscription profiles of users and even the used network access. Another problem of the Release 5 solution is that it relied on the PDP (Packet Data Protocol) context mechanism that is only defined in the UMTS (Universal Mobile Telecommunications System)/GPRS network. This solution could not accommodate other radio access technologies such as WLAN (Wireless Local Area Network) and WiMAX (Worldwide Interoperability for Microwave Access) [12]. To fill these gaps, Flow-Based Charging (FBC) was introduced in Release 6.
FBC allows to apply separate charging for different services by introducing the concept of service data flows charging (for both online and offline charging). Service data flows are identified by IP packet filters where filters are 1060 a part of charging rules. Charging rules contain information that allows the filtering of traffic to identify the packets belonging to a particular service data flow (e.g., IMS, file transfer, browsing), and allows definition of how the service data flow is to be charged (e.g. different media streams within the same bearer session) [14].
FBC provides operators with a centralized mechanism for charging and controlling access to predefined services (a certain Web page or a movie) and to dynamically defined services (IMS-based services) [13]. As shown in figure 4, the FBC architecture is made up of three (03) functional entities: the Charging Rules Function (CRF), the Traffic Plane Function (TPF) and the Application Function (AF).
The CRF provides charging rules and decides which rules have to be applied for a service flow, based on data received from the TPF (user/bearer-related information) and from the AF (session and media-related information). Such rules contain information on how packets belonging to a flow can be identified (IP filter) and how they shall be treated (such as applying offline or online charging, metering by volume or duration) [15]. Two types of charging rules can be distinguished: predefined rules and dynamic rules. Predefined rules are already fully configured, i.e. they contain all necessary information to be applied. They may be installed beforehand on the TPF or provided by the CRF in case of need. Already installed rules can either be active and used or inactive, waiting for activation by the CRF. Dynamic rules are dynamically generated (in the CRF) by using application-specific criteria like filters to identify the flow. This information is provided by the respective AF to the CRF upon request. Dynamic rules are always installed by the CRF on the TPF (using the Diameter Gx interface). They can be modified and removed at any time by the CRF.
The AF provides application services to the subscriber for which a Flow-Based Charging of packet bearer resources is required. P-CSCF and Application Servers (AS) are examples of AF. The AF provides the IMS application information to the CRF through the Diameter Rx interface. This information includes the application identifier (e.g., for an IMS call), the type of media stream (e.g., audio or video), the IP addresses and port numbers related to the media stream, the requested bandwidth, and the user information [12].
The TPF communicates with the CRF to provide bearer session information including the user identity (e.g., the MSISDN), the bearer characteristics (e.g., the negotiated QoS, and the Access Point Name (APN)), and the networkrelated information (e.g., the SGSN address, the SGSN country and network codes). According to the GPRS APN indicated in the PDP context, the TPF requests charging rules from the CRF through the Diameter Gx interface. Based on the installed charging rules (dynamically provided or activated by the CRF), the TPF differentiates the types of user data streams that belong to different service flows within a bearer session and charges them accordingly with the offline or online charging system. In case of online charging, for example, the TPF has to take care of credit control issues, i.e. maintaining and supervising the assigned quota for the service as well as the communication with the Online Charging System (OCS). The TPF is located in the GGSN and for 3GPP-WLAN inter-working, in the Packet Data Gateway (PDG). Because networks subscribers' needs are not the same, the network resources consumption varies considerably from one user to another. From a simple browsing on a website to a video streaming, the QoS requirements are not similar. It's therefore a paramount necessity for telecom operators to provide different QoS for subscribers according to the service subscribed, and to charge the service consequently.

1061
When SBLP and FBC architectures are used as separate mechanisms, the inter-working cost between networks nodes (e.g., GGSN and CSCF) and charging nodes (e.g., CRF and PDF) is increased [16]. In fact, both architectures were very similar. This resulted in mutual interference because both were based on a central node capable of making decision (PDF and CRF), both were rule-based and both had the same anchor points (the AF in the control plane and the GGSN in the transport plane) [13], [15]. This functional overlap led to the full harmonization and the merging of SBLP and FBC in the 3GPP Release 7 (completed in 2007).
SBLP and FBC were merged into a common solution called Policy and Charging Control (PCC). PCC is a serviceaware control architecture providing operators with a standardized mechanism for QoS and charging control applicable to both IMS and non-IMS based services. PCC helps reducing the signaling cost, by integrating QoS policy and charging rules, and achieving more efficient real-time interactions within the IP bearer domain [15], [17].
The PCC integration architecture is depicted in figure 5. The new Policy and Charging Enforcement Function (PCEF) includes the TPF and the PEF whereas the new Policy and Charging Rules Function (PCRF) includes the CRF and the PDF. 3GPP PCC architecture evolution:-Since its introduction in 3GPP Release 7, PCC architecture was designed to be access-agnostic, i.e. to be used with any IP-based access networks. The following releases brought many improvements to its operation.
3GPP Release 8 introduced the Evolved Packet System (EPS) as an evolution of the GPRS. Therefore, PCC architecture was enhanced in order to support many features such as multiple access technologies (E-UTRAN, UTRAN, GERAN, HRPD, WLAN and WiMAX), roaming and mobility between heterogeneous accesses. To support the requirement for multiple accesses, two PCC architecture alternatives referred to as "on-path" and "offpath" models were defined for Release 8. EPS allows for different mobility protocols depending on which access technology is used [13], [18]. For the 3GPP family of accesses (GERAN, UTRAN and E-UTRAN), either the GTP or Proxy Mobile IPv6 (PMIPv6) can be used. Any of PMIPv6, Dual Stack Mobile IPv6 (DSMIPv6) or Mobile IPv4 (MIPv4) can be used for other accesses. These different protocols have different properties depending on whether they support bearer procedures. In addition to supporting functions related to packet routing and mobility, the GTP also supports the handling of QoS and bearer signaling. When the GTP is used in the EPC between the Serving Gateway (S-GW) and the Packet Data Network Gateway (PDN-GW), the PDN-GW can therefore control the QoS through the bearer procedures toward the S-GW and the PCRF can control the QoS through the Gx interface. This model is referred to as the "on-path" model because QoS/bearer signaling takes place (using GTP) on the same path as the user plane. On the contrary, mobile IP protocols (PMIPv6, MIPv4 and DSMIPv6) are defined by IETF for the express purposes of packet routing and IP-level mobility. They don't support QoS/bearer procedures. Therefore, when any one of these protocols is used between the S-GW and the PDN-GW, the PDN-GW has no knowledge of 1062 the bearers and cannot perform the mapping between the PCC rule received from the PCRF and a corresponding QoS bearer in the access network. The Bearer-Binding and Event-Reporting Function (BBERF) was introduced to handle this situation. The BBERF receives the authorized QoS from the PCRF through the Gxa and Gxc interfaces. This model is referred to as the "off-path" model because QoS/bearer signalingtakes place on a path different from that of the user plane. In Release 9, 3GPP added Usage Monitoring Control feature which allows the operator to enforce dynamic policy decisions based on the total network usage in real time. This is supported by enhancing PCC to support monitoring of accumulated usage of network resources on a per IP-CAN session and user basis. To apply this functionality, the PCRF defines and sends the usage thresholds (based on traffic volume) to the PCEF for monitoring. As soon as a threshold is reached, the PCEF sends a notification to the PCRF and reports the accumulated usage since the last report for usage monitoring. Usage monitoring may be applied for an individual service data flow, a group of services data flows, or for all traffic of an IP-CAN session.
In Release 10, UDR (User Data Repository) is added to PCC. UDR replaces SPR when the UDC (User Data Convergence) [19] is applied to store PCC related subscription data. UDC is a concept that aims to provide convergence of user data in order to enable smoother management and deployment of new services and networks [20]. It helps to avoid data duplication and inconsistency and simplifies the creation of new services. PCRF can access the user data in UDR through the Ud interface.
Prior to 3GPP Release 11, dynamic policy and charging control could be provided only for applications with explicit service session signaling, i.e. applications for which an Application Function (AF) intervenes by exchanging service signaling with the User Equipment (UE) (e.g., IMS Call). For applications without service session signaling (e.g., peer to peer file sharing), predefined PCC rules could be used but there was not a standardized definition of filters for those predefined PCC rules [13] and rules could not be provided dynamically. To solve this issue, PCC is enhanced in Release 11 to support application awareness also when there is no explicit service session signaling. Application Detection and Control (ADC) feature has been introduced for this purpose. With the ADC feature, it is possible to request the detection of specified application traffic, to report on the start or stop of application traffic to the PCRF and to apply the specified enforcement actions. The enforcement actions may include the blocking of the application traffic (gating control), bandwidth limitations (QoS control), and the redirection of traffic to another address. The application detection and control can be implemented either by a standalone logical entity named Traffic Detection Function (TDF) or by the PCEF enhanced with ADC feature. The TDF resides on the SGi interface (between the PDN-GW and the PDN) and inspects the user traffic that goes over SGi. It communicates with the PCRF through the Sd interface. As the PCEF, the TDF may also intervene in Usage Monitoring Control and therefore both of the features may be used in conjunction.
Since the 3GPP Release 11, it is also possible to take policy decisions based on subscriber spending limits. A spending limit is a usage limit (e.g. monetary, volume, duration) that a subscriber is allowed to consume. When the subscriber spending (e.g. monetary, volume, duration) has passed a certain threshold (up or down), the system will 1063 be able to modify resources (e.g. QoS, bandwidth, access) to services accordingly. Policy counters are maintained in the OCS to track spending for a subscription and status reports are provided to the PCRF upon request. The interaction between OCS and PCRF takes place on the Sy interface.
In 3GPP Release 12 (completed in 2014), Gyn reference is introduced between OCS and TDF and Gzn reference is introduced between OFCS and TDF to allow charging of applications detected with ADC feature.

New features introduced in releases 13 and 14:-
The releases 13 and 14 brought many enhancements to PCC architecture as shown in figure 7. In this section, those features will be described.

RAN Congestion Awareness Function (RCAF):-
As mobile user traffic was growing continuously, congestion management became a crucial issue for network operators and it was therefore taken into account by the 3GPP in the Release 13 of PCC architecture [22]. The objective was to monitor the Radio Access Network (RAN) in order to detect any congestion that occurs, to report the congestion to a central network policy entity located in the Core Network, which would mitigate it by applying appropriate policies. Thus, a new feature called RAN Congestion Awareness Function (RCAF) was introduced in PCC architecture. This functional entity is in charge of transferring RAN User Plane Congestion Information (RUCI) to the PCRF to enable the PCRF to take the RAN user plane congestion status into account for policy decisions. The PCRF can then mitigate the congestion by taking action which will be applied by the PCEF, the TDF or the AF. The RAN congestion management is performed as follows: 1. The RCAF determines whether a cell or eNode B is congested. 2. It interrogates the MME (Mobile Management Entity) or SGSN to get information about UEs (IMSI -International Mobile Subscriber Identity) and services (APN) impacted by the congestion and the related congestion level of each UE. 3. This information is aggregated into a RAN User Plane Congestion Information (RUCI) and sent to the PCRF via the Np Reference point. 4. Then, the PCRF takes policy decisions which can be applied by the PCEF, the TDF and the AF to mitigate the congestion. One of the possible actions is that the PCRF can send a "Re-try interval" to the AF to indicate when a service delivery may be retried. 5. If a UE is no longer experiencing congestion, the RACF updates the PCRF with the "No congestion" state. It is important to notify that depending on the operator congestion mitigation policy, reporting restrictions can be sent from the PCRF to the RACF via the Np interface.

Service Capability Exposure Function (SCEF):-
There was a need to further enhance the 3GPP network architecture to allow operators to interact with 3rd party services providers in exposing a greater set of 3GPP service capabilities as requested by 3rd parties, using a standardized service capability exposure framework. To fill this need, Service Capability Exposure Function (SCEF) was introduced in 3GPP Release 13 for a secured exposure of 3GPP network service capability to 3rd party applications. That is, SCEF provides a means for the discovery of the exposed services and capabilities of an operator, by 3rd party application providers through homogenous and standardized network application programming interfaces (APIs) [23,24]. The SCEF has various functionalities defined by 3GPP such as: 1. Authenticating and authorizing 3rd party applications; 2. Setting required QoS for a specific AS session; 3. Changing the chargeable party during the session or at the time of session setup; 4. Informing a third party about a UE's connection properties and eventually the congestion status; … All these use cases required integration with the PCRF and this is done by Nt and Rx reference points.

Traffic Steering Support Function (TSSF):-
Traffic steering is the concept of redirecting traffic based on more than just the IP addresses. This redirection happens above layer 3, using TCP/UDP ports, session information, and applications to determine where to send traffic [25]. Traffic steering allows operators to optimize resource utilization, users' service perception and terminal or base station power consumption by directing the traffic to the Radio Access Technology (RAT) or layer that provides the best performance regarding any metric of interest [26]. In Release 13, 3GPP introduced the Traffic Steering Support Function (TSSF) which is a function that receives traffic steering control information from the PCRF and ensures that the related traffic steering policy is enforced in the (S)Gi-LAN 1 [27]. The enforcement may be performed in the PCEF, the TDF or the TSSF. A new reference point, St, was therefore introduced between the PCRF and the TSSF to allow for the provision, the modification and the removal of traffic steering control information from the PCRF to the TSSF.

Packet Flow Description Function (PFDF):-
Packet Flow Description Function (PFDF) is a new functional entity introduced by 3GPP in Release 14 for the management of Packet Flow Descriptions (PFDs). A PFD is an extension of an application detection filter that is preconfigured in the PCEF/TDF. It is a set of information enabling the detection of application traffic (e.g. PFD id, protocol, server side IP address and port number) [23]. When PFDs are provided by 3rd party AS via the SCEF, the PFDF stores the PFDs associated with an application identifier and transfers them to the PCEF/TDF via Gw/Gwn interface to enable the PCEF/TDF to perform accurate application detection [26]. Provision, modification and removal of Packet Flow Descriptions in PFDF are performed via the Nu reference point which connects the SCEF to the PFDF.

Conclusion:-
In this paper, the architecture of the 3GPP Policy and Charging Control is reviewed. From the first effort of harmonizing charging and QoS in IMS networks, there has been a significant progress. Currently, 3GPP PCC has full support of multiple access technologies, roaming and mobility between heterogeneous accesses as well as interworking with many access technologies. Over time, several features have been added to make PCC more accurate and dynamic (Usage Monitoring System, Application Detection Control) and more flexible allowing good interaction with the charging system (Spending limits-based policy). The latest 3GPP releases brought many enhancements to PCC by allowing the management of traffic congestion, the interaction with 3rd party services providers and the optimization of the use of resources.