Patent Description:
An SA2 working group of the 3rd Generation Partnership Project (3rd Generation Partnership Project, 3GPP) proposes an enhancement of service-based architecture (Enhancement of Service Based Architecture, eSBA) project for a <NUM> core network, where a service communication proxy (Service Communication Proxy, SCP) and the like are introduced. The SCP may be used for indirect communication between network functions (Network Functions, NFs). Service invocation between the NFs may be forwarded by the SCP, and the SCP may also have functions such as NF discovery and load balancing.

3GPP TR <NUM>, V1. <NUM> relates to a study on security aspects of the <NUM> Service Based Architecture (SBA). Section <NUM> of D3 discloses a solution for a service authorization procedure of NF service access for non-roaming scenarios. 3GPP document S3-<NUM> discloses that in Rel-<NUM>, SA2 is introducing the concept of instance Set for 5GC and allow re-selection of a service instance within the Set. This concept has been extended to Network Functions as well as NF Services within an NF instance. The authors propose to add a new key issue to TR <NUM> that studies the impact of this enhancement on OAuth <NUM> based Service access authorization.

3GPP document S3-<NUM> relates to clarification on service authorization and token verification. The authors propose adding scope and expire time beside the token in clause <NUM>. <NUM>, and clarification on home and serving PLMN ID verification in the roaming case.

Currently, an authorization implementation mechanism for a related NF in an eSBA architecture that has introduced the SCP is an important technical problem that needs to be studied in the industry.

Embodiments of this application provide communication methods, a network repository function, a service consumer, computer-readable storage media and a communications system as defined in the attached set of claims.

The following describes some accompanying drawings in embodiments of this application.

<FIG> is a schematic diagram of an example of a <NUM> network architecture according to an embodiment of this application. In a <NUM> network, some function network elements (for example, a mobility management entity (Mobility Management Entity, MME)) in a <NUM> network are split, and a service-based architecture is defined. In the network architecture shown in <FIG>, a function similar to that of an MME in the <NUM> network is split into an access and mobility management function (Access and Mobility Management Function, AMF), a session management function (Session Management Function, SMF), and the like.

The following describes some other related network elements/entities.

User equipment (User Equipment, UE) accesses a data network (Data Network, DN) and the like by accessing an operator network, and uses services provided by an operator or a third party in the DN.

An access and mobility management function (AMF) is a control plane network element in a 3GPP network, and is mainly responsible for access control and mobility management when the UE accesses an operator network. A security anchor function (Security Anchor Function, SEAF) may be deployed on the AMF, or deployed on a device other than the AMF. <FIG> is an example in which the SEAF is deployed on the AMF. When the SEAF is deployed on the AMF, the SEAF and the AMF may be jointly referred to as an AMF.

A session management function (SMF) is a control plane network element in the 3GPP network. The SMF is mainly responsible for managing packet data unit (Packet Data Unit, PDU) sessions of the UE. A PDU session is a channel used to transmit a PDU, and the UE and the DN may send a PDU to each other by using a PDU session. The SMF is responsible for management tasks such as establishment, maintenance, and deletion of the PDU session.

The data network (Data Network, DN), also referred to as a packet data network (Packet Data Network, PDN), is a network located outside the 3GPP network. A plurality of DNs may be connected to the 3GPP network, and a plurality of services provided by an operator or a third party may be deployed in the DN. For example, a DN is a private network of a smart factory, a sensor installed in a workshop of the smart factory plays a role of the UE, and a control server of the sensor is deployed in the DN. The UE communicates with the control server. After obtaining an instruction from the control server, the UE may transfer collected data to the control server according to the instruction. For another example, a DN is an internal office network of a company, a terminal used by an employee of the company may play a role of the UE, and the UE may access internal information and other resources of the company.

A unified data management (Unified Data Management, UDM) network element is also a control plane network element in the 3GPP network. The UDM is mainly responsible for storing subscription data, credentials (credentials), permanent identifiers (Subscriber Permanent Identifiers, SUPIs), and the like of subscribers (UEs) in the 3GPP network. The data may be used for authentication and authorization when the UE accesses a 3GPP network of an operator.

An authentication server function (Authentication Server Function, AUSF) is also a control plane network element in the 3GPP network. The AUSF is mainly used for first-level authentication (that is, subscriber authentication in the 3GPP network).

A network exposure function (Network Exposure Function, NEF) is also a control plane network element in the 3GPP network. The NEF is mainly responsible for exposing external interfaces of the 3GPP network to third parties in a secure manner. When a network element such as the SMF needs to communicate with a third party network element, the NEF may serve as a relay for communication. The NEF can translate internal and external identifiers when serving as the relay. For example, when sending an SUPI of the UE from the 3GPP network to a third party, the NEF may translate the SUPI into a corresponding external identity (Identity, ID). Conversely, when an external identity ID is sent to the 3GPP network, the NEF may translate the external identity ID into a corresponding SUPI.

A network repository function (Network Repository Function, NRF) is also a control plane network element in the 3GPP network. The NRF is mainly responsible for storing configurations and service profiles (profiles) of accessible network functions (NFs), and providing network function discovery services for other network elements.

A user plane function (User Plane Function, UPF) is a gateway for communication between the 3GPP network and the DN.

A policy control function (Policy Control Function, PCF) is a control plane function in the 3GPP network, and is configured to provide a policy of a PDU session for the SMF. The policy may be a policy related to charging, quality of service (Quality of Service, QoS), authorization, and the like.

An access network (Access Network, AN) is a sub-network of the 3GPP network. To access the 3GPP network, the UE needs to first access the AN. In a radio access scenario, the AN is also referred to as a radio access network (Radio Access Network, RAN). Therefore, terms "RAN" and "AN" are usually used interchangeably.

The 3GPP network is a network that complies with 3GPP specifications. In <FIG>, parts other than the UE and the DN may be considered as the 3GPP network. The 3GPP network is not limited to a <NUM> network defined by the 3GPP, but may further include a <NUM> network, a <NUM> network, and a <NUM> network. Usually, the 3GPP network is operated by an operator. In addition, N1, N2, N3, N4, N6, and the like in the architecture shown in <FIG> represent reference points (Reference Points) between related network elements/network functions. Nausf, Namf, and the like represent service-oriented interfaces of related network functions.

