Communication method and communication device

Abstract

[0009] An embodiment of the present application provides a communication method and a communication device. The method includes a step in which a second network function network element receives a service request message from a first network function network element and determines whether to provide a service to the first network function network element based on a first token. The service request message is used to request the second network function network element to provide a service to the first network function network element, and the service request message includes a first token and second service domain information, where the second service domain information indicates a service area of ​​the service requested by the first network function network element, and the first token includes the first service domain information, where the first service domain information indicates a service area range in which the first network function network element can obtain the service from the second network function network element. In the solution of the present application, the first service domain information is added to the first token to reduce or prevent the first network function network element from accessing the service without authorization, thereby ensuring network security.

Description

[Technical Field]

[0001] This application claims priority to Chinese Patent Application No. 202310223101.4, entitled "Communication Method and Communication Apparatus," filed with the State Intellectual Property Office of the People's Republic of China on February 28, 2023, which is incorporated herein by reference in its entirety.

[0002] The present application relates to the field of communications, and more particularly to communication methods and devices. [Background technology]

[0003] In a service-based architecture (SBA), network functions (NFs) interact with each other through service-based interfaces. For example, after obtaining an access token, a network function service consumer (NFc) may request a service from a network function service producer (NFp). To improve communication security, the NFp needs to perform an authorization check for the service requested by the NFc based on the access token, i.e., check whether the NFc is authorized to use the requested service.

[0004] However, with the current OAuth authentication mechanism, NFc may use the access token to access services without authorization, and as a result, network security cannot be guaranteed. Therefore, additional countermeasures are urgently needed to mitigate potential security risks. Summary of the Invention

[0005] The present application provides a communication method and a communication device for preventing malicious network function service consumers from obtaining services by using access tokens without authorization, so as to ensure network security. [Means for solving the problem]

[0006] According to a first aspect, a communication method is provided. The method may be performed by a second network function network element, or may be performed by a chip or circuit used in the second network function network element. This is not limited in the present application. For ease of explanation, an example in which the method is performed by the second network function network element is used for the following description.

[0007] The method includes the steps of: a second network function network element receiving a service request message from a first network function network element, the service request message being used to request the second network function network element to provide a service to the first network function network element, the service request message including a first token and second service domain information, the second service domain information indicating a service area of ​​the service requested by the first network function network element, the first token including the first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain the service from the second network function network element; and the second network function network element determining whether to provide a service to the first network function network element based on the first token.

[0008] According to the solution provided in the present application, in a process in which a first network function network element requests a service from a second network function network element, the second network function network element determines whether to provide a service to the first network function network element based on the first service domain information in the first token carried in the service request message, so that a malicious NF service consumer can be prevented from obtaining a service by using the first token without authorization, thereby ensuring network security.

[0009] For example, the service that the first network function network element requests the second network function network element to provide may be any one of services such as a data collection service, a model acquisition service, a protocol data unit (PDU) session service, a session management (SM) policy control service, a registration service, etc.

[0010] In relation to the first aspect, in some implementation forms of the first aspect, if the service is a data collection service, the first service domain information indicates an area range in which the first network function network element can acquire data from the second network function network element, or if the service is a model acquisition service, the first service domain information indicates an area range in which the first network function network element can acquire a model from the second network function network element.

[0011] A service area range for acquiring a service may be understood as an area range for acquiring service-compatible resources of the service. For a resource acquisition service, a service area range for a service may be understood as an area range for acquiring service-compatible resources of the service. For example, if the resource is data, a model, a protocol data unit, etc., the service area range of the service may be an area range for acquiring corresponding data, an area range for acquiring a model, an area range for acquiring a protocol data unit, etc. In other words, a first network function network element can acquire data or models within its service area range, or the first network function network element has permission to request a second network function network element to provide data or models within its service area range.

[0012] For example, the service area range of a data collection service indicates the service area range of data that can be obtained by a first network function network element by using the data collection service. In other words, the first network function network element has permission to request a second network function network element to provide data within its service area range.

[0013] For example, the service area range of a model acquisition service indicates the area range of a model that can be acquired by a first network function network element by using the model acquisition service. In other words, the first network function network element has permission to request a second network function network element to provide a model within its service area range.

[0014] The second network function network element may be a service providing network element, and the first network function network element may be a service requesting network element. The second network function network element determining whether to provide a service to the first network function network element based on the first token may be understood as the second network function network element determining whether the first network function network element is authorized to use the service based on the first service domain information in the first token, or the second network function network element determining to provide a service to the first network function network element or to refuse to provide a service to the first network function network element based on the first service domain information in the first token, or the second network function network element providing the requested service (or performing the service) and sending a response message, or sending a response message indicating that the service request has failed, based on the first service domain information in the first token, or the second network function network element providing the requested service (or performing the service) and sending a response message, or sending a response message indicating that the service request has been refused, based on the first service domain information in the first token.

[0015] A specific expression form of determining whether the second network function network element provides a service to the first network function network element may be as follows: if the first network function network element is authorized to use the service, the second network function network element provides the service to the first network function network element, or if the first network function network element is not authorized to use the service, the second network function network element rejects the service request message to reject the first network function network element requesting the service.

[0016] For example, the first service domain information includes one or more of service area information, serving cell information, area of ​​interest information, tracking area identity information, etc. The first token may include an Additional Scope field and a Claims field. Optionally, the Additional Scope field includes the first service domain information, or the first service domain information is carried in a separate information element. This is not limited in the present application.

[0017] In relation to the first aspect, in some implementations of the first aspect, the step of determining whether the second network function network element will provide a service to the first network function network element based on the first token includes the step of the second network function network element performing verification on the first token, and if the verification on the first token is successful, determining that the second network function network element will provide a service to the first network function network element.

[0018] Based on this implementation, the second network function network element may provide a service to the first network function network element if the verification of the first token is successful, which can prevent a malicious NF service consumer from obtaining a service by using the first token without authorization, thereby reducing potential security risks.

[0019] In relation to the first aspect, in some implementation forms of the first aspect, the step of the second network function network element performing verification on the first token includes the step of the second network function network element performing verification against integrity protection of the first token, and if the verification against integrity protection of the first token is successful, the step of the second network function network element determining whether the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information, and if the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information, the step of the second network function network element determining that the verification on the first token is successful.

[0020] It should be understood that security protection, e.g., integrity protection, is performed on the first token so that a malicious NF service consumer can be prevented from tampering with the parameters in the first token.

[0021] Based on this implementation, the second network function network element determines whether the first network function network element is authorized to use the service or whether to provide the service to the first network function network element based on whether the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information, thereby preventing malicious NF service consumers from obtaining the service by using the first token without authorization, thereby reducing potential security risks.

[0022] In relation to the first aspect, in some implementation forms of the first aspect, when the first network function network element is a data collection coordination function network element, the service request message further includes a client credentials assertion (CCA), where the CCA includes an identifier of the third network function network element and third service domain information, and the third service domain information indicates a service area of ​​the service requested by the third network function network element.

[0023] Based on this implementation, it will be understood that the third network function network element requests to obtain a data collection service from the second network function network element by using the data collection coordination function network element, and the CCA is used by the second network function network element to perform identity verification to the third network function network element.

[0024] In relation to the first aspect, in some implementation forms of the first aspect, the second network function network element determines whether to provide service to the first network function network element based on the CCA. Specifically, the second network function network element determines whether the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA. If the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA, the second network function network element determines that the verification of the CCA is successful and then determines to provide service to the first network function network element.

[0025] Based on this implementation, a verification is added to check whether the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA, to verify whether a third party entity (e.g., a data collection and coordination function network element) as a forwarder of the service request message maliciously tampers with the request of the third network function network element, thereby preventing malicious NF service consumers from obtaining services without authorization, thereby further ensuring network communication security and reducing potential security risks.

[0026] In other words, if the service request message includes a first token, the second network function network element determines whether to provide a service (e.g., data or a model) to the first network function network element based on the first token. Furthermore, if the service request message further includes a CCA, the second network function network element may further determine whether to provide a service to the first network function network element based on the CCA, to strengthen security verification, prevent malicious NF service consumers from obtaining services without authorization, and improve communication reliability.

[0027] In relation to the first aspect, in some implementation forms of the first aspect, the service request message further includes an identifier of the first network function network element, and the first token further includes an identifier of the first network function network element and an identifier of the third network function network element, and the step of the second network function network element performing verification on the first token includes the second network function network element determining whether the identifier of the third network function network element carried in the first token is the same as the identifier of the third network function network element carried in the CCA, and whether the identifier of the first network function network element carried in the first token is the same as the identifier of the third network function network element carried in the CCA. The method further includes determining whether an identifier of the network function network element of the first token is the same as an identifier of the first network function network element carried in the service request message, and if the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the CCA and the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message, the second network function network element determining that verification on the first token is successful.

[0028] Based on this implementation, a verification is added to the network element identifier, i.e., a verification is performed to check whether the identifier of the third network function network element carried in the first token is the same as the identifier of the third network function network element carried in the CCA, and a verification is performed to check whether the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message, which can prevent malicious NF service consumers from obtaining services without authorization, thereby further ensuring network communication security and reducing potential security risks.

[0029] In relation to the first aspect, in some implementations of the first aspect, the first token further includes another verification condition, and the method further includes a step of determining whether the second network function network element provides a service to the first network function network element based on the another verification condition, wherein the another verification condition includes one or more of the following: a service provider's NF instance identifier, a service provider's NF type, a service provider's single network slice selection assistance information, a service provider's network slice instance identifier, an expected identifier of the NF set to which the service provider belongs, an expected service name, and a validity period of the first token.

[0030] According to this implementation, the second network function network element adds a verification against another verification condition, and determines whether to provide a service to the first network function network element based on whether the verification is successful, thereby effectively ensuring network communication security and preventing a malicious NF service consumer from obtaining a service by using the first token without authorization.

[0031] In relation to the first aspect, in some implementations of the first aspect, if verification based on another verification condition is successful, the second network function network element determines that verification for the first token is successful.

[0032] Based on this implementation, a case is added in which verification based on service area information is successful and verification based on another verification condition is successful, so that malicious NF service consumers can be more effectively prevented from obtaining services by using the first token without authorization, thereby further ensuring network communication security and reducing or even avoiding potential security risks.

[0033] In relation to the first aspect, in some implementations of the first aspect, if any one of the following conditions is met, the second network function network element determines that verification of the first token has failed, and the second network function network element refuses to provide service to the first network function network element. The conditions include one or more of the following: a service area indicated by the second service domain information is outside a service area range indicated by the first service domain information; a service area indicated by the second service domain information is outside a service area range indicated by the third service domain information carried in the CCA; an identifier of the third network function network element carried in the first token is different from an identifier of the third network function network element carried in the CCA; an identifier of the first network function network element carried in the first token is different from an identifier of the first network function network element carried in the service request message; or verification based on another verification condition has failed.

[0034] A specific expression form of the second network function network element refusing to provide service to the first network function network element may be that the second network function network element sends a service response message to the first network function network element, and the service response message indicates that the provision of the service is denied, or the response message indicates that the service request has failed. Optionally, the service response message further includes a reason for the refusal. For example, the reason for the refusal may be that verification of the first token has failed, or that the service area indicated by the second service domain information is outside the service area range indicated by the first service domain information.

[0035] Based on this implementation, in the process of performing verification on the first token, if any one of the above cases occurs, it may be determined that the verification on the first token has failed, and the provision of the service is denied. In this way, malicious NF service consumers can be more effectively prevented from obtaining services by using the first token without authorization, thereby further ensuring network communication security and reducing or even avoiding potential security risks.

[0036] In relation to the first aspect, in some implementation forms of the first aspect, the first service domain information indicates a service area range allowed by the ability to obtain a service by the first network function network element, or the first service domain information indicates a service area range in which the authorization function network element authorizes the first network function network element to obtain a service, or the first service domain information indicates an authorized service area range of a service authorized to the first network function network element.

[0037] Optionally, the first service domain information may be determined based on a service request scope carried in the token request message of the first network function network element, or the first service domain information may be determined by the authorization function network element based on an ability to obtain a service by the first network function network element, which is indicated by an NF Profile stored locally on the first network function network element, which is not limited in the present application.

[0038] Based on this implementation, the first service domain information is carried in the first token to ensure that, when subsequently receiving a service request of the first network function network element, the second network function network element can determine whether to provide service to the first network function network element by performing verification on the first service domain information, thereby preventing malicious NF service consumers from obtaining service by using the first token without authorization, thereby further ensuring network communication security and reducing or even avoiding potential security risks.

[0039] In relation to the first aspect, in some implementation forms of the first aspect, the service area indicated by the second service domain information is included in the service area range indicated by the first service domain information.

[0040] Based on this implementation, the service area indicated by the second service domain information is restricted to be included in the service area range indicated by the first service domain information, and the service area indicated by the second service domain information is restricted to be included in the service area range indicated by the third service domain information, thereby preventing unauthorized access by the first network function network element to ensure that the second network function network element can continue to successfully verify the first token and provide services to the first network function network element, thereby improving user experience.

[0041] According to a second aspect, a communication method is provided. The method may be performed by a first network function network element, or may be performed by a chip or circuit used in the first network function network element. This is not limited in the present application. For ease of explanation, an example in which the method is performed by the first network function network element is used for the following description.

[0042] The method includes the steps of: a first network function network element obtaining a first token, the first token including first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain service from a second network function network element; the first network function network element sending a service request message to the second network function network element, the service request message being used to request the second network function network element to provide a service to the first network function network element, the service request message including the first token and second service domain information, the second service domain information indicating a service area of ​​the service requested by the first network function network element; and the first network function network element receiving the service from the second network function network element.

[0043] For example, the service requested by the first network function network element may be a data collection service or a model acquisition service. If the service is a data collection service, the first service domain information indicates an area range in which the first network function network element can acquire data from the second network function network element, or if the service is a model acquisition service, the first service domain information indicates an area range in which the first network function network element can acquire a model from the second network function network element.

[0044] According to the solution provided in the present application, in a process in which a first network function network element requests a service from a second network function network element, the second network function network element determines whether to provide a service to the first network function network element based on the first service domain information in the first token carried in the service request message, so that a malicious NF service consumer can be prevented from obtaining a service by using the first token without authorization, thereby ensuring network security.

[0045] In relation to the second aspect, in some implementations of the second aspect, the step of the first network function network element obtaining the first token includes the step of the first network function network element sending a token request message to an authorizer network element, where the token request message includes an identifier of the service, an identifier of the first network function network element, and an identifier of the second network function network element or a network element type of the second network function network element; and the step of the first network function network element receiving the first token from the authorizer network element.

[0046] Based on this implementation, upon verifying that the first network function network element is authorized, the authorization function network element generates and sends a first token to the first network function network element, so that the first network function network element can request a service from the second network function network element by using the first token, thereby improving the user experience.

[0047] In relation to the second aspect, in some implementation forms of the second aspect, the token request message further includes fourth service domain information, where the fourth service domain information indicates a service area of ​​the service requested by the first network function network element, or the fourth service domain information indicates a service area for which the first network function network element requests the authorization function network element to authorize the service.

[0048] Based on this implementation, the fourth service domain information is carried in the token request message, so that the authorization function network element can generate the first token in a targeted manner after verifying that the first network function network element is authorized. In this case, the first service domain information in the first token can reduce subsequent potential risks caused by malicious attacks on the first network function network element.

[0049] In relation to the second aspect, in some implementation forms of the second aspect, the token request message further includes a CCA, where the CCA includes an identifier of the third network function network element and third service domain information, and the third service domain information indicates a service area of ​​the service requested by the third network function network element.

[0050] In relation to the second aspect, in some implementations of the second aspect, the service request message further includes a CCA.

[0051] It should be understood that this implementation is primarily applicable to a scenario in which a first network function network element acts as a third party entity and requests a second network function network element to provide a service to a third network function network element.

[0052] Based on this implementation, the CCA carried in the service request message may be used by the second network function network element to perform identity verification to the third network function network element, so that a malicious NF service consumer can be prevented from obtaining a service by using the first token without authorization, thereby ensuring network security.

[0053] In relation to the second aspect, in some implementation forms of the second aspect, the first service domain information indicates a service area range allowed by the ability to obtain a service by the first network function network element, or the first service domain information indicates a service area range in which the authorization function network element authorizes the first network function network element to obtain a service, or the first service domain information indicates an authorized service area range of a service authorized to the first network function network element.

[0054] In relation to the second aspect, in some implementation forms of the second aspect, the service area indicated by the second service domain information is included in the service area range indicated by the first service domain information.

[0055] For the beneficial effects of the second aspect and some implementation forms of the second aspect, please refer to the relevant description of the first aspect, and the details will not be described again here.

[0056] According to a third aspect, a communication method is provided. The method may be performed by an authorization function network element (e.g., NRF), or may be performed by a chip or circuit used in the authorization function network element. This is not limited in the present application. For ease of explanation, an example in which the method is performed by the authorization function network element is used for the following description.

[0057] The method includes the steps of: receiving, by an authorizer network element, a token request message from a first network function network element, the token request message including an identifier of a service, an identifier of the first network function network element, and an identifier of a second network function network element or a type of the second network function network element; generating a first token when the authorizer network element determines that the first network function network element is authorized to obtain a service from the second network function network element, the first token including first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain the service from the second network function network element; and transmitting, by the authorizer network element, the first token to the first network function network element.

[0058] According to the solution provided in the present application, when the first network function network element determines that it is authorized to obtain a service from the second network function network element, the authorization function network element generates and sends a first token to the first network function network element, so that the second network function network element subsequently determines whether to provide the service based on the first token, thereby preventing malicious NF service consumers from obtaining a service by using the first token without authorization, and thereby ensuring network security.

[0059] For example, the authorizing function network element may perform security protection on the generated first token. The security protection in this specification may be integrity protection. For example, the authorizing function network element may generate a message authentication code (MAC) for the first token by using a shared key. The authorizing function network element may send the MAC and the first token together to the NFc, and the MAC is used to verify whether the information in the first token has been tampered with. Alternatively, the authorizing function network element may sign claims by using a private key, and the NFp may verify whether the claims have been tampered with by using the signature. It should be understood that the security protection is performed on the first token so that a malicious NF service consumer can be prevented from tampering with parameters in the first token.

