WO2021047403A1 - Authorization method and device in a plurality of nrf scenarios - Google Patents

Abstract

Embodiments of the present application provide an authorization method and device for a network function service. The method comprises: a first network repository function (NRF) network element receives a first token request, the first token request comprising an identifier of a service provider network function NF_P; the first NRF determines, according to the identifier, a target NRF network element registered by each service provider NF_R; if the target NRF comprises a second NRF network element, sending a token request to the second NRF; the second NRF generates a token according to the second token request, and returns same to the first NRF; upon receipt of the token sent by the second NRF, the first NRF sends the generated and/or received token to a token requester. By means of the technical solution, the authorization problem in a plurality of NRF scenarios comprised in the same public land mobile network (PLMN) can be solved.

Description

An authorization method and device in multiple NRF scenarios

This application claims the priority of a Chinese patent application filed with the State Intellectual Property Office on September 11, 2019, the application number is 201910860117.X, and the application name is "a method for authorization in multiple NRF scenarios", and the entire content of it is approved The reference is incorporated in this application.

Technical field

The embodiment of the present invention relates to the field of communication technology, and in particular to an authorization method in multiple NRF scenarios.

Background technique

The fifth generation mobile communication system (the Fifth Generation, 5G) adopts a service-based architecture (Service Based Architecture, SBA). The 3rd Generation Partnership Project (3rd Generation Partnership Project, 3GPP) also proposed the enhancement of Service Based Architecture (eSBA). In SBA or eSBA, the network function (Network Function, NF) allows other authorized NFs to access its services. Network storage function (NF Repository Function, NRF) provides management, discovery and authorization services for NF. The NF obtains a token corresponding to the service by requesting authorization from the NRF, and requests the service from another NF that owns the service based on this token, and after the other NF verifies the token, it returns a service response.

Currently, the 3GPP Service and System Aspects Working Group 2 (SA2) standard stipulates that the deployment of NRF can be at the public land network (Public Land Mobile Network, PLMN) level or at the slice level, that is, the same PLMN. Two or more NRFs can be deployed inside. Each NRF provides services such as registration, service discovery, and authorization for the NFs it manages. NFs managed by different NRFs cannot be directly accessed. These NFs can only complete the discovery and authorization processes through their respective registered NRFs.

At present, the authorization process defined by 3GPP Service and System Aspects Working Group 3 (SA3) only considers the situation that only one NRF is deployed inside a PLMN network, that is, all NFs in the same PLMN are registered on the same NRF , And the NRF completes the management and authorization of NF. The above authorization under multiple NRF scenarios deployed in the same PLMN is not considered in the 3GPP standard, and the existing authorization mechanism cannot solve the authorization problem under multiple NRF scenarios.

Summary of the invention

This application proposes an authorization method and device in multiple NRF scenarios to solve the authorization problem in multiple NRF scenarios. The authorization method proposed in this application involves the first network storage function NRF, the second network storage function NRF, the service requester network function (Service Consumer), and the service provider network function (Service Producer). The first NRF may be NRF_C or NRF_P0, the second NRF may be NRF_P, the service requester network function may be NF_C, and the service provider network function may be NF_P. The above-mentioned words such as "first" and "second" are only used for the purpose of distinguishing description, and cannot be understood as indicating or implying relative importance, nor as indicating or implying order. In addition, A and/or B involved in this application include three situations, for example, it can be A, it can be B, or it can be A and B.

In the first aspect, an authorization method is provided. The method is suitable for a scenario where a network function NF_C requests a token from one or more network functions NF_P registered under different network storage functions NRF. The method includes: service requester network function network The element NF_C sends a first token request containing the identification of the service provider network function network element NF_P to the registered network storage function network element NRF_C; the NRF_C uses one or more NF_Ps in the received first token request Query the registration information to determine the target NRF registered by each NF_P; when the target NRF is the NRF_C registered by NF_C, the NRF_C is authorized according to the information in the first token request, and it is generated after the authorization is successful A token, where the token includes information such as the instance ID of the token issuer NRF_C and the instance ID of the service provider NF_P.

It should be pointed out that the registration information is the network function registration information saved by NRF_C before NRF_C receives the first token request, and/or the network function registration information saved on other NRFs in the PLMN to which NRF_C belongs. .

The registration information includes network function profiles (NFProfiles), and/or the correspondence between the NF_P identifier and the NRF_P identifier registered by the NF_P.

Optionally, the target NRF may be the NRF_C registered by the NF_C, or may be one or more other network storage functions NRF_P.

Optionally, if the target NRF includes the one or more NRF_Ps, the NRF_C sends a second token request to the one or more NRF_Ps, and the second token request includes one or more The instance ID of the NF_P corresponding to each NRF_P. Wherein, the one or more NRF_Ps may be in the same PLMN as the NRF_C.

In another implementation manner, the NRF_C and the NRF_P are in different PLMNs, that is, the NRF_C is in the serving network, and the one or more NRF_Ps are in the home network. At this time, the NRF_C forwards the first token request from the NF_C to the network storage function NRF_P0 in the home network, where the NRF_P0 can be an NRF deployed in the home network dedicated to receiving roaming information, or it can be a home network. Any NRF in the network is not limited here. The NRF_P0 uses the NF_P identifier in the first token request to query the registration information to determine the target NRF registered by each NF_P;

If the target NRF includes one or more other network storage functions NRF_P, the NRF_P0 sends a second token request to each NRF_P respectively, and the second token request includes one or more NF_P corresponding to each NRF_P The instance ID. After receiving the second token request, each NRF_P performs authorization according to the information in the second token request and generates a token, and returns the token to the sender of the token request, namely NRF_C or NRF_P0, wherein the token contains information such as the instance identifier of the token issuer NRF_P and the instance identifier of the service provider NF_P.

The registration information is the registration information of the network functions stored on other NRFs in the home network that is saved and/or acquired by the NRF_P0 before the NRF_P0 receives the first token request.

The registration information includes a network function profile, and/or the corresponding relationship between the NF_P identifier and the NRF_P identifier registered by the NF_P.

Optionally, the target NRF may be NRF_P0, and in this case, the NRF_P0 performs authorization and generates a token according to the information in the first token request.

After receiving the tokens sent by each NRF_P, the NRF_P0 sends the generated token and/or the received token to the NRF_C.

After the NRF_C generates the token and/or receives the token, the generated and/or received token is sent to the service requester network function network element NF_C.

After receiving the token, the NF_C selects a token corresponding to the service provider network function network element NF_P, and sends a service request carrying the token to the NF_P. Specifically, the NF_C queries the claim claim of each token according to the instance identifier of the NF_P before the service request, wherein the token claim includes the identifier of the service provider network function network element, and the NF_C use order The token whose ID of the service provider network function network element in the card statement is consistent with the NF_P ID.

In a second aspect, an authorization method is provided, which is suitable for a scenario where a network function NF_C requests a token from one or more network functions NF_P of the same type registered under different network storage functions NRF. The method includes: the service requester NF_C network function network element sends a first token request to the registered network storage function network element NRF_C, where the first token request includes the type of the service provider network function network element NF_P; The NRF_C uses the type of the NF_P to query the registration information to determine the target NRF registered by each NF_P in one or more NF_Ps belonging to the type;

When the target NRF is the NRF_C registered by the NF_C, the NRF_C performs authorization according to the information in the first token request, and generates a token after the authorization is successful, wherein the token contains an instance of the token issuer NRF_C Identification and type of service provider NF_P and other information.

The registration information is the network function registration information saved by the NRF_C before the NRF_C receives the first token request, and/or the acquired network function registration information saved on other NRFs in the PLMN to which the NRF_C belongs.

The registration information includes network function profiles (NFProfiles), and/or the correspondence between the NF_P identifier and the NRF_P identifier registered by the NF_P.

Optionally, the target NRF may be the NRF_C registered by the NF_C, or may be one or more other network storage functions NRF_P.

Optionally, when the target NRF includes one or more NRF_Ps, the NRF_C sends a second token request to the one or more NRF_Ps, and the second token request carries the information registered on the NRF_P The type of NF_P and/or the instance identifier of NF_P. In response to the second token request, the NRF_P will generate a token and send the token to the NRF_C. The one or more NRF_Ps may be in the same PLMN as the NRF_C.

In addition, in an implementation manner, the NRF_C and the NRF_P are in different PLMNs, that is, the NRF_C is in the serving network, and the one or more NRF_Ps are in the home network. At this time, the NRF_C forwards the first token request from the NF_C to the network storage function NRF_P0 in the home network, where the NRF_P0 can be an NRF deployed in the home network dedicated to receiving roaming information, or it can be a home network. Any NRF in the network is not limited here.

The NRF_P0 uses the type of the NF_P to determine the target NRF registered by each of the one or more NF_Ps belonging to the type by querying registration information;

The registration information is the registration information of the network functions stored on other NRFs in the home network that is saved and/or acquired by the NRF_P0 before the NRF_P0 receives the first token request.

The registration information includes network function profiles (NFProfiles), and/or the correspondence between the NF_P identifier and the NRF_P identifier registered by the NF_P.

Optionally, the target NRF may be NRF_P0, and in this case, the NRF_P0 performs authorization and generates a token according to the information in the first token request.

Optionally, the target NRF includes one or more other network storage functions NRF_P located in the home network. At this time, the NRF_P0 sends a second token request to each NRF_P, and the second token request carries The type of NF_P and/or the instance identifier of NF_P registered on the NRF_P.

After receiving the second token request, each NRF_P authorizes and generates a token according to the information in the token request, and returns the token to the sender of the token request, that is, NRF_C or NRF_P0, The token includes information such as the instance identifier of the token issuer NRF_C and the type of the service provider NF_P.

After receiving the tokens sent by each NRF_P, the NRF_P0 sends the generated token and/or the received token to the NRF_C.

After the NRF_C generates the token and/or receives the token, the generated and/or received token is sent to the service requester network function network element NF_C.

After receiving the token, the NF_C selects a token corresponding to the service provider network function network element NF_P, and sends a service request carrying the token to the NF_P.

Specifically, before the service request, the NF_C selects the token corresponding to the current NF_P from the tokens returned by the NRF_C according to the instance identifier of the NRF_P registered by the service provider NF_P.