Certainly, the 3GPP network and a non-3GPP network may coexist, and some network elements in the <NUM> network may also be used in some non-<NUM> networks.

The solutions in the embodiments of this application relate to a roaming scenario and a non-roaming scenario. In the roaming scenario, a home network and a visited network exist, and architectures of the home network and the visited network may be the same or different. The home network may also be referred to as a home domain, a home network, or the like. The visited network may also be referred to as a visited domain or the like.

Refer to <FIG> show examples of some possible network architectures in which an SCP is introduced or no SCP is introduced in an eSBA architecture. <FIG>and <FIG> show some possible network architectures in which no SCP is introduced. <FIG> and <FIG>show some possible network architectures in which an SCP is introduced.

After the SCP is introduced, some messages (for example, a service request and a service response) between a service consumer (Service Consumer) and a service producer (Service Producer) may be forwarded by the SCP.

In description of some embodiments of this application, a service consumer is sometimes referred to as a consumer for short, and a service producer is sometimes referred to as a producer for short. A service producer set (Service Producer Set) is also sometimes referred to as a producer set for short, or the like.

The methods in embodiments of this application may be specifically implemented based on the network architectures shown in <FIG> (Option C) and <FIG>(Option D).

Service producers (Service Producers) in the architectures shown in <FIG> may be specifically some NFs (network functions) in a core network. There may be service-oriented interfaces between NFs in the core network. Communication between the NFs may be performed in a service invoking manner.

A network repository function (Network Repository Function, NRF) may be configured to complete NF registration, discover and store registration information of NFs in a same public land mobile network (Public Land Mobile Network, PLMN), and the like. The NRF may also function as an authorization server to complete service authorization, and the NRF may also have a function of generating a token or verifying a token.

The service communication proxy (SCP) is mainly configured to implement communication forwarding between NFs, and may be further configured to implement load balancing and NF selection. In addition, the SCP may further have functions such as NF registration, discovery, and service authorization.

The solutions in the embodiments of this application are mainly applied to a system in which a service-oriented architecture is enhanced in a second phase of <NUM>.

For example, in the Option C and Option D architectures, if the service producer (Producer) is an NF/NF service in a set, the SCP may select another NF/NF service from the set (the selected NF may not be an NF requested by the consumer) as the producer. In this scenario, the consumer can use authorization information of another instance in a same set as the producer to access services of the producer. For example, the consumer is previously authorized to access an NF_A in an NF set, but the NF_A cannot work due to a fault or performance problem. In this case, the SCP may directly select an NF_B in the same NF set without initiating a new authorization procedure. In this case, the consumer is authorized to access a service of the NF_B.

The solutions in this embodiment of this application are applicable to a scenario in which the producer is located in an NF set or an NF service set, or the producer is an NF set or an NF service set. The following embodiments are mainly described by using an example in which the producer is located in the NF set.

<FIG> is a schematic flowchart of a communication method according to an embodiment of this application. The communication method may include the following steps.

<NUM>: A service consumer sends a token request to an NRF, and the NRF receives the token request from the service consumer.

<NUM>: The NRF sends a token request response to the service consumer, where the token request response carries a token, and the token includes an NF set identifier or an NF service set identifier of a service producer (Service Producer).

<NUM>: The service consumer receives the token request response from the NRF, and sends a service request to an SCP, where the service request carries the token (the token may be generated by the NRF), and the token includes the NF set identifier or the NF service set identifier of the service producer.

<NUM>: The SCP receives the service request from the service consumer, and the SCP sends the service request to a service producer selected from an NF set or an NF service set of the service producer.

<NUM>: The SCP receives a response to the service request from the service producer, and the SCP forwards the response to the service request from the service producer to the service consumer.

A token including the NF set identifier of the service producer may be considered as a token for the NF set of the service producer, and is a token at an NF set granularity. A token including the NF service set identifier of the service producer may be considered as a token for the NF service set, and is a token at an NF service set granularity.

The token request may carry an identifier of the service consumer (the identifier of the service consumer is, for example, an NF instance identifier (NF Instance ID) of the service consumer).

The token request may further carry one or more of the following information: an identifier of the service producer, the NF set identifier of the service producer, or the NF service set identifier of the service producer.

For example, the method may further include: The NRF performs service authorization on the service consumer, and generates the token when service authorization on the service consumer succeeds.

The generating the token may include: If the token request carries the identifier of the service producer, the NRF obtains the NF set identifier of the service producer based on the identifier of the service producer, and generates a token including the NF set identifier of the service producer; or if the token request carries the NF set identifier of the service producer, the NRF generates a token including the NF set identifier of the service producer.

For example, when the service producer is an NF, an audience claim (Audience Claim) of the token includes the NF set identifier of the service producer.

Alternatively, when the service producer is an NF service, a scope claim (Scope Claim) of the token includes the NF service set identifier of the service producer.

The SCP may select the service producer from the NF set or the NF service set of the service producer according to a local policy and/or other information (for example, selection parameters carried in the service request).

For example, before the sending the service request to the service producer in the NF set represented by the NF set identifier, the method further includes: The SCP verifies the token included in the service request.

That the SCP sends the service request to the service producer in the NF set represented by the NF set identifier includes: When verification on the token succeeds, the SCP sends the service request to the service producer in the NF set represented by the NF set identifier.

For example, verification on the token may include integrity verification of the token and/or claim verification of the token.

For example, the claim verification of the token may include: verifying whether the NF set identifier of the service producer included in the audience claim of the token is consistent with an NF set identifier of the selected service producer; and when the two NF set identifiers are consistent, it indicates that audience claim verification of the token succeeds. For example, when the two NF set identifiers are inconsistent, it indicates that the audience claim verification of the token fails.

For another example, the claim verification of the token may include: verifying whether the NF service set identifier of the service producer included in the scope claim of the token is consistent with the NF service set identifier of the selected service producer; and when the two NF service set identifiers are consistent, it indicates that scope claim verification of the token succeeds. For example, when the two NF service set identifiers are inconsistent, it indicates that the scope claim verification of the token fails.

