Charging in 3GPP*
2.1 Charging Levels
2.2 Charging Methods
Additional Functionality
*
purpose of equipment is to build telecom networks
The Operator business paradigm:
purpose of network is to provide end user services
The Customer
uses – and will be billed for - the end user services
Charging is the central enabler for the end user billing
there will be no equipment sold, no network built and no service offered unless the service can be billed
*
accounting: process of apportioning charges between the Home Environment, Serving Network and Subscriber.
billing: function whereby CDRs generated by the charging function(s) are transformed into bills requiring payment.
charging: a function within the telecommunications network and the associated OCS/BD components whereby information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible to determine usage for which the charged party may be billed.
OCS: Online Charging System
Charging Levels
Charging Methods
Charging for the Packet Switched Domain (GPRS)
Charging for the I-WLAN
3. Service Charging, comprising
In future, OMA Services ?!
Charging Methods
offline charging:
Charging mechanism where charging information does not affect, in real-time, the service rendered. The final result of this charging mechanism is the forwarding of CDR files to the Billing Domain.
online charging:
*
Online charging: CAMEL
TS 03.78/09.78 (GSM)
Major CS charging parameters
Origination / Destination of call
Special Cases
Mobile Originated SMS CDR
Mobile Terminated SMS CDR
*
PS domain (GPRS) charging involves the SGSN and the GGSN
Offline Charging:
S-CDR and G-CDR capture PDP context charging
Online charging:
CAMEL based
Basic principles
There is no concept of „service invocation“, all traffic is plain IP
There is no concept of „mobile termination“, but „uplink“ and „downlink“ traffic instead
CDRs are generated per user connection (“PDP context”)
CDRs are time and volume based
Each CDR contains one or more volume containers, characterised by QoS and Tariff Time
Uplink and downlink volume counted separately
Non-volatile storage of CDRs on the CGF
Major GPRS charging parameters
APN („destination“)
*
Setting the scene –
Bearer Charging : WLAN
WLAN: an interworking architecture for non-3GPP WLAN (i.e. 802.11) with the 3GPP core network
In Rel-6, there are two relevant interworking scenarios
Scenario 2 is a SIM based authentication/authorisation, providing IP connectivity via the WLAN
Scenario 3 with Access to 3GPP services (IMS, SMS, MMS, …) on top of the above
Charging functionality is currently being specified in SA5
Will be similar to GPRS
Will make use of IETF AAA technology (use of Diameter)
Time and data volume to be counted
in WLAN only in scenario 2 reported to VPLMN
*
Determines applicable I-CSCF
Resource control via embedded PCF
Serving CSCF
May behave as SIP proxy or user agent
accepts requests and services them internally or translates / forwards them on
may terminate and independently generate SIP transactions
Interrogation CSCF
Application Server
Services are not standardised in the 3GPP specifications
Examples: movie / music clips, news flash, soccer goals, ….
*
All media component invocation information is inside the CDRs
Each CDR contains one or more media component descriptors
AS information is captured, if AS(s) is / are involved
many similarities with CS charging, BUT
Completely different, distributed charging architecture
ACR start / stop / interim are generated per SIP message
CDRs are generated by CCF and then sent to BD
ACRs and CDRs are asynchronous
No transport network infomation (e.g. radio resources)
If correlation with GPRS CDRs required, this is done by cross-correlating GPRS and IMS „Charging IDs“
*
AS information, if applicable
Offline Charging with 7 CDR types: 1 each per IMS node type
P-CSCF captures session related information
S-CSCF captures similar information as the P-CSCF, but
only S-CSCF CDR has AS related information
only P-CSCF CDR has information on authorised QoS
I-CSCF captures user registration events
AS captures service invocation information
Others (more details in „special cases“ below):
interworking with CS services
*
SIP NOTIFY
SIP MESSAGE
SIP REGISTER
SIP SUBSCRIBE
SIP Final Response indicating an unsuccessful session-unrelated procedure
SIP CANCEL, indicating abortion of a SIP session set-up
I-CSCF completing a HSS Query that was issued for a SIP INVITE
AS service invocation events
MGCF and BGCF can generate call related CDRs
Conferencing
MRFC can generate related CDRs
*
Server #3
(e.g. UMS)
MMS Charging : Generals
Multimedia Messaging Service (MMS) is based on a specific service node called the MMS Relay / Server (MMS R/S)
Originator MMS R/S serves the MM „originator“
Recipient MMS R/S serves the MM „recipient“
Inter-MMS R/S traffic uses SMTP (email)
Differences to SMS:
Only one MMS R/S involved for intra-PLMN MM transfer, e.g. T-D1 to T-D1
2 MMS R/S involved if originator and recipient are subscribed to different networks (e.g. T-D1 to Vodafone)
In SMS, only one SMSC is involved
*
destination / source addresses used by the “User Agent” (UA)
identification of the MMS R/S(s) involved in the MM transaction
the size of the MM and its components
storage duration, i.e. the time interval when a MM is saved on a non-volatile memory media
identification of the bearer resources used for the transport of the MM, i.e. the identity of the network and the network nodes
In scenarios involving a VASP, the charging information describes the identification of the VASP and the amount of user data sent and received between the MMS R/S and the VASP.
The information listed above is captured for use cases in relation to:
MM submission, retrieval and forwarding
transactions involving the MMbox
transactions involving a VASP
MM volume (size)
MM submission, retrieval and forwarding
Read reply, delivery report, notification, deletion
Upload, download, removal from / to MMBox
MM4 CDR types intended for inter-network accounting
MM exchange between MMS R/S in different networks
Read-reply and delivery reports
Submission and cancellation
Read-reply, delivery reports
*
Charging information in the Service domain (GMLC) is collected for inter-operator accounting purposes; a network requesting location info may be charged by the network providing the location info
The main charging parameters collected by the GMLCs are:
Identity of the mobile subscriber to be located
Identity of the entity requesting the location
Identity of the GMLC or PLMN serving the LCS client
the quality of the location requested by / delivered to the client
date / time the location procedure was requested by the client
Usage of continuous/periodic tracking
LBS information, describing the service specific parameters in addition to the above location resource information
The information listed above is captured for all BC use cases:
Mobile Originated Location Request
Mobile Terminated Location Request
Network Induced Location Request
Online & Offline charging
TS 32.005 (3GPP Rel-99)
TS 32.250 (3GPP Rel-6)
TS 32.251 (3GPP Rel-6)
CS & PS Online charging:
S-CSCF uses ISC interface for online charging
MMS: Offline Charging
Online Charging
TS 32.270 (3GPP Rel-6)
LCS Offline & Online Charging
TS 32.271 (3GPP Rel-6)
*
Each domain was done independently
Each domain has its own functional description and interfaces
Result: Too many different architectures and solutions
However
From an abstract viewpoint, it‘s always the same functionality, regardless of system / technology
Chargeable / billable items (events)
Create CDRs / perform online credit control
Forward CDRs to billing domain
*
Charging Trigger Function
Collects „Metrics“ from the core system, based on system specific triggers (e.g. signalling events)
Formats these metrics into charging events
forwards charging events to the CDF via Rf reference point
Charging Data Function
Collects charging events and formats them into CDRs according to system specific rules
Forwards CDRs to CGF via Ga reference point
Charging Gateway Function
Provides non-volatile CDR file store
Uses Bx reference point for CDR file transfer to Billing Domain
Billing domain
No further standardisation
Same Diameter based interface (IETF Diameter CCA)
Same source collection (building on CTF)
CS and GPRS will retain CAMEL
GPRS will also see the addition of the Diameter interface to GGSN; same as WLAN
*
32.27x
32.299
Diameter
32.295
*
Common online and offline charging architecture
General principles of Charging
Mapping of common architecture onto specific domain
Domain / subsystem / service specific charging functionality, especially type and content of CDRs and ACRs
Common interfaces and applications between the entities of the common architecture
Rf and Ro Diameter application (TS 32.299)
Bx interface to Billing Domain (TS 32.297)
Ga interface between CDF and CGF (TS 32.295)
CDR Parameter and ASN.1 Syntax Description (TS 32.298)
Special case: Online Charging System (OCS) (TS 32.296)
*
„Charging functions“ for
Session based charging
Event based charging
Holds subscriber account
Performs credit reservation on the account
Management of counters applicable for the account
Rating Function (RF)
unit determination: calculation of a number of non-monetary units (“service units”, data volume, time and events);
price determination: calculation of monetary units (price) for a given number of non-monetary units;
tariff determination: determination of tariff information based on the subscribers contractual terms and service being requested;
Management of counters applicable for rating
*
Confined to Re (Rating) interface in Rel-6
Two approaches are being standardised
Rating engine model (Class A)
Charging function fetches data from the Account Balance Management Function
Charging function issues rating request towards the Rating Function
Charging function triggers counter / account update on the Account Balance Management Function
Design goal: allow common Rating Function for online & offline charging
Extended rating engine model (Class B)
Similar to the above, but the rating function also stores and manages some of the counters needed for the rate calculation
*
Problem Statement
The problem:
Charging for bearer resources does not take into account the value of services accessed via these bearer resources
Integrated service pricing: when the tariff model calls for subscribers paying for the service (e.g. MMS), the charges for bearer usage must be removed
Due to different bearer charges in roaming and non-roaming cases, the service price must depend on whether the customer is on the HPLMN or roaming on a foreign network
The solution:
Make bearer and service charging “roaming aware”
*
Functionality
Differentiate between different service data flows for the purpose of charging, e.g.
Web browsing
Applicable to GPRS (GGSN – TS 32.251) and WLAN (PDG) charging
Charging rules for online / offline charging are predefined or provided from a CRF (TS 29.210)
*
Service Based Local Policy (SBLP) : Introduction
SBLP was defined in Rel-5 to enable the IMS to control the QoS provided by the GPRS bearer service based on the requirements of the negotiated application services.
This is based on particular interest if the bearer uses a high QoS and/or if an operator uses IMS network entities to charge application services.
*
PDF
GGSN
GPRS bearers
Policy Enforcement Point (PEP)
Policy Decision Function (PDF)