Convergent Charging in a 5G Network


 Convergent Charging in a 5G Network


5G Converged Charging at a glance by Rajarshi Pathak


Telecom Charging Basics: In my previous articles, I have explained in-depth the concepts of Online Charging and Offline Charging in the Telecom domain.

To know more about Online Charging, please read Basics of Telecom Online Charging.

To know more about Offline Charging, please read Basics of Telecom Offline Charging.


Here, is the summarized version of Online & Offline Charging Concepts: -

For Online Charging, the balance reservation/deduction happens before the consumption of the Services from the Credit balance. For Subscribers to use Services, it is required for them to have enough balance in their account.

For Offline Charging, the balance update or redemption happens after the consumption of the Services and normally, the usage charges appear on the Invoice/Bill of the Subscribers. As long as, Subscribers are not reaching their credit limit, they can consume the Services and keep on paying the bills.

I would encourage you to read the mentioned articles in case the summary is not enough.

Coming back to the topic of Convergent Charging in a 5G World.

Telecom Charging in 5G will be Converged Charging, meaning, it will support both Online as well as Offline Charging models.

Converged Charging by Rajarshi Pathak

fig. Converged Charging

It is on the same line as Converged Billing System, which can handle Postpaid as well as Prepaid Payment methods and process Online Charging as well as, Offline Charging events.

The functioning of 5G Convergent Charging System: -

5G Converged Charging, Rating, and Billing in a nutshell

fig. 5G Converged Charging, Rating, and Billing in a nutshell


How Online Charging Triggers are processed by 5G Converged Charging System:

  • Customer initiates service usage.
  • Receives Online Charging trigger from the Network.
  • Performs Service Authorization and Credit control.
  • Measures the event & performs the required balance reservations.
  • For Session based charging, Service Operations like Create, Update & Release are performed just like Initial, Update & Terminate Diameter Messages in a 3G/4G world. Via this, ConvergedCharging Operation allows Service delivery of Session-based Services with or without Quota Management.

CTF (SMF, SMSF, AMF, NEF/AF acting as NF Consumers) to demand Requested Service Units from CHF, CHF acknowledgment by Granted Service Units to CTF and later CTF updates back the Used Service Units to CHF.

  • For Event based charging, ConvergedCharging Service allows Service delivery. NF Consumer to demand Requested Service Units from CHF and CHF acknowledgment by Granted Service Units to CTF through Charging Data Request [Event] & Charging Data Response [Event].
  • On Service Termination, apply balance impacts to the measured event based on Rating & Pricing configuration.
  • Rated Event data gets generated and stored in the Billing system.


How Offline Charging Records are processed by 5G Converged Charging System:

  • Customer initiates service usage.
  • Raw CDRs get generated about this usage. Usage can be Session-based (e.g. HD Voice call, Multimedia Session, etc.) or Event-based (e.g. IOT Sensors Events, SMS, etc.). OfflineOnlyCharging Service Operations are used for Session-based Services and ConvergedCharging Service Operations are used for Event-based Services.
  • Charging Data Request and Charging Data Response Messages between CHF & CTF (SMF acting as NF Consumer) are used to construct CDRs for service usage. Operations like Create CDR, Open CDR, Update CDR, and Close CDR are performed via the APIs.
  • Raw CDRs are collected and processed.
  • Processed CDRs based on enrichment & business rules are guided to Rating Engine.
  • CDRs are rated by Rating Engine as per the rate plans by measuring the events.
  • Rated Event data gets generated and stored in the Billing system.

Interworking of 5G Charging System with Policy Control:

Along with the above, CHF works together with PCF for Spending Limit Control by monitoring the Subscriber's Usage consumption & Policy Counters by interacting with PCF. Together with PCF, it provides Policy and Charging Control during service delivery.

In case you wish you get extensive details, you can read my previous article Policy and Charging Control in a 5G Network

Let's understand the 5G Converged Charging Server mechanism as per 3GPP standard: -

Below figure explains the 5G Converged Charging architecture as per the 3GPP standard.

5G Converged Charging Architecture

fig. 5G Converged Charging Architecture