For example, the service request carries a service producer identifier or a service producer type, and the NF set identifier of the selected service producer is obtained based on the service producer identifier or the service producer type.

It can be learned that, in the foregoing solution, the NRF generates the token based on a request of the service consumer. The token includes the NF set identifier or the NF service set identifier of the service producer. In other words, the token is a token for an NF set or an NF service set to which the service producer belongs, and the token is a token at a set granularity. The use of the token at a set granularity helps implement service control based on an NF set granularity, further helps resolve a problem that different producers in a producer set verify tokens, and helps implement convenient authorization in a set scenario in an eSBA.

<FIG> is a schematic flowchart of another communication method according to an embodiment of this application. The another communication method may include the following steps.

<NUM>: A service consumer sends a service request to an SCP.

<NUM>: The SCP receives the service request from the service consumer; and the SCP performs service authorization on the service consumer, or the SCP requests an NRF to perform service authorization on the service consumer.

<NUM>: When service authorization on the service consumer succeeds, the SCP sends the service request to a service producer selected from a service producer set.

For example, the method further includes: The SCP generates a token when service authorization on the service consumer succeeds. The service request sent by the SCP to the service producer carries the token, where the token includes an NF set identifier or an NF service set identifier of the service producer.

When the service request sent by the SCP to the service producer carries the token, the service producer may perform verification on the token or request the NRF to perform verification on the token.

For example, that the SCP requests an NRF to perform service authorization on the service consumer includes:
The SCP sends an authorization request to the NRF, where the authorization request is used to request the NRF to perform service authorization on the service consumer; and the SCP receives a response to the authorization request sent by the NRF, where the response to the authorization request carries a service authorization result of the service consumer from the NRF, and the service authorization result is that service authorization succeeds or that service authorization fails.

For example, the service request carries a service identifier of a requested service, and that the SCP performs service authorization on the service consumer includes: determining, according to an authorization policy or authorization information locally configured by the SCP, whether the service consumer has permission to access the service that is represented by the service identifier and that is provided by the service producer.

It can be learned that, in the foregoing solution, the SCP generates the token. The token includes the NF set identifier or the NF service set identifier of the service producer, that is, the token is a token for an NF set or an NF service set to which the service producer belongs, and the token is a token at a set granularity. The use of the token at a set granularity helps implement service control based on an NF set granularity, further helps resolve a problem that different producers in a producer set verify tokens, and helps implement convenient authorization in a set scenario in an eSBA.

<FIG> is a schematic flowchart of another communication method according to an embodiment of this application.

The another communication method may include the following steps.

<NUM>: A service consumer_A sends a token (Token) request to an NRF.

The service consumer_A may be, for example, an NF_A (in this case, the service consumer service consumer_A is specifically an NF).

The token request may carry an identifier of the service consumer_A (the identifier of the service consumer_A may be, for example, an NF identifier of the service consumer_A, and may be specifically, for example, an NF instance ID) and a service identifier of a requested service. A service consumer may also be referred to as a consumer for short. A service producer in this embodiment of this application may be an NF or an NF service. To be specific, the service producer may be at an NF granularity, and the service producer may also be at an NF service granularity. A service producer may be referred to as a producer for short.

In the solution of this embodiment of this application, a service producer set includes one or more service producers. When a service producer in the service producer set is an NF, the service producer set may also be referred to as a service producer NF set. When a service producer in the service producer set is an NF service, the service producer set may also be referred to as a service producer NF service set.

A service producer may belong to a service producer set. A service producer set may be referred to as a producer set for short, and a producer set to which a service producer belongs may also be referred to as a set (Set) to which a service producer belongs for short. To be specific, in the description of this embodiment of this application, a set to which a service producer belongs refers to a producer set to which a service producer belongs.

For example, when the service producer is an NF, a set to which the service producer belongs is an NF set (NF set), and an identifier of the NF set is an NF set ID. An NF set ID of the service producer is the NF set ID of the NF set to which the service producer belongs.

For another example, when the service producer is an NF service, a producer set to which the service producer belongs is an NF service set (NF Service Set), where an identifier of the NF service set is an NF service set ID. An NF service set ID of the service producer is the NF service set ID of the NF service set to which the service producer belongs.

Therefore, when the service producer is an NF, the set to which the service producer belongs refers to the NF set to which the service producer belongs. The identifier of the NF set to which the service producer belongs refers to the NF set ID of the NF set to which the service producer belongs. In addition, when the service producer is an NF service, the set to which the service producer belongs refers to the NF service set to which the service producer belongs. The identifier of the NF service set to which the service producer belongs refers to the NF service set ID of the NF service set to which the service producer belongs.

The token request may also carry related information about the service producer (service producer). For example, the token request may further carry a type of a service producer and/or an identifier of the service producer_B (the identifier of the service producer_B may be, for example, an NF identifier of a service producer _B, and may be specifically, for example, an NF instance ID).

If the service producer is an NF, the identifier of the service producer_B may be the NF identifier (for example, the NF identifier is an NF instance ID) of the service producer_B. If the service producer_B is an NF service, the identifier of the service producer_B may be an NF service identifier of the service producer_B (the NF service identifier is specifically, for example, an NF service instance ID).

In some possible implementations, if the service producer belongs to an NF set (in this case, the service producer is an NF), the token request may carry the identifier (for example, the NF instance ID) of the service consumer_A and a service identifier of a requested service. In addition, the token request may further carry one or more of the following information: an NF type of the service producer_B, an NF set ID (NF set identifier) of the service producer _B, and the identifier of the service producer_B (for example, the NF instance ID of the service producer_B). The NF set ID of the service producer_B is an NF set ID of an NF set to which the service producer_B belongs.

In some other possible implementations, if the service producer_B belongs to an NF service set (in this case, the service producer_B is an NF service), the token request may carry the identifier (for example, the NF instance ID) of the service consumer_A and a service identifier of a requested service. In addition, the token request may further carry one or more of the following information: a service type of the service producer_B, the identifier of the service producer_B (for example, the NF service instance ID of the service producer_B), and an NF service set ID (NF service set ID) of the service producer_B. The NF service set ID of the service producer_B is an NF service set ID of the NF service set to which the service producer_B belongs.