[0060] In relation to the third aspect, in some implementation forms of the third aspect, the token request message further includes fourth service domain information, where the fourth service domain information indicates a service area of ​​the service requested by the first network function network element, or the fourth service domain information indicates a service area for which the first network function network element requests the authorization function network element to authorize the service.

[0061] In relation to the third aspect, in some implementation forms of the third aspect, the token request message further includes a CCA, where the CCA includes an identifier of the third network function network element and third service domain information, and the third service domain information indicates a service area of ​​the service requested by the third network function network element.

[0062] In relation to the third aspect, in some implementation forms of the third aspect, the step of the authorization function network element generating the first token includes the step of the authorization function network element determining whether the service area indicated by the fourth service domain information is included in the service area range indicated by the third service domain information carried in the CCA, and the step of generating the first token when the authorization function network element determines that the service area indicated by the fourth service domain information carried in the token request message is included in the service area range indicated by the third service domain information carried in the CCA.

[0063] Based on this implementation, a verification is added to check whether the service area indicated by the fourth service domain information belongs to the service area range indicated by the third service domain information carried in the CCA, to verify whether a third party entity (e.g., a data collection and coordination function network element) as a forwarder of the service request message maliciously tampers with the request of the third network function network element, thereby preventing a malicious NF service consumer from obtaining a service by using the first token without authorization, thereby further ensuring network communication security and reducing potential security risks.

[0064] In relation to the third aspect, in some implementation forms of the third aspect, the first service domain information indicates a service area range allowed by the ability to obtain a service by the first network function network element, or the first service domain information indicates a service area range in which the authorization function network element authorizes the first network function network element to obtain a service, or the first service domain information indicates an authorized service area range of a service authorized to the first network function network element.

[0065] For the beneficial effects of the third aspect and some implementation forms of the third aspect, please refer to the relevant descriptions of the first aspect accordingly, and the details will not be described again here.

[0066] According to a fourth aspect, a second network function network element is provided. The apparatus includes: a receiving unit used by the second network function network element to receive a service request message from a first network function network element, the service request message being used by the second network function network element to request the second network function network element to provide a service to the first network function network element, the service request message including a first token and second service domain information, the second service domain information indicating a service area of ​​data requested by the first network function network element, the first token including the first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain service from the second network function network element, the receiving unit being configured to determine whether to provide a service to the first network function network element based on the first token; and a processing unit configured to determine whether to provide a service to the first network function network element based on the first token.

[0067] The transceiver unit may perform reception and transmission in the first aspect, and the processing unit may perform processing other than reception and transmission in the first aspect.

[0068] According to a fifth aspect, a first network function network element is provided, the first network element including: a processing unit configured to obtain a first token, the first token including first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain service from a second network function network element; and a transceiver unit configured to send a service request message to the second network function network element, the service request message being used to request the second network function network element to provide a service to the first network function network element, the service request message including the first token and the second service domain information, the second service domain information indicating a service area of ​​the service requested by the first network function network element. The transceiver unit is further configured to receive the service from the second network function network element.

[0069] The transceiver unit may perform reception and transmission in the second aspect, and the processing unit may perform processing other than reception and transmission in the second aspect.

[0070] According to a sixth aspect, an authorization function network element is provided. The network element includes: a transceiver unit configured to receive a token request message from a first network function network element, the token request message including an identifier of a service, an identifier of the first network function network element, and an identifier of a second network function network element or a type of the second network function network element; and a processing unit configured to generate a first token when determining that the first network function network element is authorized to obtain a service from the second network function network element, the first token including first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain the service from the second network function network element. The transceiver unit is further configured to transmit the first token to the first network function network element.

[0071] The transceiver unit may perform the reception and transmission in the third aspect, and the processing unit may perform processing other than the reception and transmission in the third aspect.

[0072] According to a seventh aspect, there is provided a communication device including a transceiver, a processor, and a memory. The processor is configured to control the transceiver to transmit and receive signals. The memory is configured to store a computer program. The processor is configured to call and execute the computer program from the memory to cause the communication device to perform any one of the methods of the first to third aspects and any possible implementation forms of the first to third aspects.

[0073] Optionally, there are one or more processors and one or more memories.

[0074] Optionally, the memory may be integrated with the processor, or the memory and the processor may be located separately.

[0075] Optionally, the communication device further includes a transmitter (sender) and a receiver (receiver).

[0076] According to an eighth aspect, there is provided a communication system including one or more of the aforementioned first network function network element, second network function network element, and authorization function network element.

[0077] According to a ninth aspect, there is provided a computer-readable storage medium. The computer-readable storage medium stores a computer program or code. When the computer program or code is executed on a computer, the computer is caused to perform any one of the methods of the first to third aspects and any possible implementation forms of the first to third aspects.

[0078] According to a tenth aspect, there is provided a chip including at least one processor, the at least one processor being coupled to a memory configured to store a computer program, the processor being configured to call the computer program from the memory and execute the computer program to cause a communication device having the chip system installed therein to perform any one of the methods of the first to third aspects and any possible implementation forms of the first to third aspects.

[0079] The chip may include input circuits or interfaces for transmitting information or data and output circuits or interfaces for receiving information or data.

[0080] According to an eleventh aspect, there is provided a computer program product, the computer program product including computer program code that, when executed on a communication device, causes the communication device to perform any one of the methods of the first to third aspects and any possible implementations of the first to third aspects. [Brief explanation of the drawings]

[0081] [Figure 1] 1 is a diagram of a network architecture 100 to which embodiments of the present application are applicable. [Figure 2] 2 is a schematic flowchart of a token request method and a service request method 200 according to an embodiment of the present application. [Figure 3] 3 is a schematic flowchart of a model sharing method 300 according to an embodiment of the present application. [Figure 4] 4 is a schematic flowchart of another model sharing method 400 according to an embodiment of the present application. [Figure 5] 5 is a schematic flowchart of a communication method 500 according to an embodiment of the present application. [Figure 6] 6 is a schematic flowchart of a communication method 600 according to an embodiment of the present application. [Figure 7] 7 is a schematic flowchart of a communication method 700 according to an embodiment of the present application. [Figure 8] 8 is a schematic flowchart of a communication method 800 according to an embodiment of the present application. [Figure 9] 1 is a diagram of the structure of a communication device 1000 according to an embodiment of the present application. [Figure 10] FIG. 20 is a diagram of the structure of another communication device 2000 according to an embodiment of the present application. [Figure 11] FIG. 3 is a diagram of the structure of a chip system 3000 according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0082] The following describes the technical solutions of the present application with reference to the accompanying drawings.

[0083] The technical solutions provided in this application may be applied to various communication systems, such as new radio (NR) systems, long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, and LTE time division duplex (TDD) systems. The technical solutions provided in this application may further be applied to device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine (M2M) communication, machine type communication (MTC), internet of things (IoT) communication systems, or other communication systems.

[0084] In a communication system, the portion operated by an operator may be called a public land mobile network (PLMN) or an operator network. A PLMN is a network established and operated by a government or an operator authorized by the government to provide public land mobile communication services, and is primarily a public network over which a mobile network operator (MNO) provides mobile broadband access services for users. The PLMN described in the embodiments of the present application may specifically be a network that complies with the requirements of the 3rd generation partnership project (3GPP®) standard, commonly referred to as a 3GPP® network. 3GPP® networks typically include, but are not limited to, 5G networks, 4th-generation (4G) networks, and other future communication systems, such as 6th-generation (6G) networks.

[0085] For ease of explanation, a 5G network is used as an illustrative example in the embodiments of the present application.

[0086] 1 is a diagram of a network architecture 100 to which an embodiment of the present application can be applied. As shown in FIG. 1, the network architecture may specifically include three parts: a terminal device part, a data network (DN) part, and an operator network PLMN part. The functions of the network elements in each part will be briefly described below.

[0087] The terminal device portion may include a terminal device 110, which may also be referred to as user equipment (UE). The terminal device 110 in this application is a device having wireless transmission and reception capabilities and may communicate with one or more core network (CN) devices via an access network device (alternatively, may be referred to as an access device) in a radio access network (RAN) 140. The terminal device 110 may also be referred to as an access terminal, terminal, subscriber unit, subscriber station, mobile station, remote station, remote terminal, mobile device, user terminal, user agent, user equipment, etc. The terminal device 110 may be deployed on land, including an indoor terminal device, an outdoor terminal device, a handheld terminal device, or a vehicle-mounted terminal device, or may be deployed on water (e.g., on a ship) or in the air (e.g., on an aircraft, balloon, or satellite). The terminal device 110 may be a cellular phone, an unmanned aerial vehicle, an intelligent vehicle, a cordless phone, a session initiation protocol (SIP) phone, a smartphone, a mobile phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), etc. Alternatively, the terminal device 110 may be a handheld device with wireless communication capabilities, a computing device or another device connected to a wireless modem, an in-vehicle device, a wearable device, an unmanned aerial vehicle device, a terminal in the Internet of Things or Internet of Vehicles, any form of terminal in 5G networks and future networks, relay user equipment, a terminal in a future evolved 6G network, etc. The relay user equipment may be, for example, a 5G residential gateway (RG).For example, the terminal device 110 may be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. The terminal device here is a 3GPP (registered trademark) terminal. The type, category, etc. of the terminal device are not limited in the embodiments of the present application. For ease of description, an example in which a UE represents a terminal device is used in the following description in this application.

[0088] The operator network PLMN portion may include, but is not limited to, a radio access network (RAN) 120 and a core network CN portion.

[0089] The (R)AN 120 can be considered a subnetwork of an operator network and is an implementation system between a service node in the operator network and the terminal device 110. To access the operator network, the terminal device 110 may first go through the (R)AN 120 and then connect to a service node in the operator network via the (R)AN 120. An access network device (RAN device) in an embodiment of the present application is a device that provides wireless communication capabilities to the terminal device 110 and may also be referred to as a network device. RAN devices include, but are not limited to, next generation node base stations (gNBs) in 5G systems, evolved node Bs (eNBs) in LTE, radio network controllers (RNCs), node Bs (NBs), base station controllers (BSCs), base transceiver stations (BTSs), home base stations (e.g., home evolved Node Bs, or home node Bs, HNBs), base band units (BBUs), transmitting and receiving points (TRPs), transmitting points (TPs), pico base station devices (pico), mobile switching centers, network devices in future networks, etc. In systems using different radio access technologies, devices having the functionality of access network devices may have different names. For ease of description, in all embodiments of the present application, the aforementioned devices providing wireless communication functions to terminal devices 110 are collectively referred to as access network devices, or simply referred to as RANs or ANs. It should be understood that the particular type of access network device is not limited herein.

[0090] The CN portion may include, but is not limited to, the following network functions (NFs): a user plane function (UPF) 130, a network exposure function (NEF) 131, a network function repository function (NRF) 132, a policy control function (PCF) 133, a unified data management (UDM) function 134, a unified data repository (UDR) function 135, a network data analytics function (NWDAF) 136, an authentication server function (AUSF) 137, an access and mobility management function (AMF) 138, and a session management function (SMF) 139.

[0091] The data network DN 140 may also be referred to as a packet data network (PDN) and is typically a network external to the operator network, e.g., a third-party network. Of course, in some implementations, the DN may alternatively be deployed by the operator, i.e., the DN belongs to a part of the PLMN. Whether the DN belongs to a PLMN is not limited in this application. The operator network PLMN may access multiple data network DNs 140. The data network DN 140 may be deployed with multiple services and may provide data services, voice services, etc. to the terminal device 110. For example, the data network DN 140 may be a private network of a smart factory, sensors installed in the workplace of the smart factory may be the terminal device 110, and a control server for the sensor may be deployed on the data network DN 140, and the control server may provide services to the sensor. The sensor may communicate with the control server to obtain instructions from the control server, transmit collected sensor data to the control server according to the instructions, etc. In another example, the data network DN 140 may be a company's internal office network, and the company's employee's mobile phone or computer may be the terminal device 110, which may access information, data resources, etc. on the company's internal office network. The terminal device 110 may establish a connection to the operator network through an interface (e.g., N1) provided by the operator network and use services such as data and / or voice provided by the operator network. The terminal device 110 may further access the data network DN 140 through the operator network and may use operator services deployed on the data network DN 140 and / or services provided by a third party.

[0092] Below we briefly explain the NF functions included in the CN.

[0093] 1. The UPF 130 is a gateway provided by an operator for communication between the operator network and the data network DN 140. The UPF network function 130 includes user plane related functions such as data packet routing and transmission, data packet detection, traffic usage reporting, quality of service (QoS) handling, lawful interception, uplink data packet detection, and downlink data packet storage.

[0094] 2. The NEF 131 is a control plane function provided by the operator that primarily enables third parties to use services provided by the network, supports the network in exposing network capabilities, event and data analysis, providing security configuration information for the PLMN from external applications, translating information exchanged within and outside the PLMN, etc.

[0095] 3. NRF 132 is a control plane function provided by the operator and may be configured to maintain real-time information of network functions and services in the network, for example, to support network service discovery, maintain services supported by NF configuration data (NF profile) for NF instances, support service discovery for service communication proxies (SCPs), maintain SCP configuration data (SCP profile) for SCP instances, send notifications about newly registered, deregistered, and updated NFs and SCPs, maintain health status of NFs and SCPs, etc.

[0096] 4. PCF 133 is a control plane function provided by the operator that manages network behavior and supports a unified policy framework to provide policy rules and subscription information related to policy decisions for other control functions.

[0097] 5. The UDM 134 is a control plane function provided by an operator and is responsible for storing information such as a subscriber permanent identifier (SUPI), a subscriber's generic public subscription identifier (GPSI), and credentials of a subscriber within the operator network. The SUPI is first encrypted during transmission, and the encrypted SUPI is called a subscription concealed identifier (SUCI). The information stored in the UDM network function 134 can be used for authentication and authorization of the terminal device 110 to access the operator network. A subscriber of the operator network may specifically be a user who uses a service provided by the operator network, such as a user who uses a China Telecom subscriber identity module (SIM) card or a user who uses a China Mobile subscriber identity module card. The subscriber's credentials may be a long-term key stored on the subscriber identity module card or a small file stored therein, such as information related to the encryption of the subscriber identity module card, and used for authentication and / or authorization. For ease of explanation, it should be noted that the embodiments of the present application do not limit or distinguish between information such as permanent identifiers, credentials, security contexts, authentication data, and tokens related to verification / authentication and authorization.

[0098] 6. UDR135 is a control plane function provided by the operator, which provides the function of storing and retrieving UDM subscription data, provides the function of storing and retrieving PCF policy data, and stores and retrieves user NF group ID information.

[0099] 7. NWDAF 136 is a control plane function provided by the operator. The main function of NWDAF 136 is to collect data from NFs, external application functions (AFs), operations, administration and maintenance (OAM) systems, etc., and provide NWDAF service registration, data publication, data analysis, etc. to NFs and AFs.

[0100] 8. The AUSF 137 is a control plane function provided by an operator and is typically used for primary authentication, i.e., authentication between the terminal device 110 (subscriber) and the operator network. After receiving an authentication request initiated by a subscriber, the AUSF network function 137 may perform authentication and / or authorization for the subscriber by using authentication information and / or authorization information stored in the UDM network function 134, or may generate authentication information and / or authorization information for the subscriber by using the UDM network function 134. The AUSF network function 137 may feed back the authentication information and / or authorization information to the subscriber.

[0101] 9. AMF 138 is a control plane network function provided by the operator network and is responsible for access control and mobility management when terminal devices 110 access the operator network, including functions such as mobility status management, temporary user identity assignment, user authentication and authorization, etc.

[0102] 10. The SMF 139 is a control plane network function provided by the operator network and is responsible for managing the PDU sessions of the terminal device 110. A PDU session is a channel for transmitting PDUs, and the terminal device and the data network DN 140 need to transmit PDUs to each other through the PDU session. The SMF network function 139 is responsible for establishing, maintaining, deleting, etc. the PDU session. The SMF network function 139 includes session-related functions such as session management (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF 130 and the (R)AN 120), selection and control of the UPF network function 130, service and session continuity (SSC) mode selection, and roaming.

[0103] Optionally, the network architecture may further include a data collection coordination function (DCCF) network element and an analytics data repository function (ADRF) network element. The DCCF supports the following functions: determining data sources that can provide data for a received data request, determining if data has been collected from the data sources, indicating a message forwarding framework for sending the data to consumers or notification endpoints, indicating a message forwarding framework for formatting and processing the data sent via the message forwarding framework, formatting and processing the data, sending the data to consumers or notification endpoints, and registering the NWDAF and ADRF that received data from the data sources.

[0104] The ADRF provides data and analytics storage and retrieval services to consumers. For example, a consumer sends a Nadrf_DataManagement_StorageRequest to the ADRF containing the data or analytics to be stored. Alternatively, a consumer sends a Nadrf_DataManagement_StorageSubscriptionRequest to the ADRF to request that the ADRF subscribe to and receive the data or analytics for storage. The ADRF then subscribes to the NWDAF or DCCF to obtain the data or analytics and provides the ADRF notification address (or notification association ID). The analytics or data are then provided as notifications using the DCCF, NWDAF, or MFAF services (Ndccf_DataManagement, Nnwdaf_DataManagement, or Nmfaf_3caDataManagement services).

[0105] For example, a consumer sends a Nadrf_DataManagement_RetrievalRequest request to the ADRF to retrieve data or analyses in a specified data or analysis collection time window. The ADRF determines the availability of the data or analyses in the ADRF's repository and sends the data or analyses to the consumer or obtains a description of the data or analyses in response, or the consumer sends a Nadrf_DataManagement_RetrievalSubscribe request to the ADRF to retrieve data or analyses in the specified data or analysis collection time window. If the time window includes the future and the ADRF subscribes to receive the data or analyses, subsequent notifications received by the ADRF are sent by the ADRF to the notification endpoint. The ADRF determines the availability of the data or analyses and sends a success / failure indication to the consumer in response. The ADRF then sends one or more notifications using Nadrf_DataManagement_RetrievalNotify to the notification address (or notification association ID) specified by the consumer. The notifications provide the data or analyses or provide instructions to the endpoint to retrieve the data or analyses using the Nadrf_DataManagement_RetrievalRequest.

[0106] It may be understood that the aforementioned network elements or functions may be physical entities within a hardware device, software instances running on dedicated hardware, or virtualized functions instantiated on a shared platform (e.g., a cloud platform). In short, the NFs may be implemented by hardware or software.