Optionally, before acquiring the token, the NF_C may obtain the instance ID of the NRF_P registered by the type of NF_P in this solution from the NRF_C where it is registered through the service discovery process, and save the instance ID of the NF_P and the NRF_P The corresponding relationship of the instance ID; at this time, the NF_C can query the instance ID of NRF_P according to the instance ID of NF_P, and then query the claim claim of each token according to the instance ID of NRF_P, wherein the token statement includes The identity of the network storage function network element, and the NF_C uses a token whose identity of the network storage function network element in the token statement is consistent with the NRF_P identity registered by the NF_P.

Optionally, after the NF_C obtains the token, the NF_C requests the registered NRF_C to query the instance identifier of the NRF_P, and the NRF_C queries the registration information according to the embodiment identifier of the NF_P, and returns to the NF_C The instance ID of the NRF_P registered by NF_P. The NF_C queries the claim claim of each token according to the received instance identifier of the NRF_P, wherein the token claim includes the identity of the network storage function network element, and the NF_C uses the network storage function network element in the token claim The token whose ID is consistent with the NRF_P ID registered by the NF_P.

In a third aspect, an authorization method is provided. The steps of the method include: the service requester network function network element NF_C sends a token request to the registered network storage function network element NRF_C, and the token request includes one or more services The instance identifier of the provider network function NF_P or the type of the service provider network function NF_P, the token request also includes information related to other service requests, which is not limited here;

In a possible design, when the token request contains the instance ID of NF_P, NRF_C determines the target NRF registered by each NF_P by querying the registration information according to the above-mentioned one or more instance IDs of NF_P;

In another possible design, when the token request contains the type of NF_P, NRF_C determines the registered target of each NF_P in one or more NF_Ps of the type by querying the registration information according to the type of NF_P mentioned above. NRF;

Optionally, the target NRF may be the NRF_C registered by the NF_C. At this time, the NRF_C is authorized according to the information in the token request, and after the authorization is successful, a token is generated and returned to the NF_C. The token includes information such as the instance ID of the token issuer NRF_C and the instance ID or type of the service provider NF_P.

Optionally, the target NRF includes one or more other network storage function network elements NRF_P. At this time, the NRF_C returns the instance identifier of the NRF_P registered by each NF_P to the NF_C.

After the NF_C receives the instance ID of the one or more NRF_Ps, it sends a token request to each NRF_P according to the instance ID of the NRF_P, and the token request includes the instance ID or type of the NF_P , The token request also includes information related to other service requests, which is not limited here;

After receiving the token request, each NRF_P performs authorization according to the information in the token request and generates a token, and returns the token to the sender NF_C of the token request. The token includes information such as the instance ID of the token issuer NRF_P and the instance ID or type of the service provider NF_P.

After receiving the token, the NF_C selects a token corresponding to the service provider NF_P, and sends a service request carrying the token to the NF_P. The method of token selection depends on the information of NF_P contained in the token. When the token contains the NF_P instance identifier, the token selection method is the same as the token selection step described in the first aspect; when the token contains the type of NF_P, the token selection method is the same as that described in the second aspect. The token selection steps will not be repeated here.

In a fourth aspect, an authorization device is provided, including a receiving module, configured to receive a first token request, where the first token request includes the identifier or type of the service provider network function network element NF_P; and the processing module is configured to determine The target network storage function network element NRF registered by each service provider NF_P, the processing module uses the instance identifier or type of the NF_P to query the registration information to determine the target NRF; the sending module is used to send to the target NRF Second token request;

The receiving module is also used to receive the token fed back by the target NRF;

The processing module may also be used to authorize and generate a token according to the information in the token request; when the device and the NF_P are located in different PLMNs, the processing module is also used to determine the home network where the NF_P is located The network storage function NRF_P0;

The sending module is also used to return the token generated by the processing module and/or the token received by the receiving module to the sender of the token request; when the device and the NF_P are located in different PLMNs, the The sending module is used to forward the first token request to the NRF_P0.

The device has the function of realizing the NRF_C behavior of the network storage function network element in any one of the possible designs of the above-mentioned first aspect.

In a fifth aspect, another authorization device is provided, including a receiving module, configured to receive a first token request, where the first token request includes the type of the service provider network function network element NF_P; and the processing module is configured to determine each A target network storage function network element NRF registered by a service provider NF_P, the processing module is used to determine the target NRF by querying the registration information according to the type of the NF_P; a sending module is used to send a second order to the target NRF Card request

The receiving module is also used to receive the token fed back by the target NRF;

The processing module can also be used to authorize and generate a token according to the information in the first token request; when the belonging device and the NF_P are located in different PLMNs, the processing module is also used to determine the home network where the NF_P is located Network storage function NRF_P0;

The sending module is further configured to return the token generated by the processing module and/or the token received by the receiving module to the sender of the first token request; when the device and the NF_P are located in different PLMNs, The sending module is configured to forward the first token request to the NRF_P0.

The device has the function of realizing the NRF_C behavior of the network storage function network element in any one of the possible designs of the second aspect.

In a sixth aspect, another authorization device is provided, including a sending module, configured to send a first token request, where the first token request includes the identifier of the service provider network function network element NF_P; and the receiving module is configured to receive The token generated by the network storage function registered by the service provider network element NF_P; the processing module is used to determine the token corresponding to the service provider NF_P; the sending module is also used to send the carrier to the service provider NF_P The service request of the token; the receiving module is also used to receive the service response fed back by the service provider NF_P.

The device has the function of realizing the behavior of the network function network element NF_C in any one of the possible designs of the above-mentioned first aspect.

In a seventh aspect, another authorization device is provided, including a sending module, configured to send a first token request, where the first token request includes the type of the service provider network function network element NF_P; and the receiving module is configured to receive The token generated by the network storage function registered by the service provider network element NF_P; the processing module is used to determine the token corresponding to the service provider NF_P; the sending module is also used to send the carrier to the service provider NF_P The service request of the token; the receiving module is also used to receive the service response fed back by the service provider NF_P.

The device has the function of realizing the behavior of the network function network element NF_C in any one of the possible designs of the second aspect.

In an eighth aspect, an authorization device is provided, including a receiving module, configured to receive a first token request, where the first token request includes an identifier of a service provider network function network element NF_P; a processing module, configured to determine each The target network storage function network element NRF registered by the service provider NF_P, the processing module determines the target NRF according to the instance identifier of the NF_P; the sending module is configured to send a second token request to the target NRF; the receiving The module is also used to receive the token fed back by the target NRF; the processing module can also be used to authorize and generate the token according to the information in the first token request; the sending module is also used to send the token to the The sender of the request returns the token generated by the processing module and/or the token received by the receiving module.

The device has the function of realizing the NRF_P0 behavior of the network storage function network element in any one of the possible designs of the first aspect described above.

In a ninth aspect, another authorization device is provided, including a receiving module, configured to receive a first token request, where the first token request includes the type of the service provider network function network element NF_P; and the processing module is configured to determine each A target network storage function network element NRF registered by a service provider NF_P, the processing module determines a target NRF according to the type of the NF_P; a sending module is used to send a second token request to the target NRF; the receiving The module is also used to receive the token fed back by the target NRF; the processing module can also be used to authorize and generate the token according to the information in the first token request; the sending module is also used to send the token to the The sender of the request returns the token generated by the processing module and/or the token received by the receiving module.

The device has the function of realizing the NRF_P0 behavior of the network storage function network element in any one of the possible designs of the second aspect described above.

In a tenth aspect, another authorization device is provided, including:

The receiving module is configured to receive a token request, where the token request includes the type or instance identifier of the service provider network function network element NF_P;

The processing module is used to authorize and generate the token according to the information in the token request; the processing module can also be used to determine the target network storage function network element NRF registered by each service provider NF_P, the processing The module determines the target NRF according to the instance identifier or type of the NF_P;

The sending module returns the token generated by the processing module to the token requester. The sending module is also used to return to the token requester the instance identification of the target NRF registered by each NF_P determined by the processing module.

The device has the function of realizing the NRF_C behavior of the network storage function network element in any one of the possible designs of the third aspect.

In an eleventh aspect, another authorization device is provided, including

The sending module is used to send a token request, the token request includes the instance identifier or type of the service provider network function network element NF_P; the sending module is also used to send the service carrying the token to the service provider NF_P request;

The receiving module is used to receive the token generated and sent by the NRF_C; the receiving module is also used to receive the instance identifier of the NRF_P registered by the NF_P sent by the NRF_C; the receiving module is also used to receive and send each NRF_P generated and sent Token. The receiving module is also used to receive the service response fed back by the service provider NF_P.

The processing module is used to select the token corresponding to the current service provider NF_P from the tokens received by the receiving module before the service request;

The device has the function of realizing the behavior of the network storage function network element NF_C in any one of the possible designs of the third aspect.

In a twelfth aspect, a device is provided, which includes: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute the Instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instruction to realize the function of the NRF_C behavior in any one of the possible designs of the first aspect.

In a thirteenth aspect, another device is provided, which includes: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute all The instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instructions to implement the function of the NRF_C behavior in any one of the possible designs of the second aspect.

In a fourteenth aspect, another device is provided, which includes: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute all The instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instructions to implement the function of the NF_C behavior in any one of the possible designs of the first aspect.

In a fifteenth aspect, a device is provided. The device includes: a storage unit, a communication interface, and a processor coupled to the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute the Instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instruction to implement the function of the NF_C behavior in any one of the possible designs of the second aspect.

In a sixteenth aspect, another device is provided, the device includes: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute all The instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instruction to implement the function of the NRF_P0 behavior in any one of the possible designs of the first aspect.

In a seventeenth aspect, another device is provided, which includes: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute all The instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instruction to implement the function of the NRF_P0 behavior in any one of the possible designs of the second aspect.

In an eighteenth aspect, another device is provided, the device includes: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute all The instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instruction to realize the function of the NRF_C behavior in any one of the possible designs of the third aspect.

In a nineteenth aspect, another device is provided, which includes: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute all The instructions, the communication interface is used to communicate with other devices under the control of the processor;

The processor executes the instruction to implement the function of the NF_C behavior in any one of the possible designs of the third aspect.