<NUM>: The NRF receives the token request from the service consumer_A, and the NRF performs service authorization on the service consumer_A.

The performing service authorization on the service consumer _A may specifically include: obtaining information such as the identifier of the service consumer _A from the token request, and performing service authorization on the service consumer _A according to a locally configured authorization policy and/or authorization information.

In some possible implementations, when the service producer_B is an NF, if the token request carries the identifier of the service producer_B (but does not carry the NF set ID), after service authorization succeeds, the NRF may query the NF set ID of the NF set to which the service producer_B belongs based on the identifier of the service producer_B, and generate a token including the NF set ID of the service producer_B. Specifically, for example, an audience claim (Audience Claim) of the token may include the NF set ID of the service producer_B.

If the token request carries the NF set ID of the service producer_B, a step of querying the NF set ID of the NF set to which the service producer_B belongs based on the identifier of the service producer_B may be omitted. The token including the NF set ID of the service producer_B is generated directly. Specifically, for example, the audience claim (Audience Claim) of the token may include the NF set ID of the service producer_B.

When an audience claim of a token includes an NF set ID of an NF set to which a service producer belongs, it indicates that the token is a token at an NF set granularity, and the token may be used to access a service of each producer in the NF set to which the service producer belongs.

In some other possible implementations, when the service producer_B is an NF service, if the token request carries the identifier of the service producer (but does not carry the NF service set ID), after service authorization succeeds, the NRF may query the NF service set ID of the NF service set to which the service producer_B belongs based on the identifier of the service producer_B, and generate a token including the NF service set ID of the service producer_B. For example, a scope claim (Scope Claim) of the token may include the NF service set ID of the service producer_B. If the token request carries the NF service set ID of the service producer_B, a step of querying the NF service set ID of the NF service set to which the service producer_B belongs based on the identifier of the service producer_B may be omitted. The token including the NF service set ID of the service producer_B is generated directly. For example, the scope claim (Scope Claim) of the token may include the NF service set ID of the service producer_B.

When a scope claim of a token includes the NF service set ID of the NF service set to which the service producer_B belongs, it indicates that the token is a token at an NF service set granularity, and the token may be used to access a service of each producer in the NF service set to which the service producer_B belongs.

<NUM>: The NRF sends a token request response carrying the token to the service consumer_A (the token request response may be referred to as a token response for short).

<NUM>: The service consumer_A receives the token request response from the NRF, and the service consumer_A sends a service request to an SCP.

The service request sent by the service consumer_A carries the token, the identifier of the service consumer_A (for example, the NF instance ID of the service consumer_A), the identifier of the service producer_B (for example, the NF instance ID or the NF service instance ID of the service producer _B), and a service identifier of a requested service. The service request sent by the service consumer_A may further carry selection parameters.

<NUM>: The SCP receives the service request from the service consumer_A. The SCP selects a service producer_C from the producer set to which the service producer_B belongs (the service producer_C may be or may not be the same as the service producer_B).

The selecting the service producer_C from the producer set may specifically include: If the service request carries the selection parameters, the SCP may select the service producer_C from the producer set based on the selection parameters carried in the service request. In addition, if the service request does not carry the selection parameters, for example, the SCP may select the service producer_C from the producer set according to a locally configured related policy.

For example, when a service producer is an NF service, the service producer_C selected by the SCP from the producer set may be referred to as an NF service_C.

For example, when the service producer is an NF, the service producer_C selected by the SCP from the producer set may be referred to as an NF_C.

<NUM>: The SCP sends the service request carrying the token to the service producer _C.

The SCP may add, delete, and/or replace the information carried in the service request from the service consumer_A (for example, the SCP may delete the selection parameters carried in the service request), and then send the service request to the service producer_C. Certainly, the SCP may alternatively directly send the service request to the service producer_C without modifying the information carried in the service request from the service consumer_A.

<NUM>: The service producer_C receives the service request that carries the token and that is forwarded by the SCP. The service producer_C performs verification on the token.

The verification on the token specifically includes token integrity verification and token claim verification.

The token integrity verification may include: verifying token integrity by using a public key of the NRF or a shared key of the NRF.

After the token integrity verification succeeds, the token claim verification may include token audience claim verification.

The token audience claim verification may include: verifying whether an NF set ID included in the audience claim of the token is consistent with an NF set ID of an NF set to which the service producer_C that is found based on an identifier of the service producer_C belongs. If the two IDs are consistent, the audience claim verification succeeds. If the two IDs are inconsistent, the audience claim verification fails.

After the token integrity verification succeeds, the token claim verification may include token scope claim verification. The token scope claim verification may include: verifying whether an NF service set ID included in the scope claim of the token is consistent with an NF service set ID of an NF service set to which the service producer_C that is found based on the identifier of the service producer_C belongs. If the two IDs are consistent, the scope claim verification succeeds. If the two IDs are inconsistent, the scope claim verification fails.

In addition, the service producer_C may request the NRF to verify the token carried in the service request. For example, the service producer_C may send the token carried in the service request to the NRF, and request the NRF to verify the token. After verifying the token, the NRF returns a token verification result to the service producer_C (the result is that verification on the token succeeds or that verification on the token fails).

<NUM>: The service producer_C sends a response to the service request (for example, the response to the service request may be referred to as a service response for short) to the service consumer_A.

If verification on the token succeeds, the response may carry a service request success indication (in this case, the service producer_C agrees to provide a service for the service consumer_A).

If verification on the token fails, the response may carry a service request failure indication (in this case, the service producer_C refuses to provide a service for the service consumer _A).

<NUM>: After receiving the service response from the service producer_C, the SCP may forward the received service response to the service consumer_A.

<FIG> is a schematic flowchart of a communication method according to an embodiment of this application. The procedure shown in <FIG> is a roaming scenario corresponding to the procedure in <FIG>. The communication method may include the following steps.

