Convergent Charging in a 5G Network
Convergent Charging in a 5G Network
To learn more about Offline Charging, please read Basics of Telecom Offline Charging.
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.
 |
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: -
 |
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.
- 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.
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.
Below
figure explains the 5G Converged Charging architecture as per the 3GPP
standard.
 |
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.
 |
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.
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!
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)
Subscription and Usage Monetization | OSS BSS | SAAS, 5G, 4G, Broadband, IPTV, Pay TV, Prepaid | TOGAF
Posts
Hi Rajarshi,
ReplyDeleteThank 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
Hello Farid,
DeleteGlad 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
Hi again Rajarshi,
DeleteThank 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
Hi Farid,
DeleteTS 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!
Hi Rajarshi,
DeleteSorry 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
Thank you Farid for your kind comments.
ReplyDeleteHi Rajarshi
ReplyDeleteMy 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.
Sure Animesh, I will clarify your doubts. We use Nchf_OfflineOnlyCharging service to provide offline only charging for any session-based service.
DeleteCreate, 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.