1 / 46

Charging Management in 3GPP SA5 SWGB What the standards provide Chair: Karl-Heinz Nenner (T-Mobile) Vice Chair: Gerald

Charging Management in 3GPP SA5 SWGB What the standards provide Chair: Karl-Heinz Nenner (T-Mobile) Vice Chair: Gerald Görmer (Siemens AG). SA5 SWGB Rapporteur Group Structure. General Charging Session Karl-Heinz Nenner (T-Mobile). Bearer Charging Session Benni Alexander (Nokia).

Télécharger la présentation

Charging Management in 3GPP SA5 SWGB What the standards provide Chair: Karl-Heinz Nenner (T-Mobile) Vice Chair: Gerald

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  1. Charging Management in 3GPP SA5 SWGB What the standards provide Chair: Karl-Heinz Nenner (T-Mobile) Vice Chair: Gerald Görmer (Siemens AG)

  2. SA5 SWGB Rapporteur Group Structure General Charging Session Karl-Heinz Nenner (T-Mobile) Bearer Charging Session Benni Alexander (Nokia) IMS Charging Session Göran Andersson (Ericsson) Service Charging Session Gerald Görmer (Siemens AG)

  3. Table of contents 1. Motivation 2. Setting the scene for charging in 3GPP 2.1 Charging Levels 2.2 Charging Methods 3. Timeline 4. Release 6 4.1 Common Charging Architecture 4.2 Common Interfaces and Applications • Additional Functionality 5.1 The Online Charging System 5.2 Flow based Bearer Charging

  4. MotivationThe business principles behind The Vendor business paradigm: • to sell equipment to Operators, • purpose of equipment is to build telecom networks The Operator business paradigm: • build and operate a (mobile) telecom network • 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 charging is at the core of the business for vendors and operators alike!

  5. MotivationThe key terms in 3GPP 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 BD: Billing Domain

  6. Setting the scene for charging in 3GPP Charging Levels • Bearer, Subsystem and Service charging Charging Methods • Online versus Offline charging

  7. Setting the sceneCharging Levels 1. Bearer Charging, comprising • Charging for the Circuit Switched Domain • Charging for the Packet Switched Domain (GPRS) • Charging for the I-WLAN 2. Subsystem Charging, i.e. IMS 3. Service Charging, comprising • MMS • LCS • More to come, e.g. MBMS, Push, Presence, Messaging • In future, OMA Services ?!

  8. Setting the sceneCharging 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: Charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with bearer/session/service control is required. The mechanism comprises the execution of credit control and subscriber account balance management on the Online Charging System.

  9. Setting the scene – Bearer Charging : CS domain CS domain charging involves: • the GMSC • the MSC (server) • the HLR • the EIR • Offline Charging: • CDR types for MOC, MTC, IncGW, OutGW…. • Online charging: CAMEL • TS 03.78/09.78 (GSM) • TS 23.078 / 29.078 (3GPP)

  10. Setting the scene – Bearer Charging : CS domain Basic principles • „call records“ per call/duration • Multiple „partial records“ for long calls • Tariff Time Change captured within CDR • All service invocation information inside CDRs Major CS charging parameters • Origination / Destination of call • Invoked services (BS, TS, SS) • Radio resource usage for data Special Cases • SMS (supported from the early days) • Mobile Originated SMS CDR • Mobile Terminated SMS CDR • LCS (supported as of Rel-4) • Mobile terminated location request CDR • Mobile originated location request CDR • Network induced location request CDR

  11. Setting the scene – Bearer Charging : PS domain PS domain (GPRS) charging involves the SGSN and the GGSN Offline Charging: • M-CDR records MM items when user is GPRS attached • S-CDR and G-CDR capture PDP context charging Online charging: • CAMEL based • TS 03.78/09.78 (GSM) • TS 23.078 / 29.078 (3GPP) • Diameter based • Built upon IETF DCC

  12. Setting the scene – Bearer Charging : PS domain 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 • User ID („origination“) as in CS • APN („destination“) • Time, data volume, QoS Special Cases: SMS and LCS as in CS domain

  13. 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 • in WLAN, VPLMN AAA and HPLMN AAA in scenario 3, where user traffic traverses VPLMN and HPLMN

  14. Setting the scene – Subsystem ChargingIP Multimedia Subsystem (IMS)

  15. Setting the scene – Subsystem ChargingIMS Charging : Generals Proxy Call Session Control Function („CSCF“) • Determines applicable I-CSCF • Routes SIP signalling between UE and S-CSCF • Resource control via embedded PCF Serving CSCF • Responsible for session control • Interacts with service platforms • 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 • Determines applicable S-CSCF • Routes SIP signalling to / from „foreign“ networks (Roaming) Application Server • Provides any kind of „service“ • Services are not standardised in the 3GPP specifications • Examples: movie / music clips, news flash, soccer goals, ….

  16. Setting the scene – Subsystem ChargingIMS Charging : Basic principles  CDRs are generated per IMS session / duration  Tariff Time Change is captured within CDR  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“ • Correlation between IMS CDRs is required (e.g. CSCF CDRs, AS CDRs) – all CDRs contain the same IMS „Charging ID“

  17. Setting the scene – Subsystem ChargingIMS Charging : Aspects Major IMS charging parameters • Origination / Destination of session • Invoked media components (audio, video, etc.) • 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 • Conferencing Online charging only in S-CSCF, AS and MRFC

  18. Setting the scene – Subsystem ChargingIMS Charging : Special cases SIP Events create ACR Events instead of start/interim/stop messages • SIP NOTIFY • SIP MESSAGE • SIP REGISTER • SIP SUBSCRIBE • SIP Final Response indicating an unsuccessful SIP session set-up • 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 CS interworking • Several nodes support CS interworking, i.e. MGCF, MGW, BGCF • MGCF and BGCF can generate call related CDRs Conferencing • MRFC and MRFP provide conferencing capabilities (H.248) • MRFC can generate related CDRs

  19. Setting the scene – Service ChargingMultimedia Messaging Service (MMS)

  20. Setting the scene – Service ChargingMMS 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 • In contrast to SMS, MMS charging is standardised in the service area (i.e. the MMS R/S), not the bearer domain (MSC/SGSN)

  21. Setting the scene – Service ChargingMMS Charging : Basic principles  The MMS R/S collects charging information such as: • 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

  22. Setting the scene – Service ChargingMMS Charging : Aspects Major charging parameters • Originator and Recipient (user agent & network) • MM volume (size) Offline Charging • MM1 CDR types to enable end user billing • 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 • MM7 CDR types for VASP transactions • Submission and cancellation • Read-reply, delivery reports Online Charging with Diameter Credit Control

  23. Setting the scene – Service ChargingLoCation Service (LCS)

  24. Setting the scene – Service ChargingLCS Charging : Generals • 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

  25. Timeline of charging TS • Bearer, Subsystem and Service charging Releases • Online & Offline charging

  26. Timeline of charging TSCS and PS domains  CS Offline Charging • TS 12.05 (GSM until Rel-98) • TS 32.005 (3GPP Rel-99) • TS 32.205 (3GPP Rel 4/5) • TS 32.250 (3GPP Rel-6)  PS Offline Charging • TS 12.15 (GSM Rel-97/98) • TS 32.015 (3GPP Rel-99) • TS 32.215 (3GPP Rel 4/5) • TS 32.251 (3GPP Rel-6) • CS & PS Online charging: CAMEL • TS 03.78/09.78 (GSM) • TS 23.078 / 29.078 (3GPP) • PS Online Charging: based on IETF DCC • TS 32.251 (Rel-6)

  27. Timeline of charging TSIMS and Service Charging IMS: Offline & Online Charging • TS 32.225 (3GPP Rel-4/5) -> TS 32.260 (3GPP Rel-6) • S-CSCF uses ISC interface for online charging MMS: Offline Charging • TS 32.235 (3GPP Rel-4/5) -> TS 32.270 (3GPP Rel-6) Online Charging • TS 32.270 (3GPP Rel-6) LCS Offline & Online Charging • TS 32.271 (3GPP Rel-6) As a major change, Rel-6 sees the introduction of common charging architecture, interfaces and applications for all 3GPP charging

  28. 3GPP Release 6 • Common Charging Architecture • Common Interfaces and Applications

  29. Charging Standards Rel-6Getting more organised  Every new technology came with its own charging solution • 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) • Calls / Sessions • Service Events • The same basic tasks • Collect charging relevant information (usually from signalling parameters) • Create CDRs / perform online credit control • Forward CDRs to billing domain • Identical information flow from network to Billing Domain / OCS according to the above basic tasks


  31. Charging Standards Rel-6 Common offline charging architecture

  32. Charging Standards Rel-6 Common offline charging architecture 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 • Receives CDR files from CGF • No further standardisation

  33. Charging Standards Rel-6 Common online charging architecture

  34. Charging Standards Rel-6 Common online charging architecture Common approach for online charging • 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 All new Rel-6 services (MBMS, Push, Presence, Messaging, …) will use same offline and online charging functions

  35. Charging Standards Rel-6Structure of TS series

  36. Charging Standards Rel-6Structure of TS series  TS 32.240 Architecture and Principles • Common online and offline charging architecture • General principles of Charging  One „Middle Tier“ TS per domain / subsystem / service • 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)

  37. Additional functionality • The Online Charging System • Flow based Bearer Charging

  38. The Online Charging System

  39. The Online Charging System The following components of an „OCS“ have been identified • „Charging functions“ for • Session based charging • Event based charging • Account Balance Management Function (ABMF) • Holds subscriber account • Controls addition / deduction of monetary amounts from 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

  40. The Online Charging SystemTS 32.296: OCS applications and interfaces  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 • Requires additional scenario on Re to acknowledge service delivery and counter update

  41. Flow based Bearer ChargingProblem 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 charging “service aware” • Make service charging “access aware” • Make bearer and service charging “roaming aware”

  42. Flow based Bearer ChargingFunctionality • Differentiate between different service data flows for the purpose of charging, e.g. • Web browsing • IP Video Telephony • MMS versus WAP traffic • ……. • 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) • Charging rules determine the CDR generation (offline charging) and credit control procedure (online charging)

  43. Backup

  44. 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. • In Rel-6 the concept was extended for non-IMS application functions.

  45. Service Based Local Policy (SBLP) : Architecture

  46. Service Based Local Policy (SBLP) : Functions • Policy Enforcement Point (PEP) • Policy Decision Function (PDF) • Application Function (AF)

More Related