<NUM>: A service consumer_A sends a token (Token) request to a vNRF (the vNRF is an NRF in a visited network).

When the service consumer_A roams to the visited network, the service consumer_A may send the token (Token) request to the vNRF (the vNRF is the NRF in the visited network).

For information carried in the token request, refer to related description in step <NUM>.

<NUM>: The vNRF forwards the token request from an NF_A to an hNRF (the hNRF is an NRF in a home network). The hNRF receives the token request from the vNRF, and the hNRF performs service authorization on the service consumer _A and generates a token.

For a manner in which the hNRF performs service authorization on the service consumer_A and generates the token, refer to the manner in which the NRF performs service authorization on the service consumer_A and generates the token in step <NUM>.

<NUM>: The hNRF sends a token request response carrying the token to the NF_A through the vNRF (the token request response may be referred to as a token response for short).

<NUM>: The service consumer_A receives the token request response forwarded by the vNRF from the hNRF, and the service consumer_A sends a service request to a vSCP (the vSCP is an SCP in the visited network).

The service request sent by the service consumer_A carries the token, an identifier of the service consumer_A (for example, an NF instance ID of the service consumer _A), an identifier of a service producer_B (for example, an NF instance ID or an NF service instance ID of the service producer_B), and a service identifier of a requested service.

The service request sent by the service consumer _A may further carry selection parameters.

<NUM>: The vSCP receives the service request from the service consumer_A, and the vSCP forwards the service request from the service consumer _A to an hSCP (the hSCP is an SCP in the home network).

<NUM>: The hSCP receives the service request forwarded by the vSCP from the service consumer_A.

The hSCP selects a service producer_C from a producer set to which the service producer_B belongs (the service producer_C may be or may not be the same as the service producer _B).

The selecting the service producer_C from the producer set may specifically include: If the service request carries the selection parameters, the hSCP may select the service producer_C from the producer set based on the selection parameters carried in the service request. In addition, if the service request does not carry the selection parameters, for example, the hSCP may select the service producer_C from the producer set according to a locally configured related policy.

For example, when a service producer is an NF service, the service producer_C selected by the hSCP from the producer set may be referred to as an NF service_C.

For example, when the service producer is an NF, the service producer_C selected by the hSCP from the producer set may be referred to as an NF_C.

<NUM>: The hSCP sends the service request carrying the token to the service producer _C.

The hSCP may add, delete, and/or replace the information carried in the service request from the service consumer_A (for example, the hSCP may delete the selection parameters carried in the service request), and then send the service request to the service producer_C. Certainly, the hSCP may also directly send the service request to the service producer_C without modifying the information carried in the service request from the service consumer_A.

<NUM>: The service producer_C receives the service request that carries the token and that is forwarded by the hSCP.

The service producer_C performs verification on the token. For a specific manner of verification on the token, refer to related description in step <NUM>.

In addition, the service producer_C may request an NRF to verify the token carried in the service request. For example, the target service producer_C may send the token carried in the service request to the NRF, and request the NRF to verify the token. After verifying the token, the NRF returns a token verification result to the service producer_C (the result is that verification on the token succeeds or that verification on the token fails).

If verification on the token succeeds, the response may carry a service request success indication (in this case, the service producer_C agrees to provide a service for the service consumer _A).

<NUM>: After receiving the service response from the service producer_C, the hSCP forwards the received service response to the service consumer _A through the vSCP.

It may be understood that the token claims in this embodiment of this application further include other information, for example, may further include one or more of the following information: a service type of the provider, a service type of the consumer, S-NSSAI, an NF set ID, a service instance set ID, a service zone ID, a service area, a DNN, a TAI, a PLMN ID, location information of the target NF or NF service. Information included in the token claims in the following embodiments may also be the same, and details are not described again in the following embodiments.

In the solutions shown in <FIG> and <FIG>, after service authorization, the NRF may query an NF set ID of a producer, and generate a token based on the NF set ID of the producer. After selecting the producer, the SCP sends the token to a selected producer_C (for example, an NF_C). The producer_C verifies an NF set ID of an audience claim in the token. This implements authorization based on an NF set granularity, resolves a problem that different producers in an NF set verify tokens, and implements authorization in a set scenario in an eSBA.

In the solutions shown in <FIG> and <FIG>, after performing authorization according to a locally configured policy or authorization information, the NRF queries whether the producer is located in a set, and generates a token at a set granularity, where a token audience claim includes a set ID. After the token is sent to a service producer NF_C selected by the SCP along with the service request, the NF_C verifies the set ID included in the token audience claim.

<FIG> is a schematic flowchart of another communication method according to an embodiment of this application. In the solution shown in <FIG>, an SCP (or an NRF) may perform verification on a token.

As shown in <FIG>, the communication method may include the following steps.

<NUM>: A service consumer _A sends a token (Token) request to an NRF.

<NUM>: The NRF receives the token request from the service consumer_A, and the NRF performs service authorization on the service consumer_A and generates a token.

<NUM>: The NRF sends a token request response carrying the token to the service consumer _A (the token request response may be referred to as a token response for short).

<NUM>: The service consumer _A receives the token request response from the NRF, and the service consumer_A sends a service request to an SCP.

For related detailed description of steps <NUM> to <NUM>, refer to related detailed description of steps <NUM> to <NUM>.

<NUM>: The SCP receives the service request from the service consumer_A.

The SCP performs verification on the token. The verification on the token specifically includes token integrity verification and token claim verification.

The token audience claim verification may include: verifying whether an NF set ID included in an audience claim of the token is consistent with an NF set ID of an NF set to which a service producer_C that is found based on an identifier of the service producer_C belongs. If the two IDs are consistent, the audience claim verification succeeds. If the two IDs are inconsistent, the audience claim verification fails.

After the token integrity verification succeeds, the token claim verification may include token scope claim verification. The token scope claim verification may include: verifying whether an NF service set ID included in a scope claim of the token is consistent with an NF service set ID of an NF service set to which the service producer_C that is found based on the identifier of the service producer_C belongs. If the two IDs are consistent, the scope claim verification succeeds. If the two IDs are inconsistent, the scope claim verification fails.

