SNPN Access Token Authorization for Cross-Network NF Roaming
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In standalone non-public network (SNPN) roaming scenarios, service authorization or service requests cannot be successfully completed due to the inability to uniquely identify the home and visited networks, leading to reduced network reliability and security.
Innovation Solution
A service authorization method that includes adding standalone non-public network (SNPN) information, such as a network identifier (NID) and public land mobile network identifier (PLMN ID), to access token requests, enabling unique network identification and ensuring successful completion of service authorization processes by incorporating SNPN information into access tokens and N32 interface contexts.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If PLMN ID is used to identify networks in roaming scenarios, then network identification is simple, but network identification is incomplete for SNPN roaming scenarios
Solution Approach 1:
The network identification process is segmented into two parts: PLMN ID for public network identification and NID for SNPN-specific identification. By dividing the identification task into these separate components, the system can maintain simplicity for PLMN networks while adding SNPN capability without redesigning the entire identification mechanism.
Solution Approach 2:
The NID is nested within the existing PLMN ID framework. The access token structure accommodates both PLMN ID and NID, where NID serves as an additional identifier that is only activated when SNPN roaming is detected. This nested approach allows SNPN identification to be integrated into the existing PLMN-based architecture without requiring a complete system overhaul.
2Reliability
If SNPN information is added to access token requests, then network identification accuracy is improved, but message structure complexity increases
Solution Approach 1:
Instead of requiring complete network identification information in all cases, the system applies partial action by only including NID when SNPN roaming is detected. The access token structure is designed to accommodate NID optionally, so that for PLMN roaming scenarios the message structure remains simple, while for SNPN scenarios the additional NID is included only when necessary.
Solution Approach 2:
The system changes the parameter structure of the access token dynamically based on the roaming scenario. When SNPN is detected, the token structure includes additional NID parameters; when PLMN roaming is detected, the token uses the traditional structure without NID. This parameter change approach allows the system to adapt the message structure to the specific scenario, minimizing unnecessary complexity.
3Reliability
If access token includes SNPN information, then service authorization reliability is improved, but token size increases
Solution Approach 1:
The access token includes NID only when SNPN roaming is detected, rather than always including it. This partial inclusion approach ensures that the token contains necessary SNPN identification information for reliable authorization in SNPN scenarios, while avoiding unnecessary data in PLMN roaming scenarios, thus minimizing token size overhead.
Solution Approach 2:
The system performs preliminary detection of whether the roaming scenario involves SNPN before generating the access token. This preliminary action determines whether NID should be included in the token, allowing the system to prepare the appropriate token structure in advance based on the detected scenario, thereby avoiding unnecessary data inclusion and optimizing token size.
Data Source
AI summary
Embodiments of this application relate to a service authorization method and system, and an apparatus. The method includes: a first network repository function (NRF) receives a first request requesting an access token for accessing a service of a second network function (NF) in a second network from a first NF, where the first NF and the first NRF are located in a first network, and the first request includes standalone non-public network (SNPN) information of the first network and/or the second network; the first NRF forwards the first request to a second NRF located in the second network; the second NRF generates an access token in response to the first request, where the access token includes the SNPN information of the first network and/or the second network; the second NRF sends the access token to the first NRF, and the first NRF receives the access token and sends the access token to the first NF.