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 learn more about Online Charging, please read Basics of Telecom Online Charging.
To learn 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 the 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 the 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:

  • The 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:

  • The customer initiates service usage.
  • Raw CDRs are generated for 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 the 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 that generates charging triggers whenever a Customer uses services. Let's suppose, a Customer wants to send an SMS. Here, the SMSF node acts as a CTF and generates charging triggers for SMS delivery.

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

If compared with a 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, Parses & 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, the 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 in the Billing System. It also interacts with PCF for Policy & Charging Control.

Towards the end…

The 5G Charging System should be capable of charging 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 API 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 exploring 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.

8 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
  3. Hi Rajarshi

    My question is basically on the 5G Nchf_offlineChargingOnly . It is getting a bit confusion as to why create/update& terminate are required for the offline charging of the event (APIs of offlineonlycharging)..smth that has already taken place. Can you please help to explain the offlinecharging scenario in 5G how it would take place with an example.

    ReplyDelete
    Replies
    1. Sure Animesh, I will clarify your doubts. We use Nchf_OfflineOnlyCharging service to provide offline only charging for any session-based service.

      Create, Update and Release operations are required to manage the entire session of service consumption and to collect the session records.

      Suppose you want to download a 4K video from an edge server. On the download initiation, Create API will be called by SMF for initial auth & service authorization. On successful response, the download will begin. Later based on the requested/used quota, Update API will be called to maintain the download session. After the complete download, Release API will be called to inform about the end of the session and finalize the charging information in the form of EDRs, which will be later processed by Mediation/Billing. I hope this clarifies.

      Delete

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.