In a twentieth aspect, a computer-readable storage medium is provided, and a program stored in the computer-readable storage medium is executed by a processor to complete any method executed by any device provided in the embodiments of the present application Some or all of the steps.

In a twenty-first aspect, a computer program product is provided, which when the computer program product runs on a computer device, causes the computer device to execute part or part of any method executed by any device provided in the embodiments of this application. All steps.

It can be seen that in the embodiment of this application, after the network storage function network element NRF_C receives the first token request carrying information of one or more service provider network function network elements NF_P registered under different network storage functions NRF_P, According to the identification or type of the network function network element NF_P in the token request, by querying the registration information, determine the network storage function network element NRF_P registered by each service provider network function network element NF_P, and then send a second token request to it , And receive its feedback token. Further, NRF_C sends the saved and/or received token to the token requester. When requesting a service, the service requester network function network element NF_C of the requesting token finds the token corresponding to the NF_P from the received token according to the identifier of the service provider network function network element NF_P, and finally provides the service The NF_P sends a service request carrying a token. It can be seen that the implementation of the embodiments of the present application can realize authorization in multiple NRF scenarios and make up for the vacancy of the existing authorization mechanism.

Description of the drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background art, the following will describe the drawings that need to be used in the embodiments of the present application or the background art.

FIG. 1 is a diagram of a network system architecture involved in an embodiment of this application;

2a and 2b are diagrams of an application scenario involved in an embodiment of this application;

FIG. 3 is a schematic flowchart of an authorization method according to an embodiment of the application;

FIG. 4 is a schematic flowchart of another authorization method according to an embodiment of the application;

Figures 5a and 5b are diagrams of another application scenario involved in an embodiment of this application

FIG. 6 is a schematic flowchart of another authorization method according to an embodiment of the application;

FIG. 7 is a schematic flowchart of another authorization method according to an embodiment of the application;

8a and 8b are diagrams of another application scenario involved in an embodiment of this application;

FIG. 9 is a schematic flowchart of another authorization method according to an embodiment of the application;

FIG. 10 is a schematic flowchart of another authorization method according to an embodiment of the application;

FIG. 11 is a schematic structural diagram of a device according to an embodiment of the application;

FIG. 12 is a schematic structural diagram of a device according to an embodiment of the application.

detailed description

The embodiments of the present application provide an authorization method and device in a multi-NRF scenario, which are used to implement authorization when a NF requests a service in a PLMN with multiple NRF scenarios. Among them, the method and the device are based on the same inventive concept. Since the principles of the method and the device to solve the problem are similar, the implementation of the device and the method can be referred to each other, and the repetition will not be repeated.

In the description of the embodiments of the present application, “and/or” describes the association relationship of the associated objects, indicating that there can be three types of relationships, for example, A and/or B, which can mean: A alone exists, and both A and B exist separately. There are three cases of B. The character "/" generally indicates that the associated objects before and after are in an "or" relationship. At least one involved in this application refers to one or more; multiple refers to two or more. In addition, it should be understood that in the description of this application, words such as "first" and "second" are only used for the purpose of distinguishing description, and cannot be understood as indicating or implying relative importance, nor can it be understood as indicating Or imply the order.

The communication method provided in the embodiments of the present application can be applied to a 5G communication system or various future communication systems.

The embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. The terminology used in the implementation mode part of this application is only used to explain the specific embodiments of this application, and is not intended to limit this application.

Service-Based Architecture (SBA) is proposed in the 5G communication system. The SBA includes multiple network functions (Network Functions, NF), and each NF interacts through a service-based interface (SBI), and one NF can provide one or more NF services. The NF service can adopt a "request-feedback" or "subscription-notification" approach. Each NF can act as a service provider (Service Producer) to provide an application programming interface (Application Programming Interface, API) for other NFs to call, or as a service consumer (Service Consumer) to call APIs of other NFs. Hereinafter, the Service Producer is called the service provider, and the Service Consumer is called the service requester.

Figure 1 is a schematic diagram of a possible network architecture in a non-roaming scenario. The network architecture consists of user equipment, access network, and operator network. The operator network includes core network and data network, and user equipment accesses through access network nodes. Operator network. The specific description is as follows:

User Equipment (UE). The UE is a logical entity. Specifically, the UE may be any of a terminal equipment (Terminal Equipment), a communication device (Communication Device), and an Internet of Things (IoT) device. Among them, the terminal device can be a smart phone (smart phone), a smart watch (smart watch), a smart tablet (smart tablet), etc.; the communication device can be a server, a gateway (Gateway, GW), a controller, etc.; IoT devices It can be a sensor, an electric meter, a water meter, and so on.

Radio Access Net (RAN). The RAN is responsible for UE access. The RAN can be a base station, a wireless fidelity (Wi-Fi) access point, and a Bluetooth access point.

Data network (DN). The data network DN is also called PDN (Packet Data Network). The DN can be an operator's external network or an operator-controlled network for providing business services to users.

Core network (CN), CN, as a bearer network, provides an interface to the DN, providing UE with communication connection, authentication, management, policy control, and carrying data services. Among them, CN includes: access and mobility management network element, session management network element, user plane node function, authentication server, unified data management network element, network exposure function network element, application function network element, network slice selection function network element, Policy control network elements, network storage functions, etc.

Access and Mobility Management Function (AMF), the control plane network element provided by the operator, is responsible for the access control and mobility management of the UE's access to the operator's network.

The Session Management Function (SMF), a control plane network element provided by the operator, is responsible for managing the session of the data packet of the UE.

User Plane Function (UPF), a user plane network element provided by an operator, is a gateway for communication between the operator's network and the DN. UPF can be a gateway, server, controller, user plane function network element, etc. The UPF can be set inside or outside the operating network.

The authentication server function (Authentication Server Function, AUSF), the control plane network element provided by the operator, can be used for the operator's network to authenticate the network subscribers.

Unified Data Manager (UDM), the control plane network element provided by the operator, is responsible for storing the Subscriber Permanent Identifier (SUPI), registration information, credential, etc. of the operator’s network Contract data, etc.

Network Exposure Function (NEF), the operator provides control plane network elements, and NEF exposes the external interface of the operator's network to third parties in a safe manner.

Application Function (AF) is used to store business security requirements and provide information for policy determination.

The policy control function (Policy Control Function, PCF) can be used to be responsible for policy control decision-making, to provide functions such as service data flow and application detection, gating, QoS, and flow-based charging control.

A network slice selection function (Network Slice Selection Function, NSSF) is used to select a network slice instance serving the user equipment, determine the AMF set for the user equipment, and so on.

Network storage function (NF Repository Function, NRF), responsible for NF automated management, selection and expansion, specifically including NF service registration, discovery, status monitoring, service authorization, etc., to achieve on-demand configuration of network functions and services and NF inter-connection Interconnection. In a specific implementation, the NRF can be a functional entity such as a network element, a controller, or a server.

In Figure 1, N1, N2, N3, N4, and N6 are the interfaces between the corresponding network elements; Namf, Nsmf, Nausf, Nudm, Nnef, Npcf, Naf, Nnssf, and Nnrf are AMF, SMF, AUSF, UDM, NEF, respectively , PCF, AF, NSSF, and NRF, the service-oriented interface SBI.

In this embodiment, NF may be a network function in AMF, SMF, AUSF, UDM, NEF, PCF, AF, or NSSF. The aforementioned network elements may be network elements implemented on dedicated hardware, software instances running on dedicated hardware, or instances of virtualized functions on an appropriate platform.

The embodiments of this application are mainly applied to a scenario where two or more NRFs are deployed in the same PLMN. Each NRF provides services such as registration, service discovery, and authorization for the NFs it manages. NFs managed by different NRFs cannot be directly accessed. These NFs can only complete the discovery and authorization processes through their respective registered NRFs. The embodiments of the present application also consider roaming scenarios and non-roaming scenarios. In a roaming scenario, there are a service network and a home network, and the architecture of the service network and the home network may be the same or different.

Based on the above-mentioned service-oriented architecture system, the application scenarios and corresponding authorization methods of the embodiments of the present application are introduced below.

The authorization method proposed in the embodiment of the application involves a first network storage function NRF, a second network storage function NRF, a service requester network function (Service Consumer), and a service provider network function (Service Producer). The first NRF may be NRF_C or NRF_P0, the second NRF may be NRF_P, the service requester network function may be NF_C, and the service provider network function may be NF_P. There may be one or more of the aforementioned NRF_Ps in the application scenarios of the embodiments of the present application, such as NRF_P1, NRF_P2, etc.; there may also be one or more of NF_Ps, such as NF_P1, NF_P2, NF_P3, and so on.

Figures 2a and 2b describe the scenario where the service requester NF requests a token of a specific service provider NF registered on different NRFs. For example, AMF requests service from SMF, or AUSF requests service from UDM, etc., which is not limited here.

Figure 2a shows a scenario where the service requester network element and the service provider network element are located in the same PLMN. Specifically, the service requester NF_C is registered on NRF_C; the service provider NF_P is registered on NRF_P; NRF_C and NRF_P can interact.

Figure 2b shows a scenario where the service requester network element and the service provider network element are located in different PLMNs. Specifically, the service requester NF_C is registered on NRF_C located in the service network cPLMN; the service provider NF_P1 is registered on NRF_P1 located in the home network pPLMN; NRF_C interacts with NRF_P0 in pPLMN; NRF_P0 interacts with NRF_P1.

Referring to FIG. 3, a possible process of one of the authorization methods provided in the embodiment of the present application is as follows.

This process describes the authorization scenario in which the token request sent by the service requester NF contains the identities of the service provider NF registered under different NRFs, where the service requester NF and the service provider NF are located in the same PLMN network, namely For non-roaming scenes, the scene description is shown in Figure 2a. This scenario involves four network elements, including the service requester NF_C and the corresponding NRF_C, the service provider NF_P and the corresponding NRF_P.

S300. This step is a preliminary step that needs to be completed before the authorization process starts.

Before the authorization process starts, each network function network element NF is registered with its corresponding network storage function network element NRF. For example, in this embodiment, the service requester NF_C is registered with NRF_C, and the service provider NF_P is registered with NRF_P. Each network storage function NRF stores each other's registration information through registration, that is, one NRF is registered to another NRF;