In addition, the SCP may further request the NRF to verify the token carried in the service request. For example, the SCP may send the token carried in the service request to the NRF, and request the NRF to verify the token. After verifying the token, the NRF returns a token verification result to the SCP (the result is that verification on the token succeeds or that verification on the token fails).

If verification on the token succeeds (the SCP performs verification on the token to obtain the token verification result, or the SCP requests the NRF to perform verification on the token and obtains the token verification result based on corresponding feedback from the NRF), the SCP selects the service producer_C from a producer set to which a service producer_B belongs (the service producer_C may be or may not be the same as the service producer _B).

The selecting the service producer_C from the producer set may specifically include: If the service request carries selection parameters, the SCP may select the service producer_C from the producer set based on the selection parameters carried in the service request. In addition, if the service request does not carry the selection parameters, for example, the SCP may select the service producer_C from the producer set according to a locally configured related policy.

In addition, if verification on the token fails, the SCP may send a response to the service request to a consumer_A, where the response may carry a service request failure indication (in this case, the service producer_C refuses to provide a service for the consumer _A). In this case, the service request failure indication may specifically indicate that a failure cause is that verification on the token fails.

<NUM>: The SCP sends the service request (the service request may carry or not carry the token) to the service producer_C. The SCP may add, delete, and/or replace information carried in the service request from the service consumer_A (for example, the SCP may delete the selection parameters carried in the service request), and then forward the service request to the NF_C. Certainly, the SCP may also directly forward the service request to the service producer_C without modifying the information carried in the service request from the service consumer_A.

<NUM>: The service producer_C receives the service request forwarded by the SCP. The service producer_C sends the response to the service request (for example, the response to the service request may be referred to as a service response for short) to the service consumer_A.

The response may carry a service request success indication (in this case, the service producer_C agrees to provide a service for the service consumer _A), or the response may carry a service request failure indication (in this case, the service producer_C refuses to provide a service for the service consumer _A).

In the solution of this embodiment, the SCP performs verification on the token (or the SCP entrusts token verification to a third party (for example, the NRF)), but the NF_C does not perform verification on the token. In this scenario, the NF_C trusts the SCP, that is, the SCP is a trusted SCP of the NF_C. A mechanism for establishing trust between the NF_C and the SCP is not described herein again.

In this embodiment, verification on the token is completed on the SCP, and the SCP determines, based on the token verification result, whether to select a producer and forward the service request. This helps further simplify a process.

<NUM>: A service consumer_A sends a token (Token) request to a vNRF.

<NUM>: The vNRF receives the token request from the service consumer_A, and forwards the token request to an hNRF. <NUM>: The hNRF receives the token request forwarded by the vNRF from the service consumer_A, and the hNRF performs service authorization and generates a token.

<NUM>: The hNRF sends a token request response carrying the token to the service consumer _A through the vNRF (the token request response may be referred to as a token response for short).

<NUM>: The service consumer_A receives the token request response forwarded by the vNRF from the hNRF, and the service consumer_A sends a service request carrying the token to a vSCP.

<NUM>: The vSCP receives the service request carrying the token from the service consumer_A, and the vSCP forwards the service request carrying the token from the service consumer_A to an hSCP.

<NUM>: The hSCP receives the service request carrying the token forwarded by the vSCP from the service consumer_A. The hSCP performs verification on the token. The verification on the token specifically includes token integrity verification and token claim verification.

If the verification on the token succeeds (an SCP performs verification on the token to obtain a token verification result, or the SCP requests an NRF to perform verification on the token and obtains the token verification result based on corresponding feedback from the NRF), the SCP selects a service producer_C from a producer set to which a service producer_B belongs (the service producer_C may be or may not be the same as the service producer _B).

<NUM>: The hSCP forwards the service request (the service request may carry or not carry the token) to the service producer _C.

<NUM>: The service producer_C receives the service request forwarded by the hSCP. The service producer_C may send a response to the service request (for example, the response to the service request may be referred to as a service response for short) to the service consumer _A through the hSCP and the vSCP.

In the solution of this embodiment, the hSCP performs verification on the token (or the hSCP entrusts token verification to a third party (for example, an hNRF)), but the NF_C does not perform verification on the token. In this scenario, the NF_C trusts the SCP, that is, the SCP is a trusted SCP of the NF_C. A mechanism for establishing trust between the NF_C and the SCP is not described herein again.

<FIG> is a schematic flowchart of another communication method according to an embodiment of this application. The communication method may include the following steps.

<NUM>: A service consumer_A sends a service request to an SCP.

The service request sent by the service consumer_A carries an identifier of the service consumer _A (for example, an NF instance ID of the service consumer_A), an identifier of a service producer_B (for example, an NF instance ID or an NF service instance ID of the service producer _B), and a service identifier of a requested service.

<NUM>: The SCP receives the service request from the service consumer_A, and the SCP performs service authorization on the service consumer_A.

The performing service authorization on the service consumer _A may specifically include: obtaining information such as the identifier of the service consumer_A from a token request, and performing service authorization on the service consumer _A according to a locally configured authorization policy and/or authorization information.

The SCP selects a service producer_C from a producer set to which the service producer_B belongs (the service producer_C may be or may not be the same as the service producer _B).

For example, when a service producer is an NF service, the service producer_C selected by the SCP from the producer set may be referred to as an NF service _C.

<NUM>: The SCP forwards the service request to the service producer_C.

<NUM>: The service producer_C receives the service request forwarded by the SCP. The service producer_C sends a response to the service request (for example, the response to the service request may be referred to as a service response for short) to the service consumer_A.

In this embodiment, the service producer_C trusts the SCP. Therefore, service authorization performed by the SCP is considered trustworthy.

<FIG> is a schematic flowchart of another communication method according to an embodiment of this application. The procedure shown in <FIG> is a roaming scenario corresponding to the procedure in <FIG>. The communication method may include the following steps.

<NUM>: A service consumer_A sends a service request to a vSCP.

<NUM>: The vSCP receives the service request from the service consumer_A, and the vSCP forwards the service request from the service consumer _A to an hSCP.