CTF (Charging Trigger Function): This is the node in the network which generates charging triggers whenever a Customer uses services. Let's suppose, a Customer wants to send an SMS. Here, the SMSF node acts a CTF and generates charging triggers for SMS delivery.

CHF (CHarging Function): CHF is an integral entity in CCS (Converged Charging System) which provides Account Balance Management function (ABMF) for balance management/quota management, Rating Function (RF) for measuring the events, and Charging Gateway Function (CGF). Together, they are known as Converged Charging Server (CCS).

If compared with 4G Network, CHF combines the functionality of OCF (Online Charging Function) and CDF (Charging Data Function). Hence, CHF enables Online and Offline Charging by closely interfacing with NF Consumers.

CGF (Charging Gateway Function): It Collects, Validates, Parse & Enriches the Raw CDRs and Distributes the processed CDRs to the BSS systems.

Billing System: This is the core system of the Operators' BSS stack. It consumes the rated events stored in the database and adds up the Usage charges against the Customer's bill amount. During Bill Run, charges like monthly recurring charges, one-time charges, cancellation charges, etc. are processed along with usage charges. Other activities like billing time discounts, adjustments, settlements, taxes, etc. are also considered during the Bill Run. Once the Bill is finalized, it becomes ready for Payments against the Invoice.

Below is the simplified view of CHF and associated Network Functions in a typical 5G Network Architecture: -

A simplified view of CHF in a 5G Network

fig. A simplified view of CHF in a 5G Network

As explained above, Converged Charging Server takes care of processing Online & Offline Charging records by working with NF Consumers like SMF, SMSF, AF, etc. and updating rated events into the Billing System. It also interacts with PCF for Policy & Charging Control.

Towards the end…

5G Charging System should be capable to charge customers/enterprises based on the Services consumed through different Network slices.

It should be Cloud-enabled for the required Auto-scaling & flexibility for high-volume usage processing. Along with the RESTful APIs support, it should also be backward compatible with Diameter & CAMEL charging protocols as well.

5G Charging System is expected to support charging for Use cases related to eMBB, mMTC, and URLLC Services. This requires Usage Processing based on high bandwidth (e.g. FWA, 4K/8K content delivery), low latency/high threshold (e.g. AR/VR, Self-driving cars) and high density (e.g. IoT devices, Smart Cities, Industry 4.0) Service consumptions.

5G Network caters to B2C, B2B, and B2B2X business models, and hence, the Charging requirements may vary based on the business use cases for Consumers, Enterprises, and Partners.

The road to explore the full potential of the 5G Monetization Solution will be quite interesting!

To know more about 5G Charging System Requirements, please read Requirements for the 5G Monetization Solution

Kindly share this article with your friends and colleagues. Feel free to like and comment. Happy learning.


Glossary:  3GPP (3rd Generation Partnership Project), BSS (Business Support System), OSS (Operations Support System), SBI (Service based Interface), CHF (Charging Function), CCS (Converged Charging Service/System), SMF (Session Management Function), NF (Network Function), SMSF (Short Message Service Function), Nchf (CHF Service Based Interface), PCF (Policy Control Function), AMF (Access and Mobility Management Function), NEF (Network Exposure Function), UE (User Equipment), AF (Application Function), AAA (Authentication, Authorization & Accounting Server), eMBB (enhanced Mobile Broadband), URLLC (Ultra-Reliable Low Latency Communications), mMTC (massive Machine Type Communications), FWA (Fixed Wireless Access), CAMEL (Customized Applications for Mobile network Enhanced Logic)


Please use the CONTACT Form to get in touch with me for any training needs, consulting assignments, or other requirements. You can also connect with me via LinkedIn.