Optional NRF_C and NRF_P can also save each other's registration information through network configuration. For example, NRF_C saves all NF information registered on NRF_P; optionally, NRF_C and NRF_P can also pass through the Nnrf_NFManagement service Two operations, NFStatusSubscribe and NFStatusNotify, complete the acquisition and update of registration information. The acquisition of registration information between NRF_C and NRF_P includes but is not limited to the above methods, and this application is not limited.

The registration information includes network function profiles (NFProfiles), and the NFProfiles may include NF instance ID (Instance ID), NF type, PLMN ID, network slicing related ID, and NF fully qualified domain name (Fully Qualified Domain Name). , FQDN) or IP address, NF capacity information, NF priority information, NF set ID, service name supported by NF, NF specific service authorization information, etc. Optionally, the registration information further includes the correspondence between the NF type and the instance IDs of all NRFs registered with this type of NF, and/or the correspondence between the instance ID of the NF and the instance ID of the NRF registered by the NF relationship;

After the registration is completed, the service requester NF_C initiates an NF discovery process to NRF_C, and NRF_C returns to NF_C information that can provide a specific NF service or a group of NFs belonging to the target NF type. The information includes the instance ID of the NF and/or the NF registered The identification of the NRF, the type of the NF, the FQDN or IP address of the NF, the name of the service provided, etc. The information returned by the service discovery also includes PLMN ID, NF location information, NF set ID and other related information, which will not be listed here. For example, the information in this embodiment includes the instance identifier of NF_P.

S301. The service requester NF_C sends a first token request to the registered NRF_C, and correspondingly, the NRF_C receives the token request from the NF_C.

The token request carries the identifier of the service provider NF_P, for example, carries the instance identifier of NF_P. The token request also carries the identity of the service requester NF_C, the service name and other parameters required for authorization and token generation, which are not limited here.

S302. The network storage function NRF_C determines the NRF registered by the service provider NF_P.

After receiving the token request, the NRF_C obtains the target NRF corresponding to the NF_P, that is, the identification of the NRF_P, by querying the registration information according to the identifier of the service provider NF_P in the token request. The identifier may be the instance identifier and/or FQDN of NRF_P, or other identifiers or addresses of NRF_P, etc., which is not limited here.

S303. NRF_C forwards the token request to NRF_P according to the identifier of NRF_P, and correspondingly, NRF_P receives the token request from NRF_C.

S304, NRF_P performs authorization, generates a token, and performs integrity protection.

After receiving the token request, NRF_P obtains the information in the token request combined with locally configured policies or authorization information for authorization, and NRF_P generates a token after successful authorization.

The Token Claim Claim of the token generated by the NRF_P contains the identity of the token issuer, that is, the instance identity of the NRF_P. The token also carries information such as the instance identifier of the service requester NF_C, the instance identifier of the service provider NF_P, the requested service name, and the validity period of the token.

In addition, NRF_P uses the shared key with the service provider NF_P or uses its own private key to protect the integrity of the token.

S305. The NRF_P sends a token to the NRF_C, where the token is a token after integrity protection by the NRF_P, and the corresponding NRF_C receives the token.

S306. NRF_C sends the received token to NF_C, and correspondingly, NF_C receives the token.

Optionally, when sending the token, the NRF_C also sends the correspondence between the NF_P and the instance identifier of the NRF_P to the NF_C, and correspondingly, the NF_C receives and saves the correspondence between the NF_P and the NRF_P. When the subsequent NF_C requests the token of the NF_P, the identification of the NRF_P corresponding to the NF_P can be found by querying the stored information, and the token request can be sent directly to the NRF_P.

S307. The service requester NF_C sends a service request to the service provider NF_P, and the service request carries the token. Correspondingly, NF_P receives a service request carrying a token from NF_C.

S308. NF_P uses the shared key negotiated with NRF_P, or uses the public key of NRF_P to perform integrity verification on the token, and executes the token verification after the verification passes.

The token verification means that the service requester NF_P verifies whether the information carried in the token is consistent with the relevant information of the NF_P, for example, whether the instance identifier of the service provider carried in the token is the instance identifier of the NF_P.

S309. After the above token verification is passed, the service provider NF_P sends a service response to the service requester NF_C. The corresponding NF_C receives the service response from NF_P.

In this embodiment, the registration information is shared between NRF_C and NRF_P. After receiving the token request, NRF_C determines the NRF_P registered by the service provider NF_P by querying the registration information and forwards the token request to it, so that NRF_P completes the authorization and order The token is generated, and the subsequent service provider NF_P verifies the token, thereby solving the problem of service authorization between NFs when multiple NRFs are deployed in the same PLMN network in the prior art.

Referring to FIG. 4, a possible process of one of the authorization methods provided in the embodiment of the present application is as follows.

This process describes the authorization scenario where the token request sent by the service requester NF contains the identities of the service provider NF registered under different NRFs, where the service requester NF and the service provider NF are located in different PLMN networks, namely Roaming scene, the scene description is shown in Figure 2b. This scenario involves five network elements, including the service requester NF_C and the corresponding NRF_C located in the service network, the first network storage function NRF_P0, the service provider NF_P1 and the corresponding NRF_P1 located in the home network. The NRF_P0 can be a network storage function deployed in pPLMN that is specifically responsible for receiving roaming requests, or it can be any network storage function in pPLMN.

S400. This step is a preliminary step that needs to be completed before the authorization process starts.

Before the authorization process starts, each network function network element NF is registered with its corresponding network storage function network element NRF. For example, in this embodiment, the service requester NF_C is registered with NRF_C, and the service provider NF_P1 is registered with NRF_P1.

The network storage functions NRF_C and NRF_P0, as well as NRF_P0 and NRF_P1 can save the registration information of each other through the network configuration, that is, the information of all NFs registered on the NRF;

Optionally, the registration information of each other is saved between NRF_P0 and NRF_P1 through registration, that is, one NRF is registered to another NRF;

Optional NRF_C and NRF_P0, as well as NRF_P0 and NRF_P1, can also use the two operations of NFStatusSubscribe and NFStatusNotify in the Nnrf_NFManagement service to complete the acquisition and update of registration information. The acquisition of registration information between NRFs includes but is not limited to the above methods, and this application is not limited.

After the registration is completed, the service requester NF_C initiates an NF discovery process to NRF_C, and NRF_C returns to NF_C information that can provide specific NF services or a group of NFs belonging to the target NF type. The information that may contain is detailed in S300, this implementation The information in the example includes the instance ID of NF_P1.

S401. This step is similar to S301. The difference is that in addition to the content described in S301, the token request also includes the PLMN ID of the service network cPLMN to which the service requester NF_C belongs and the PLMN ID of the home network pPLMN to which the service provider NF_P belongs.

S402. The network storage function NRF_C determines the first network storage function NRF_P0 deployed in the PLMN where the service provider is located.

NRF_C obtains the instance ID and/or FQDN of the network storage function NRF_P0 deployed in the pPLMN according to the PLMN ID of the home network pPLMN to which the service provider NF_P1 belongs in the above token request, and obtains the ID or address of other NRF_P, etc. , This application is not restricted.

S403. NRF_C forwards the token request to NRF_P0 according to the identifier of NRF_P0, and correspondingly, NRF_P0 receives the token request from NRF_C.

S404. The network storage function NRF_P0 determines the NRF_P1 registered by the service provider NF_P1.

The network storage function NRF_P0 determines the target NRF registered by NF_P1, that is, the identification of NRF_P1, by querying the registration information according to the identification of the service provider NF_P1 in the token request. The identifier may be an instance identifier and/or FQDN of NRF_P1, or other identifiers or addresses of NRF_P1, etc., which is not limited in this application.

S405. The network storage function NRF_P0 sends the token request to the NRF_P1 registered by the NF_P1 according to the identifier of the NRF_P1, and the corresponding NRF_P1 receives the token request from the NRF_P0.

S406, NRF_P1 performs authorization, generates a token, and performs integrity protection.

This step is similar to S304, except that, in addition to the content of S304, the token also carries the PLMN ID of the service network cPLMN to which the service requester NF_C belongs and the PLMN ID of the home network pPLMN to which the service provider NF_P1 belongs.

S407. The NRF_P1 corresponding to the service provider sends a token to the NRF_P0, and correspondingly, the NRF_P0 receives the token from the NRF_P1.

The token is a token obtained by NRF_P1 using a shared key with the service provider NF_P1 or using its own private key to protect the integrity of the token.

S408. NRF_P0 forwards the received token to NRF_C, and correspondingly, NRF_C receives the token.

S409~S412 are the same as S306~S309, and will not be repeated here.

Compared with Embodiment 1, this embodiment is suitable for roaming scenarios. NRF_C and NRF_P0, and NRF_P0 and NRF_P1 share registration information. After receiving the token request, NRF_C first queries NRF_P0 and forwards the token request to it, then NRF_P0 queries NRF_P1 and forwards the token request to it, so that NRF_P1 completes the authorization and token generation, and the subsequent service provider NF_P1 pairs the token The verification is performed, thereby solving the service authorization problem between NFs in the roaming scenario when multiple NRFs are deployed in the same PLMN network in the prior art.

Figures 5a and 5b describe the scenario where the service requester NF requests certain tokens of specific service providers NF registered on different NRFs. For example, AMF requests services from SMF, NEF, and UDM, or AUSF requests AMF, UDM, and UDM tokens. SMF requests for services, etc., are not limited here.

Figure 5a shows a scenario where the service requester network element and several service provider network elements are located in the same PLMN network. Specifically, the service requester NF_C is registered on NRF_C; service provider one NF_P1 is registered on NRF_P1, service provider two NF_P2 and service provider three NF_P3 are registered on NRF_P2; NRF_C, NRF_P1 and NRF_P2 can interact with each other.

Figure 5b shows a scenario where the service requester and several service providers are located in different PLMN networks. For example, the AMF located in the serving network cPLMN requests services from SMF, NEF, and UDM located in the home network pPLMN, or the AUSF located in the serving network cPLMN requests services from AMF, UDM, and SMF located in the home network pPLMN. limited. NRF_C interacts with NRF_P0 in the home network pPLMN, and NRF_P0, NRF_P1, and NRF_P2 interact with each other; the registration relationship of each network function NF is the same as that in Figure 5a, and will not be repeated here.