[0107] In FIG. 1 , Nnef, Nnrf, Npcf, Nudm, Nudr, Nnwdaf, Nausf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface sequence numbers. For example, the meaning of interface serial numbers can be found in the definitions of 3GPP (registered trademark) standard protocols. The meaning of interface serial numbers is not limited in this application. Note that the names of interfaces between network functions in FIG. 1 are merely examples. In a specific implementation, the names of interfaces in the system architecture may alternatively be different names. This is not limited in this application. In addition, the names of messages (or signaling) transmitted between the aforementioned network elements are merely examples and do not constitute any limitations on the functions of the messages.

[0108] For ease of explanation, in the embodiments of the present application, network functions (e.g., NEF 131, ..., and SMF 139) are collectively / simply referred to as NFs. In other words, the NFs described below in the embodiments of the present application may be replaced with any network functions. Note that FIG. 1 describes only some network functions as an example, and the NFs described below are not limited to the network functions shown in FIG. 1.

[0109] It should be understood that the above-described network architectures applied to the embodiments of the present application are merely network architectures described from the perspective of a service-based architecture, and that the network architectures applicable to the embodiments of the present application are not limited thereto. Any network architecture capable of implementing the functions of the above-described network elements is applicable to the embodiments of the present application.

[0110] It should be further understood that the AMF, SMF, UPF, NEF, AUSF, NRF, PCF, and UDM shown in Figure 1 may be understood as network elements configured to implement different functions in the core network, and may be combined as needed to form, for example, a network slice. These core network elements may be independent devices or may be integrated into the same device to implement different functions. The specific forms of the aforementioned network elements are not limited in this application.

[0111] It should be further understood that the above names are defined merely to distinguish different functions and should not constitute any limitation on the present application. The present application does not exclude the possibility that other names will be used in 5G networks and other networks in the future. For example, in a 6G network, some or all of the above network elements may still use 5G terminology or may use other names.

[0112] To facilitate understanding of the solutions provided in the embodiments of the present application, a brief description of the communication mode between service-based network elements is first provided.

[0113] In the 5G service-based system architecture, two parties that communicate with each other based on a service-based interface are called a service consumer and a service provider, respectively. The party that requests a service is a service consumer, and the party that provides a service is a service producer. A service consumer may also be called a consumer, a consuming network element, a user, a requester, a requestor, a service-consuming network element, etc. A service provider may also be called a providing network element, a service-providing network element, a provider, a producer, a responder, etc. This is not a limitation in the present application.

[0114] 2 is a schematic flowchart of a method 200 for obtaining an access token and an NF service according to an embodiment of the present application. As shown in FIG. 2, an example in which an NFc obtains a data collection service from an NFp via a DCCF is used for description. The method includes the following steps. For parts not described in detail, please refer to existing protocols.

[0115] S201: An NF service consumer NFc (e.g., NWDAF) sends an access token request message #1 to an authorization function network element (e.g., network repository function network element NRF).

[0116] In response, the NRF receives an access token request message #1 from the NFc.

[0117] The Access Token Request Message #1 is used to request an authorization token to obtain data collection services from the DCCF.

[0118] In some cases, the NFc may request an access token to access a service of the NFp of a specific network function type (NF type). In this case, the access token request message #1 includes the NFc's NF instance ID (e.g., NF Instance Id(s) of the NF service consumer), expected NF service name(s) (e.g., expected NF service name(s), e.g., data collection), expected NF type (e.g., DCCF), the NFc's NF type, and the NFp's NF type. Optionally, the access token request message #1 may further include additional scopes (i.e., requested resources and requested operations on the resources), an expected single network slice selection assistance information (S-NSSAI) list or NSI ID list of the NFp instance, an expected NF Set ID of the NFp instance, an S-NSSAI list of the NFc, etc.

[0119] In another case, the NF service consumer may request an access token to access a service of a specific NF service provider instance or NF service provider service instance. In this case, the access token request message #1 includes the NF instance ID of the requested NFp, the expected service name, and the NF instance ID of the NFc. Optionally, the access token request message #1 further includes an additional scope (i.e., the requested resource and the requested operation on the resource).

[0120] For example, the access token request message #1 may be an Nnrf_AccessToken_Get Request message.

[0121] Optionally, before the NFc sends the access token request message #1 to the NRF, the NFc and NFp complete registration with the NRF. To ensure the security of the information exchange between the NF and the NRF, the registration information exchange may conform to the OAuth 2.0 standard authorization framework established by the Internet Engineering Task Force (IETF). In OAuth 2.0, the client corresponds to the NFc, the client ID corresponds to the NFc instance ID, and the authorization server corresponds to the NRF. For specific NF registration procedures, please refer to existing protocols; details will not be described here.

[0122] It should be noted that this implementation is applicable when NFc and NFp belong to the same operator, and also when NFc and NFp belong to different operators, which is not specifically limited in this application.

[0123] S202: The NRF authorizes the NFc and generates an access token token#1 (e.g., access_token_nwdaf).

[0124] In a service-based system architecture, when an NFc requests a service from an NFp, the NFp needs to perform an authorization check for the service requested by the NFc, i.e., check whether the NFc is authorized to use the requested service. The NFp provides the corresponding service to the NFc only after the authorization check is successful. The authorization verification performed by the NFp for the service requested by the NFc may use an authorization verification solution based on an access token.

[0125] For example, the NRF performing an authorization check on the NFc may include the NRF performing verification on the identity of the NFc, and if the identity verification is successful, verifying whether the NFc has permission to access the requested service. Since token#1 is generated when the NFc has permission, the service obtained by the NFc by using token#1 is an authorized service, and unauthorized use of the service is prevented.

[0126] The NRF's verification of the identity of the NFc may include verifying whether the parameters (e.g., the NF type of the NFc) carried in the token#1 acquisition request match the public key certificate or NF configuration information of the NFc. If the parameters match the public key certificate or NF configuration information, the identity verification is successful, and if the parameters do not match the public key certificate or NF configuration information, the verification fails. Specifically, for example, the NRF may obtain a corresponding public key certificate from the NFc. The public key certificate includes information about the NFc. The NRF compares the parameters of the token#1 acquisition request (e.g., the NF type of the NFc) with the information included in the public key certificate. If the information matches, the identity verification is successful, or if the information does not match, the identity verification fails. Alternatively, as another example, the NRF acquires NF configuration information corresponding to the NF instance ID (i.e., NF configuration information of NFc) stored locally in the NRF network element based on the NF instance ID of NFc in the token#1 acquisition request, and compares a parameter in the token#1 acquisition request, such as the NF type of NFc, with the NF type in the NF configuration information. If the NF types match, identity verification is successful, or if the NF types do not match, identity verification fails.

[0127] The NRF verifying whether the NFc has authorization to access the requested service may include the NRF determining whether the NFc has authorization to access the requested service based on the service-related parameters (e.g., expected service name) carried in the token #1 acquisition request, the NF type of the NFc, and local configuration. For example, NFc is an NWDAF network element, NFp is a DCCF network element, and the expected service name is data collection service. If the NRF determines, based on the local configuration, that the NWDAF network element has authorization to acquire data from the DCCF network element, the authorization check is successful. In another example, NFc is an NWDAF network element, NFp is an ADRF network element, and the expected service name is model acquisition. In this case, the NRF determines, based on the local configuration, that the NWDAF network element cannot acquire models from the ADRF network element, so the authorization check fails. If the authorization check for the NFc is successful, the NRF generates an access token including claims.

[0128] Furthermore, if the authorization check for the NFc is successful, i.e., if the NFc is authorized, the NRF generates token#1 including claims. The claims include the NF instance ID of the authorized network element, the NF instance ID of the NF service consumer, the NF type of the NF service provider, the expected service name, the expiration time (expires_in), etc. Optionally, the claims may further include additional scope (resources that are allowed to be requested and the requested action on the resources), the expected S-NSSAI list or NSI ID list of the NF service provider instance, the expected NF Set ID of the NF service provider instance, etc.

[0129] Furthermore, the NRF may perform security protection on the generated token#1. The security protection in this specification may be integrity protection. For example, the NRF may generate a message authentication code (MAC) for token#1 using a shared key, and then send the MAC and token#1 together to the NFc. The MAC is used to verify whether the information in token#1 has been tampered with. Alternatively, the NRF may sign claims by using a private key, and the NFp may verify whether the claims have been tampered with by using the signature. For specific methods of protecting access tokens by using signatures and MAC values, please refer to the definition in RFC7515.

[0130] If the NFc is not authorized, the NRF cannot issue token#1 to the NFc. It should be understood that integrity protection is the use of physical or cryptographic means to ensure that information is not tampered with or changed without authorization during and after generation, transmission, and storage.

[0131] Optionally, the claims may further include other parameters, such as allowed resources, network slice information, "additional scope" information (i.e., allowed resources and allowed resource operations (service operations)), an expected NSSAI or NSI ID list for the NFp instance, and an expected NF Set ID for the NFp instance.

[0132] Note that the check granularity of the NRF in step S202 is at the service level. Therefore, when the verification is successful, the NFc may initiate a service request to any NFp that can provide the service based on token#1.

[0133] S203: The NRF sends an access token response message #1 to the NFc.

[0134] In response, the NFc receives an access token response message #1 from the NRF.

[0135] The access token response message #1 is used to authorize the NFc to obtain data collection services from the DCCF, i.e., to receive data requested by the NFc from the DCCF. The access token response message #1 includes token #1.

[0136] Optionally, the access token response message #1 may further include the validity period of the token #1, and the token #1 can usually be reused within the validity period.

[0137] For example, if all parameters in the access token request message #1 are verified and the NFc is authorized to access the requested service, the NRF sends the generated token #1 to the NFc by using the access token response message #1 (e.g., Nnrf_AccessToken_Get Response). Optionally, the access token response message #1 may further include other parameters, such as the expiration time of token #1 and the range within which token #1 is allowed to be used in the request. If the authorization verification in S202 fails, the NRF sends an error response or a rejection response to the NFc.

[0138] S204: The NFc sends an NF service request message #1 to the DCCF.

[0139] In response, the DCCF receives NF Service Request Message #1 from the NFc.

[0140] The NF Service Request Message #1 is used to request data acquisition from the NFp via the DCCF. The NF Service Request Message #1 includes token #1 and a CCA (e.g., CCA_NWDAF) generated by the NFc. The CCA_NWDAF is used by the NFp to perform identity verification of the NFc in a subsequent step.

[0141] For example, the NF service request message #1 may be an NF Service Request message, or more specifically, an Ndccf_DataManagement_Subscribe message.

[0142] S205: DCCF performs verification on token#1 and executes the service after the verification is successful.

[0143] For example, the DCCF performs integrity verification on token#1 to ensure that token#1 is issued by the NRF. For example, the DCCF performs verification on the digital signature by using the NRF's public key and checks the MAC value by using the shared key to verify the integrity protection of token#1, ensuring that token#1 has not been tampered with or modified without authorization. Furthermore, after the integrity verification is successful, verification is performed on the identity of the NFc by comparing CCA_NWDAF with the instance ID of the NFc carried in token#1. Optionally, if the authenticity and validity of token#1 are guaranteed, the DCCF may further determine the validity of token#1 by using the validity period of token#1. The content verified by the DCCF specifically depends on the parameters carried in the claims. Only after the aforementioned verification is successful, the DCCF executes the service requested by the NFc, i.e., executes step S206. If the aforementioned verification fails, the service request is rejected. Optionally, the NRF may return a response message to the NFc indicating a validation error.

[0144] S206: DCCF determines NFp.

[0145] Optionally, if information about the NFp (e.g., the type of NFp and the instance ID of the NFp) is carried in step S204, the DCCF may not autonomously select the NFp but send a request to the NRF by using the NFp provided by the NFc, i.e., step S207 is executed.

[0146] S207: The DCCF sends an access token request message #2 to the NRF.

[0147] In response, the NRF receives an access token request message #2 from the DCCF.

[0148] The Access Token Request Message #2 is used to request an authorization token to obtain a data collection service from the NFp. The Access Token Request Message #2 includes the NFc instance ID (e.g., NWDAF), the DCCF NF instance ID, CCA_NWDAF, the expected NF service name (e.g., data collection), and the expected NFp type (e.g., data producer NF). It should be understood that the DCCF NF instance ID may be included in a different information element (IE) from the NFc.

[0149] Optionally, the access token request message #2 further includes, but is not limited to, the type of NFc (e.g., NWDAF), the expected NSSAI list or NSI ID list of the NFp instance, the expected NF Set ID of the NFp instance, the S-NSSAI list of the NFc, etc.

[0150] For example, the access token request message #2 may be an Nnrf_AccessToken_Get Request message.

[0151] S208: The NRF performs verification on the identities of the DCCF and NFc and generates token#2 (e.g., access_token_dataproducer).

[0152] For example, the NRF checks whether the DCCF and NFc are allowed to access the services provided by the determined NFp. For example, the NRF performs identity verification on the DCCF and NFc according to one of the SBA methods. For example, the NRF performs verification on parameters (such as the NF type) in the access token request message #2 to determine whether the parameters match the public key certificate or the NF profile of the NF service consumer. In addition, the NRF further checks whether the NFc is authorized to access the requested service.

[0153] Optionally, in the standard version of 3GPP® Release 16, the NRF performs identity verification against the NFc using CCA_NWDAF. In the standard version of 3GPP® Release 16 or earlier, the NRF verifies whether the NFc is authorized to accept the requested service, but does not verify whether the DCCF is authorized to accept the requested service.

[0154] If the verification in the above verification procedure is successful, the NRF generates token#2, which includes claims, including additional claims of the NF instance ID of the NFc and the identifier of the DCCF, which are used to authorize the NFc and DCCF to obtain data collection services from the NFp.

[0155] Optionally, the claims may further include, but are not limited to, the NF instance ID of the issuing NRF, the NF type of the NFp, the expected service name of the NFc, the validity period of token#2, allowed resources, network slice information, "additional scope" information (i.e., allowed resources and allowed resource operations (service operations)), the expected NSSAI or NSI ID list of the NFp instance, the expected NF Set ID of the NFp instance, etc.

[0156] Optionally, in the standard version of 3GPP® Release 16 or earlier versions, the additional claim of the DCCF identifier may not be added to token#2.

[0157] Furthermore, the NRF may perform security protection on the generated token #2. The security protection in this specification may be integrity protection. For example, the NRF may generate a message authentication code (MAC) for token #2 using a shared key, and then send the MAC and token #2 together to the DCCF or NFc. The MAC is used to verify whether the information in token #2 has been tampered with. Alternatively, the NRF may sign claims by using a private key, and the NFp may verify whether the claims have been tampered with by using the signature.

[0158] S209: The NRF sends an access token response message #2 to the DCCF.

[0159] In response, the DCCF receives an access token response message #2 from the NRF.

[0160] The access token response message #2 indicates that the NFc and DCCF are authorized to obtain data collection from the NFp, and the access token response message #2 includes token #2.

[0161] Optionally, the access token response message #2 may further include the validity period of the token #2, and the token #2 can typically be reused within the validity period.

[0162] For example, the access token response message #2 may be an Nnrf_AccessToken_Get Response message.

[0163] S210: The DCCF sends an NF service request message #2 to the NFp.

[0164] In response, the NFp receives NF Service Request Message #2 from the DCCF.

[0165] The NF Service Request message #2 is used to request the NFp to provide a data collection service, i.e., the DCCF requests to obtain data from the NFp for the NFc. The NF Service Request message #2 includes token #2, the NF instance ID of the DCCF, and the CCA_NWDAF.

[0166] For example, NF Service Request Message #2 may be an NF Service Request message.

[0167] S211: The NFp performs verification on the token #2 and provides the service after the verification is successful.

[0168] For example, the NFp performs verification on the NFc, token#2, and DCCF. For example, the NFp performs verification on the identity of the NFc by comparing the CCA_NWDAF with the instance ID of the NFc carried in token#2, performs verification on the identity of the DCCF by comparing the identifier of the DCCF in the claims included in token#2 with the NF instance ID of the DCCF carried in the NF service request message#2, performs verification on the digital signature by using the public key of the NRF to ensure that token#2 was issued by the NRF, and performs verification on the integrity protection of token#2 by checking the MAC value by using the shared key to ensure that token#2 has not been tampered with or changed without authorization. If the verification on the integrity protection of token#2 is successful, the NFp must further perform verification on the claims in token#2. For example, it verifies whether the NF instance ID or NF type of the NFc in the claims matches the id or type of the NFp. If the claims include an S-NSSAI or NSI ID, the NFp verifies whether the corresponding slice can be served. If the claims include the NFp's NF Set ID, the NFp verifies whether the NF Set ID in the claims matches the NFp's NF Set ID. If the claims include a service name, the NFp verifies whether the requested service operation matches. If the claims include information about additional scopes, the NFp verifies whether the additional scope matches the requested operation. The NFp compares the expiration time of token#2 with the current time to verify whether the token has expired. If the NF service request message#2 includes an NF Set ID, the NFp verifies whether the NF Set ID matches the NF Set ID in the claims in token#2, and so on.

[0169] Optionally, if the DCCF's identifier is not included in the additional claims of token#2, for example, if the NRF uses the standard version of 3GPP Release 16 or an earlier version, the NFp may locally authorize the DCCF and execute the service after successful authentication and authorization. Optionally, the DCCF may include an additional CCA for identity verification.

[0170] S212: The NFp sends an NF service response message #2 to the DCCF.

[0171] In response, the DCCF receives NF Service Response Message #2 from the NFp.

[0172] NF Service Response Message #2 contains the data requested by the NFc.

[0173] For example, NF service response message #2 may be an NF Service Response via notification message.

[0174] It should be understood that based on the successful verification of token#2 in step S211, the NFp will execute the service; otherwise, the NFp will refuse to provide the service.

[0175] S213: The DCCF sends an NF service response message #1 to the NFc.

[0176] In response, the NFc receives NF service response message #1 from the DCCF.

[0177] The NF Service Response Message #1 contains the data requested by the NFc.

[0178] For example, NF service response message #1 may be an NF Service Response via notification message.

[0179] Optionally, if another NFc requests the data collected in step S212 from the DCCF at a later stage, steps S201 to S212 need to be executed. Then, when the NFp receives the NF Service Request message, the NFp needs to perform identity verification on the new NFc and perform verification on the access token carried in the NF Service Request message, and sends an NF Service Response message to the DCCF. If the NF Service Response message indicates that the access token has been successfully verified, the DCCF may also send the data to the new NFc. If the NF Service Response message indicates that the access token verification failed, the DCCF rejects the NF Service Request of the new NFc.

