Charging architecture and principles

Charging architecture
and principles

Agenda
• What is SAE and EPC
• PCC
• Offline Charging (OFCS)
• Online Charging (OCS)
• Charging related reference points
• GTP’ and PQM
• Charging scenarios
• Flow based charging
• Mobile charging protocols

What is SAE and EPC
• System Architecture Evolution (SAE) is a new network architecture
designed to simplify LTE networks and establish a flat architecture similar
to other IP based communications networks
• The main component of the SAE architecture is the Evolved Packet Core
(EPC), also known as SAE Core. The EPC will serve as the equivalent of
GPRS networks (via the Mobility Management Entity (MME), Serving
Gateway (SGW) and PDN Gateway (PGW) subcomponents)

PCC (Policy and Charging Control)
• To assure fair usage of the 3G and 4G mobile data networks, service providers will need to
identify the IP service flows, control these flows (authorize, block, restrict) and charge
these flows with two possible charging methods (online and offline charging). For this
purpose, a PCC (Policy and Charging Control) architecture has been introduced
• Mobile data networks operate in a connection oriented mode. The user establishes an end
to end connectivity between his UE and the node which terminates the access (GGSN in
2G/3G and PDN GW in 4G) to send/receive IP packets. This connectivity is called PDP
Context (2G/3G) or bearer (4G)
• Policy control is performed by means of interactions between PCEF (Policy and Charging
Enforcement Function) and PCRF (Policy and Charging Rules Function)
• PCEF is generally embedded within the GGSN/PDN GW, although it may be a standalone
component
• The DIAMETER-based interface between PCEF and PCRF is Gx

PCC (Policy and Charging Control) Cont’d
• Charging control is performed by means of interactions between PCEF and charging
systems
• Two charging systems exist : OCS (Online Charging System) and OFCS (Offline Charging
System)
• The DIAMETER-based interface between PCEF and OCS is Gy. Gz is used between PCEF
and OFCS
• The PCC functionality is comprised by the functions of the Policy and Charging
Enforcement Function (PCEF), the Policy and Charging Rules Function (PCRF), the
Application Function (AF), the Traffic Detection Function (TDF), the Online Charging
System (OCS), the Offline Charging System (OFCS) and the Subscription Profile
Repository (SPR) or the User Data Repository (UDR). UDR replaces SPR when the UDC
(User Data Convergence) architecture

PCC (Policy and Charging Control) Cont’d

PCC Architecture
• Serving Gateway (SGW): acts as a router, and forwards data between the base station and
the PDN gateway. It is also responsible for inter-eNB handovers in the U-plane and
provides mobility between LTE and other types of networks
• Packet Data Network Gateway (P-GW): communicates with the outside world ie. packet
data networks PDN, using SGi interface. Each packet data network is identified by an
access point name (APN). The PDN gateway has the same role as the GPRS support node
(GGSN) and the serving GPRS support node (SGSN) with UMTS and GSM
• Policy and Charging Enforcement Function (PCEF): is the functional entity which
includes policy enforcement along with flow based charging functionalities. The PCEF
enforces policy decisions (e.g. gating, maximum bit rate policing) received from the PCRF
and also provides the PCRF with user- and access-specific information over the Gx
interface. It reports usage of resources to the OFCS and interacts with the OCS for credit
management. The PCEF can also provide usage reports to the PCRF if policy decisions
based on consumed volume or time are desired

PCC Architecture Cont’d
• Policy Control and Charging Rules Function (PCRF): is a component which is responsible
for policy control decision-making, as well as for controlling the flow-based charging
functionalities in the Policy Control Enforcement Function (PCEF), which resides in the
P-GW
• Evolved Packet Data Gateway (ePDG): is critical to the network function of the 4G mobile
core network, known as the evolved packet core (EPC). The ePDG is responsible for
interworking between the EPC and untrusted non-3GPP networks that require secure
access, such as a WiFi, LTE metro, and femtocell access networks
• The Application Function (AF): (eg. P-CSCF for IMS solution) interacts with applications
or services that require dynamic PCC. The AF extracts session information from the
application signaling and provides it to the PCRF over the Rx interface
• Traffic Detection Function (TDF): is a functional entity that performs application
detection and reporting of detected application and its service data flow description to the
PCRF. TDF shall detect Start and Stop of the application traffic for the ADC rules that
the PCRF has activated at the TDF