Referring to FIG. 6, a possible process of one of the authorization methods provided in the embodiment of the present application is as follows.

This process describes the authorization process in a scenario where the service requester network function network element NF_C is registered on the network storage function NRF_C, and at least two or more service provider network function network elements NF_P are registered on different NRF_Ps in the same PLMN. , The scene description is shown in Figure 5a. This scenario involves seven network elements, including service requester network function network element NF_C and corresponding NRF_C, service provider network function network element NF_P1 and corresponding NRF_P1, service provider NF_P2, NF_P3 and their corresponding NRF_P2.

S600. This step is a preliminary step that needs to be completed before the authorization process starts.

Before the authorization process starts, each network function network element NF is registered with its corresponding network storage function network element NRF. For example, in this embodiment, the service requester NF_C is registered on NRF_C, the service provider NF_P1 is registered on NRF_P1, and the service is provided NF_P2 and NF_P3 are registered on NRF_P2. Each network storage function NRF stores each other's registration information through registration, that is, one NRF is registered to another NRF;

Optional NRF_C, NRF_P1, and NRF_P2 can also save each other's registration information through network configuration, that is, the information of all NFs registered on NRF; optionally, NRF_C, NRF_P1 and NRF_P2 can also use NFStatusSubscribe in the Nnrf_NFManagement service And NFStatusNotify two operations, complete the acquisition and update of registration information. The acquisition of registration information between NRF_C, NRF_P1 and NRF_P2 includes but is not limited to the above methods, and this application is not limited. The registration information has been described in S300, and will not be repeated here.

After registration is completed, the service requester NF_C initiates an NF discovery process to NRF_C, and NRF_C returns to NF_C information that can provide a specific NF service or a group of NFs belonging to the target NF type. The content of the information can be found in S300, here No longer. The information in this embodiment includes instance identifiers of NF_P1, NF_P2, and NF_P3.

S601. The service requester NF_C sends a first token request to the registered network storage function network element NRF_C, and the network storage function network element NRF_C receives the first token request.

The first token request carries the identifier of each service provider NF_P, for example, carries the instance identifier of NF_P1, the instance identifier of NF_P2 and/or NF_P3. The first token request may also carry the identifier of the service requester NF_C, the service name and other parameters required for authorization and token generation, which are not limited here.

S602. The network storage function NRF_C determines the target NRF registered by each service provider NF_P.

After receiving the token request, the network storage function network element NRF_C determines the identity of the target NRF registered by each NF_P according to the identity of the service provider NF_P in the token request and queries the registration information. For example, NRF_C is based on the instance identity of NF_P1 Obtain the instance ID and/or FQDN of NRF_P1, or the ID or address of NRF_P, etc. This application is not limited; NRF_C obtains the instance ID and/or FQDN of NRF_P2, or the ID or address of NRF_P according to the instance ID of NF_P2 and/or NF_P3 Etc., this application is not restricted.

In this embodiment, the target NRFs are all other NRFs in the same PLMN of the NRF_C, that is, NRF_P1 and NRF_P2; optionally, in other scenarios, the target NRF may be the NRF_C registered by NF_C. NRF_C performs authorization according to the information in the first token request, generates a token after authorization is successful, and protects the integrity of the token.

S603. NRF_C sends a second token request to NRF_P1 corresponding to NF_P1, and the corresponding NRF_P1 receives the second token request from NRF_C, where the second token request includes the instance identifier of NF_P1;

After the network storage function NRF_C obtains the identification of the NRF_P corresponding to each service provider NF_P, it sends a second token request to each NRF_P. In this step, NRF_C sends the token request to NRF_P1.

S604, NRF_P1 performs authorization, generates a token, and performs integrity protection. The specific content is the same as S304, and will not be repeated here.

S605. The NRF_P1 corresponding to the service provider sends a token to the NRF_C corresponding to the service requester.

The token is a token obtained by NRF_P1 using a shared key with the service provider NF_P or using its own private key to protect the integrity of the token.

S606. NRF_C sends a second token request to NRF_P2, and the corresponding NRF_P2 receives the second token request from NRF_C. The second token request includes the instance identifier of NF_P2 and/or NF_P3.

Optionally, for the situation where multiple service provider network elements NF_P are registered on the same NRF_P, NRF_C can send multiple token requests for a single service provider to NRF_P. In this case, S606~S608 are the same as S303~S305. . I won't repeat them here.

S607, NRF_P2 performs authorization, generates a token and performs integrity protection.

NRF_P2 obtains the information carried in the token request combined with locally configured policies or authorization information for authorization, and generates a token after authorization is successful.

The token claim claim of the token includes the token issuer NRF_P2 instance logo. The token also carries information such as the instance identifier of the service requester NF_C, the instance identifiers of the service providers NF_P2 and NF_P3, the requested service name, and the validity period of the token.

In addition, NRF_P2 uses a shared key with service providers NF_P2 and NF_P3 or uses its own private key to protect the integrity of the token.

S608. The NRF_P2 corresponding to the service provider sends a token to the NRF_C corresponding to the service requester, and the corresponding NRF_C receives the token from the NRF_P2.

S603~S605 and S606~S608 do not have a strict execution order, and can be executed in an exchange order.

S609. NRF_C receives the token sent by each NRF_P and sends all the acquired tokens to the service requester NF_C through a token response. For example, the tokens from NRF_P1 and NRF_P2 in this embodiment. Correspondingly, NF_C receives the tokens from NRF_C. Token.

Optionally, if in other scenarios, the target NRF includes the NRF_C, the NRF_C sends the token generated by the NRF_C and/or received by the NRF_C to the NF_C.

Optionally, when sending the token, the NRF_C also sends the corresponding relationship between the instance identifier of each NF_P and the instance identifier of the registered NRF_P to the NF_C. Correspondingly, the NF_C receives and saves the corresponding relationship between each NF_P and NRF_P. For example, in this embodiment, the correspondence between NF_P1 and NRF_P1, and the correspondence between NF_P2, NF_P3 and NRF_P2, and so on. When the subsequent NF_C requests a token of a certain NF_P, the identifier of the NRF_P corresponding to the NF_P can be found by querying the saved correspondence relationship, and the token request is sent directly to the NRF_P.

S610 to S613 take NF_P1 as an example to describe the steps of the service requester NF_C requesting the service from the service provider NF_P1. The steps for the service requester NF_C to initiate a service request to NF_P2 or NF_P3 in this embodiment are the same as the above steps.

S610. Before initiating the service request, the service requester NF_C queries and finds the token corresponding to the service provider NF_P1 according to the instance identifier of the service provider NF_P1.

According to the information carried in the token described in S604 (same as S304) and S607, it can be known that the token generated by NRF_P carries the instance identifier of the service provider NF_P1. Therefore, NF_C can find out the token carrying the instance ID according to the instance ID of the service provider NF_P1.

S611. NF_C sends a service request carrying a corresponding token to NF_P1.

The service requester NF_C sends a service request to the service provider NF_P1, and the service request carries the token corresponding to the NF_P1, that is, the token with the instance identifier of the NF_P1.

S612. After the service provider NF_P1 receives the service request carrying the token, it uses the public key of its corresponding network storage function network element NRF_P1 or the shared key negotiated between NF_P1 and NRF_P1 to perform integrity verification, and execute the token after the verification is passed. check.

The token verification means that the service requester NF_P1 verifies whether the information carried in the token is consistent with the related information of NF_P1, for example, whether the instance identifier of the service provider carried in the token is the instance identifier of the NF_P1.

S613. After the above token verification is passed, the service provider NF_P1 sends a service response to the service requester NF_C. Correspondingly, the service requester NF_C receives the service response from the service provider NF_P.

In this embodiment, the registration information is shared among NRF_C, NRF_P1, and NRF_P2. After receiving the first token request, NRF_C queries the registration information and sends the registration information of each service provider NF_P to the NRF_P registered by each NF_P. In the second token request, each NRF_P generates a token for one or several NF_Ps. When initiating a service request, the service requester selects the corresponding token according to the service provider's identity, and the subsequent service provider verifies the token. The above method realizes that the service requester generates multiple tokens in one token request for multiple service providers, and the subsequent service requester carries the correct token in the service request to avoid the failure of the service provider’s token verification , Thereby solving the problem of token request for certain service providers in the scenario where multiple NRFs are deployed in the same PLMN in the prior art.

Referring to FIG. 7, another possible process of one of the authorization methods provided in the embodiment of the present application is as follows.

This process corresponds to the scenario where the service requester network function network element NF_C is registered on the network storage function NRF_C, and at least two or more specific service provider network function network elements NF_P are registered on different NRF_Ps, where the service requester is located Service network, the service provider is located in the home network, that is, authorization in the roaming scenario, the scenario description is shown in Figure 5b. The authorization process described in Figure 7 involves eight network elements, including the service requester NF_C and the corresponding NRF_C in the service network cPLMN, the network storage function NRF_P0 in the home network pPLMN, the service provider NF_P1 and the corresponding NRF_P1, the service provider NF_P2, NF_P3 and their corresponding NRF_P2. The NRF_P0 may be a network storage function deployed in the pPLMN that is specifically responsible for receiving roaming requests, or it may be any network storage function in the pPLMN.

S700, the initial steps of the authorization process.

Before the authorization process starts, each network function network element NF is registered with its corresponding network storage function network element NRF. For example, in this embodiment, the service requester NF_C is registered on NRF_C, the service provider NF_P1 is registered on NRF_P1, and the service is provided NF_P2 and NF_P3 are registered on NRF_P2;

The network storage functions NRF_C and NRF_P0, as well as NRF_P0, NRF_P1 and NRF_P2 can save the registration information of each other through the network configuration, that is, the information of all NFs registered on the NRF;

Optionally, NRF_C and NRF_P0, as well as NRF_P0, NRF_P1 and NRF_P2, save the registration information of each other through registration, that is, one NRF is registered to another NRF;

Optional NRF_C and NRF_P0, as well as NRF_P0, NRF_P1 and NRF_P2, can also use the two operations of NFStatusSubscribe and NFStatusNotify in the Nnrf_NFManagement service to complete the acquisition and update of registration information. The acquisition of registration information between NRFs includes but is not limited to the above methods, and this application is not limited.

