Operator-Specific API Version Negotiation in 5G NRF
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current mechanisms for API version registration and negotiation in 5G wireless networks are inadequate for accommodating different network operators with varying capabilities and backward compatibility, requiring enhanced mechanisms for network functions to adjust their services based on operator-specific API versions and features.
Innovation Solution
Network functions are enabled to register and negotiate operator-specific API versions and features through the Network Repository Function, using extended API version information formats and data structures, allowing for discovery and negotiation of operator-specific supported features.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If standard API version registration mechanisms are used, then basic API versioning is supported, but operator-specific capabilities and backward compatibility cannot be accommodated
Solution Approach 1:
The API version information is segmented into multiple distinct fields: major version, minor version, patch version, and operator-specific extensions. This segmentation allows each component to be independently managed and negotiated, enabling operator-specific customization without affecting the core versioning structure.
Solution Approach 2:
The patent adds an additional dimension to the API versioning system by introducing operator-specific extension fields beyond the standard three-version-field structure. This dimensional expansion allows operators to specify their unique requirements and capabilities while maintaining compatibility with the base versioning mechanism.
2Reliability
If operator-specific API version information is negotiated, then service compatibility across diverse operator environments is enhanced, but negotiation complexity increases
Solution Approach 1:
Operator-specific API version information and supported features are pre-registered with the Network Repository Function before actual service deployment. This preliminary action allows the negotiation mechanism to simply retrieve and match pre-defined configurations rather than performing complex real-time negotiations, thereby reducing negotiation complexity while ensuring compatibility.
Solution Approach 2:
The Network Repository Function serves as an intermediary that stores and manages operator-specific API version information. Network functions can query this intermediary to discover compatible versions and features, simplifying the negotiation process by offloading the complexity of maintaining version information to a centralized repository.
3Loss of information
If extended API version formats are implemented, then discovery of operator-specific features is enabled, but information processing overhead increases
Solution Approach 1:
Operator-specific feature information is extracted and stored as separate, dedicated fields in the extended API version format. This extraction allows the system to handle standard versioning information and operator-specific information independently, reducing processing overhead by only loading and processing relevant fields based on the specific operator and service context.
Data Source
AI summary
A system includes one or more devices that include a memory to store instructions and one or more processors to execute the instructions. The devices include an updated network function (NF) service producer that includes a recent update, wherein the NF service producer is configured to register at a Network Repository Function (NRF) using a Network Function profile (NF profile), wherein the NF profile indicates a Network Function type (NF type) and Application Programming Interface versions. The devices further include a network function (NF) service consumer configured to: receive a message from a network component; determine to engage a service of a NF service producer of the NF type based on the message; and send a discovery request to the NRF in response to the message, wherein the message includes search criteria that specify a version field extended with an operator dependent version field.