Charging architecture and
information flows for non-5G
systems– reference points
Rf
Rf
CAP
Bx
Bx
Ga
Ro
ISC
CAP
Gy
Gyn
CDF
Billing Domain
ONLINEOFFLINE CHARGING
MRFC
SIP AS
AF
CS-NE
SGSN
CGF
OCS
IMS-
GWFS-CSCF
Service-NE
P-GW
PCEF
S-GW
ePDG
CHARGING
TDF
PCRF
TWAG
MME
MGCF
BGCF
IBCF
P-CSCF
I-CSCF
E-CSCF
TF
TRF
ATCF

Offline Charging
CN
Domain
Service
element
Sub-
system
Billing
Domain
Rf Ga Bx
C
T
F
C
D
F
C
G
F
3GPP network

Offline Charging
• Charging Trigger Function (CTF): generates charging events based on the observation of
network resource usage as described above. In every network and service element that
provides charging information, the CTF is the focal point for collecting the information
pertaining to chargeable events within the network element, assembling this information
into matching charging events, and sending these charging events towards the CDF. CTF
examples: P-GW, P-CSCF
• Charging Data Function (CDF): receives charging events from the CTF (described above) via
the Rf reference point. It then uses the information contained in the charging events to
construct CDRs. CDF serve as the Diameter Server for the Rf interface
• Charging Gateway Function (CGF): The CDRs produced by CDF are transferred immediately
to the Charging Gateway Function (CGF) via the Ga interface point. The CGDBs interface for
transfer of CDR files to Billing Domain

Online Charging
CN
Domain
Service
element
Sub-
system
Ro
C
T
F
3GPP network
CAP
O
C
F
ABMF
RF
OCS
Rc
Re

• Rating Function (RF): determines the value of the network resource usage (described in the
charging event received by the OCF from the network) on behalf of the OCF. To this end, the
OCF furnishes the necessary information, obtained from the charging event, to the RF and
receives in return the rating output (monetary or non-monetary units), via the Re reference
point
• Account Balance Management Function (ABMF): is the location of the subscriber’s account
balance within the OCS
Online Charging

Convergent Charging Systems Architecture
3GPP network
CN
Domain
CHF
Converged Charging System
CTF
ABMF
CGF
RF
Billing
Domain
Nchf
Bx

Charging related reference points
• Offline charging reference points
 Rf
 Gz
 Ga
 Bx
 Gzn
• Online charging reference points
 Ro
 CAP
 Gy
 Re
 Rc
 Gyn

Offline charging reference points Cont’d
• Rf: The Rf interface is the offline charging interface between the Charging Trigger Function
(CTF) (for example,P-GW, P-CSCF) and the Charging Collection Function (CCF). The Rf
protocol allows the CTF (Diameter client) to issue offline charging events to a Charging Data
Function (CDF) (Diameter server). The charging events can either be one-time events or may
be session-based
• Gz: The Gz reference point is functionally equivalent to Ga for Legacy PS domain and to Ga
or Rf for Evolved PS domain, and hence is replaced by Ga or Rf within the common charging
architecture
• Ga: The Ga is the reference point from the Charging Data Function (CDF) to the Charging
Gateway Function (CGF), which is intended for the transport of Charging Data Records
(CDRs). Ga is solely related to offline charging. The transport protocol associated to the Ga
reference point is GTP'

Offline charging reference points Cont’d
• Bx: The Bx reference point supports interaction between a CGF and the BD. The information
crossing this reference point is comprised of CDR files. A common, standard file transfer
protocol (e.g. FTAM, FTP) can be used
• Gzn: The Gzn reference point is functionally equivalent to Ga or Rf in PS domain, and hence
is replaced by Ga or Rf within the common charging architecture

Online charging reference points
• Ro: Ro reference point supports interaction between a CTF and an OCF. Used to send
charging events from CTF to OCF, receive acks from OCF to CTF. The protocol(s) crossing
this reference point shall support Realtime transaction, Stateless mode for event based
charging and stateful mode for session based charging. For online charging the Diameter
Credit-Control Application (DCCA) is used over Ro.
• CAP: The CAP reference point provides similar functionality for online charging as Ro,
however, it is based on CAMEL techniques. It is kept within the overall charging architecture
as CAMEL may be used in the CS and PS domains
• Gy: The Gy reference point is functionally equivalent to Ro, and hence is replaced by Ro
within the common charging architecture
• Re: The Re reference point supports interaction between the OCF and a Rating Function (RF)
in order to determine the value of chargeable events in terms of monetary or non-monetary
units. The messages and data types used on the Re interface are defined based on the
Diameter base protocol

