NEF API Charging Rules for Zero-Charge Request Identification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing communication systems struggle to differentiate between production and testing API service requests from enterprise subscribers, leading to incorrect billing and inefficiencies in charging for API service requests, particularly in 5G Core Networks, due to the inability to identify whether requests are chargeable or zero-charge requests.
Innovation Solution
Implementing a northbound API charging rule using a Network Exposure Function (NEF) that creates a whitelist with enterprise subscriber information, including IP addresses and protocol port numbers, to assign rating groups for API service requests, allowing for zero-charge or chargeable billing based on the context of the request.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If existing communication systems use generic billing for all API service requests, then billing simplicity is maintained, but billing accuracy deteriorates due to inability to differentiate between production and testing requests
Solution Approach 1:
The system pre-establishes a whitelist containing enterprise subscriber information (IP addresses, protocol port numbers) before API service requests are made. This preliminary configuration enables the NEF to quickly determine whether requests should be charged or free by checking against the pre-defined whitelist, achieving accurate billing differentiation without complex real-time analysis
Solution Approach 2:
The Network Exposure Function (NEF) acts as an intermediary between the API service requests and the charging function. The NEF receives requests, compares them against the whitelist to determine rating groups (chargeable vs. zero-charge), and forwards appropriate indicators to the CHF. This intermediary role enables accurate billing differentiation while keeping the charging system itself relatively simple
2Measurement precision
If specialized APIs are created to differentiate testing and production requests, then request identification accuracy is improved, but API complexity increases
Solution Approach 1:
The system uses a single northbound API for all API service requests, regardless of whether they are for testing or production. The differentiation is achieved not through multiple specialized APIs but through the universal API combined with whitelist-based routing that directs requests to appropriate rating groups. This multi-functional approach maintains API simplicity while achieving accurate request identification
Solution Approach 2:
Instead of creating different APIs, the system changes parameters within the existing API framework by using IP addresses and protocol port numbers as identifying parameters. These parameters are compared against the whitelist to determine the appropriate rating group, enabling request differentiation through parameter analysis rather than through API structure complexity
3Productivity
If all API service requests are charged, then revenue generation is maximized, but operational efficiency deteriorates due to inability to automatically identify zero-charge requests
Solution Approach 1:
The whitelist is pre-configured with enterprise subscriber information before operational use. This preliminary action enables the system to automatically identify zero-charge requests (testing requests) by simple whitelist matching, eliminating the need for complex real-time analysis and reducing charging processing overhead while maintaining operational efficiency
Solution Approach 2:
The system enables self-service billing determination where the NEF automatically compares incoming requests against the whitelist and self-determines the appropriate rating group without requiring external intervention or complex processing. This self-service mechanism efficiently distinguishes between chargeable and zero-charge requests, reducing operational overhead
Data Source
AI summary
A method comprises writing, by a Network Exposure Function (NEF) to a memory, a first Internet Protocol (IP) address to a whitelist that is of the communication device and that is associated with an enterprise subscriber of a network provider; receiving, by the NEF, the API service request from the AF based on an invocation of an API, wherein the API service request comprises a second IP address of the communication device; comparing, by the NEF, the first IP address with the second IP address; obtaining, by the NEF, a rating group for the API service request based on comparing the first IP address with the second IP address; sending, by the NEF to a charging function (CHF), an indicator for indicating the rating group of the API service request; and sending, by the NEF, a second indicator to the CHF indicating the API service request is completed.