The specific content of the registration information has been described in S300, and will not be repeated here.

After registration is completed, the service requester NF_C initiates an NF discovery process to NRF_C, and NRF_C returns to NF_C information that can provide specific NF services or a group of NFs belonging to the target NF type. The information that may contain is detailed in S300. To repeat, the information in this embodiment includes instance identifiers of NF_P1, NF_P2, and NF_P3.

S701. The service requester NF_C sends a first token request to the registered network storage function network element NRF_C, and the network storage function network element NRF_C receives the first token request.

The first token request carries the identifier of each service provider NF_P, for example, carries the instance identifier of NF_P1, the instance identifier of NF_P2 and/or NF_P3. The token request also carries the ID of the public land network PLMN where the service requester and the service provider network element are located, that is, the ID of the service network cPLMN and the ID of the home network pPLMN in this embodiment. The token request may also carry the identity of the service requester NF_C, service name and other parameters required for authorization and token generation, which are not limited here.

S702. The network storage function NRF_C determines the network storage function NRF_P0 deployed in the PLMN where the service provider is located.

NRF_C obtains the identity of the network storage function NRF_P0 in pPLMN according to the PLMN ID of the home network pPLMN to which the service provider NF_P belongs in the above token request, and obtains the identity of the network storage function NRF_P0 in the pPLMN. The identity can be the instance identity of NRF_P0 and/or FQDN, or Other logos or addresses of NRF_P0 are not restricted in this application.

S703. The network storage function network element NRF_C sends the first token request to the NRF_P0, and the corresponding NRF_P0 receives the first token request from the NRF_C.

The steps S704 to S710 performed by the NRF_P0 in the home network in this embodiment are similar to the steps S602 to S608 performed by the NRF_C in FIG. 7, and they are all based on the service provider NF_P carried in the received first token request. Identification, by querying the registration information, find out the NRF_P registered by each NF_P, and send a token request to each NRF_P.

S704. The network storage function NRF_P0 determines the target NRF registered by each service provider NF_P.

The network storage function NRF_P0 determines the identification of the target NRF corresponding to each NF_P according to the identification of each service provider NF_P in the first token request, and determines the identification of the target NRF corresponding to each NF_P, such as the identification of NRF_P1 and NRF_P2 in this embodiment. The identifier may be the instance identifier and/or FQDN of NRF_P, or other identifiers or addresses of NRF_P, etc., which is not limited in this application.

In this embodiment, the target NRFs are all other NRFs in the same home network of the NRF_P0, that is, NRF_P1 and NRF_P2; optionally, in other scenarios, the target NRF may be the NRF_P0, and in this case, the NRF_P0 Authorization is performed according to the information in the first token request, the token is generated after the authorization is successful, and the integrity of the token is protected.

S705. The network storage function NRF_P0 sends a second token request to NRF_P1 corresponding to NF_P1, and the corresponding NRF_P1 receives the second token request from NRF_P0, where the second token request includes the instance identifier of NF_P1;

After the network storage function NRF_P0 obtains the identification of the NRF_P corresponding to each service provider NF_P, it sends a second token request to each NRF_P. In this step, NRF_P0 sends the second token request to NRF_P1.

S706, NRF_P1 performs authorization, generates a token, and performs integrity protection.

This step is similar to S604, except that, in addition to the content of S304, the token also carries the PLMN ID of the service network cPLMN to which the service requester NF_C belongs and the PLMN ID of the home network pPLMN to which the service provider NF_P1 belongs.

S707. The NRF_P1 corresponding to the service provider sends a token to the NRF_P0 corresponding to the service requester.

The token is a token obtained by NRF_P1 using a shared key with the service provider NF_P or using its own private key to protect the integrity of the token.

S708. The network storage function NRF_P0 sends a second token request to NRF_P2, and the corresponding NRF_P2 receives the second token request from NRF_P0. The token request includes the instance identifier of NF_P2 and/or NF_P3.

Optionally, for the situation where multiple service provider network elements NF_P are registered on the same NRF_P, NRF_P0 can send multiple token requests for a single service provider to NRF_P. In this case, S708~S710 are the same as S405~S407 . I won't repeat them here.

S709, NRF_P2 performs authorization, generates a token, and protects the integrity of the token.

This step is similar to S607, except that, in addition to the content of S304, the token also carries the PLMN ID of the service network cPLMN to which the service requester NF_C belongs and the PLMN ID of the home network pPLMN to which the service provider NF_P2 belongs.

S710. The NRF_P2 corresponding to the service provider sends a token to the NRF_P0, and the corresponding NRF_P0 receives the token from the NRF_P2.

S705~S707 and S708~S710 do not have a strict execution order, and can be executed in an exchange order.

S711. After receiving the token sent by each NRF_P, the NRF_P0 sends all the acquired tokens to the NRF_C in the service network cPLMN through the token response, such as the tokens from NRF_P1 and NRF_P2 in this embodiment. Correspondingly, NRF_C receives the token from NRF_P0.

Optionally, if in other scenarios, the target NRF contains the NRF_P0, the NRF_P0 sends the token generated by the NRF_P0 and/or received by the NRF_P0 to the NRF_C.

S712. The NRF_C sends the received token to the service requester network element NF_C.

S713 to S716 are the same as S610 to S613, and will not be repeated here.

Compared with the authorization process in Figure 7, the NRF_C registered by the service requester NF_C located in the service network cPLMN in this embodiment forwards the token request to the first network storage function NRF_P0 located in the home network pPLMN, which is determined by NRF_P0 and sent to pPLMN The target NRF_P within the target NRF_P respectively sends a token request, thereby solving the problem of service authorization between the service requester NF and certain service provider NFs in the roaming scenario when multiple NRFs are deployed in the same PLMN network in the prior art.

Figures 8a and 8b describe the scenario in which the service requester NF requests the tokens of a certain type of service provider NF registered on different NRFs. For example, AMF requests service from SMFs registered on different NRFs, or AUSF requests the tokens registered on different NRFs. UDM request services on NRF, etc., are not limited here.

Figure 8a shows a scenario where the service requester network element and a certain type of service provider network element are located in the same PLMN network. Specifically, service requester NF_C is registered on NRF_C; service provider one NF_P1 is registered on NRF_P1, service provider two NF_P2 and service provider three NF_P3 are registered on NRF_P2, where NF_P1, NF_P2 and NF_P3 belong to the same type of network element; NRF_C, NRF_P1 and NRF_P2 can interact with each other.

Figure 8b shows a scenario where the service requester and a certain type of service provider are located in different PLMN networks. For example, the AMF located in the serving network cPLMN requests service from the three SMFs located in the home network pPLMN. NRF_C interacts with NRF_P0 in the home network pPLMN, and NRF_P0, NRF_P1, and NRF_P2 interact with each other; the registration relationship of each network function NF is the same as that in Fig. 8a, and will not be repeated here.

Referring to FIG. 9, a possible process of the second authorization method provided by the embodiment of the present application is as follows.

This process describes the authorization process in the scenario where the service requester network function network element NF_C is registered on the network storage function NRF_C, and a certain type of service provider network function network element NF_P is registered in different NRF_Ps in the same PLMN. Scenario description See Figure 8a for details. This scenario involves six network elements, including service requester network function network element NF_C and corresponding NRF_C, service provider network function network element NF_P1 and corresponding NRF_P1 and service provider NF_P2 and corresponding NRF_P2, said service provider NF_P1 It belongs to the same type of network element as NF_P2.

S900. Preliminary steps of the authorization process.

Before the authorization process starts, each NF is registered with its corresponding NRF, and registration information is shared between each NRF. For details, see S600.

After the registration is completed, the service requester NF_C obtains information from the NRF_C that can provide a specific NF service or a group of NFs belonging to the target NF type through the service discovery step. The information is detailed in S300.

The optional service discovery step described above can be performed after the token request step, that is, between S912 and S913.

Optionally, when steps S901 to S903 are executed, the above service discovery step may not be executed.

S901. The service requester NF_C sends an NF discovery request to the registered network storage function network element NRF_C, where the request includes the type of NF_P, and the corresponding NRF_C receives the NF discovery request from the NF_C.

S902. After receiving the NF discovery request sent by NF_C, NRF_C queries the registration information, finds one or more service providers NF_P that meet the requirements, and returns to NF_C the instance identification of each NF_P through the service discovery response, as well as the registration of each NF_P The instance ID of the NRF_P; correspondingly, NF_C receives the service discovery response.

S903. After receiving the service discovery response, the NF_C saves the corresponding relationship between the instance ID of each NF_P and the instance ID of the registered NRF_P.

The above steps S901 to S903 are optional steps, which can be executed between S900 and S904, or between S912 and S913. If steps S901 to S903 are executed, the following S913 to S915 should be skipped.

S904. The service requester NF_C sends a first token request to the registered network storage function network element NRF_C, and correspondingly, the network storage function network element NRF_C receives the first token request.

The first token request carries the identity of the service requester, that is, the identity of NF_C, including the instance identity and type of NF_C; the first token request also carries the identity of the service provider NF_P, and the identity includes the type of NF_P The first token request may also carry other parameters required for authorization and token generation, such as the requested service name.

S905. The network storage function NRF_C determines the identities of all target NRFs corresponding to the type of NF_P according to the type of the service provider network function network element NF_P in the first token request, by querying the registration information, for example, NRF_P1 in this embodiment And the instance ID and/or FQDN of NRF_P2, or the ID or address of NRF_P, etc., this application is not limited;

In this embodiment, the target NRFs are all other NRFs in the same PLMN of the NRF_C, that is, NRF_P1 and NRF_P2; optionally, in other scenarios, the target NRF may be the NRF_C registered by NF_C. NRF_C performs authorization according to the information in the first token request, generates a token after authorization is successful, and protects the integrity of the token.

S906. NRF_C sends a second token request to NRF_P1, and correspondingly, NRF_P1 receives the second token request from NRF_C.

The token request includes the type of NF_P1, and/or the instance ID of NF_P1, and/or the instance ID of NF_P1 and NF_P2.

S907, NRF_P1 performs authorization, generates a token, and performs integrity protection.