<NUM>: The hSCP receives the service request forwarded by the vSCP from the service consumer_A, and the hSCP performs service authorization.

The performing service authorization on the service consumer_A may specifically include: obtaining information such as the identifier of the service consumer_A from a token request, and performing service authorization on the service consumer_A according to a locally configured authorization policy and/or authorization information.

The hSCP selects a service producer_C from a producer set to which the service producer_B belongs (the service producer_C may be or may not be the same as the service producer_B).

<NUM>: The hSCP forwards the service request to the service producer _C.

<NUM>: The service producer_C receives the service request forwarded by the hSCP.

<NUM>: The service producer_C sends a response to the service request (for example, the response to the service request may be referred to as a service response for short) to the service consumer_A through the hSCP and the vSCP.

<NUM>: The SCP receives the service request from the service consumer_A, and the SCP performs service authorization on the service consumer _A and generates a token.

For a specific manner in which the SCP generates the token, refer to a manner in which an NRF generates a token.

In addition, if service authorization fails, the SCP may send a response to the service request to the service consumer_A, where the response may carry a service request failure indication (in this case, the service producer_C refuses to provide a service for the service consumer _A). In this case, the service request failure indication may specifically indicate that a failure cause is that service authorization fails.

<NUM>: The SCP forwards the service request carrying the token to the service producer_C.

The SCP may add, delete, and/or replace information (for example, the token) carried in the service request from the service consumer_A (for example, the SCP may delete the selection parameters carried in the service request), and then forward the service request to the service producer_C.

For a specific manner in which the service producer_C performs verification on the token, refer to related description in the embodiment shown in <FIG>.

In addition, the service producer_C may request an NRF to verify the token carried in the service request. For example, the service producer_C may send the token carried in the service request to the NRF, and request the NRF to verify the token. After verifying the token, the NRF returns a token verification result to the service producer_C (the result is that verification on the token succeeds or that verification on the token fails).

<NUM>: The service producer_C sends the response to the service request (for example, the response to the service request may be referred to as a service response for short) to the service consumer_A.

The service request sent by the service consumer_A carries an identifier of the service consumer_A (for example, an NF instance ID of the service consumer_A), an identifier of a service producer_B (for example, an NF instance ID or an NF service instance ID of the service producer _B), and a service identifier of a requested service.

<NUM>: The hSCP receives the service request forwarded by the vSCP from the service consumer_A, and the hSCP performs service authorization and generates a token.

For a specific manner in which the hSCP generates the token, refer to a manner in which an NRF generates a token.

In addition, if service authorization fails, the hSCP may send a response to the service request to the service consumer_A, where the response may carry a service request failure indication (in this case, the service producer_C refuses to provide a service for the service consumer_A). In this case, the service request failure indication may specifically indicate that a failure cause is that service authorization fails.

<NUM>: The hSCP forwards the service request carrying the token to the service producer_C.

The hSCP may add, delete, and/or replace information (for example, the token) carried in the service request from the service consumer_A (for example, the hSC may delete the selection parameters carried in the service request), and then forward the service request to the service producer _C.

<NUM>: The service producer_C receives the service request that carries the token and that is forwarded by the hSCP. The service producer_C performs verification on the token.

The service producer_C performs verification on the token.

It can be learned that, in solutions of some embodiments of this application, the NRF or the SCP may perform service authorization, or the NRF or the SCP may perform token generation, and a generated token may be at a set granularity. This can implement authorization in an indirect mode in which the SCP participates in an eSBA architecture when a producer is located in an NF/NF service set, or when a producer is an NF/NF service set. In this case, a consumer can use authorization information of another instance in a same set as the producer to access services of the producer. In addition, authorization in a roaming scenario can be implemented in the foregoing interactive mode.

The following further provides related device embodiments.

Refer to <FIG>. An embodiment of this application further provides a network repository function (NRF) <NUM>, including:.

For example, the token request carries one or more of the following information: an identifier of the service producer, or the NF set identifier of the service producer.

For example, the NRF may further include a processing unit <NUM>. The processing unit is configured to: if the token request carries the identifier of the service producer, obtain the NF set identifier of the service producer based on the identifier of the service producer, and generate a token including the NF set identifier of the service producer; or if the token request carries the NF set identifier of the service producer, generate a token including the NF set identifier of the service producer.

Alternatively, when the service producer is an NF service, a scope claim (Scope Claim) of the token includes an NF service set identifier of the service producer.

Refer to <FIG>. An embodiment of this application further provides an NRF, including:
a processor <NUM> and a memory <NUM> that are coupled to each other. The processor invokes a program stored in the memory, to perform the following steps: receiving a token (Token) request from a service consumer; and sending a token request response to the service consumer, where the token request response carries a token, and the token includes an NF set identifier or an NF service set identifier of a service producer (Service Producer).

Refer to <FIG>. An embodiment of this application further provides an SCP <NUM>, including:.

The service producer may be selected according to a local policy and/or other information (for example, selection parameters carried in the service request) from the NF set or the NF service set of the service producer.

For example, the SCP further includes a processing unit <NUM>, configured to verify the token included in the service request before sending the service request to the service producer in the NF set represented by the NF set identifier.

The sending unit is specifically configured to send the service request to a service producer in the NF set represented by the NF set identifier when verification on the token succeeds.

Refer to <FIG>. An embodiment of this application further provides an SCP <NUM>, including:
a processor <NUM> and a memory <NUM> that are coupled to each other. The processor <NUM> is configured to invoke a program stored in the memory <NUM>, to perform the following steps:
receiving a service request from a service consumer, where the service request carries a token (this token may be generated by an NRF), and the token includes an NF set identifier or an NF service set identifier of a service producer; and sending the service request to a service producer selected from an NF set or an NF service set of the service producer.

Refer to <FIG>. An embodiment of this application further provides a service producer <NUM>, including: a receiving unit <NUM>, configured to receive a service request sent by a service communication proxy (SCP), where the service request carries a token, and the token includes an NF set identifier of the service producer;.