[0180] It should be noted that the above-provided token acquisition and service request procedures are only examples for illustration purposes, and the present application is not limited thereto. All other methods that can implement token acquisition and service request fall within the scope of protection of the present application.

[0181] Based on this implementation, the NFc may receive data from the NFp via the DCCF. Because the NF service may have an authorized service range, if the NFc is compromised, unauthorized access between service areas may occur on the NF service. In other words, the NFc can obtain data between areas without authorization, causing network security issues.

[0182] 3 is a schematic flowchart of a model sharing method 300 according to an embodiment of the present application. Specifically, the NFc requests the analytical data repository function network element ADRF to obtain the model trained by the NFp. As shown in FIG. 3, the method includes the following steps. For parts not described in detail, please refer to existing protocols.

[0183] S301: The NF service producer NFp (e.g., NWDAF MTLE) performs registration by using an interoperability ID.

[0184] S302: The NF service consumer NFc (eg, NWDAF AnLF) performs registration by using the vendor ID.

[0185] It should be understood that an interoperability ID is a list of vendor IDs that allow each analytic ID to access an ML model.

[0186] For example, in step S301, an NWDAF including an MTLE registers its NFp profile with the NRF, where the profile is supported by the NWDAF including the MTLE and its interoperability ID. Similarly, in step S302, an NWDAF including an AnLF registers its NFc profile with the NRF, where the profile is supported by the NWDAF including the AnLF and its vendor ID.

[0187] S303: Optionally, the NFp performs an interoperability ID specific operation.

[0188] For example, the NFp performs operations such as encryption and data integrity protection for the security of the ML model. The encryption scheme for the ML model is not within the scope of 3GPP.

[0189] S304: NFp triggers the storage of the ML model.

[0190] For example, the NFp sends a request message to the ADRF to request storage of an ML model. The request message includes a storage address of the ML model in the NFp, for example, URL1. The request message further includes a model association identifier (for example, a model correction ID). In response, the ADRF obtains the protected ML model based on the address URL1 of the ML model in the NFp and stores the ML model.

[0191] S305: The ADRF sends the storage location of the ML model to the NFp.

[0192] For example, the storage location of the ML model in the ADRF is URL2, which is subsequently used by the NFp to update or access the ML model.

[0193] S306: Perform an MTLF discovery process between the NFc and the NRF.

[0194] Based on the above steps, the NRF records the status of the ML models trained by the NFp, such as the analytic ID of each ML model. Since the NFc registers with the NRF by using the vendor ID, the NRF can inform the NFc of the association relationship between the ML model and the analytic ID, and the NFc and the vendor ID, so that the NFc can request ML models from the ADRF in a targeted manner.

[0195] S307: The NFc sends an access token request message to the NRF.

[0196] In response, the NRF receives an access token request message from the NFc.

[0197] The access token request message includes the analysis ID.

[0198] For example, the access token request message may be an Nnrf_AccessToken_Get Request message.

[0199] S308: The NRF sends an access token response message to the NFc.

[0200] In response, the NFc receives an access token response message from the NRF.

[0201] The access token response message includes a token, which includes the specified vendor ID.

[0202] For example, the access token response message may be an Nnrf_AccessToken_Get Response message.

[0203] Specifically, for specific implementations of steps S307 and S308, see steps S201 to S203 in method 200, including the implementation in which the NRF authorizes the NFc. For the sake of brevity, the details will not be described herein.

[0204] S309: The NFc sends a model request message to the NFp.

[0205] In response, the NFp receives a model request message from the NFc.

[0206] The model request message includes an analysis ID and a token, where the token carries the specified vendor ID.

[0207] S310: The NFp performs verification on the token and executes authorization.

[0208] For example, the NFp needs to verify whether the specified vendor ID carried in the token corresponds to the analysis ID carried in the model request message. It should be understood that when verifying that the token is valid, the NFp may perform further authorization by using the specified vendor ID in the token. If the ML model requested by the NFc is stored in the ADRF, steps S311 to S313 continue to be executed.

[0209] S311: The NFp sends a URL request message to the ADRF.

[0210] In response, the ADRF receives a URL request message from the NFp.

[0211] The URL request message includes a model association identifier (eg, a model correction ID) or URL2.

[0212] For example, after receiving the URL request for NFp, the ADRF checks whether the owner of the stored ML model is NFp in step S304. If the check is successful, the ADRF provides a new storage address of the stored ML model, for example, URL3, and then executes step S312. URL3 may be a URL that is used only once.

[0213] S312: The ADRF sends URL3 to the NFp.

[0214] In response, the NFp receives URL3 from the ADRF.

[0215] S313: The NFp sends URL3 to the NFc.

[0216] In response, NFc receives URL3 from NFp.

[0217] It should be understood that a prerequisite for performing the above steps S311 to S313 is that the ML model requested by the NFc is stored in the ADRF. Optionally, if the ML model requested by the NFc is stored in the NFp, after step 310, the NFp provides a new storage address of the stored ML model, for example, URL4, and returns URL4 to the NFc. That is, steps S311 to S313 may not be performed. URL4 may be a URL that is used only once. Therefore, the NFc may obtain the protected ML model from the NFp or the ADRF based on URL4 or URL3.

[0218] S314: Optionally, the NFc performs an interoperability ID specific operation.

[0219] For example, the NFc may perform operations such as decryption and integrity checks taking into account the interoperability ID on the protected ML model.

[0220] Based on this implementation, the ML model has a service area restriction. Because the access token does not include service domain information, the NFp does not know the service area of ​​the NFc and may authorize the NFc to use an ML model that exceeds the service range of the NFc. In this case, model leakage will occur and network security cannot be guaranteed.

[0221] 4 is a schematic flowchart of another model sharing method 400 according to an embodiment of the present application. As shown in FIG. 4, the method includes the following steps. For parts not described in detail, please refer to existing protocols.

[0222] S401: Optionally, the NF service producer NFp (eg, NWDAF MTLE) performs registration by using an analysis ID and an interoperability ID.

[0223] S402: Optionally, the NF service consumer NFc (eg, NWDAF AnLF) performs registration by using the analysis ID and the vendor ID.

[0224] For example, in step S401, an NWDAF including an MTLE registers its NFp profile with the NRF, where the profile is supported by the NWDAF including the MTLE and its analysis ID and interoperability ID. Similarly, in step S402, an NWDAF including an AnLF registers its NFc profile with the NRF, where the profile is supported by the NWDAF including the AnLF and its analysis ID and vendor ID.

[0225] S403: The NFp encrypts an ML model that is not specified by 3GPP.

[0226] The specific encryption method is not limited to the embodiments of the present application.

[0227] S404: NFp triggers the storage of the ML model.

[0228] S405: The ADRF sends the storage location of the ML model to the NFp.

[0229] S406: Optionally, the ADRF performs registration by using the analysis ID, the interoperability ID, and the MTLF ID.

[0230] For example, the ADRF registers its NF profile with the NRF, and the profile includes an analysis ID, an interoperability ID, and an MTLF ID.

[0231] S407: Optionally, perform an MTLF discovery process between the NFc and the NRF.

[0232] For example, an NFc (eg, an NWDAF including an AnLF) performs an Nnrf_NF discovery request operation by using the requested analysis ID to select an appropriate NFp (eg, an NWDAF including an MTLF).

[0233] For specific implementation forms of steps S403 to S407, please refer to the relevant descriptions of steps S303 to S306 in method 300. For the sake of brevity, the details will not be described again here.

[0234] S408: The NFc sends an access token request message #1 to the NRF.

[0235] In response, the NRF receives an access token request message #1 from the NFc.

[0236] The access token request message #1 is used to request retrieval of an access token to obtain an ML model. The access token request message #1 includes the target NF (e.g., NFp (NWDAF including MTLF)), the NF type and / or NFc ID of the NFc (e.g., NWDAF including AnLF), and the analysis ID and vendor ID of the NFc.

[0237] For example, the access token request message #1 may be an Nnrf_AccessToken_Get Request message.

[0238] S409: The NRF sends an access token response message #1 to the NFc.

[0239] In response, the NFc receives an access token response message #1 from the NRF.

[0240] The access token response message #1 includes token #1.

[0241] For example, the access token response message #1 may be an Nnrf_AccessToken_Get Response message.

[0242] For specific implementation forms of steps S408 and S409, refer to steps S307 and S308 in method 300. For example, before performing step S409, the NRF needs to check whether the NWDAF including the AnLF is authorized to access the service provided by the NWDAF including the MTLF, and verify whether the NWDAF including the vendor ID of the AnLF is included in the NWDAF including the analysis ID and interoperability ID of the MTLF. Only if the verification is successful, the NRF performs step S409 after generating token #1 based on the MTLF NF information included in the NWDAF. For brevity, details will not be described herein.

[0243] S410: The NFc sends an ML model request message #1 to the NFp.

[0244] In response, the NFp receives an ML model request message #1 from the NFc.

[0245] The ML model request message #1 is used to search for an ML model associated with the analysis ID, and the ML model request message #1 includes token #1, the analysis ID, and the vendor ID.

[0246] For example, ML model request message #1 may be a Nnwdaf_ML modelProvision_Subscribe message.

[0247] S411: The NFp sends an ML model notification message #1 to the NFc.

[0248] In response, NFc receives ML model notification message #1 from NFp.

[0249] The ML model notification message #1 includes URL2, ie, the storage address of the ML model in the ADRF.

[0250] For example, ML model notification message #1 may be a Nnwdaf_ML modelProvision_Notify message.

[0251] Note that before executing step S411, NFp needs to verify token#1 to determine the ML model corresponding to the analysis ID. For specific methods for performing verification on token#1, please refer to the related descriptions above. For brevity, the details will not be described again here. Furthermore, if the ML model determined by NFp is stored in the ADRF, the aforementioned step S411 is executed, that is, it indicates that the storage address of the ML model requested by NFc is URL2 in the ADRF.

[0252] S412: The NFc sends an access token request message #2 to the NRF.

[0253] In response, the NRF receives an access token request message #2 from the NFc.

[0254] The access token request message #2 is used to request retrieval of an authorization token to retrieve an ML model stored in the ADRF. The access token request message #2 includes the target NF (e.g., ADRF), the NF type and / or NFc ID of the NFc (e.g., NWDAF including AnLF), the vendor ID of the NFc, the analysis ID, and the ID of the NFp (e.g., NWDAF including MTLF).

[0255] For example, the access token request message #2 may be an Nnrf_AccessToken_Get Request message.

[0256] S413: The NRF sends an access token response message #2 to the NFc.

[0257] In response, the NFc receives an access token response message #2 from the NRF.

[0258] The access token response message #2 includes token #2.

[0259] For example, the access token response message #2 may be an Nnrf_AccessToken_Get Response message.

[0260] For specific implementation forms of steps S412 and S413, please refer to steps S408 and S409. For example, before executing step S413, the NRF needs to verify whether the NWDAF including the AnLF vendor ID is included in the analysis ID and interoperability ID of the model producer NF, i.e., whether the ADRF's NF Profile includes the NWDAF including the MTLF. Only if the verification is successful, the NRF generates token #2 based on the information provided in the ADRF's NF Profile, and then executes step S413. For brevity, details are not described herein.

[0261] S414: Optionally, the NFc retrieves the ML model from the storage address URL2 in the ADRF based on the token#2, and the ADRF performs verification on the token#2 to check whether the NFc is authorized to access the stored ML model. Only if the verification is successful, the ADRF authorizes the NFc to retrieve the ML model stored in the ADRF.

[0262] S415: NFc decodes ML models not specified by 3GPP.

[0263] For example, the NFc may perform operations such as decryption and integrity checks taking into account the vendor ID associated with the protected ML model.

[0264] In this implementation, the access token obtained by the NFc does not include service domain information. Therefore, the NFc may access all ML models associated with the analysis ID of the NFp, and the usage scope of the ML models may exceed the service area of ​​the NFc. In this case, model leakage may occur, and network security cannot be guaranteed.

[0265] In conclusion, the current OAuth authentication mechanism does not include checking service area information and cannot meet the requirements of services with finer granularity, such as service area restrictions. If an NF service has area restrictions but the access token obtained by the NFc does not contain service domain information, the service provided by the NFp when token validation is successful may be accessed without authorization, and network security cannot be guaranteed.

[0266] In view of this, the present application provides a communication method and apparatus, in which service domain information is added to the access token to provide a finer-grained authentication mechanism, so that the problem of NFc accessing services across areas without authorization can be solved, network communication security can be guaranteed, and user experience can be improved.

[0267] To facilitate understanding of the embodiments of the present application, the following points are provided.

[0268] First, in this application, unless otherwise specified or there is no logical contradiction, the terms and / or descriptions between different embodiments are consistent and may be cross-referenced, and the technical features of different embodiments may be combined into a new embodiment based on their internal logical relationships.

[0269] Second, in this application, "at least one" means one or more, and "more" means two or more. The term "and / or" describes the association relationship between associated objects and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: only A is present, both A and B are present, and only B is present. A and B may be singular or plural. In the text description of this application, the character " / " typically indicates an "or" relationship between associated objects. "At least one of the following items" or similar expressions means any combination of these items, including any combination of one item or multiple items. For example, "at least one of a, b, and c" may refer to a, b, c, a and b, a and c, b and c, or a, b, and c. Each of a, b, and c may be singular or plural.