After receiving the second token request, the NRF_P1 corresponding to the service provider network function network element NF_P1 obtains the information in the token request combined with locally configured policies or authorization information for authorization, and NRF_P1 generates a token after successful authorization. In addition, NRF_P1 uses the shared key with the service provider NF_P1 or uses its own private key to protect the integrity of the token.

The token claim claim of the token generated by NRF_P1 carries the identity of the token issuer, that is, the instance identity of NRF_P1. The token also carries information such as the type of the service provider NF_P1, the instance identifier of the service requester NF_C, the requested service name, and the validity period of the token.

S908. The NRF_P1 corresponding to the service provider sends a token to the NRF_C corresponding to the service requester, and correspondingly, the NRF_C corresponding to the service requester receives the token from the NRF_P1.

S909-S911 send the second token request to NRF_P2, and NRF_P2 performs authorization, generates a token, and sends the token to NRF_C. The specific content is the same as S903-S905.

S912, the same as S609.

S913~S919 take NF_P1 as an example, and describe the steps in which the service requester NF_C selects the corresponding token to request the service from the service provider NF_P.

S913. Before the service request, the NF_C sends the instance identifier of the NF_P1 to the NRF_C, and the corresponding NRF_C receives the NF_P1 instance identifier from the NF_C.

In this step, the service request used to request NRF_C to query and return the instance identifier of NRF_P can be an existing Nnrf_NFDiscover_NFDiscover Request, Nnrf_NFManagement_NFProfileRetrieval Request or other service requests, or a newly defined service request, which is not limited here.

S914. The NRF_C queries the registration information according to the instance ID of the NF_P1, and finds the instance ID of the NRF_P1 registered by the NF_P1.

S915. NRF_C sends the found instance ID of NRF_P1 registered by NF_P1 to NF_C. Correspondingly, NF_C receives the NRF_P1 instance ID from NRF_C.

This step can be a service response corresponding to S910, or it or a newly defined service response, which is not limited here.

S916. NF_C queries and finds the token corresponding to it according to the instance identifier of NRF_P1.

According to the information carried in the token described in S907, the token generated by the NRF_P carries the instance identifier of the service provider NRF_P. Therefore, the NF_C can find the token carrying the instance ID according to the instance ID of the service provider NRF_P1.

If the above S901～S903 are not executed, when S913～S915 are executed, NF_C will query token 1 according to the instance ID of NRF_P1 returned by NRF_C; if the above S901～S903 are executed, when S913～S915 are executed, NF_C will query itself according to the instance ID of NF_P1. The corresponding relationship between the saved instance ID of NF_P and the instance ID of NRF_P is obtained, the instance ID of NRF_P1 is obtained, and token 1 is found according to the instance ID of NRF_P1.

S917～S919 are the same as S611～S613, so I won’t repeat them here.

In this embodiment, the service requester NF_C requests a token used to access a certain type of service provider NF_P. After receiving the token request, NRF_C queries the registration information according to the type of NF_P, and registers the NF_P for each service provider. In case, a token request is sent to the registered NRF_P of this type of NF_P, and each NRF_P generates a token for this type of NF_P. When initiating a service request, the service requester NF_C selects a corresponding token according to the NRF_P identifier, and the subsequent service provider verifies the token. The above method realizes that the service requester generates multiple tokens in a token request for a certain type of service provider, and the subsequent service requester carries the correct token in the service request to avoid the token verification of the service provider Failure, thereby solving the problem of the token request for a certain type of service provider in the scenario where multiple NRFs are deployed in the same PLMN in the prior art.

Referring to FIG. 10, another possible process of the second authorization method provided by the embodiment of the present application is as follows.

This process describes the authorization of the service requester network function network element NF_C registered on the network storage function NRF_C, a certain type of service provider network function network element NF_P registered in different NRF_P scenarios, where the service requester NF_C Located in the service network, the service provider NF_P is located in the home network, that is, authorization in the roaming scenario, the scenario description is shown in Figure 4-b. This scenario involves seven network elements, including the service requester NF_C and the corresponding NRF_C in the service network cPLMN, the first network storage function NRF_P0 in the home network pPLMN, the service provider NF_P1 and the corresponding NRF_P1, the service provider NF_P2 and the corresponding NRF_P2. The NRF_P0 may be a network storage function deployed in the pPLMN that is specifically responsible for receiving roaming requests, or it may be any network storage function in the pPLMN.

S1000, the first steps of the authorization process.

Before the authorization process starts, each NF is registered with its corresponding NRF, and registration information is shared between each NRF. For details, see S700.

After registration is completed, the service requester NF_C initiates an NF discovery process to NRF_C, and NRF_C returns to NF_C information that can provide specific NF services or a group of NFs belonging to the target NF type. The information that may contain is detailed in S300. To repeat, the information in this embodiment includes instance identifiers of NF_P1, NF_P2, and NF_P3.

The optional service discovery step described above can be performed after the token request step, that is, between S1015 and S1016.

Optionally, when steps S1001 to S1003 are executed, the above service discovery step may not be executed.

S1001 to S1003 are the same as S901 to 903, and will not be repeated here.

S1004. The service requester NF_C sends a first token request to the registered network storage function network element NRF_C, and the network storage function network element NRF_C receives the first token request.

The first token request carries the identity of the service requester, that is, the identity of NF_C, including the instance identity and type of NF_C and the PLMN ID of the network to which it belongs, that is, the ID of the cPLMN; the first token request also carries the service provider The identifier of NF_P, the identifier includes the type of NF_P and the PLMN ID of the network to which it belongs, that is, the ID of pPLMN. The first token request may also carry other parameters required for authorization and token generation, such as the requested service name.

S1005 is the same as S702, and will not be repeated here.

S1006 is the same as S703, and will not be repeated here.

S1007. The network storage function NRF_P0 determines the identities of all target NRFs corresponding to the type of NF_P by querying the registration information according to the type of the service provider NF_P in the first token request, such as the instance identities of NRF_P1 and NRF_P2 in this embodiment And/or FQDN, or the identification or address of NRF_P, etc., this application is not restricted;

In this embodiment, the target NRFs are all other NRFs in the same home network of the NRF_P0, that is, NRF_P1 and NRF_P2; optionally, in other scenarios, the target NRF may be the NRF_P0, and in this case, the NRF_P0 Authorization is performed according to the information in the first token request, the token is generated after the authorization is successful, and the integrity of the token is protected.

S1008. The aforementioned network storage function NRF_P0 sends a second token request to each NRF_P corresponding to the type of service provider NF_P, where the token request includes the type of NF_P and/or one or more NF_P instance identifiers. In this step, NRF_P0 sends the second token request to NRF_P1.

S1009, NRF_P1 performs authorization, generates a token and performs integrity protection.

After receiving the second token request, the NRF_P1 corresponding to the service provider network function network element NF_P1 obtains the information in the second token request and combines it with locally configured policies or authorization information for authorization, and NRF_P1 generates a token after successful authorization. In addition, NRF_P1 uses the shared key with the service provider NF_P1 or uses its own private key to protect the integrity of the token.

The token generated by NRF_P1 carries the identity of the token issuer, that is, the instance identity of NRF_P1. The token also carries the instance ID of the service requester NF_C and the public land network PLMN ID to which it belongs, the type of the service provider NF_P1 and the public land network PLMN ID to which it belongs, the requested service name and the token Validity period and other information.

S1010. The NRF_P1 corresponding to the service provider sends a token to the NRF_C corresponding to the service requester, and correspondingly, the NRF_C corresponding to the service requester receives the token from the NRF_P1.

S1011～S1013, NRF_C sends a second token request to NRF_P2, NRF_P2 authorizes, generates a token and returns the token to NRF_C, the specific content is the same as S1005～S1007

S1008～S1010 and S1011～S1013 do not have a strict execution order, and they can be executed in an exchange order.

S1014. NRF_P0 receives the token from each NRF_P and sends it to NRF_C, and the corresponding NRF_C receives the token sent by NRF_P0.

Optionally, if in other scenarios, the target NRF contains the NRF_P0, the NRF_P0 sends the token generated by the NRF_P0 and/or received by the NRF_P0 to the NRF_C.

S1015. The NRF_C sends the received token to the service requester network element NF_C.

S1016~S1022 take NF_P1 as an example, and describe the steps in which the service requester NF_C selects the corresponding token to request the service from the service provider NF_P. The specific content is the same as S913~S919, and will not be repeated here.

Compared with the authorization process in Figure 9, the NRF_C registered by the service requester NF_C located in the service network cPLMN in this embodiment forwards the token request to the first network storage function NRF_P0 located in the home network pPLMN, and NRF_P0 according to the service provider The type of NF_P is determined and a token request is sent to the target NRF_P in pPLMN respectively. This solves the problem of service authorization between the service requester NF and a certain type of service provider NF in the roaming scenario when multiple NRFs are deployed in the same PLMN network in the prior art.

The method in the embodiment of the present application is described in detail above. Based on the same inventive concept of the above method embodiment, the present embodiment also provides related devices and equipment.

Referring to FIG. 11, an embodiment of the present application provides an apparatus 1100, which includes a receiving module 1101, a processing module 1102, and a sending module 1103.

The device 1100 can be used for NRF_C or NRF_C, and the device can perform the operations performed by the NRF_C in the foregoing method embodiments. Taking the authorization method in Figure 7 as an example, the receiving module 1101 is used to receive the first token request; the processing module 1102 is used to determine the target network storage function network element NRF registered by each network function network element; the sending module 1103 also uses To send a second token request to each target NRF; the receiving module 1101 is also used to receive the token fed back by the target NRF; the sending module 1103 is also used to send to the token requestor, that is, NF_C in FIG. 7 Receive the token received by the module 1101.

The device 1100 can also be used for NF_C or NF_C, and the device can perform operations performed by NF_C in the foregoing method embodiments. Taking the authorization method in Figure 3 as an example, the sending module 1103 is used to send the first token request to NRF_C; the receiving module 1101 is used to receive the token sent by NRF_C; the processing module 1102 is used to determine the token carried in the service request The sending module 1103 is also used to send service requests to the service provider network element; the receiving module 1101 is also used to receive service requests fed back by the service provider.

