The Nchf services produced by the Charging Function (CHF) implement the charging system in the 5GC. Network Functions that implement the Charging Trigger Function (CTF) report the chargeable activities of subscribers to the CHF, which in turn delivers Charging Data Record (CDR) files to the operator’s Billing Domain. When offline charging is used the charging data is collected during resource consumption by the subscriber and reported when a threshold is crossed or after the resource is released. Offline charging has no affect on subscribers’ real-time activities or resource consumption. Conversely, online charging occurs for particular services or events when the service is requested or the event is initiated, and it involves authorization, and possibly re-authorization, of service accessibility or prepaid credit remaining. Service delivery may be curtailed if a subscriber is not authorized to access it, does not have sufficient credit quota to pay for it, or chooses not to pay for it in real time. The same chargeable event can be reported by both online and offline charging, although the type of information reported may differ.
While offline and online charging were separately implemented in previous wireless technologies, in 5G the Converged Charging System supports simultaneous online and offline charging through the Nchf_ConvergedCharging Service. The Nchf_OfflineOnlyCharging service provides session-based and post-event charging if event-based charging is not desired. In addition, PCFs can now use the Nchf_SpendingLimitControl service to subscribe to notifications of policy counter changes that influence their policy decisions.
When one of the CTFs shown above receives a request for session establishment for a service that requires charging authorization, it determines the number of charging units required, or to be initially requested, for the service and then uses the Create operation to send a Charging Data Request to the CHF. In this request the CTF identifies the subscriber, the service requested, and the type of charging that triggered the request: Immediate Event Charging (IEC), Session-based Charging with Unit Reservation (SCUR), or Event-based Charging with Unit Reservation (ECUR). In addition, the CTF may include other information, such as UE location, depending on the service requested and will report any usage if service delivery was allowed to begin. In any of these charging scenarios the CTF, depending on its configuration and on the service requested, may allow service delivery while awaiting the CHF’s response or it may block service delivery until authorization is received.
Upon receipt of a request for authorization the CHF converts the units requested into monetary units using the applicable rating — which may vary based on UE location, time of day, or other factors — and deducts that amount from the subscriber’s account if the balance is sufficient to cover the charge. In this case the CHF opens a Charging Data Record (CDR), where it will record the transaction data, and then responds to the CTF with the units allocated. When the balance is insufficient the CHF notifies the CTF, which in turn typically denies service delivery to the UE. This completes the charging service delivery for IEC or ECUR charging.
When SCUR charging is authorized, CTFs report actual usage to the CHF using the Update operation as usage or other factors reach reporting triggers. The CHF may choose to re-authorize the subscriber when usage crosses a quota trigger or other events occur, and notifies the CTF that it should invoke the Update operation. Should the subscriber exhaust their credit quota, the CHF determines whether the service delivery must be terminated, and notifies the CTF to terminate the session when indicated. In some cases the subscriber may be prompted to replenish their credit in order to continue. When the subscriber’s service delivery is complete the CTF uses the Release operation to notify the CHF and includes the final usage report in the request. The CHF adjusts any remaining credit balance as necessary and closes out the CDR.
CTFs can utilize Post Event Charging (PEC) in cases where charging authorization is not required. In this case the CTF reports service initiation, delivery, and usage with one Charging Data Request and the CHF creates the CDR after service delivery is complete.
In all of these scenarios the CHF determines, based on its configuration, when and how to forward closed CDRs to the operator’s billing domain.
SMFs may utilize the OfflineOnlyCharging service for event-based or session-based charging that does not require authorization or quota management. The SMF uses the Create operation upon event occurrence or session establishment to open a CDR in the CHF and includes an initial, or final in the case of event-based charging, report of usage. The CHF may provide usage reporting triggers for session-based charging in its response. As the session proceeds the CTF uses the Update operation to report usage to the CHF when indicated, and when the session terminates it uses the Release operation to notify the CHF that service delivery is complete.
PCFs use this service to retrieve policy counter status information about a subscriber in order to inform its policy decisions. With the Subscribe operation they convey the subscriber’s identity and specify the information to which they subscribe. The CHF returns the current status in its response, and will notify the PCF if that status changes. A PCF may also use the Subscribe operation to modify its subscription, and it may implicitly unsubscribe by setting a validity time on the subscription. In addition to notifying a PCF of policy counter status changes, the CHF will notify the PCF when the subscriber has been removed from the CHF, which should trigger the PCF to use the Unsubscribe operation to release its subscription.
Use our CHF emulator in your test network to provide Nchf_ConvergedCharging and Nchf_SpendingLimitControl services in your lab while also verifying NF service consumer compliance with service APIs.
Test your CHF by surrounding it with our CTF and PCF consumer emulators:
- Create and release individual contexts in the CHF using the CTF emulators’ Nchf_ConvergedCharging events.
- Subscribe to and unsubscribe from policy counter change notifications using the PCF emulator’s Nchf_SpendingLimitControl events.
- Configure the CTF emulators to periodically update active individual contexts in the CHF to trigger notifications towards the PCF.
As with all dsTest products, the node configurations and test scenarios are easily defined and configured with XML files that are validated against a published XML Schema to avoid invalid definitions. With our dsClient Desktop application you can create, run, and archive tests; capture, graph and archive operational measurements; capture real-time data flows and subscriber events; and manage your dsTest platforms and testing scenarios with a standalone application that runs on your PC.
Advanced Testing Features
SmartEvents — Alter application behavior or coordinate multiple interface applications with SmartEvents — our programmable, subscriber-level state machine. All dsTest applications are event-driven, enabling you to easily alter subscribers’ activities. Use our visual composer to draw your state machine and to trace a single subscriber’s path through the state machine while the test is running. Define event handlers that affect a subscriber’s behavior in an application, or that trigger an event in another application. You can also configure event handlers to modify subscriber information during run-time, introduce timers, or randomize subscriber behavior based on configurable probabilities to name just a few of the many options in one of dsTest’s most powerful features.
SmartMessageElement — Insert, delete, or replace elements in Diameter, RADIUS, MAP, LDAP, GTP, REST, or SOAP messages with our SmartMessageElement feature. Define proprietary signaling or corrupt elements to facilitate negative testing. You can specify when your elements are used with SmartEvents.
Traffic Profile — Draw the shape of your test actions across time with Traffic Profile. You can define the rate for any action as a static rate or reference a Traffic Profile configuration, which also means that multiple Traffic Profiles can be running concurrently. Use Traffic Profile in conjunction with the randomizing features in SmartEvents to design a test that more truly simulates real-world network activity.
REST Dictionary — Add conformance testing to your performance or functional test with our REST Dictionary. You can validate message types and JSON structures by simply including our base dictionary. You can also build custom dictionaries to explicitly define required parameter and property values and selectively include the dictionary to be used for a particular test.
dsTest provides rich sets of measurements for Nchf services:
- Transaction and transport layer attempts, successes, and failures
- Transaction duration, transactions-per-second, and round-trip delay
- Message and byte counters
- Errors encountered and error indications received in messages