For another example, the claim verification of the token may include: verifying whether the NF service set identifier of the service producer included in the scope claim of the token is consistent with an NF service set identifier of the selected service producer; and when the two NF service set identifiers are consistent, it indicates that scope claim verification of the token succeeds. For example, when the two NF service set identifiers are inconsistent, it indicates that the scope claim verification of the token fails.

For example, when verification on the token succeeds, the response to the service request sent by the service producer may carry a token verification success indication. When verification on the token fails, the response to the service request sent by the service producer may carry a token verification failure indication.

Refer to <FIG>. An embodiment of this application further provides a service producer <NUM>, including a processor <NUM> and a memory <NUM> that are coupled to each other. The processor invokes a program stored in the memory, to perform the following steps: receiving a service request sent by a service communication proxy (SCP), where the service request carries a token, and the token includes an NF set identifier of a service producer; verifying the token; and sending a response to the service request.

For example, the SCP is further configured to generate a token when service authorization on the service consumer succeeds. The service request sent by the SCP to the service producer carries the token, where the token includes an NF set identifier or an NF service set identifier of the service producer.

That the processing unit requests the NRF to perform service authorization on the service consumer includes:
sending an authorization request to the NRF, where the authorization request is used to request the NRF to perform service authorization on the service consumer; and receiving a response to the authorization request sent by the NRF, where the response to the authorization request carries a service authorization result of the service consumer from the NRF, and the service authorization result is that service authorization succeeds or that service authorization fails.

For example, the service request carries a service identifier of a requested service, and that the processing unit performs service authorization on the service consumer includes: determining, according to an authorization policy or authorization information locally configured by the SCP, whether the service consumer has permission to access the service that is represented by the service identifier and that is provided by the service producer.

Refer to <FIG>. An embodiment of this application further provides an SCP <NUM>, including a processor <NUM> and a memory <NUM> that are coupled to each other. The processor <NUM> invokes a program stored in the memory, to perform the following steps: receiving a service request from a service consumer; performing service authorization on the service consumer, or requesting an NRF to perform service authorization on the service consumer; and when service authorization on the service consumer succeeds, sending the service request to a service producer in a service producer set.

Refer to <FIG>. An embodiment of this application further provides a network repository function <NUM>, including:.

For example, the authorization request carries a service identifier of a requested service. The performing service authorization on the service consumer represented by the service consumer identifier includes: determining, according to an authorization policy or authorization information locally configured by the NRF, whether the service consumer has permission to access the service that is represented by the service identifier and that is provided by a service producer.

Refer to <FIG>. An embodiment of this application further provides a network repository function <NUM>, including a processor <NUM> and a memory <NUM> that are coupled to each other. The processor invokes a program stored in the memory, to perform the following steps: receiving, from a service communication proxy (SCP), an authorization request carrying a service consumer identifier; performing service authorization on a service consumer represented by the service consumer identifier; and sending a response to the authorization request to the SCP, where the response to the authorization request carries a service authorization result of the service consumer from the NRF, and the service authorization result is that service authorization succeeds or that service authorization fails.

Refer to <FIG>. An embodiment of this application further provides a service consumer <NUM>, including:.

The sending unit <NUM> is further configured to send a service request carrying the token to a service communication proxy (SCP), where the service request is used by the SCP or the service producer to verify the token.

The receiving unit <NUM> is further configured to receive a response to the service request sent by the SCP.

Refer to <FIG>. An embodiment of this application further provides a service consumer <NUM>, including a processor <NUM> and a memory <NUM> that are coupled to each other. The processor <NUM> invokes a program stored in the memory, to perform the following step: sending a token (Token) request to an NRF; receiving a token request response sent by the NRF, where the token request response carries a token, and the token includes an NF set identifier or an NF service set identifier of a service producer; sending a service request carrying the token to a service communication proxy (SCP), where the service request is used by the SCP or the service producer to verify the token; and receiving a response to the service request sent by the SCP.

Refer to <FIG>. An embodiment of this application further provides a service consumer <NUM>, including a processor <NUM> and a memory <NUM> that are coupled to each other. The processor <NUM> invokes a program stored in the memory, to perform the following steps: sending a service request to a service communication proxy (SCP), where the service request includes an NF set identifier or an NF service set identifier of a service producer, where the service request is used by the SCP or a network repository function (NRF) to perform service authorization on the service consumer; and receiving a service response to the service request sent by the SCP.

An embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and the computer program is executed by hardware (for example, a processor), to perform some or all of the steps of any method performed by any device in the embodiments of this application.

An embodiment of this application further provides a computer program product including instructions. When the computer program product is run on a computer device, the computer device is enabled to perform some or all of the steps of any method in the foregoing aspects.

All or some of the foregoing embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, the embodiments may be implemented completely or partially in a form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the procedures or functions according to the embodiments of this application are all or partially generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or other programmable apparatuses. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line) or wireless (for example, infrared, radio, or microwave) manner. The computer-readable storage medium may be any usable medium accessible by a computer, or a data storage device, such as a server or a data center, integrating one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, an optical disc), a semiconductor medium (for example, a solid state drive), or the like. In the foregoing embodiments, description of the embodiments has respective focuses. For a part that is not described in detail in an embodiment, refer to related description in other embodiments.

In the foregoing embodiments, the description of the embodiments has respective focuses. For a part that is not described in detail in an embodiment, refer to related description in other embodiments.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the division into units is merely logical function division and may be other division in actual implementation. In addition, the displayed or discussed mutual indirect couplings, direct couplings, or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic or other forms.

The units described as separate parts may or may not be physically separate. Parts displayed as units may or may not be physical units, and may be located in one position or may be distributed on a plurality of network units.

Claim 1:
A communication method, comprising:
receiving (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>), by a network repository function (<NUM>, <NUM>) a token request from a service consumer (<NUM>, <NUM>); and
sending (<NUM>, <NUM>, <NUM>), by the network repository function (<NUM>, <NUM>), a token request response to the service consumer (<NUM>, <NUM>), wherein the token request response carries a token, characterized in that the token comprises a network function set identifier of a service producer (<NUM>, <NUM>) and is a token for a network function set of the service producer.