The device 1100 can also be used for NF_P or NF_P. The device can perform the operations performed by NF_P in the foregoing method embodiments. The NF_P can be NF_P1, or NF_P2, NF_P3. Taking the authorization method in Figure 7 as an example, the receiving module 1101 is used to receive the service request of the service requester; the processing module 1102 is used to verify the token in the service request; the sending module 1103 is used to return the service to the service requester. response.

The device 1100 can also be used for NRF_P0 or NRF_P0, and the device can perform the operations performed by NRF_P0 in the foregoing method embodiments. Taking the authorization method in Figure 8 as an example, the receiving module 1101 is used to receive the first token request; the processing module 1102 is used to determine the target network function NRF registered by each network function network element; the sending module 1103 is used to send each The target NRF sends a second token request. The receiving module 1101 is also used to receive the token fed back by the target NRF; the sending module 1103 is also used to send the token received by the receiving module 1101 to the token requester, that is, the NRF_C in FIG. 8.

The device 1100 can also be used for NRF_P or NRF_P. The device can perform the operations performed by NRF_P in the foregoing method embodiments. The NRF_P can be NRF_P1 or NRF_P2. Taking the authorization method in FIG. 7 as an example, the receiving module 1101 is used to receive the second token request; the processing module 1102 is used to combine the locally configured policy or authorization information according to the information carried in the token request received by the receiving module 1101 The processing module 1102 is also used to perform integrity protection on the generated token; the sending module 1103 is used to send the token generated and protected by the processing module 1102 to the token requester.

Referring to FIG. 12, an embodiment of the present application further provides a device 1200. The device 1200 includes a processor 1201, a communication interface 1202, and a memory 1203.

The processor 1201 is used to execute program instructions, and when the program is executed, the processor 1202 executes operations performed by NRF_C, NF_C, NF_P, NRF_P, or NRF_P0 in each authorization method provided in the foregoing embodiment. The processor 902 may be, but is not limited to, a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), or a combination of CPU and NP. When the processor 1201 is a CPU, the CPU may be a single-core CPU or a multi-core CPU.

The processor 1201 may further include a hardware chip. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (Programmable Logic Device, PLD), or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (Complex Programmable Logic Device, CPLD), a field programmable logic gate array (Field-Programmable Gate Array, FPGA), a general array logic (Generic Array Logic, GAL) or any combination thereof.

The communication interface 1202 is used to communicate with other devices under the control of the processor 1201, such as sending data and/or receiving data. The sending module and the receiving module in FIG. 7 can be implemented through the communication interface 1202.

The memory 1203 is used to store programs executed by the processor 1201. The memory 1203 may include, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Portable read-only memory (Compact Disc Read-Only Memory, CD-ROM), flash memory (flash memory), hard disk (HDD) or solid-state drive (SSD); memory 1203 may also include Any combination of the above types of memory.

The embodiment of the present application provides a computer-readable storage medium that stores a computer program, and the computer program includes instructions for executing the method provided in the foregoing embodiment.

The embodiments of the present application provide a computer program product containing instructions, which when run on a computer, cause the computer to execute the method provided in the above-mentioned embodiments.

Those skilled in the art should understand that the embodiments of the present application can be provided as methods, devices, equipment (systems) or computer program products. Therefore, this application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

This application is described with reference to flowcharts and/or block diagrams of methods, devices, equipment (systems) and computer program products according to the embodiments of this application. It should be understood that each process in the flowchart can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

The above are only some specific implementations of this application, but the protection scope of this application is not limited to this. Anyone familiar with the technical field can make adjustments to these embodiments within the technical scope disclosed in this application. Additional changes and modifications. Therefore, the appended claims are intended to be interpreted as including the above-mentioned embodiments and changes and modifications that fall within the scope of the present application. Therefore, the protection scope of this application shall be subject to the protection scope of the claims.

Claims (32)

An authorization method in multiple NRF scenarios, which is characterized by: The first network storage function network element NRF receives a first token request, where the first token request includes the identities of one or more service provider network function network elements NF_P; The first NRF determines the target NRF registered by each NF_P according to the identification of the one or more NF_Ps; If the target NRF includes a second network storage function network element NRF, the first NRF sends a second token request to the second NRF, and the second token request includes one or more NF_P identifiers; Wherein, the first NRF and the second NRF are located in the same public land network PLMN; The first NRF receives the token fed back by the second NRF. The method according to claim 1, wherein before the first NRF receives the first token request, the method further comprises: Acquiring, by the first NRF, registration information of network functions stored on other NRFs in the PLMN; The first NRF determining the target NRF registered by each NF_P according to the identification of the one or more NF_Ps includes: The first NRF uses the one or more NF_P identifiers to query the registration information saved and/or obtained by the first NRF to determine the target NRF registered by each NF_P. The method according to claim 1 or 2, wherein the first NRF receiving a first token request includes: The first NRF receives a first token request sent by a network function network element of a service requester. The method according to claim 3, wherein after the first NRF receives the token fed back by the second NRF, the method further comprises: The first NRF sends the token generated by the first NRF and/or the token received by the first NRF to the service requester network function network element. The method according to claim 1 or 2, wherein the first NRF is located in a home network; The first NRF receiving the first token request includes: The first NRF receives the first token request sent by the network storage function of the service network. The method according to claim 5, wherein after the first NRF receives the token fed back by the second NRF, the method further comprises: The first NRF sends the token generated by the first NRF and/or the token received by the first NRF to a network storage function network element of the service network. An authorization method in multiple NRF scenarios, which is characterized by: The first network storage function network element NRF receives a first token request, where the first token request includes the type of the service provider network function network element NF_P; The first NRF determines the target network storage function NRF registered by the NF_P belonging to the type; If the target NRF includes a second network storage function network element NRF, the first NRF sends a second token request to the second NRF; wherein, the first NRF and the second NRF are located in the same public Land network PLMN; Receiving the token fed back by the second NRF by the first NRF; The method according to claim 7, characterized in that, before the first NRF receives the first token request, the method further comprises: Acquiring, by the first NRF, registration information of network functions stored on other NRFs in the PLMN; The determination by the first NRF to belong to the target NRF registered by the type of NF_P includes: The first NRF uses the type of the NF_P to query the registration information saved and/or obtained by the first NRF to determine the identity of each target NRF registered by the type of NF_P. The method according to claim 7 or 8, wherein: The second token request includes the type of the NF_P registered on the second NRF, and/or one or more identifiers of the NF_P. The method according to claim 9, wherein the first NRF receiving a first token request comprises: The first NRF receives a first token request sent by a network function network element of a service requester. The method according to claim 10, wherein after the first NRF receives the token fed back by the second NRF, the method further comprises: The first NRF sends the token generated by the first NRF and/or the token received by the first NRF to the service requester network function network element. The method according to claim 9, wherein the first NRF is located in a home network; The first NRF receiving the first token request includes: The first NRF receives the first token request sent by the network storage function of the service network. The method according to claim 12, wherein after the first NRF receives the token fed back by the second NRF, the method further comprises: The first NRF sends the token generated by the first NRF and/or the token received by the first NRF to a network storage function network element of the service network. An authorization device, characterized in that it comprises: The receiving module is configured to receive a first token request, where the token request includes one or more instance identifiers of network function network elements NF_P that provide functional services; A processing module, configured to determine the target NRF registered by each NF_P according to the instance identifier of the one or more NF_P; The sending module is configured to send a second token request to the second NRF if the target NRF determined by the processing module includes a second network storage function network element NRF, and the second token request includes one or more NF_P identification; wherein, the device and the second NRF are located in the same public land network PLMN; The receiving module is further configured to receive the token fed back by the second NRF; The device of claim 14, wherein: The receiving module is also used to obtain registration information of network functions stored on other NRFs in the PLMN; The processing module is configured to use the one or more NF_P identifiers to query the registration information saved and/or obtained by the device to determine the target NRF registered by each NF_P. The device according to claim 14 or 15, wherein the receiving module receives the first token request, comprising: The receiving module receives the first token request sent by the network function network element of the service requester. The device of claim 16, wherein: The sending module is further configured to send the token generated by the device and/or received by the device to the network function network element of the service requester. The device according to claim 14 or 15, wherein the device is located in a home network; The receiving module is configured to receive the first token request sent by the network storage function network element of the service network. The device of claim 18, wherein: The sending module is further configured to send the token to a network storage function network element of the service network. An authorization device, characterized in that it comprises: The receiving module is configured to receive a first token request, where the token request includes the type of the network function network element NF_P that provides the function service; Processing module, used to determine the target network storage function NRF corresponding to each NF_P belonging to the type; The sending module is configured to send a second token request to the second NRF if the target NRF determined by the processing module includes a second network storage function network element NRF, where the device and the second NRF are located at The same public land network PLMN; The receiving module is further configured to receive the token fed back by the second NRF; The device of claim 20, wherein: The receiving module is also used to obtain registration information of network functions stored on other NRFs in the PLMN; The processing module is configured to use the type of the NF_P to query the registration information saved and/or obtained by the device to determine the identification of each target NRF registered by the type of the NF_P. The device according to claim 20 or 21, wherein: The second token request sent by the sending module includes the type of the NF_P registered on the second NRF, and/or one or more identifiers of the NF_P. The apparatus according to claim 22, wherein the receiving module is configured to receive a first token request sent by a network function network element of a service requester. The device of claim 23, wherein: The sending module is configured to send the token generated by the device and/or received by the device to the service requester network function network element. The device according to claim 22, wherein the device is located in a home network; The receiving module is configured to receive the first token request sent by the network storage function of the service network. The device of claim 25, wherein: The sending module is configured to send the token generated by the device and/or received by the device to the network storage function network element of the service network. A device, characterized in that the device comprises: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute the instructions , The communication interface is used to communicate with other devices under the control of the processor; The processor executes the instructions to implement the method according to any one of claims 1 to 6. A device, characterized in that the device comprises: a storage unit, a communication interface, and a processor coupled with the storage unit and the communication interface; the storage unit is used to store instructions, and the processor is used to execute the instructions , The communication interface is used to communicate with other devices under the control of the processor; The processor executes the instructions to implement the method described in any one of claims 7-13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is executed. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 7 to 13 is executed. A computer program product, characterized in that: The computer program is executed by a processor to implement the method according to any one of claims 1 to 6. A computer program product, characterized in that: The computer program is executed by a processor to implement the method according to any one of claims 7-13.

Images