Online charging reference points Cont’d
• Rc: allows the interaction between the OCF and an Account Balance Management Function
(ABMF) in order to access the account of the subscriber on the OCS. Re is based on Diameter
base protocol
• Gyn: The Gyn reference point is functionally equivalent to Ro, and hence is replaced by Ro
within the common charging architecture

GPRS Tunneling Protocol Extension (GTP’)
• When UE access data services though GPRS is 2G/3G or SGW in 4G CDRs are generated on
GSN or SGW/PGW to be sent to Charging Gateway (CG) though Ga interface
• Implemented based on UDP/IP or TCP/IP. In some commercial products default is UDP/IP
• GTP’ utilizes some aspects of the GPRS Tunneling Protocol (GTP) specifically, GTP Control
Plane (GTP-C) is partly reused
• A GTP’ message contains a GTP’ header and the payload. The payload may contain several
Information Elements (IEs) like: Cause, packet Transfer Command, Data Record Packet and
Private Extension
• GTP’ header may follow the standard 20-octet GTP header format or a simplified six-octet
format. The six-octet GTP’ header is the same as the first six octets of the standard GTP
header
• GTP’ has some useful message types like: Echo Request, Echo Response, Data Record
Transfer Request, Data Record Transfer Response

Prepaid Quota Management (PQM)
• GTP’ is typically designed for postpaid charging. By extending the GTP’ protocol, we can
design new types of messages for quota management to provide the prepaid service
• In the prepaid service, a GSN or PGW interacts with a Prepaid Quota Management (PQM)
server
• There are several PQM messages based on the GTP’ protocol. These new messages can be
implemented by using the reserved GTP’ message types, or encapsulated in the Private
Extension IE in GTP’ Data Record Transfer Request/Response messages
• Common usage is to use Private Extension IE to encapsulate a PQM message
• There are several PQM message types like: Authorization Request/Response, Reservation
Request/Response, and Quota Reclaim Request/Response

Charging principals
• Charging data generation and quota supervision
• Aspects of charging information transfer
• Charging levels and charging data correlation
• Charging information utilization

Charging scenarios
• Both online and offline charging can be categorized into two distinct classes, namely event
based charging and session based charging. Event based charging implies that a chargeable
event is defined as a single end-user-to-network transaction, e.g. the sending of a multimedia
message. This chargeable event is then mapped to an appropriate charging event, resulting
in a single CDR or in a single Credit-Control and resource usage authorisation procedure
• In contrast, session based charging is characterized by the existence of a user session, such
as a circuit call, an IP CAN bearer, or an IMS session. This user session is then matched by a
charging session, resulting in the generation of multiple chargeable/charging events and the
creation of one or more CDRs in offline charging or the performance of a Credit-Control
session in online charging

