Callback URI API Prefix Handling for NF Reselection Routing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing 3GPP Service Based Architecture (SBA) lacks support for an optional deployment-specific API prefix in callback Uniform Resource Identifiers (URIs), leading to issues such as incorrect routing and processing of notification requests due to mismatched software versions and route selectors when NF service consumer instances are reselected.
Innovation Solution
Enhance the callback URI structure to explicitly indicate the presence and value of an API prefix using new headers (e.g., 3gpp-Sbi-Binding, 3gpp-Sbi-callback-uri-prefix) and modify the NF service consumer reselection procedure to include the API prefix in the new URI, ensuring flexible and reliable communication between NF service producer and consumer instances.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If the callback URI structure is enhanced to include API prefix, then routing precision and software version matching are improved, but device complexity increases
Solution Approach 1:
The callback URI is segmented into distinct components including the API prefix, host, and path. The API prefix is extracted and stored separately in the 3gpp-Sbi-Binding header, allowing it to be independently managed and applied during service consumer reselection. This segmentation enables precise routing without overwhelming the overall system structure.
Solution Approach 2:
The API prefix is determined and stored in advance during the service request phase, before service consumer reselection occurs. The 3gpp-Sbi-Binding header is populated with the api-prefix parameter ahead of time, so that when reselection is needed, the correct prefix is already available for constructing the new callback URI, eliminating the need for complex real-time determination.
2Reliability
If NF service consumer reselection is implemented, then system reliability is improved, but incorrect routing occurs due to mismatched software versions
Solution Approach 1:
The system uses the 3gpp-Sbi-Binding header as a feedback mechanism that carries the API prefix information from the service consumer back to the service producer. This feedback loop ensures that when reselection occurs, the new callback URI constructed includes the correct API prefix that matches the software version of the target service consumer instance, preventing routing mismatches.
Solution Approach 2:
The callback URI parameters are dynamically changed during reselection based on the API prefix stored in the 3gpp-Sbi-Binding header. The system modifies the callback URI by incorporating the stored api-prefix parameter, ensuring that the URI parameters match the software version of the reselected service consumer instance, thereby maintaining routing precision across reliability improvements.
3Adaptability or versatility
If API prefix is stored in 3gpp-Sbi-Binding header, then adaptability among NFs is improved, but information loss occurs during reselection
Solution Approach 1:
The 3gpp-Sbi-Binding header is designed to serve multiple functions: it stores binding information for service consumer reselection, carries the API prefix for routing, and provides feedback for URI construction. This multi-functionality ensures that the API prefix information is preserved and utilized across different operations, preventing information loss while enhancing adaptability.
Solution Approach 2:
The 3gpp-Sbi-Binding header acts as an intermediary that bridges the service consumer and service producer during reselection. It carries the API prefix information through the reselection process, ensuring that no information is lost in the transition. The header mediates the exchange of routing information, preserving the API prefix from the original service consumer to the new callback URI construction.
Data Source
AI summary
Embodiments of the present disclosure relate to supporting API prefix in callback URI. A first first device is provided comprising at least one processor and at least one memory storing instructions. The at least one memory and the instructions are configured to, with the at least one processor, cause the first device at least to: receive, from a second device, a service request message, wherein the service request message comprises a first callback Uniform Resource Identifier, URI, with a first Application Programming Interface, API, prefix; in response to determining that the second device is not reachable, send, to a third device, a discovery request for discovering a further second device instance; receive, from the third device, a discovery response; determine a second callback URI based on the discovery response; and send to the further second device instance a callback request message based on the second callback URI.