If you liked it, or content was helpful to you please add "+1" to article you used or share it on facebook or so.
Make it easier to find for others who could need those information, allow them find these articles on the spot. But.. it's your call.
Recommendations until now


Jan 18, 2012

Gx interface - sitting between PCRF and PCEF

After you are familiar with OFCS (Offline Charging System) and OCS (Online Charging System) time has come to be more up to date with interfaces that are being used to exchange signaling data. At first I will talk about Gx interface which is responsible for Offline Charging, but not only.
The Gx reference point is located between the Policy Control and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF). The Gx reference point is used for provisioning and removal of Policy and Charging Control (PCC) rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control or both by applying AVPs relevant to the application.
As you probably know, it's always good to start from big picture. Here we go.
Fig. 1. Gx reference point at the Policy and Charging Control (PCC) architecture

So at first, few information about..

PCC (Policy and Charging Control)


Oh, and please note that by IP CAN bearer I mean: IP transmission path of defined capacity, delay and bit error rate, etc. For more details please see 3GPP TS 21.905.
An IP-CAN session incorporates one or more IP-CAN bearers. Support for multiple IP-CAN bearers per IP-CAN session is IP-CAN specific. An IP-CAN session exists as long as the related UE IPv4 address and/or IPv6 prefix are assigned and announced to the IP network.
It will be needed for text presented below.

Policy and Charging Control Rule Definition
The purpose of the PCC rule is to:
  • Detect a packet belonging to a service data flow
    • The service data flow filters within the PCC rule are used for selection of downlink IP CAN bearers
    • Service data flow filters within the PCC rule are used for the enforcement that uplink IP flows are transported in the correct IP CAN bearer
  • Identify the service data flow contributes to
  • Provide applicable charging parameters for a service data flow
  • Provide policy control for a service data flow
The PCEF (Policy and Charging Enforcement Function) shall select a PCC rule for each received packet by evaluating received packets against service data flow filters of PCC rules in the order of the precedence of the PCC rules. When a packet matches a service data flow filter, the packet matching process for that packet is completed, and PCC rule for that filter shall be applied.
There are two different types of PCC (Policy and Charging Control):
  • Dynamic PCC rules. Are dynamically provisioned by the PCRF to the PCEF via the Gx interface. These PCC rules may be either predefined or dynamically generated in the PCRF. Dynamic PCC rules can be Installed, Modified and Removed any time.
  • Predefined PCC rules. Preconfigured in the PCEF. Predefined PCC rules can be Activated or Deactivated by the PCRF at any time. Predefined PCC rules within the PCEF may be grouped allowing  the PCRF to dynamically activate set of PCC rules over the Gx interface.
PCC rules consist of:
  • rule name - shall be used to reference a PCC rule in communication between PCEF and the PCRF
  • service identifier - shall be used to identify the service or service component the service data flow relates to
  • service data flow filter(s) - shall be used to select the traffic for which the rule applies. It shall be possible to define wildcarded service data flow filters, both for dynamic and predefined PCC rules
  • precedence
  • gate status - indicates whether the service data flow, detected by the service data flow filter may pass (state open) or shall be discarded (state closed) in uplink and/or in downlin direction
  • QoS parameters - includes QoS Class Identifier (QCI), that means authorized QoS class for the service data flow, also the Allocation and Retention Priority (ARP) and authorized bitrates for uplink and downlik
  • charging key (i.e. rating group) - define whether online and offline charging interfaces are used, what is to be metered in offline, on what level the PCEF shall report the usage related to the rule, etc.
  • other charging parameters
  • monitoring key - identifies a monitoring control instance that shall be used for usage monitoring control of the service data flows controlled by the predefined PCC rule or dynamic PCC rule
As I secretly mentioned earlier, we are able to make
Operations on Policy and Charging Control (PCC) rules
For dynamic PCC rules:
  • Installation: to provision a PCC rules that has not been already provisioned
  • Modification: to modify a PCC rule already installed
  • Removal: to remove a PCC rule already installed
For predefined PCC:
  • Activation: to allow the PCC rule being active
  • Deactivation: to disallow the PCC rule


Functional elements

PCRF
The PCRF (Policy Control and Charging Rules Function) is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF reveives session and media related information from the Application Function (AF) and informs AF of traffic plane events.
The PCRF Shall provision PCC rules to the PCEF via the Gx interface.
The PCRF PCC rule decisions may be based on one or more of the following:
  • Information obtained from the Application Function (AF) via Rx interface, e.g. session, media and subscriber related information
  • Information obtained from the PCEF via the Gx interface, e.g. IP CAN bearer attributes, request type and subscriber related information
  • Information obtained fromthe SPR via the Sp interface, e.g. subscriber and service related data
  • Information obtained from the BBERF via the Gxx interface
  • Own PCRF pre-configured information