Event based charging
• In online charging, the charging event is transferred to the EBCF via the Ro or CAP
reference point
• The chargeable event is authorized after successfully performing Credit-Control on the
subscriber account
• The complete procedure must occur in real-time
• If the chargeable event is not authorised by the OCS (e.g. when the subscriber account does
not contain sufficient credit), the NE rejects the resource usage pertaining to that chargeable
event
• The event charging procedure may occur with or without reservation of units from the
subscriber’s account ("Event Charging with Unit Reservation" (ECUR) or "Immediate Event
Charging" (IEC), respectively)
• In offline charging, the charging event is transferred to the CDF via the Rf reference point.
The CDF produces a matching CDR, which is then sent to the CGF via the Ga reference point

Session based charging
• In online charging, an "initial" charging event (session start) is transferred to the SBCF via
the Ro or CAP reference point and the start of the user session is authorized after
successfully performing Credit-Control on the subscriber account
• In offline charging, the "initial" charging event is transferred to the CDF via the Rf reference
point
• Upon termination of the subscriber session, or when a new chargeable event occurs, further
charging events ("final" or "interim" events, respectively) are sent for the session from the NE
to the CDF
• The CDF formats one or more of these events into CDRs according to CDR formats specified
in the middle tier TSs

Flow based charging (FBC)
• With the FBC, the IP packets belonging to different types of mobile services can be identified
and charged by various billing/tariff plans at the GGSN or PGW
• UE can activate more than one PDP context. The first activated PDP context and the
subsequent PDP contexts are referred to as the primary PDP context and the secondary PDP
contexts, respectively
• The primary and the secondary PDP contexts share the same PDP context information except
for the QoS profiles
• When an IMS service is delivered through a GPRS or IP-CAN bearer session, the operator
needs to charge the IMS signaling message and IMS media data separately
• The existing solution for UMTS R5 activates two PDP contexts. The IMS signaling is
transported via the primary PDP context and the IMS media packets are delivered via the
secondary PDP context
• In this case, the operator charges the transferred data for IMS/LTE signaling and IMS media
via two PDP contexts with different tariff plans

Flow based charging (FBC)
• As the number of simultaneous service sessions increase, the aforementioned charging
solution is not effective because many PDP contexts should be activated to handle multiple
service types, which consume extra network resources
• This issue is resolved by the FBC in UMTS R6
• Another problem of the R5 solution is that it relies on the PDP context mechanism that is
only defined in the UMTS/GPRS network. This solution cannot accommodate other radio
access technologies such as WLAN and WiMAX
• The FBC utilizes the concept of the service data flow specified by the IP packet filters, where
the filters are a part of a charging rule

FBC architecture for IMS/GPRS services

Mobile Charging Protocols
• GPRS Tunneling Protocol Extension (GTP’)
• Customized Applications for Mobile network Enhanced Logic (CAMEL)
• Remote Authentication Dial In User Service (RADIUS)
• Diameter
• Session Initiation Protocol (SIP): Charging Headers

CAMEL
• Intelligent Network (IN) allows fixed or mobile operators to offer enhanced telephony
services such as number translation and prepaid call. As an IN standard, CAMEL
provides control intelligence across a mobile communications network
• CAMEL has been evolved in four phases
• Phase 1 was tailored for the GSM-based core networks
• Phase 2 extended phase 1 with a greater range of options such as prepaid call charging.
In this phase, a pre-recorded announcement can be played to alert the prepaid user of a
prepaid call when the user’s credit is depleted
• Phase 3 supports control capabilities for mobile services including SMS and GPRS
• Phase 4 is extensible for any enhancements. In particular, it provides control capabilities
for the IMS services

RADIUS
• The Remote Authentication Dial In User Service (RADIUS) protocol was originally
defined by the Internet Engineering Task Force (IETF) to provide a centralized
Authentication, Authorization and Accounting (AAA) framework for network access
• RADIUS is developed based on the client–server architecture, and is commonly used in
Network Access Servers (NASs) such as wireless access points and VoIP gateways
• RADIUS client is responsible for passing user information to the RADIUS server and
then takes some actions based on the returned response
• A RADIUS message consists of a 20-octet header followed by several attributes. The
RADIUS attributes convey information between RADIUS clients and RADIUS servers

RADIUS Cont’d
• RADIUS header format
• RADIUS Codes

RADIUS Cont’d
• RADIUS attributes carry specific AAA information described as follows:
• The User-Name attribute specifies the name of the user
• The User-Password attribute indicates the password of the user
• The NAS-IP-Address attribute contains the IP address of the network access server (i.e.,
the RADIUS client)
• The Service-Type attribute specifies the type of requested service
• The Acct-Status-Type attribute shows the status of an Accounting-Request message. The
attribute value can be Start (value 1), Interim-Update (value 3) or Stop (value 2)
• The Acct-Input-Octets attribute indicates how many octets have been received by the
network access server

RADIUS Cont’d
• The Acct-Output-Octets attribute indicates how many octets have been sent out from the
network access server
• The Acct-Session-Id attribute records a unique accounting identity that matches the start
and the stop accounting records
• The Acct-Session-Time attribute indicates the elapsed time of the service session
• The Acct-Terminate-Cause attribute indicates why the session is terminated, which can
only be presented in the Accounting-Request message where the Acct-Status-Type is set
to “Stop’’. This attribute can be User Request (value 1), Session Timeout (value 5), or
Admin Reboot (value 7)
• The Called-Station-Id attribute specifies the called phone number
• The Calling-Station-Id attribute specifies the calling phone number

Diameter
• The Diameter protocol was derived from RADIUS to offer more flexibility, and is the next
generation AAA protocol
• The Diameter protocol has fail-over capabilities
• Application layer protocol can run over TCP/SCTP transport
• Diameter has modular architecture offers a flexible base protocol which allows
application-specific extensions
• Like RADIUS, Diameter follows the client–server architecture where a client interact
through the Diameter request and answer message exchange
• Diameter relay agent may be used to forward a Diameter message to the appropriate
destination

Diameter Cont’d
• A Diameter message consists of a 20-octet header followed by several Attribute-Value
Pairs (AVPs)
• Diameter command codes

Diameter Cont’d
• Diameter is used in both online through the Ro interface and offline charging through the
Rf reference point
• Offline charging is achieved by exchanging the Diameter Accounting Request (ACR) and
Accounting Answer (ACA) messages
• All-IP mobile network utilizes the Diameter Credit Control (DCC) application to
communicate with the OCS
• There are several AVPs for each diameter message type like: ACR, ACA, CCR, CCA
• Offline charging Accounting Control Request (ACR) message contains the following AVPs

Diameter offline charging ACR AVPs
• The Session-Id AVP identifies the offline charging session
• The Origin-Host and the Origin-Realm AVPs contain the address and the realm for the
Diameter client
• The Destination-Realm AVP contains the realm of the Diameter server
• The Acct-Application-Id AVP contains the value “3’’ as defined in RFC 3588. This value
indicates the Diameter accounting application
• The Accounting-Record-Type AVP indicates the transfer type of the offline accounting
information. There are four transfer types:
 EVENT_RECORD (value 1) indicates that an event-based service is delivered
 An event-based service creates exactly one EVENT_RECORD record
 START_RECORD (value 2) initiates a charging session contains charging information relevant to
the initiation of the session
 INTERIM_RECORD (value 3) contains up-to-date charging information for an existing charging
session
 STOP_RECORD (value 4) terminates a charging session. This record contains final accounting
information of the session

Diameter offline charging ACR AVPs
• A session-based service consists of one START_RECORD, one STOP_RECORD and zero
or more INTERIM_RECORD records
• The Accounting-Record-Number AVP identifies the record within a session
• The User-Name AVP contains the user name in the Network Access Identifier (NAI)
• The Acct-Interim-Interval AVP specifies the time interval between the previous and the
next charging records
• The Event-Timestamp AVP specifies the time when the accounting message is created
• The Service-Information AVP contains the service-specific parameters

Diameter offline charging ACAAVPs
• The Result-Code AVP contains the result of the accounting request like:
• The Session-Id, the Origin-Host, the Origin-Realm, the Acct-Application-Id, the
Accounting-Record-Type, the Accounting-Record-Number, the User-Name, the Acct-
Interim-Interval, and the Event-Timestamp AVPs are the same as those in the ACR
message

Diameter Applications
• A Diameter Application is not a software application but is a protocol based on the
Diameter base protocol
• Each application is defined by an application identifier and can add new command codes
and/or new mandatory AVPs (Attribute-Value Pair). Adding a new optional AVP does not
require a new application
• Application example:
 Diameter Mobile IPv4 Application (Mobile IP, RFC 4004)
 Diameter Network Access Server Application (NASREQ, RFC 7155)(Obsoletes: RFC 4005)
 Diameter Extensible Authentication Protocol Application (RFC 4072)
 Diameter Credit-Control Application (DCCA, RFC 8506])(Obsoletes: RFC 4006)
 Diameter Session Initiation Protocol Application (RFC 4740)

Session Initiation Protocol (SIP):
Charging Headers
• The IMS architecture provides real-time multimedia service by utilizing the Session
Initiation Protocol (SIP)
• In order to correlate the CDRs generated by different IMS nodes and the GGSN for an
IMS call session , some charging information headers must be included in a SIP message
• With these headers, each involved IMS node can obtain the correlated charging data and
then include them in the CDRs
• SIP Header examples in IMS:
 P-Charging-Function-Addresses
 P-Charging-Vector

Charging architecture and principles

More Related Content

What's hot (20)

Similar to Charging architecture and principles (20)

Recently uploaded (20)

Charging architecture and principles