6 comments:

  1. Hi Rajarshi,

    Thank you for this interesting post.

    I have a question related to the offline charging process for 5G data connectivity domain.
    In this context, can you please clarify where the RF and ABMF functions are operated for such Charging Data Requests (without quota management)?
    5G CCS or Billing Domain (BD)?

    According to this post, offline charging requests are rated through the 5G CCS which I doubt...
    3GPP related TS documents are not really clear on this topic.
    My understanding is that, in case of offline charging, the CHF is used only to produce CHF CDRs to be transferred by the CGF to the BD for post-processing activities (such as Rating & Billing).

    What's your opinion on this?

    Br,

    Farid

    ReplyDelete
    Replies
    1. Hello Farid,

      Glad you found the article interesting.

      Your query is mainly from the implementation perspective, on how the concept of Offline charging wrt 5G CCS or CHF can be envisioned in the current Monetization Suite (consisting of OCS/OFCS/Mediation/Billing Products) which supports Diameter/RADIUS/CAMEL requests & will be handling HPPT2 requests/responses as well. Hence, you cannot find this level of details in 3GPP TS documents.

      Coming back to your specific query on handling offline charging for 5G data usage. It can be implemented in various ways depending on the capabilities & architecture of BSS providers. It is also worth to note that CCS & BD are closely knitted to each other. They are highly dependent on each other for the E2E processing of Online/Offline records, its reflection in the Customer's balance impact & finally on the Invoice.

      Some of the ways are: -
      1. Operators keep using their existing Convergent Charging (you can even call Convergent Billing) platforms which supports Online/Offline records. Add one wrapper which supports HTTP2 request/response to support Nchf interface with NF (e.g. SMF). Using which, produce the charging request/response to form the CDRs and feed it to existing CGF for processing the usage records. Use the Convergent charging server for rating the usage records, generate the rated events to later loading into the Billing domain for actual balance impact against the customer account. This can be the classical case of handing Offline charging records for Postpaid subscribers.
      2. If its 5G NSA Data service, then continue to use your existing Convergent Billing (or Charging) platform to handle the CDRs generated by NF (acting as CDF), processed by CGF, consumed by rating engine & later loading into the BD. This is how Diameter based Offline charging is handled today as well for Session based services.
      3. To accommodate the real time behavior of 5G services & offerings, 5G CCS can directly process Nchf interface based HTTP2 Charging Data records into the cache by using the customer, rating & product related data in the cache, perform balance management & rating in the cache, generate the rated events, and later load it into Billing domain for the actual balance impact. This behavior is uniform for both online & offline charging requests generated by CHF and will be beneficial for handling 5G SA services.

      There can be other ways too. It’s how the current Monetization suites will be handling the CHF triggers for Online/Offline requests with minimized changes in their current product architectures. You can reach out to me by directly messaging incase of any further discussions.

      Thanks again for reading the post!

      Regards,
      Rajarshi

      Delete
    2. Hi again Rajarshi,

      Thank you very much for your detailed answer.

      My concern relates to the 3GPP specifications and not to the implementation itself.

      I do agree with you on the different options when it comes to the implementation phase.

      However, if you analyze the charging scenario defined in TS document 32290, section 5.3.2.3 (Converged Session based charging) , the step 11 specifies that RF and ABMF processes shall be applied to the reported charging data in case of a usage reporting trigger (step 9, without quota management - offline charging).
      So here it means that RF and ABMF functions reside in the 5G CCS for offline charging.

      Is this due to the context of the charging scenario that specifies a “Centralized Rating configuration, user’s account deduction” ?

      Br,

      Farid

      Delete
    3. Hi Farid,

      TS 32290 Sec 5.3.2.3 is not specific to Offline Charging. This section talks about Converged Charging and hence, the flow mentioned is covering both Online (Charging Data Request/Response triggers) & Offline charging scenarios (CDR generation).
      Coming to Step 11, all its doing is updating the 5G CCS cache or balance via CHF (Nchf interface) by reporting the Used units against the Granted units.

      You can check Point 3 in my previous comment on how CCS is performing RF & ABMF functions to update the Customer balance cache. On Session Termination, this updated cache gets processed to rated events and impacts the Customer's actual balance.

      Thanks!

      Delete
    4. Hi Rajarshi,

      Sorry for the late reply !

      Yes indeed, we are aligned now.

      Thank you very much for your feedback and your insights in this subject.
      It is appreciated.

      Take care.

      Farid

      Delete
  2. Thank you Farid for your kind comments.

    ReplyDelete

Thanks for visiting! Please use the CONTACT Form to get in touch for any training needs, consulting assignments, or other requirements. You can also connect with me via LinkedIn.