If the information from the PCEF (Policy and Charging Enforcement Function) contains traffic mapping information not matching any service data flow filter known to the PCRF, and PCRF allows the UE to request enhanced QoS fo services not known to the PCRF. The PCRF shall add this traffic mapping information as service data flow filters to the corresponding authorized PCC rule. The PCRF may wildcard missing filter parameters.
PCRF shall report events to the AF via Rx interface.
The PCRF shall inform the PCEF through the use of PCC rules on the treatment of each service data flow that is under PCC control, in accordance with the PCRF policy decisions. PCRF shall be able to select the bearer control mode that will apply for the IP CAN session and provide it to the PCEF via the Gx interface.


Upon subscription to loss of AF (Application Function) signalling bearer notifications by the AF, the PCRF shall request the PCEF to notify the PCRF of the los of resources associated to the PCC rules corresponding with AF Signaling IP Flows, it this has not been requestet previously.


PCEF
The PCEF (Policy and Charging Enforcement Function) is the functional element that encompasses policy enforcement and follow based charging functionalities. This functional entity is located at the Gateway (PGW). It provides control over the user plane traffic handling at the Gateway and its QoS, and provides service data dlow detection and counting as well as online and offline charging interactions.
For a service data flow that is under policy control the PCEF shall allow the service data flow to pass through the Gateway if and only if the corresponding gate is open.
For a service data flow that is under charging control the PCEF shall allow the service data flow to pass through the Gateway if and only if there is a corresponding a active PCC rule and, for online charging, the OCS has authorized the applicable credit with that Charging Key (Rule Base). The PCEF may let a service data flow pass through the Gateway during the course of the credit re-authorization procedure.

If requested by the PCRF, the PCEF shall report to the PCRF when the status of the related service data flow changes. This procedure can be used to monitor an IP CAN bearer dedicated tfor AF signalling traffic.


Procedures over Gx interface

Request and Provisioning for PCC rules
For detailed information about what fields are set, and so on please see the TS 29.212 paragraph 4.5.1.

The PCRF shall indicate via Gx interface PCC rules to be applied at the PCEF. This may be using one of the following procedures:
  • PULL procedure (Provisioning solicited by PCEF): In response to a request for PCC rules being made by the PCEF, the PCRF shall provision PCC rules in the CCA (Credit Control Answer)
Fig. 2. PCC "PULL" procedure sequence flow
1. When an event-trigger event occurs, the PCEF sends a Credit Control Request (CCR-I in our case, because it's "Initial_Request") message that carries an event-trigger parameter to the PCRF, requesting to deliver PCC rules
2. The PCRF judges whether to update the PCC rules (namely, old PCC rules) according to the event-trigger, and returns a Credit Control Answer (CCA-I) message to the PCEF. If the PCC rules need update, the retuned CCA-U  (CCR-U and CCA-U stand Credit Control Request/Answer Update_Request) message carries the updated PCC rules (namely, new PCC rules), and the PCRF stores both the old PCC rules and the new PCC rules.
3. After receiving the CCA message, the PCEF executes the PCC rules. If the returned CCA message carries the new PCC rules, the PCEF executes the new PCC rules; if the returned CCA message carries no new PCC rules, the PCEF executes the old PCC rules. When the PCEF executes the PCC rules unsuccessfully, the PCEF sends a new CCR message.
  • PUSH procedure (Unsolicited provisioning): The PCRF may decide to provision PCC rules without obtaining a request from the PCEF, e.g. in response to information provided to the PCRF via the Rx interface, or in response to an internal trigger within the PCRF. To provision PCC rules without a request from the PCEF, the PCRF shall include these PCC rules in an RAR (Re-Auth-Request) message. No CCR/CCA (Credit Control Request/Credit Control Answer) messages are triggered by this RA-Request.
Fig. 3. PCC "PUSH" procedure sequence flow
1. When an event-trigger event occurs, the PCRF updates the PCC rules, and sends a Re-Auth Request (RAR) message to the PCEF. The RAR message carries new PCC rules, and the PCRF does not store the old PCC rules.
2. The PCEF executes the new PCC rules delivered through the RAR message. After completion of the execution, the PCEF sends a Re-Auth Answer (RAA) message to the PCRF. 


For each request from the PCEF or upon the unsolicited provision the PCRF shall provision zero or more PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means:
  • To activate or deactivate a PCC rule that is predefined at the PCEF, the PCRF shall provision a reference to this PCC rule within a Charging-Rule-Name AVP and indicate the required action by choosing either the Charging-Rule-Install AVP or the Charging-Rule-Remove AVP.
  • To install or modify a PCRF-provisioned PCC rule, the PCRF shall provision a corresponding Charging-Rule-Definition AVP within a Charging-Rule-Install AVP.
  • To remove a PCC rule which has previously been provisioned by the PCRF, the PCRF shall provision the name of this PCC rule as value of a Charging-Rule-Name AVP within a Charging-Rule-Remove AVP.
  • If, for certain accesses, the PCRF performs the bearer binding, the PCRF may move previously installed or activated PCC rules from one IP CAN bearer to another IP CAN bearer. See annex A in TS 29.212 for further details.