[0270] Third, in this application, the terms "first," "second," and various numbers (e.g., #1 and #2) are used merely for distinction purposes to facilitate description, and are not intended to describe a particular order or sequence, or to limit the scope of the embodiments of this application, such as distinguishing between different messages, etc. It should be understood that the subject matter so described may be interchangeable in appropriate circumstances so that solutions other than the embodiments of this application may be described.

[0271] In the following, please note that the meanings represented by information #1, resource indication information #1, and resource request information #1 are different from each other. It should be understood that the names of the information are merely examples for explanation. This is not limited in the present application and should not constitute any limitation on the technical solution of the present application.

[0272] Fourth, in this application, the terms "when," "in the case of," and "if" all mean that the device performs the corresponding process in the intended case, and do not limit the time, and the device is not required to perform the decision action during implementation. This does not imply any other limitation.

[0273] Fifth, in this application, the terms "comprise," "have," and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those explicitly recited steps or units, but may include other steps or units that are not explicitly recited or that are inherent to the process, method, product, or device.

[0274] Sixth, in this application, "indicate" may include "directly indicate" and "indirectly indicate." When an instruction is described as indicating A, the instruction may directly indicate A or indirectly indicate A, but it does not necessarily mean that the instruction conveys A.

[0275] The instruction method in the embodiments of the present application should be understood to cover various methods that can enable the party to be instructed to know the information to be instructed. The information to be instructed may be transmitted as a whole, or may be divided into multiple sub-information for separate transmission. Furthermore, the transmission periods and / or transmission opportunities of the sub-information may be the same or different. The specific transmission method is not limited in the present application.

[0276] The "indication information" in the embodiments of the present application may be an explicit indication, i.e., directly indicated by signaling, or obtained by referring to another rule or another parameter, or by derivation based on the parameter indicated by signaling, or may be an implicit indication, i.e., obtained according to a rule or a relationship, or based on another parameter, or by derivation, which is not specifically limited in the present application.

[0277] Seventh, in this application, a "protocol" may refer to a standard protocol in the communications field, and may include, for example, a 5G protocol, an NR protocol, and related protocols applied to future communications systems. This is not limited in this application. "Predefined" may include being predefined, for example, being defined in a protocol. "Preconfigured" may be implemented by prestoring a corresponding code or a corresponding table in a device, or by another method capable of indicating related information. The specific implementation form is not limited in this application.

[0278] Eighth, in this application, "storage" may mean storage in one or more memories. The one or more memories may be located separately or integrated into the encoder or decoder, processor, or communication device. Alternatively, a portion of the one or more memories may be located separately, or a portion of the one or more memories may be integrated into the decoder, processor, or communication device. The type of memory may be any form of storage medium. This is not a limitation in this application.

[0279] Ninth, in this application, "communication" may also be described as "data transmission," "information transmission," "data processing," etc. "Transmission" includes "sending" and "receiving."

[0280] Hereinafter, the communication method provided in the embodiments of the present application will be described in detail with reference to the accompanying drawings. For example, the communication method may be applied to the communication system shown in FIG.

[0281] 5 is a schematic flowchart of a communication method 500 according to an embodiment of the present application. The method 500 may be applied to the network architecture shown in FIG 1. As shown in FIG 5, the method includes the following steps:

[0282] S510: A first network function network element obtains a first token.

[0283] The first token includes first service domain information, and the first service domain information indicates a service area range in which the first network function network element can obtain service from the second network function network element.

[0284] For example, the first network function network element may be an NFc network element, and the second network function network element may be an NFp network element. In other words, the second network function network element may be a service-providing network element, and the first network function network element may be a service-requesting network element. The first network function network element may request one or more services, and the second network function network element may provide one or more services. This is not limited in the present application. Optionally, the identifier of the aforementioned network function network element may be an NF ID (Identity or Identifier) ​​or an NF Instance ID.

[0285] Optionally, the service may be a data collection service or a model acquisition service, or another service, such as a registration service or an SM policy control service. For example, if the NF service consuming network element is an NWDAF network element and the NF service providing network element is a DCCF network element, the NWDAF network element requests to acquire the data collection service from the DCCF network element. As another example, if the NF service consuming network element is an NWDAF network element and the NF service providing network element is an ADRF network element, the NWDAF network element requests to acquire the model acquisition service from the ARDF network element. As another example, if the NF service consuming network element is an SMF network element and the NF service providing network element is a PCF network element, the SMF network element requests the SM policy control service from the PCF network element.

[0286] A service area range for acquiring a service may be understood as an area range for acquiring service-compatible resources of the service. For a resource acquisition service, a service area range for a service may be understood as an area range for acquiring service-compatible resources of the service. For example, if the resource is data, a model, a protocol data unit, etc., the service area range of the service may be an area range for acquiring corresponding data, an area range for acquiring a model, an area range for acquiring a protocol data unit, etc. In other words, a first network function network element can acquire data or models within its service area range, or the first network function network element has permission to request a second network function network element to provide data or models within its service area range.

[0287] It should be understood that the first service domain information indicates a service area range allowed by the service acquisition capability of the first network function network element, or the first service domain information indicates a service area range in which the authorization function network element authorizes the first network function network element to acquire a service. For example, if the service area range allowed by the data acquisition capability of the first network function network element is areas 1, 2, and 3, the service area range indicated by the first service domain information may be one or more of areas 1, 2, and 3.

[0288] In other words, the first service domain information may be used to limit the service area range from which the first network function network element can request services. In this embodiment of the present application, the service domain information is mainly for services (e.g., data collection services or model acquisition services) within the authorized service area range. For example, the NWDAF has permission to request services (data or models) within service domain #1 from the NFp, but does not have permission to request services (data or models) within service domain #2 other than service domain #1 from the NFp.

[0289] In this embodiment of the present application, the first service domain information may be classified into multiple dimensions based on different standards. For example, the classification may be performed based on a geographical location or a network logical area location, or by using a combination of a geographical location and a network logical area. Optionally, the name of the first service domain information may be a Serving Area, an Area of ​​interest, a Service Area, a servingScope, a tracking area identity (TAI), an NF domain name, a fully qualified domain name (FQDN) type, etc. It should be understood that the aforementioned names are merely examples provided to facilitate understanding of the solution, and the first service domain information may alternatively have another name, which is not specifically limited in the present application.

[0290] For example, from the perspective of classification based on geographic location, the first service domain information may be understood as a designated location area in a 3GPP system. The area of ​​interest is represented by a tracking area list, a cell list, or a RAN node identifier list. In the case of an LADN, an event user (e.g., SMF) provides an LADN DNN to reference an LADN service area as an area of ​​interest. In the case of a PRA, an event user (e.g., SMF or PCF) may provide an identifier of the area of ​​interest to reference a predefined area as an area of ​​interest. The servingScope may indicate a geographic area and may be used, for example, to discover and select NFs in a central data center, where the NF is expected to serve users located in a specific area, or to reduce TAI configuration of an NF instance. From the perspective of classification based on logical location, the first service domain information can be understood as TAI (or servingScope, i.e., the serving area of ​​the NFc instance), NF domain name or FQDN type, analysis IDs supported by the NWDAF, serving area information of the NWDAF (i.e., a list of TAIs to which the NWDAF can provide trained ML models and / or data), analysis delays supported by each analysis ID, NF type of the NF data source, NF set ID of the NF data source, analysis aggregation function, analysis metadata pre-configuration function, S-NSSAI and service area of ​​trained ML models per analysis ID of the ML model, etc.

[0291] For example, in the case of a data collection service, the first service domain information indicates that the first network function network element can request the second network function network element to provide data within an authorized service area, and in the case of a model acquisition service, the first service domain information indicates that the first network function network element can request the second network function network element to provide models within an authorized service area.

[0292] In one example, the capability of the first network function network element can support collection of data in service areas 1, 2, and 3. If the token request message sent in step S511 does not carry second service domain information, the authorization function network element determines, based on the NF Profile stored locally in the first network function network element, that the first network function network element can collect data within service areas 1, 2, and 3. In this case, the first service domain information carried in the generated first token can authorize service areas 1, 2, and 3.

[0293] In another example, the capability of the first network function network element can support collection of data in service areas 1, 2, and 3. If the token request message sent in step S511 carries second service domain information, and the second service domain information indicates service areas 1 and 2, the authorization function network element performs verification on the identity of the first network function network element and determines, based on the NF Profile stored locally in the first network function network element, that the first service domain information carried in the generated first token can authorize service areas 1 and 2. Optionally, the first service domain information herein may alternatively authorize service areas 1, 2, and 3. This is not limited in the present application.

[0294] Optionally, an implementation in which the first network function network element obtains the first token includes the following steps S511 to S513.

[0295] S511: A first network function network element sends a token request message to an authorization function network element.

[0296] In response, the authorizer network element receives a token request message from the first network function network element.

[0297] The token request message includes an expected service name or identifier of the first network function network element (e.g., Expected NF service name(s)), an identifier of the first network function network element, an identifier of the second network function network element, or a type of the second network function network element. The service expected by the first network function network element may be a data collection service or a model acquisition service.

[0298] For example, the token request message may be a Nnrf_AccessToken_GetRequest message.

[0299] Optionally, the token request message further includes fourth service domain information, where the fourth service domain information indicates a service area of ​​the service requested by the first network function network element.

[0300] For example, the fourth service domain information may be an area range of resources corresponding to the data requested by the first network function network element. For example, if the service area range allowed by the data acquisition capability of the first network function network element is areas 1, 2, and 3, the service area range indicated by the fourth service domain information may be one or more of areas 1, 2, and 3. Optionally, the service area range indicated by the fourth service domain information may alternatively include area 4, i.e., data within an area beyond the capability range of the first network function network element is requested. In this implementation, the authorization function network element may refuse to generate the first token.

[0301] In the technical solution of the present application, the area range of the resource corresponding to the data acquired by the first network function network element is ultimately affected by the service area range indicated by the first service domain information in the token generated by the authorization function network element.

[0302] Optionally, the token request message further includes a CCA, where the CCA includes an identifier of the third network function network element (e.g., an NWDAF) and third service domain information, where the third service domain information indicates a service area of ​​the service requested by the third network function network element. It should be understood that this implementation is mainly applicable to a scenario in which a first network function network element acts as a third party entity and requests a second network function network element to provide a service to the third network function network element. The CCA is used by the second network function network element to subsequently perform identity verification on the third network function network element and to verify whether the service area indicated by the second service domain information and requested by the first network function network element is included in the service area range indicated by the third service domain information carried in the CCA, thereby preventing the first network function network element from maliciously tampering with the service area range requested by the third network function network element and improving network communication security. For example, the first network function network element is a DCCF, the third network function network element is an NWDAF, and the second network function network element is a data generating network element and is configured to request a data collection service.

[0303] Optionally, if the first network function network element is an NFc (e.g., a DCCF) and the second network function network element is an NFp (e.g., a data producer), the service area indicated by the fourth service domain information carried in the token request message sent by the DCCF to the NRF is included in the service area indicated by the third service domain information. It should be understood that in this implementation, the DCCF may select one or more NFp. This is not limited in the present application. For example, the fourth service domain information indicates areas 1 and 2. If the DCCF selects one NFp1, the DCCF sends token request message #1 to the NRF. After verifying that the DCCF and the NWDAF are authorized, the NRF provides token #A to the DCCF. Subsequently, the DCCF may use token #A to request data within areas 1 and 2 from NFp1. Alternatively, if the DCCF selects two or more NFp (e.g., NFp2 and NFp3), the DCCF sends token request message #2 to the NRF. After verifying that the DCCF and NWDAF are authorized, the NRF provides token #B to the DCCF. The DCCF may then request to obtain data in Area 1 from NFp2 by using token #B. In addition, the DCCF sends token request message #3 to the NRF. After verifying that the DCCF and NWDAF are authorized, the NRF provides token #C to the DCCF. The DCCF may then request to obtain data in Area 2 from NFp3 by using token #C.

[0304] In this embodiment of the present application, the service area indicated by the third service domain information should be included in the service area range indicated by the first service domain information. For example, if the service area range allowed by the data acquisition capability of the first network function network element is Areas 1, 2, and 3, the service area range indicated by the third service domain information may be one or more of Areas 1, 2, and 3.

[0305] In this embodiment of the present application, when an access token carrying first service domain information for another service requested by the NF service consumer is obtained from the authorization function network element, the NF service consumer may request a service within the authorized service area range from the NF service producer. This is a scenario in which the NF service consumer communicates directly with the NF service consumer. Alternatively, the NF service consumer may request the NF service producer to obtain a service within the authorized service area range by using a third-party entity. When the third-party entity sends a service request to the NF service producer, the NF service producer may perform identity verification on the NF service consumer and verify whether the service domain information carried in the CCA includes the service domain information sent by the third-party entity to prevent the third-party entity from maliciously tampering with the service area range of the service (e.g., data or model) requested by the NF service consumer, avoid unauthorized access, and ensure network communication security.

[0306] S512: The authorizer network element generates a first token.

[0307] In one implementation, if the first network function network element determines that it is authorized to obtain the service, the authorizer network element generates a first token.

[0308] For a specific implementation of generating the first token, please refer to the relevant description of step S202 in method 200. For brevity, the details will not be described again here. The difference lies in that the first token generated by the authorization function network element in step S512 carries first service domain information.

[0309] In another implementation, the token request message further includes a CCA, where the CCA includes an identifier of a third network function network element (e.g., an NWDAF) and third service domain information. In this case, the authorization function network element performs verification on the identities of the first network function network element and the third network function network element to determine whether the service area indicated by the fourth service domain information carried in the token request message is included in the service area range indicated by the third service domain information carried in the CCA. If the authorization function network element determines that the service area indicated by the fourth service domain information belongs to the service area range indicated by the third service domain information carried in the CCA, it generates a first token to ensure that the service area range of the service requested by the third network function network element is not maliciously tampered with or extended by the first network function network element, thereby ensuring network security.

[0310] S513: The authorizer network element sends the first token to the first network function network element.

[0311] In response, the first network function network element receives a first token from the authorizer network element.

[0312] For example, the authorization function network element sends a token response message to the first network function network element, where the token response message may be an Nnrf_AccessToken_GetResponse message, and the token response message includes the first token.

[0313] Based on the above implementation steps, if the first network function network element obtains the first token and determines that a service needs to be provided by the second network function network element, it may generate a service request message and perform the following step S520.

[0314] S520: The first network function network element sends a service request message to the second network function network element.

[0315] In response, the second network function network element receives a service request message from the first network function network element.

[0316] The service request message is used to request a second network function network element to provide a service to a first network function network element, and the service request message includes a first token and second service domain information, and the second service domain information indicates a service area of ​​the service requested by the first network function network element.

[0317] For example, the service request message may be an NF Service request message.

[0318] In one example, the service request message further includes a CCA, and the CCA includes an identifier of the third network function network element and third service domain information. For example, if the first network function network element is a data collection coordination function network element, the service request message is used by the data collection coordination function network element to request a data collection service from the second network function network element.

[0319] Optionally, before the first network function network element (e.g., DCCF) sends a service request message to the second network function network element (e.g., NFp), the first network function network element receives a service request message from a third network function network element (e.g., NWDAF), where the service request message carries the CCA and the second service domain information.

[0320] For example, if the service area range indicated by the first service domain information is areas 1, 2, and 3, the second service domain information indicates that the service area of ​​the service requested by the first network function network element may be one or more of areas 1, 2, and 3, and the third service domain information indicates that the service area of ​​the service requested by the first network function network element may be one or more of areas 1, 2, and 3.

[0321] In other words, in this embodiment of the present application, if the first network function network element is an NFc (e.g., an NWDAF) and the second network function network element is an NFp (e.g., a DCCF), the service area indicated by the second service domain information is the same as the service area indicated by the third service domain information. Alternatively, if the first network function network element is an NFc (e.g., a DCCF) and the second network function network element is an NFp (e.g., a data producer), the service area indicated by the second service domain information is included in the service area indicated by the third service domain information. In this implementation, the DCCF may select one or more NFp. This is not limited in the present application. For example, the second service domain information indicates areas 1 and 2. If the DCCF selects one NFp, after the DCCF sends a service request message to the NFp, the NFp provides data within areas 1 and 2 for the DCCF after successful verification of the first token. Alternatively, if the DCCF selects two or more NFps (e.g., NFp1 and NFp2), the DCCF sends a service request message #1 to NFp1, carrying information about the CCA and Area 1. After successful verification of the first token, NFp1 provides data in Area 1 for the DCCF. Similarly, the DCCF sends a service request message #2 to NFp2, carrying information about the CCA and Area 2. After successful verification of the first token, NFp2 provides data in Area 2 for the DCCF.

[0322] S530: The second network function network element determines whether to provide service to the first network function network element based on the first token.

[0323] The second network function network element determining whether to provide a service to the first network function network element based on the first token may be understood as the second network function network element determining whether the first network function network element is authorized to use the service based on the first service domain information in the first token, or the second network function network element determining to provide a service to the first network function network element or to refuse to provide a service to the first network function network element based on the first service domain information in the first token, or the second network function network element providing the requested service (or performing the service) and sending a response message, or sending a response message indicating that the service request has failed, based on the first service domain information in the first token, or the second network function network element providing the requested service (or performing the service) and sending a response message, or sending a response message indicating that the service request has been refused, based on the first service domain information in the first token.

[0324] In other words, a specific expression form in which the second network function network element determines whether the first network function network element is authorized to use the service may be as follows: if the second network function network element determines that the first network function network element is authorized to use the service, the second network function network element provides the service to the first network function network element, or if the second network function network element determines that the first network function network element is not authorized to use the service, the second network function network element rejects the service request message to reject the first network function network element requesting the service.

[0325] Specifically, the second network function network element performs verification on the first token, and if the verification on the first token is successful, the second network function network element determines to provide service to the first network function network element.

[0326] In one implementation, the step of the second network function network element performing verification on the first token includes the step of the second network function network element performing verification on the integrity protection of the first token; if the verification on the integrity protection of the first token is successful, the step of the second network function network element determining whether the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information; and if the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information, the step of the second network function network element determining that the verification on the first token is successful.

[0327] The second network function network element performing verification on the integrity protection of the first token may be the second network function network element performing verification on the MAC of the first token by using a shared key to determine whether the information in the first token has been tampered with, or the second network function network element may perform verification on the signature in the claims of the first token by using the private key of the authorization function network element to determine whether the claims have been tampered with. For specific implementation forms, please refer to the prior art. For the sake of brevity, the details will not be described again here.

[0328] Furthermore, when the verification against the integrity protection of the first token is successful, if the second service domain information indicates service areas 1 and 2, and the service area range authorized by the first service domain information in the first token includes service areas 1, 2, and 3, it indicates that the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information. In this case, the second network function network element determines that the verification against the first token is successful.

[0329] Optionally, if the service request message further includes a CCA, and the CCA includes an identifier of a third network function network element and third service domain information, the method further includes determining whether the second network function network element provides service to the first network function network element based on the CCA.

[0330] Specifically, the second network function network element determines whether the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA, and if the service area indicated by the second service domain information belongs to the service area range indicated by the third service domain information carried in the CCA, the second network function network element determines to provide data or models within the area indicated by the second service domain information to the first network function network element.

[0331] Optionally, the service area indicated by the second service domain information is the same as the service area indicated by the third service domain information.

[0332] Optionally, the service area indicated by the second service domain information is included in the service area indicated by the third service domain information.

[0333] For example, when the first network function network element is an NFc (e.g., an NWDAF) and the second network function network element is an NFp (e.g., a DCCF), if the second service domain information indicates service areas 1 and 2, the third service domain information carried in the CCA indicates service areas 1 and 2, and the first service domain information indicates service areas 1, 2, and 3, it indicates that the service area indicated by the second service domain information is the same as the service area indicated by the third service domain information and is included in the service area range indicated by the first service domain information. In this case, the DCCF determines that the verification of the first token is successful and provides the NWDAF with data within service areas 1 and 2.

[0334] For example, when the first network function network element is an NFc (e.g., DCCF) and the second network function network element is an NFp (e.g., data producer), if the second service domain information indicates service areas 1 and 2, the third service domain information carried in the CCA indicates service areas 1 and 2, and the first service domain information indicates service areas 1, 2, and 3, it indicates that the DCCF will not tamper with the service area information of the service requested by the third network function network element. In this case, the NFp determines that the verification for the first token is successful and provides the data within service areas 1 and 2 to the DCCF. Furthermore, the DCCF provides the data within service areas 1 and 2 to the NWDAF.

[0335] For example, when the first network function network element is an NFc (e.g., a DCCF) and the second network function network element is an NFp (e.g., a data producer), if the second service domain information sent by the DCCF indicates service area 1, the third service domain information carried in the CCA indicates service areas 1 and 2, and the first service domain information indicates service areas 1, 2, and 3, the NFp1 determines that the verification for the first token is successful and provides the data within service area 1 for the DCCF. If the second service domain information sent by the DCCF indicates service area 2, the third service domain information carried in the CCA indicates service areas 1 and 2, and the first service domain information indicates service areas 1, 2, and 3, the NFp2 determines that the verification for the first token is successful and provides the data within service area 2 for the DCCF. Furthermore, the DCCF provides the data within service areas 1 and 2 to the NWDAF.

[0336] In one implementation, the service request message may further include an identifier of the first network function network element, and the first token further includes an identifier of the first network function network element and an identifier of the third network function network element.

[0337] Specifically, the step of the second network function network element performing verification on the first token further includes the step of the second network function network element determining whether an identifier of the third network function network element carried in the first token is the same as the identifier of the third network function network element carried in the CCA and whether the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message; and the step of the second network function network element determining that the verification on the first token is successful if the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the CCA and the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message.

[0338] For example, if the identifier of the third network function network element carried in the first token is NWDAF_ID, the identifier of the third network function network element carried in the CCA is also NWDAF_ID, the identifier of the first network function network element carried in the first token is DCCF_ID, and the identifier of the first network function network element carried in the service request message is also DCCF_ID, this indicates that the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the CCA, and the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message. In this case, the second network function network element determines that the verification of the first token is successful.

[0339] In one implementation, the first token further includes another verification condition, and the second network function network element determines whether to provide a service to the first network function network element based on the another verification condition, wherein the another verification condition includes one or more of a service provider's NF instance identifier, a service provider's NF type, a service provider's single network slice selection assistance information, a service provider's network slice instance identifier, an expected identifier of an NF set to which the service provider belongs, an expected service name, and a validity period of the first token.

[0340] Specifically, the second network function network element performing verification on the first token further includes the second network function network element performing verification against another verification condition, and if the verification against the another verification condition is successful, the second network function network element determines that the verification on the first token is successful.

[0341] For example, another validation condition for the first token may further include that the expected service name is a data collection service, the validity period of the first token is 24 hours, the generation timestamp of the first token is 10:30, and the expected NFp type is a data producer function network element (Data producer NF). If the second network function network element is a data producer function network element, and the service request message received by the second network function network element is used to request data collection and the current timestamp is 23:30, this indicates that the first token is still within the validity period, which indicates that the validation against the other validation condition has been successful. In this case, the second network function network element determines that the validation against the first token has been successful.

[0342] In one implementation, if any one of the following conditions is met, the second network function network element determines that verification of the first token has failed, and the second network function network element refuses to provide service to the first network function network element:

[0343] The conditions include one or more of the following: the service area indicated by the second service domain information is outside the service area range indicated by the first service domain information; the service area indicated by the second service domain information is outside the service area range indicated by the third service domain information carried in the CCA; the identifier of the third network function network element carried in the first token is different from the identifier of the third network function network element carried in the CCA; the identifier of the first network function network element carried in the first token is different from the identifier of the first network function network element carried in the service request message; or verification based on another verification condition has failed.

[0344] In other words, when the second network function network element performs verification on the parameters carried in the first token, if the verification based on any condition fails, it refuses to provide service to the first network function network element. For example, the second service domain information carried in the service request message indicates service area 1, while the first service domain information carried in the first token indicates service area 2. In this case, the first network function network element may access the service without authorization. Therefore, the second network function network element may determine that the verification on the first token has failed, and the second network function network element may refuse to provide service to the first network function network element. Optionally, the second network function network element sends a response message to the first network function network element indicating that the service request has failed. Optionally, a cause of denial is carried, i.e., the area of ​​the service requested by the first network function network element is outside the authorized service area range.

[0345] S540: The second network function network element provides a service to the first network function network element.

[0346] In response, the first network function network element receives the service from the second network function network element.

[0347] Based on the aforementioned step S530, the second network function network element provides a service, such as a data collection service or a model acquisition service, to the first network function network element only if the verification of the first token is successful. For example, the second network function network element sends a service response message to the first network function network element. The service response message may be an NF Service response message. For example, the service response message includes data or a model.

[0348] For example, in the case of a data collection service, a data collection coordination function network element (e.g., DCCF) may receive data from a second network function network element (e.g., data producer function network element) and then forward the data to a third network function network element (e.g., NWDAF). In the case of a model acquisition service, upon successful validation of the first token, the second network function network element (e.g., NWDAF MTLE) may acquire a model from an analytical data repository function network element and then forward the model to the first network function network element (e.g., NWDAF AnLF).

[0349] According to the solution provided in the present application, in a process in which a first network function network element requests a service from a second network function network element, the second network function network element determines whether the first network function network element is authorized to use the service based on the first token carried in the service request message, and compares the first service domain information, network element identifier, or another verification condition, etc. carried in the first token with the service domain information, network element identifier, or another verification condition, etc. carried in the service request message, to prevent a malicious NF service consumer from using the first token to obtain a service without authorization, thereby ensuring network security.

[0350] Next, an example in which the NF service consumer is an NFc, the NF service producer is an NFp, the authorization function network element is a network repository function network element NRF, the data collection and coordination function network element is a DCCF, and the NFc requests to obtain data from the NFp via the DCCF will be used to explain the solution for improving the authorization granularity of access tokens, with reference to Figures 6 to 8.

[0351] 6 is a schematic flowchart of a communication method 600 according to an embodiment of the present application. In the method, an NFc is authorized to receive data from an NFp via a DCCF. To solve the problems of cross-area unauthorized access and data leakage of the NFc, service domain information is added to the authorization token, and the service domain information is added to the service request procedure, and data is provided when the verification against the service domain information of the NFc is successful. As shown in FIG. 6, the method includes the following steps:

[0352] S601: The NFc (eg, NWDAF) sends an access token request message #a to an authorization server (eg, NRF).

[0353] In response, the NRF receives an access token request message #a from the NFc.

[0354] The access token request message #a includes the NF instance ID of the NFc, service domain information #1 (i.e., the fourth service domain information), expected NF service name(s) (e.g., expected NF service name(s) such as data collection), and expected NF type (e.g., data collection coordination function network element DCCF).

[0355] Optionally, the access token request message #a may further include, but is not limited to, the NF type of the NFc, an expected NSSAI list or NSI ID list of the NFp, an expected NF Set ID of the NFp, an S-NSSAI list of the NFc, etc.

[0356] For example, the access token request message #a may be an Nnrf_AccessToken_GetRequest message.

[0357] Optionally, the service domain information #a may be a Serving Area, an Area of ​​interest, a Service Area, a TAI, etc. For specific definitions, please refer to the related description of the method 500. It should be understood that the above names are merely examples provided to facilitate understanding of the solution, and the service domain information #a may alternatively have other names, which are not specifically limited in the present application.

[0358] S602: The NRF authorizes the NFc and generates token#a (i.e., the first token).

[0359] Token #a includes service domain information #2 (i.e., first service domain information). It should be understood that the scope of service domain information #2 may be the same as or different from the scope of service domain information #1. This depends primarily on the scope in which NFc requests to use the service (i.e., NFc is allowed to use the service in the service domain) and the service scope that can be obtained by NFc and stored in the NRF.

[0360] For example, the service range indicated by service domain information #1 sent by the NFc is area #1, and the NFc Profile stored in the NRF indicates that the service areas that can be authorized for the NFc are area #1 and area #2. In this case, service domain information #2 authorized by the NRF may indicate area #1, i.e., the NFc has permission to access NF services within area #1. Alternatively, the service range indicated by service domain information #1 sent by the NFc is area #1, and the NFc Profile stored in the NRF indicates that the service areas that can be authorized for the NFc are area #2 and area #3. In this case, service domain information #2 authorized by the NRF does not include area #1, i.e., the NFc does not have permission to access NF services within area #1, and the NRF may reject the token request. Alternatively, the service areas indicated by the service domain information #1 sent by the NFc are area #1 and area #3, and the NFc Profile stored in the NRF indicates that the service areas that can be authorized for the NFc are area #1 and area #2. In this case, the service domain information #2 authorized by the NRF may indicate area #1, i.e., the NFc has permission to access NF services in area #1, or the NRF may reject the token request. This is not specifically limited in this application. Note that the service area authorized for the NF service is the subject of the authorized service domain information #2 in token #a.

[0361] It should be understood that Service Domain Information #2 may indicate that the NFc is authorized to initiate a service within the service area or that the NFc is authorized to acquire data within the service area. For example, the service requested by the NFc is data collection, and the data has a target area content, e.g., the area to which the data belongs. The authorized access area of ​​the data is, for example, the area in which the NFc is allowed to collect data. Similarly, the service requested by the NFc is model acquisition, and the authorized access area of ​​the model is, for example, the area in which the NFc is allowed to use the model. In particular, if the service is data collection or model acquisition, the scope of the service requested by the NFc needs to be included in the access area authorized by the NRF to collect data or use the model.

[0362] Furthermore, for an implementation form in which the NRF authorizes the NFc, please refer to the related description of step S202 in method 200. For the sake of brevity, the details will not be described again here.

[0363] S603: The NRF sends an access token response message #a to the NFc.

[0364] In response to this, the NFc receives an access token response message #a from the NRF.

[0365] The access token response message #a indicates that the NFc is authorized to access the DCCF, and the access token response message #a includes the token #a.

[0366] Optionally, the access token response message #a may further include the validity period of the token #a, and the token #a can usually be reused within the validity period.

[0367] For example, the access token response message #a may be an Nnrf_AccessToken_Get Response message.

[0368] S604: The NFc sends an NF service request message #a (i.e., a service request message) to the DCCF.

[0369] In response, the DCCF receives an NF service request message #a from the NFc.

[0370] The NF service request message #a is used to request access to the NFp to obtain data. The NF service request message #a includes a token #a, service domain information #3 (i.e., second service domain information), and a CCA (e.g., CCA_NWDAF). The CCA is used by the NRF or NFp to perform identity verification with the NFc. The CCA includes service domain information #4 (i.e., third service domain information).

[0371] Note that both service domain information #3 and service domain information #4 are subsets of the authorized service domain information #2 in token #a. For example, if the service areas indicated by service domain information #2 are area #1 and area #2, the service areas indicated by service domain information #1 and service domain information #3 may be area #1 and / or area #2, and cannot exceed the range of the service area authorized by token #a, to prevent the NFc from accessing the service without authorization. For example, the service areas indicated by service domain information #1 and service domain information #3 may be the same, area #1.

[0372] For example, the NF service request message #a may be an NF Service Request message, or may be, for example, an Ndccf_DataManagement_Subscribe message.

[0373] S605: DCCF performs verification on token#a and executes the service after the verification is successful.

[0374] For the specific verification method of token#a, the specific meaning of token#a, and the information contained in token#a, please refer to the relevant description of step S205 in method 200. For the sake of brevity, the details will not be described again here.

[0375] For example, the DCCF compares the service area indicated by service domain information #2 carried in token #a with the service area indicated by service domain information #3 carried in the NF service request message #a to ensure that the service area of ​​the service requested by the NFc belongs to the service area authorized by the NRF. Optionally, the DCCF may also verify whether the service area indicated by service domain information #4 carried in the CCA belongs to the service area indicated by service domain information #2 in token #a authorized by the NRF, and whether the service area range indicated by service domain information #4 carried in the CCA is equal to the service area indicated by service domain information #3 carried in the NF service request message #a.

[0376] Therefore, only if, based on the verification in step S205, it is determined that token#a is issued by the NRF and has not been maliciously tampered with, the area indicated by service domain information #3 is included in the area indicated by service domain information #2, and optionally, the area indicated by service domain information #3 is equal to the area indicated by service domain information #4, the DCCF determines that the verification for token#a is successful and can perform the subsequent service.

[0377] S606: DCCF determines NFp.

[0378] Specifically, for an implementation form in which the DCCF determines the NFp, please refer to the relevant description of step S206 in method 200. For brevity, the details will not be described again here. Note that when selecting the NFp, the DCCF needs to further consider the service domain information of the NFc carried in token#a, i.e., perform selection to provide service within the corresponding service area of ​​the NFc. For example, if the service area authorized by token#a is area#1 and the service area indicated by the service domain information#3 carried in the NF service request message#a is area#1, the NFp selected by the DCCF has the ability to provide data to area#1.

[0379] Optionally, the number of NFp is not limited in this application. For example, if the service area indicated by the service domain information #3 carried in the NF service request message #a is area #1 and area #2, the NFp selected by the DCCF can provide data in both area #1 and area #2. Alternatively, the NFp1 selected by the DCCF may provide data in area #1, and the NFp2 selected by the DCCF may provide data in area #2. The difference is that when there are multiple NFp, the following steps S607 to S612 are executed multiple times in sequence.

[0380] S607: The DCCF sends an access token request message #b (i.e., a token request message) to the NRF.

[0381] In response, the NRF receives an access token request message #b from the DCCF.

[0382] The access token request message #b includes the NF instance ID of the NFc, the NF instance ID of the DCCF, the CCA (e.g., carrying service domain information #4), service domain information #5 (i.e., the fourth service domain information), the expected NF service name (e.g., data collection), and the expected NFp type (e.g., data producer function network element Data producer NF).

[0383] Optionally, if there is one NFp, the service area indicated by service domain information #5 is the same as the service area indicated by service domain information #3. If there are multiple NFp, the service area indicated by service domain information #5 is included in the service area indicated by service domain information #3.

[0384] Optionally, the access token request message #b may further include, but is not limited to, the NF type (e.g., NWDAF) of NFc, an expected NSSAI list or NSI ID list of NFp, an expected NF Set ID of NFp, an S-NSSAI list of NFc, etc.

[0385] For example, the access token request message #b may be an Nnrf_AccessToken_Get Request message.

[0386] S608: The NRF performs verification on the identities of the DCCF and the NFc, and generates token#b (i.e., the first token) after the verification is successful.

[0387] The first token includes service domain information #6 (ie, the first service domain information).

[0388] For example, the service area indicated by service domain information #6 is the same as the service area indicated by service domain information #5.

[0389] For example, the NRF checks whether the DCCF and NFc are allowed to access the services provided by the determined NFp. For example, the NRF performs identity verification on the DCCF and NFc according to one of the SBA methods.

[0390] Furthermore, if an NFp can provide data in all areas requested in the NF service request message #b, the DCCF may select one NFp. In this case, the service area indicated by service domain information #5 may be the same as the service area indicated by service domain information #3. Furthermore, to ensure secure network communications, the NRF may further determine whether the service area indicated by service domain information #5 is equal to the service area range indicated by service domain information #4 carried in the CCA to ensure that the DCCF or another network element does not maliciously tamper with the service domain information requested by the NFc. If the DCCF can select two NFp, i.e., NFp1 and NFp2, can provide data within area #1 and area #2, respectively, requested in the NF service request message #b, it indicates that the service area indicated by service domain information #5 is included in the service area indicated by service domain information #4. Furthermore, the NRF may further determine whether the service area indicated by service domain information #5 is included in the service area range indicated by service domain information #4 to ensure secure network communication and to ensure that the DCCF or another network element does not maliciously tamper with the service domain information requested by the NFc. It should be understood that the NRF determines that the verification is successful and generates token #b only if it determines that the service area indicated by service domain information #5 is included in the service area range indicated by service domain information #4.

[0391] Specifically, for an implementation in which the NRF performs verification on the identities of the DCCF and the NFc and generates token#b, please refer to the relevant description of step S208 in method 200. For the sake of brevity, the details will not be described again here.

[0392] For example, token#b generated by the NRF includes the NF instance ID of NFc, the NF instance ID of DCCF, and service domain information #2. In other words, for the authorized service area in token#b, both service domain information #1 requested in step S607 and service domain information #3 carried in the CCA need to be considered.

[0393] S609: The NRF sends an access token response message #b to the DCCF.

[0394] In response to this, the DCCF receives an access token response message #b from the NRF.

[0395] The access token response message #b indicates that the NFc and DCCF are authorized to access the NFp, and the access token response message #b includes the token #b.

[0396] Optionally, the access token response message #b may further include the validity period of the token #b, and the token #b can usually be reused within the validity period.

[0397] For example, the access token response message #b may be an Nnrf_AccessToken_Get Response message.

[0398] S610: The DCCF sends an NF service request message #b (i.e., a service request message) to the NFp.

[0399] In response, the NFp receives an NF service request message #b from the DCCF.

[0400] The NF service request message #b is used to request to obtain data, and the NF service request message #b includes service domain information #7 (i.e., the second service domain information), token #b (carrying service domain information #6), and CCA (carrying service domain information #4).

[0401] For example, the service area indicated by service domain information #7 is the same as the service area indicated by service domain information #5, the service area indicated by service domain information #7 is included in the service area indicated by service domain information #4, and the service area indicated by service domain information #7 is included in the service area indicated by service domain information #6.

[0402] For example, the NF service request message #b may be an NF Service Request message.

[0403] S611: The NFp performs verification on the token#b and provides the service after the verification is successful.

[0404] For example, the NFp compares the service domain information #6 in token #b with the service domain information #7 in the NF service request message #b to ensure that the service area indicated by the service domain information #7 is included in the service area range indicated by the service domain information #6. In addition, the NFp further determines whether the service area range indicated by the service domain information #4 in the CCA includes the service area indicated by the service domain information #7 in the NF service request message #b, to ensure that the service domain information #a requested by the NFc is not maliciously tampered with by the DCCF during the transmission process. Only when the verification of the above contents is guaranteed to be successful, the NFp determines that the verification of token #b is successful and can perform the subsequent service, i.e., provide data within the specified service area range (i.e., service domain information #7) for the DCCF.

[0405] Specifically, for an implementation in which the NFp performs verification of the identities of the NFc and DCCF and performs verification on another parameter carried in token#b, please refer to the relevant description of step S211 in method 200. For the sake of brevity, the details will not be described again here.

[0406] S612: The NFp sends an NF service response message #b to the DCCF.

[0407] In response to this, the DCCF receives an NF service response message #b from the NFp.

[0408] The NF service response message #b contains the data requested by the NFc.

[0409] For example, the NF service response message #b may be an NF Service Response via notification message.

[0410] It should be understood that NFp executes the service when the verification against token#b is successful. In the opposite case, NFp refuses to provide the service.

[0411] S613: The DCCF sends an NF service response message #a to the NFc.

[0412] In response to this, the NFc receives an NF service response message #a from the DCCF.

[0413] The NF service response message #a contains the data requested by the NFc.

[0414] For example, the NF service response message #a may be an NF Service Response via notification message.

[0415] According to the method disclosed in this application, service domain information is added to access tokens (e.g., token#a and token#b) to limit the range of services requested by the NFc, and the service is provided only if the NRF successfully verifies the service domain information. This can solve the problem of cross-area unauthorized access of the NFc, ensure network communication security, and improve user experience.

[0416] FIG. 7 is a schematic flowchart of a communication method 800 according to an embodiment of the present application. In the method, the NFc is authorized to receive data from the NFp via the DCCF. To solve the problems of cross-area unauthorized access and data leakage of the NFc, service domain information is added to the authorization token, and the service domain information is added to the service request procedure, and data is provided when the verification against the service domain information of the NFc is successful. Compared with method 600, in method 700, when the NFc requests to obtain an access token and requests to obtain an NF service, the service domain information may not be carried, and the NRF and DCCF may correspondingly complete authorization based on local policies. As shown in FIG. 7, the method includes the following steps:

[0417] S701: The NFc (eg, NWDAF) sends an access token request message #A (ie, a token request message) to an authorization function network element (eg, NRF).

[0418] In response, the NRF receives an access token request message #A from the NFc.

[0419] The access token request message #a includes the NF instance ID of the NFc, the expected NF service name (e.g., data collection), and the expected NF type (e.g., data collection coordination function network element DCCF).

[0420] Optionally, the access token request message #A may further include, but is not limited to, the NF type of the NFc, an expected NSSAI list or NSI ID list of the NFp, an expected NF Set ID of the NFp, an S-NSSAI list of the NFc, etc.

[0421] For example, the access token request message #A may be an Nnrf_AccessToken_GetRequest message.

[0422] S702: The NRF authorizes the NFc based on the local policy and generates token#A (i.e., the first token).

[0423] Token #A includes service domain information #a (i.e., first service domain information). Note that the authorized service area for the NF service is the subject of the authorized service domain information #a in token #A.

[0424] Optionally, the service domain information #a may be a Serving Area, an Area of ​​interest, a Service Area, a TAI, etc. For specific meanings of the service domain information #a, please refer to the relevant description of step S701 in method 700. For the sake of brevity, the details will not be described again here.

[0425] For example, when the NFc requests to obtain an access token, the NRF may further authorize the NFc to request NF services within area #1 and area #2 from the NFp based on the NF service areas, e.g., area #1 and area #2, supported by the capabilities of the NFc indicated in the locally stored NFc Profile. In other words, the service domain information #a includes information indicating area #1 and area #2.

[0426] S703: The NRF sends an access token response message #A to the NFc.

[0427] In response, the NFc receives an access token response message #A from the NRF.

[0428] The access token response message #A includes token #A.

[0429] Optionally, the access token response message #A may further include the validity period of the token #A, and the token #A can usually be reused within the validity period.

[0430] For example, the access token response message #A may be an Nnrf_AccessToken_Get Response message.

[0431] S704: The NFc sends an NF service request message #A (i.e., a service request message) to the DCCF.

[0432] In response, the DCCF receives an NF service request message #A from the NFc.

[0433] The NF service request message #A is used to request access to the NFp to obtain data. The NF service request message #A includes service domain information #b (i.e., second service domain information), token #A, and a CCA (e.g., CCA_NWDAF) used by the NRF or NFp to perform identity verification with the NFc. The CCA includes service domain information #c (i.e., third service domain information). Note that both service domain information #b and service domain information #c are subsets of the authorized service domain information #a in token #A. For example, if the service areas indicated by service domain information #a are area #1 and area #2, the service areas indicated by service domain information #b and service domain information #c may be area #1 and / or area #2, and cannot exceed the range of the service area authorized by token #A, to avoid a case where the NFc accesses a service without authorization. For example, the service areas indicated by service domain information #b and service domain information #c may be the same, i.e., area #1.

[0434] For example, NF service request message #A may be an Ndccf_DataManagement_Subscribe message.

[0435] S705: DCCF performs verification on token#A and executes the service after the verification is successful.

[0436] For the specific verification method of token#a, the specific meaning of token#a, and the information contained in token#a, please refer to the relevant description of step S605 in method 600. For the sake of brevity, the details will not be described again here.

[0437] Specifically, for the verification of other information in token#A and other information included in token#A, please refer to the relevant description of step S605 in method 600. For the sake of brevity, the details will not be described again here.

[0438] S706: DCCF determines NFp.

[0439] Specifically, for an implementation form in which the DCCF determines the NFp, please refer to the related description of step S606 in method 600. For the sake of brevity, the details will not be described again here.

[0440] S707: The DCCF sends an access token request message #B (i.e., a token request message) to the NRF.

[0441] In response to this, the NRF receives an access token request message #B from the DCCF.

[0442] The access token request message #B includes service domain information #d (i.e., the fourth service domain information), the NF instance ID of NFc, the NF instance ID of DCCF, the CCA (carrying service domain information #c), the expected NF service name (e.g., data collection), and the expected NFp type (e.g., data producer function network element Data producer NF).

[0443] Optionally, if there is one NFp, the service area indicated by the service domain information #d is the same as the service area indicated by the service domain information #b. If there are multiple NFp, the service area indicated by the service domain information #d is included in the service area indicated by the service domain information #b.

[0444] Optionally, the access token request message #B may further include, but is not limited to, the NF type (e.g., NWDAF) of the NFc, an expected NSSAI list or NSI ID list of the NFp, an expected NF Set ID of the NFp, an S-NSSAI list of the NFc, etc.

[0445] For example, the access token request message #B may be an Nnrf_AccessToken_Get Request message.

[0446] S708: The NRF performs verification on the identities of the DCCF and the NFc and generates token#B (i.e., the first token).

[0447] The first token includes service domain information #e (ie, first service domain information).

[0448] For example, the service area indicated by service domain information #d is the same as the service area indicated by service domain information #e.

[0449] For example, the NRF checks whether the DCCF and NFc are allowed to access the services provided by the determined NFp based on the locally stored profiles of the DCCF and NFc.

[0450] Furthermore, if an NFp can provide data in all areas requested in the NF service request message #b, the DCCF may select one NFp. In this case, the service area indicated by service domain information #5 may be the same as the service area indicated by service domain information #3. Furthermore, to ensure secure network communications, the NRF may further determine whether the service area range indicated by service domain information #c carried in the CCA is equal to the service area indicated by service domain information #d carried in the access token request message #B to ensure that the DCCF or another network element does not maliciously tamper with the service domain information requested by the NFc. If the DCCF can select two NFps, i.e., NFp1 and NFp2, can provide data within area #1 and area #2, respectively, requested in the NF service request message #B, it indicates that the service area indicated by service domain information #d is included in the service area indicated by service domain information #c. Furthermore, the NRF may further determine whether the service area indicated by the service domain information #d is included in the service area range indicated by the service domain information #c to ensure secure network communication and to ensure that the DCCF or another network element does not maliciously tamper with the service domain information requested by the NFc. It should be understood that the NRF determines that the verification is successful and generates token #B only when it determines that the service area indicated by the service domain information #d is included in the service area range indicated by the service domain information #c.

[0451] S709: The NRF sends an access token response message #B to the DCCF.

[0452] In response to this, the DCCF receives an access token response message #B from the NRF.

[0453] The access token response message #B includes token #B.

[0454] Optionally, the access token response message #B may further include the validity period of the token #B, and the token #B can usually be reused within the validity period.

[0455] For example, the access token response message #B may be an Nnrf_AccessToken_Get Response message.

[0456] S710: The DCCF sends an NF service request message #B (i.e., a service request message) to the NFp.

[0457] In response, the NFp receives an NF service request message #B from the DCCF.

[0458] The NF service request message #B is used to request to obtain data, and the NF service request message #B includes service domain information #f (i.e., second service domain information), token #B (service domain information #e), and CCA (service domain information #c).

[0459] For example, the service area indicated by service domain information #f is the same as the service area indicated by service domain information #d, the service area indicated by service domain information #f is included in the service area indicated by service domain information #e, and the service area indicated by service domain information #f is included in the service area indicated by service domain information #c.

[0460] For example, NF service request message #B may be an NF Service Request message.

[0461] S711: The NFp performs verification on token#B and provides service after the verification is successful.

[0462] For example, the NFp compares the service domain information #e in token #B with the service domain information #f carried in the NF service request message #B to ensure that the service area indicated by the service domain information #f is included in the service area range indicated by the service domain information #e. In addition, the NFp further determines whether the service area range indicated by the service domain information #c in the CCA includes the service area indicated by the service domain information #f in the NF service request message #B, to ensure that the service domain information #A requested by the NFc is not maliciously tampered with by the DCCF during the transmission process. Only when the verification of the above contents is guaranteed to be successful, the NFp determines that the verification of token #B is successful and can perform the subsequent service, i.e., provide data within the specified service area range (i.e., service domain information #f) for the DCCF.

[0463] Specifically, for an implementation in which the NFp performs verification of the identities of the NFc and DCCF and performs verification on another parameter carried in token#B, please refer to the relevant description of step S611 in method 600. For the sake of brevity, the details will not be described again here.

[0464] S712: The NFp sends an NF service response message #B to the DCCF.

[0465] In response to this, the DCCF receives an NF service response message #B from the NFp.

[0466] The NF service response message #B contains the data requested by the NFc.

[0467] For example, NF service response message #B may be an NF Service Response via notification message.

[0468] S713: The DCCF sends an NF service response message #A to the NFc.

[0469] In response, the NFc receives an NF service response message #A from the DCCF.

[0470] The NF Service Response Message #A contains the data requested by the NFc.

[0471] For example, NF service response message #A may be an NF Service Response via notification message.

[0472] According to the method disclosed in this application, service domain information is added to access tokens (e.g., token#A and token#B) to limit the service scope requested by the NFc, and the service is provided only if the NRF successfully verifies the service domain information. This can solve the problem of cross-area unauthorized access of the NFc, ensure network communication security, and improve user experience.

[0473] 8 is a schematic flowchart of a communication method 800 according to an embodiment of the present application. In the method, the NFc requests the ADRF to obtain an ML model trained by the NFp. To solve the problems of cross-area unauthorized access and model leakage of the NFc, service domain information is added to the authorization token, and the service domain information is added to the service request procedure, and the model is provided when the verification against the service domain information of the NFc is successful. As shown in FIG. 8, the method includes the following steps:

[0474] S801: The NF service producer NFp (e.g., NWDAF MTLE) performs registration.

[0475] S802: The NF service consumer NFc (eg, NWDAF AnLF) performs registration.

[0476] For specific implementations of the registration in steps S810 and S802, please refer to steps S401 and S402 in method 400. For the sake of brevity, the details will not be described again here.

[0477] S803: The NFp encrypts an ML model that is not specified by 3GPP (registered trademark).

[0478] The specific encryption method is not limited to the embodiments of the present application.

[0479] S804: The NFp triggers the storage of the ML model.

[0480] For example, the NFp requests the ADRF to store an ML model, and the storage address is URL1.

[0481] S805: The ADRF sends the storage location of the ML model to the NFp.

[0482] For example, the storage location of the ML model in ADRF is URL2.

[0483] S806: Perform an MTLF discovery process between the NFc and the NRF.

[0484] For specific implementation forms of steps S803 to S806, please refer to steps S303 and S306 in method 300. For the sake of brevity, the details will not be described again here.

[0485] S807: The NFc sends an access token request message (ie, a token request message) to the NRF.

[0486] In response, the NRF receives an access token request message from the NFc.

[0487] The access token request message includes the NF instance ID of the NFc, expected NF service name(s) (e.g., expected NF service name(s) such as model get), expected NF type, and analysis ID. It should be understood that the analysis ID is associated with one or more ML models.

[0488] Optionally, the access token request message includes service domain information #A (ie, the fourth service domain information).

[0489] For example, the access token request message may be an Nnrf_AccessToken_Get Response message.

[0490] S808: The NRF sends an access token response message to the NFc.

[0491] In response, the NFc receives an access token response message from the NRF.

[0492] For example, if the access token request message in step S807 carries service domain information #A, the NRF performs verification on the service domain information #A carried in the access token request message based on the locally configured service domain information Service Area. If the request is permitted, i.e., if the service area indicated by the service domain information #A is included in the service area indicated by the service domain information locally configured in the NRF, the access token response message includes token #A, which includes service domain information #B (i.e., first service domain information) and the operator ID of the NFc. For example, if service domain information #A indicates area #1 but the locally configured service domain information in the NRF indicates area #2, the service domain information #B in token #A returned by the NRF to the NFc indicates area #2. In this case, service domain information #B is different from service domain information #A. As another example, if service domain information #A indicates area #1 and the service domain information configured locally in the NRF indicates area #1 and area #2, service domain information #B in token #A returned by the NRF to the NFc indicates area #1. In this case, service domain information #B is the same as service domain information #A.

[0493] Optionally, if the access token request message in step S807 does not carry service domain information #A, the NRF adds locally configured service domain information #B to token #A for subsequent token validation performed by the NFp. Note that the service area authorized for the NF service is subject to the authorized service domain information #B in token #A. The following embodiments are specifically described by using an example in which the access token request message in step S807 carries service domain information #A and the token #A in the access token response message in step S808 carries service domain information #B.

[0494] For example, the access token response message may be an Nnrf_AccessToken_Get Response message.

[0495] In other words, before step S808 is performed, the NRF needs to authorize the NFc. For specific implementation, please refer to the related description of step S202 in method 200. For brevity, the details will not be described again here.

[0496] S809: The NFc sends an ML model request message (ie, a service request message) to the NFp.

[0497] In response, the NFp receives an ML model request message from the NFc.

[0498] The ML model request message includes token#A, analysis ID, and service domain information#C (i.e., second service domain information), and token#A includes service domain information#B and the operator ID of the NFc.

[0499] For example, the ML model request message may be a model request message.

[0500] S810: The NFp executes verification on token#A.

[0501] For example, for an implementation in which the NFp performs verification on token#A, see step S310 in method 300. For brevity, the details will not be described again here. Furthermore, it should be particularly noted that the NFp needs to compare the service domain information #B in token#A with the service domain information #C carried in the ML model request message. Only when it is determined that the service area indicated by the service domain information #C is included in the service area indicated by the service domain information #B, the NFp determines that the verification on token#A is successful and can provide service to the NFc, i.e., perform the subsequent steps S811 to S813 to provide a model within the specified service area range (i.e., service domain information #C) to the NFc.

[0502] S811: The NFp sends a URL request message to the ADRF.

[0503] In response, the ADRF receives a URL request message from the NFp.

[0504] The URL request message includes a model association identifier (eg, a model correction ID) or URL2.

[0505] S812: The ADRF sends URL3 to the NFp.

[0506] In response, the NFp receives URL3 from the ADRF.

[0507] S813: The NFp sends URL3 or URL4 to the NFc.

[0508] In response, NFc receives URL3 or URL4 from NFp.

[0509] For specific implementation forms of steps S811 to S813, please refer to steps S311 to S313 in method 300. For the sake of brevity, the details will not be described again here.

[0510] According to the method disclosed in this application, service domain information is added to an access token (e.g., token#A) to limit the service range requested by the NFc. The NRF completes access authorization for a specific service area based on local configuration and provides services to the NFc only after successful verification of the service domain information. This can solve the problem of cross-area unauthorized access of the NFc, ensure network communication security, and improve user experience.

[0511] Above, a communication method embodiment of the present application has been described in detail with reference to Figures 1 to 8. Hereinafter, a communication device embodiment of the present application will be described in detail with reference to Figures 9 and 10. The description of the device embodiment corresponds to the description of the method embodiment, and therefore, it should be understood that for parts not described in detail, please refer to the above-mentioned method embodiment.

[0512] 9 is a block diagram of a communication device according to an embodiment of the present application. As shown in FIG. 9, the device 1000 may include a transceiver unit 1010 and a processing unit 1020. The transceiver unit 1010 is capable of communicating with the outside, and the processing unit 1020 is configured to process data. The transceiver unit 1010 may also be referred to as a communication interface or a transceiver unit.

[0513] In a possible design, the device 1000 may perform steps or procedures performed by a first network function network element (e.g., NFc) in the aforementioned method embodiments. The processing unit 1020 is configured to perform processing-related operations of the NFc in the aforementioned method embodiments. The transceiver unit 1010 is configured to perform reception / transmission-related operations of the NFc in the aforementioned method embodiments.

[0514] In another possible design, the device 1000 may perform steps or procedures performed by a second network function network element (e.g., NFp) in the aforementioned method embodiments. The transceiver unit 1010 is configured to perform reception / transmission-related operations of the NFp in the aforementioned method embodiments. The processing unit 1020 is configured to perform processing-related operations of the NFp in the aforementioned method embodiments.

[0515] In another possible design, the device 1000 may perform steps or procedures performed by an authorization function network element (e.g., NRF) in the aforementioned method embodiments. The transceiver unit 1010 is configured to perform reception / transmission-related operations of the NRF in the aforementioned method embodiments. The processing unit 1020 is configured to perform processing-related operations of the NRF in the aforementioned method embodiments.

[0516] It should be understood that device 1000 herein is embodied in the form of a functional unit. The term "unit" herein may refer to an application specific integrated circuit (ASIC), an electronic circuit, a memory and processor (e.g., a shared processor, a dedicated processor, or a group of processors) configured to execute one or more software or firmware programs, a combinational logic circuit, and / or another suitable component supporting the described functionality. In optional examples, those skilled in the art may understand that device 1000 may specifically be a transmitter in the above-described embodiments and may be configured to perform procedures and / or steps corresponding to the transmitter in the above-described method embodiments, or that device 1000 may specifically be a receiver in the above-described embodiments and may be configured to perform procedures and / or steps corresponding to the receiver in the above-described method embodiments. To avoid repetition, details will not be described again here.

[0517] The device 1000 in the above-described solution has a function for implementing corresponding steps performed by a transmitter in the above-described method, or the device 1000 in the above-described solution has a function for implementing corresponding steps performed by a receiver in the above-described method. The functions may be implemented using hardware or by using hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described functions. For example, a transceiver unit may be replaced with a transceiver (e.g., a transmitting unit in a transceiver unit may be replaced with a transmitter, and a receiving unit in a transceiver unit may be replaced with a receiver), and other units, such as a processing unit, may be replaced with a processor, and the transmitting and receiving operations and related processing operations in the method embodiments may be separately performed.

[0518] In addition, the transceiver unit may alternatively be a transceiver circuit (e.g., the transceiver circuit may include a receiver circuit and a transmitter circuit), and the processing unit may be a processing circuit. In the embodiments of the present application, the device in FIG. 9 may be a receiver or a transmitter in the aforementioned embodiments, or may be a chip or a chip system, such as a system on chip (SoC). The transceiver unit may be an input / output circuit or a communication interface. The processing unit is a processor, a microprocessor, or an integrated circuit integrated on a chip. This is not limited herein.

[0519] 10 illustrates another communication device 2000 according to an embodiment of the present application. As shown in FIG. 10, the device 2000 includes a processor 2010 and a transceiver 2020. The processor 2010 and the transceiver 2020 communicate with each other via an internal connection path. The processor 2010 is configured to execute instructions to control the transceiver 2020 to transmit and / or receive signals.

[0520] Optionally, the device 2000 may further include a memory 2030. The memory 2030 is in communication with the processor 2010 and the transceiver 2020 via an internal connection path. The memory 2030 is configured to store instructions. The processor 2010 may execute the instructions stored in the memory 2030.

[0521] In a possible implementation, the device 2000 is configured to implement procedures and steps corresponding to the first network function network element in the above method embodiment.

[0522] In another possible implementation, the device 2000 is configured to implement procedures and steps corresponding to the second network function network element in the above method embodiment.

[0523] In another possible implementation, the device 2000 is configured to implement procedures and steps corresponding to the authorization function network element in the above method embodiments.

[0524] It should be understood that the device 2000 may specifically be a transmitter or a receiver in the aforementioned embodiments, or may be a chip or a chip system. Correspondingly, the transceiver 2020 may be a transceiver circuit of a chip. This is not limited herein. Specifically, the device 2000 may be configured to perform steps and / or procedures corresponding to the transmitter or receiver in the aforementioned method embodiments.

[0525] Optionally, the memory 2030 may include read-only memory and random access memory and may provide instructions and data to the processor. A portion of the memory may further include non-volatile random access memory. For example, the memory may further store information about device types. The processor 2010 may be configured to execute instructions stored in the memory. When the processor 2010 executes the instructions stored in the memory, the processor 2010 is configured to perform the steps and / or procedures of the aforementioned method embodiments corresponding to the transmitter or receiver.

[0526] In the implementation process, the steps in the aforementioned method can be implemented using hardware integrated logic circuits in a processor or using instructions in the form of software. The steps of the method disclosed with reference to the embodiments of the present application may be directly executed by a hardware processor, or may be executed by a combination of hardware and software modules in a processor. The software modules may be located in a storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory, and the processor reads information in the memory and performs the steps of the aforementioned method together with the hardware of the processor. To avoid repetition, details will not be described again here.

[0527] It should be noted that the processor in the embodiments of the present application may be an integrated circuit chip and have signal processing capabilities. In the implementation process, the steps in the above-described method embodiments can be implemented using hardware integrated logic circuitry in the processor or using instructions in the form of software. The processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The processor in the embodiments of the present application may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc. The steps of the methods disclosed with reference to the embodiments of the present application may be performed directly by a hardware decoding processor or by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory, and the processor reads information in the memory and performs the above-described method steps together with the processor's hardware.

[0528] It will be understood that memory in embodiments of the present application may be volatile memory, non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM) used as an external cache. Many forms of RAM are available, such as, by way of example and not limitation, static random access memory, dynamic random access memory, synchronous dynamic random access memory, double data rate synchronous dynamic random access memory, extended synchronous dynamic random access memory, SyncLink dynamic random access memory, and direct Rambus random access memory. Note that memory for the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0529] 11 is a diagram of a chip system 3000 according to one embodiment of the present application. The chip system 3000 (which may also be called a processing system) includes a logic circuit 3010 and an input / output interface 3020.

[0530] The logic circuit 3010 may be a processing circuit in the chip system 3000. The logic circuit 3010 may be coupled to a storage unit and call instructions in the storage unit, so that the chip system 3000 can implement the methods and functions in the embodiments of the present application. The input / output interface 3020 may be an input / output circuit in the chip system 3000, which outputs information processed by the chip system 3000 or inputs data or signaling information to be processed into the chip system 3000 for processing.

[0531] In the solution, the chip system 3000 is configured to perform the operations performed by the first network function network element, the first network function network element, or the repository function network element in the above-mentioned method embodiments.

[0532] An embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions used to implement the method performed by a device (e.g., NFc, NFp, DCCF or ADRF, or NRF) in the above-mentioned method embodiments.

[0533] An embodiment of the present application further provides a computer program product including instructions, which, when executed by a computer, perform the method performed by the device (e.g., NFc, NFp, DCCF or ADRF, or NRF) in the aforementioned method embodiments.

[0534] An embodiment of the present application further provides a communication system including one or more of the aforementioned NFc, NFp, DCCF or ADRF, NRF, etc.

[0535] For the description of the relevant contents and beneficial effects of any one of the above-provided devices, please refer to the corresponding method embodiments provided above, and the details will not be described again here.

[0536] Those skilled in the art may recognize that, in combination with the examples described in the embodiments disclosed herein, the units and algorithm steps may be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether a function is implemented by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may implement the described functions using various methods for each specific application, but such implementation should not be considered to go beyond the scope of this application.

[0537] For convenience and simplicity of description, it can be clearly understood by those skilled in the art that the specific operation processes of the above-mentioned systems, devices, and units may refer to the corresponding processes in the above-mentioned method embodiments, and details will not be described again here.

[0538] In some embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other ways. For example, the described device embodiments are merely examples. For example, the division into units is merely a logical division of functionality. In actual implementations, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. Furthermore, the shown or depicted mutual couplings or direct couplings or communication connections may be implemented through some interfaces, and indirect couplings or communication connections between devices or units may be implemented in electrical, mechanical, or other forms.

[0539] The units described as separate parts may or may not be physically separate, and the parts presented as units may or may not be physical units, and may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual requirements to achieve the objectives of the solutions of the embodiments.

[0540] In addition, the functional units of the embodiments of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.

[0541] When a function is implemented in the form of a software functional unit and sold or used as an independent product, the function may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may essentially, or a portion that contributes to the prior art, or a portion of the technical solution may be implemented in the form of a software product. A computer software product is stored in a storage medium and includes several instructions for instructing a computer device to perform all or part of the steps of the method described in the embodiments of the present application. The aforementioned storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory, a random-access memory, a magnetic disk, or an optical disk.

[0542] The above description is merely a specific implementation of the present application. However, the scope of protection of the present application is not limited thereto. Any modifications or replacements that can be easily conceived by those skilled in the art within the technical scope disclosed in the present application shall fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims. [Explanation of symbols]

[0543] 100 Network Architecture 110 Terminal Devices 130 User Plane Function (UPF), UPF Network Function 131 Network Published Function (NEF) 132 Network Function Repository Facility (NRF) 133 Policy Control Function (PCF) 134 Unified Data Management (UDM) function, UDM network function 135 Unified Data Repository (UDR) Function 136 Network Data Analysis Facility (NWDAF) 137 Authentication Server Function (AUSF), AUSF Network Function 138 Access and Mobility Management Function (AMF) 139 Session Management Function (SMF), SMF Network Function 140 Radio Access Network (RAN), Data Network DN 200 Service Request Method 300 How to share models 400 How to share models 500 Communication Method 600 Communication Methods 700 Communication Methods 800 Communication Methods 1000 devices, communication equipment 1010 Transceiver Unit 1020 Processing Unit 2000 Devices, Communication Equipment 2010 processor 2020 Transceiver 2030 Memory 3000 Chip System 3010 Logic Circuits 3020 Input / Output Interface

Claims

1. 1. A communication method comprising: receiving, by a second network function network element, a service request message from a first network function network element, the service request message being used to request the second network function network element to provide a service to the first network function network element, the service request message including a first token and second service domain information, the second service domain information indicating a service area of ​​the service requested by the first network function network element, the first token including first service domain information, and the first service domain information indicating a service area range in which the first network function network element can obtain the service from the second network function network element; determining, by the second network function network element, whether to provide the service to the first network function network element based on the first token; A communication method, including:

2. determining, by the second network function network element, whether to provide the service to the first network function network element based on the first token, performing, by the second network function network element, a validation on the first token; determining, by the second network function network element, to provide the service to the first network function network element if the verification of the first token is successful; 2. The method of claim 1, comprising:

3. performing, by the second network function network element, a validation on the first token, performing, by the second network function network element, a verification of the integrity protection of the first token; If the verification of the integrity protection of the first token is successful, determining by the second network function network element whether the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information; determining, by the second network function network element, that the verification of the first token is successful if the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information; 3. The method of claim 2, comprising:

4. 4. The method of claim 1, wherein the service request message further includes a client credential assertion (CCA), the client credential assertion (CCA) including an identifier of a third network function network element and third service domain information, the third service domain information indicating a service area of ​​the service requested by the third network function network element.

5. The method comprises: determining, by the second network function network element, whether to provide the service to the first network function network element based on the CCA; and more specifically, determining, by the second network function network element, whether the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA; determining, by the second network function network element, to provide the service to the first network function network element if the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA; 5. The method of claim 4, comprising:

6. The service request message further includes an identifier of the first network function network element, and the first token further includes an identifier of the first network function network element and an identifier of the third network function network element, and the step of performing verification on the first token by the second network function network element includes: determining, by the second network function network element, whether the identifier of the third network function network element carried in the first token is the same as the identifier of the third network function network element carried in the CCA, and whether the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message; determining, by the second network function network element, that the verification of the first token is successful if the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the CCA and the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message; 6. The method of claim 5, further comprising:

7. The first token further includes another verification condition, and the method further comprises: determining, by the second network function network element, whether to provide the service to the first network function network element based on the other verification condition, wherein the other verification condition is one of the following: one or more of: an NF instance identifier of a service provider; an NF type of the service provider; single network slice selection support information of the service provider; a network slice instance identifier of the service provider; an expected identifier of an NF set to which the service provider belongs; an expected service name; and a validity period of the first token. including, steps, 7. The method of claim 6, further comprising:

8. The method comprises: determining, by the second network function network element, that the verification of the first token is successful if the verification based on the other verification condition is successful; 8. The method of claim 7, further comprising:

9. The method comprises: determining, by the second network function network element, that the validation of the first token has failed if any one of the following conditions is met: refusing, by the second network function network element, to provide the service to the first network function network element; and wherein the conditions are: the service area indicated by the second service domain information is outside the service area range indicated by the first service domain information; the service area indicated by the second service domain information is outside the service area range indicated by the third service domain information; the identifier of the third network function network element carried in the first token is different from the identifier of the third network function network element carried in the CCA; the identifier of the first network function network element carried in the first token is different from the identifier of the first network function network element carried in the service request message; or the verification based on the other verification condition has failed; 9. The method of claim 7 or 8, comprising one or more of:

10. The method according to claim 1 , wherein the service area indicated by the second service domain information is included in the service area range indicated by the first service domain information.

11. the service includes one of the following: a data collection service or a model acquisition service; If the service is the data collection service, the first service domain information indicates an area range in which the first network function network element can obtain data from the second network function network element; or 11. The method according to claim 1, wherein, when the service is the model acquisition service, the first service domain information indicates an area range in which the first network function network element can acquire a model from the second network function network element.

12. 1. A communication method comprising: Obtaining a first token by a first network function network element, the first token including first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain service from a second network function network element; sending a service request message by the first network function network element to the second network function network element, the service request message being used to request the second network function network element to provide the service to the first network function network element, the service request message including the first token and second service domain information, the second service domain information indicating a service area of ​​the service requested by the first network function network element; receiving, by the first network function network element, the service from the second network function network element; A communication method, including:

13. The step of obtaining the first token by the first network function network element includes: sending, by the first network function network element, a token request message to an authorization function network element, wherein the token request message includes an identifier of the service, an identifier of the first network function network element, and an identifier of the second network function network element or a network element type of the second network function network element; receiving, by the first network function network element, the first token from the authorization function network element; 13. The method of claim 12, comprising:

14. 14. The method of claim 13, wherein the token request message further includes fourth service domain information, the fourth service domain information indicating the service area of ​​the service requested by the first network function network element.

15. 15. The method of claim 14, wherein the token request message further includes a client credential assertion (CCA), the CCA including an identifier of a third network function network element and third service domain information, the third service domain information indicating a service area of ​​the service requested by the third network function network element.

16. The method of claim 15 , wherein the service request message further includes the CCA.

17. The method according to claim 12, wherein the service area indicated by the second service domain information is included in the service area range indicated by the first service domain information.

18. the service includes one of the following: a data collection service or a model acquisition service; If the service is the data collection service, the first service domain information indicates an area range in which the first network function network element can obtain data from the second network function network element; or 18. The method according to claim 12, wherein, when the service is the model acquisition service, the first service domain information indicates an area range in which the first network function network element can acquire a model from the second network function network element.

19. 1. A communication method comprising: receiving, by an authorization function network element, a token request message from a first network function network element, the token request message including an identifier of a service, an identifier of the first network function network element, and an identifier of a second network function network element or a type of the second network function network element; generating a first token by the authorization function network element when determining that the first network function network element is authorized to obtain the service, the first token including first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain the service from the second network function network element; transmitting, by the Authorization Function network element, the first token to the first Network Function network element; A communication method, including:

20. 20. The method of claim 19, wherein the token request message further includes fourth service domain information, the fourth service domain information indicating a service area of ​​the service requested by the first network function network element.

21. 21. The method of claim 20, wherein the token request message further includes a client credential assertion (CCA), the CCA including an identifier of a third network function network element and third service domain information, the third service domain information indicating a service area of ​​the service requested by the third network function network element.

22. The step of generating the first token by the authorization function network element includes: determining, by the authorization function network element, whether the service area indicated by the fourth service domain information is included in the service area range indicated by the third service domain information carried in the CCA; generating the first token when the authorization function network element determines that the service area indicated by the fourth service domain information is included in the service area range indicated by the third service domain information carried in the CCA; 22. The method of claim 21, comprising:

23. the service includes one of the following: a data collection service or a model acquisition service; If the service is the data collection service, the first service domain information indicates an area range in which the first network function network element can obtain data from the second network function network element; or 23. The method according to claim 19, wherein, when the service is the model acquisition service, the first service domain information indicates an area range in which the first network function network element can acquire a model from the second network function network element.

24. 1. A communication method comprising: Obtaining a first token by a first network function network element, the first token including first service domain information, the first service domain information indicating a service area range in which the first network function network element can obtain service from a second network function network element; sending, by the first network function network element, a service request message to the second network function network element and receiving, by the second network function network element, the service request message from the first network function network element, the service request message being used to request the second network function network element to provide the service to the first network function network element, the service request message including the first token and second service domain information, the second service domain information indicating a service area of ​​the service requested by the first network function network element; determining, by the second network function network element, whether to provide the service to the first network function network element based on the first token; A communication method, including:

25. determining, by the second network function network element, whether to provide the service to the first network function network element based on the first token, performing, by the second network function network element, a validation on the first token; determining, by the second network function network element, to provide the service to the first network function network element if the verification of the first token is successful; receiving, by the first network function network element, the service from the second network function network element; 25. The method of claim 24, comprising:

26. performing, by the second network function network element, a validation on the first token, performing, by the second network function network element, a verification of the integrity protection of the first token; If the verification of the integrity protection of the first token is successful, determining by the second network function network element whether the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information; determining, by the second network function network element, that the verification of the first token is successful if the service area indicated by the second service domain information belongs to the service area range indicated by the first service domain information; 26. The method of claim 25, comprising:

27. The step of obtaining the first token by the first network function network element includes: sending, by the first network function network element, a token request message to an authorization function network element; and receiving, by the authorization function network element, the token request message from the first network function network element, wherein the token request message includes an identifier of the service, an identifier of the first network function network element, and an identifier of the second network function network element or a network element type of the second network function network element; generating, by the authorization function network element, the first token when determining that the first network function network element is authorized to obtain the service, the first token including the first service domain information, the first service domain information indicating the service area range in which the first network function network element can obtain the service from the second network function network element; transmitting, by the Authorization Function network element, the first token to the first Network Function network element and receiving, by the first Network Function network element, the first token from the Authorization Function network element; 27. The method of any one of claims 24 to 26, comprising:

28. 28. The method of claim 27, wherein the token request message further includes fourth service domain information, the fourth service domain information indicating the service area of ​​the service requested by the first network function network element.

29. 29. The method of claim 28, wherein the token request message further includes a client credential assertion (CCA), the CCA including an identifier of a third network function network element and third service domain information, the third service domain information indicating a service area of ​​the service requested by the third network function network element.

30. 30. The method of claim 29, wherein the service request message further includes the CCA.

31. The step of generating the first token by the authorization function network element includes: determining, by the authorization function network element, whether the service area indicated by the fourth service domain information is included in the service area range indicated by the third service domain information carried in the CCA; generating the first token when the authorization function network element determines that the service area indicated by the fourth service domain information is included in the service area range indicated by the third service domain information carried in the CCA; 31. The method of claim 29 or 30, comprising:

32. The method comprises: determining, by the second network function network element, whether to provide the service to the first network function network element based on the CCA; and more specifically, determining, by the second network function network element, whether the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA; determining, by the second network function network element, to provide the service to the first network function network element if the service area indicated by the second service domain information is included in the service area range indicated by the third service domain information carried in the CCA; 32. The method of any one of claims 29 to 31, comprising:

33. The service request message further includes an identifier of the first network function network element, and the first token further includes an identifier of the first network function network element and an identifier of the third network function network element, and the step of performing verification on the first token by the second network function network element includes: determining, by the second network function network element, whether the identifier of the third network function network element carried in the first token is the same as the identifier of the third network function network element carried in the CCA, and whether the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message; determining, by the second network function network element, that the verification of the first token is successful if the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the CCA and the identifier of the first network function network element carried in the first token is the same as the identifier of the first network function network element carried in the service request message; 33. The method of claim 32, further comprising:

34. The first token further includes another verification condition, and the method further comprises: determining, by the second network function network element, whether to provide the service to the first network function network element based on the other verification condition, wherein the other verification condition is one of the following: one or more of: an NF instance identifier of a service provider; an NF type of the service provider; single network slice selection support information of the service provider; a network slice instance identifier of the service provider; an expected identifier of an NF set to which the service provider belongs; an expected service name; and a validity period of the first token. including, steps, 34. The method of claim 33, further comprising:

35. The method comprises: determining, by the second network function network element, that the verification of the first token is successful if the verification based on the other verification condition is successful; 35. The method of claim 34, further comprising:

36. The method comprises: determining, by the second network function network element, that the validation of the first token has failed if any one of the following conditions is met: refusing, by the second network function network element, to provide the service to the first network function network element; and wherein the conditions are: the service area indicated by the second service domain information is outside the service area range indicated by the first service domain information; the service area indicated by the second service domain information is outside the service area range indicated by the third service domain information; the identifier of the third network function network element carried in the first token is different from the identifier of the third network function network element carried in the CCA; the identifier of the first network function network element carried in the first token is different from the identifier of the first network function network element carried in the service request message; or the verification based on the other verification condition has failed; 36. The method of claim 34 or 35, comprising one or more of:

37. 37. The method according to claim 24, wherein the service area indicated by the second service domain information is included in the service area range indicated by the first service domain information.

38. the service includes one of the following: a data collection service or a model acquisition service; If the service is the data collection service, the first service domain information indicates an area range in which the first network function network element can obtain data from the second network function network element; or 38. The method of claim 24, wherein, when the service is the model acquisition service, the first service domain information indicates an area range in which the first network function network element can acquire a model from the second network function network element.

39. A communications device comprising one or more functional modules or network elements configured to perform a method according to any one of claims 1 to 11, or wherein the one or more functional modules or network elements are configured to perform a method according to any one of claims 12 to 18, or wherein the one or more functional modules or network elements are configured to perform a method according to any one of claims 19 to 23.

40. A communications device comprising a processor, the processor coupled to a memory, the processor configured to execute a computer program stored in the memory, such that the communications device performs the method of any one of claims 1 to 11, or the communications device performs the method of any one of claims 12 to 18, or the communications device performs the method of any one of claims 19 to 23.

41. 24. A communication system comprising a first network function network element, a second network function network element, and an authorization function network element, wherein the second network function network element is configured to perform the method of any one of claims 1 to 11, the first network function network element is configured to perform the method of any one of claims 12 to 18, and the authorization function network element is configured to perform the method of any one of claims 19 to 23.

42. 24. A computer-readable storage medium storing a computer program that, when executed, causes a computer to perform the method of any one of claims 1 to 23.

43. 24. A computer program product, which when executed by a communications device performs the method of any one of claims 1 to 23.

Images