Communication method and apparatus

Abstract

The present application relates to the technical field of communications, and provides a communication method and apparatus. The method comprises: a first network function receiving a first message, the first message comprising first information, and the first information being used for instructing to check resource owner consent for invocation of a first API; and sending a first notification on the basis of the first information, the first notification being used for triggering a second network function or a third network function to perform checking of the resource owner consent for the invocation of the first API, the second network function being used for providing an API invocation main entry, and the third network function being used for providing the first API. On this basis, it can be known which APIs perform checking of resource owner consent, and which device is used to check the resource owner consent for the invocation of the APIs.

Description

Communication method and apparatus

[0001] Cross-reference to Related Applications

[0002] This application claims priority to the Chinese Patent Application No. 202410889939.1, filed on July 3, 2024, and entitled "A Communication Method and Apparatus", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] Embodiments of the present application relate to the field of communication technology, and in particular to a communication method and apparatus. BACKGROUND

[0004] In order to better run application services, operators can provide network services or network capabilities to applications in the form of application program interfaces (APIs). Based on this, the third generation partnership project (3GPP) defines a common application program interface framework (CAPIF) for the publication, discovery and management of APIs. Under this architecture, applications can conveniently and quickly use APIs.

[0005] Under this architecture, the 3GPP network can process some information containing user data. In particular for the processing of user data, the authorization of the user (i.e., resource owner) needs to be obtained, otherwise the user's privacy information can be exposed when the API is called. There are many service APIs in the existing CAPIF system, but not all service APIs need to perform resource owner consent checks, and the existing technology performs resource owner consent checks for each service API, introducing additional signaling and resource consumption. Based on this, there is an urgent need to provide a strategy for performing resource owner consent checks for API calls. SUMMARY

[0006] The present application provides a communication method and apparatus to determine which APIs to perform resource owner consent checks and which device to perform the checks.

[0007] In a first aspect, the present application provides a communication method applied to a first network function, wherein the first network function is a core function or an authorized function of a common API framework (CAPIF), for example, a CAPIF core function (CCF), and the first network function can be a specific device, chip or circuit, etc. in specific application. The following is executed:

[0008] receiving a first message, the first message comprising first information, the first information being used to indicate that a call of a first API needs to be checked for resource owner consent; and sending a first notification according to the first information, the first notification being used to trigger a second network function or a third network function to perform a check for resource owner consent for the call of the first API, the second network function being used to provide a total API call entry, and the third network function being used to provide the first API.

[0009] It should be noted that if the first information is used to indicate that the call of the first API does not need to be checked for resource owner consent, the first network function determines according to the first information that there is no need to trigger a check for resource owner consent for the call of the first API. In specific application, a second notification can be sent, the second notification being used to indicate that there is no need to perform a check for resource owner consent for the call of the first API, or the second notification can not be sent, and then the second network function or the third network function can default to not performing a check for resource owner consent for the call of the first API.

[0010] In the present application, after the first network function receives the first message and obtains the information used to indicate that the call of the first API needs to be checked for resource owner consent, the first network function sends the first notification according to the first information to trigger the second network function or the third network function to perform a check for resource owner consent for the call of the first API. Based on this, it can be determined which API needs to be checked for resource owner consent, and it can be avoided that a resource owner-aware northbound API access (RNAA) type API also needs to be checked for resource owner consent (ROC), thereby reducing signaling interaction and resource waste, and it can be determined which device is used to check for resource owner consent for the call of the API, thereby avoiding that the same RNAA type API needs to be checked for ROC multiple times, and reducing signaling interaction and resource waste.

[0011] In an optional mode, the first network function determines a first device that performs the check of the resource owner consent on the call of the first API, the first device being the second network function or the third network function; and sends a first notification to the first device, the first notification being used to trigger the first device to perform the check of the resource owner consent on the call of the first API.

[0012] Based on this, the first network function can explicitly send the first notification to which device, and the device that performs the check of the resource owner consent on the call of the first API can be explicitly determined, and flexible selection of the service API check node can be implemented.

[0013] In an optional mode, the first network function further sends a second notification to a second device, the second notification being used to indicate that the check of the resource owner consent on the call of the first API is performed by the first device, or indicate that the second device does not need to perform the check of the resource owner consent on the call of the first API, or indicate that the second device skips the check of the resource owner consent on the call of the first API, the second device being the second network function and a device other than the first device in the second network function.

[0014] Based on this, it can be determined which devices do not perform the check of the resource owner consent on the call of the first API, flexible selection of the service API check node can be implemented, repeated ROC check can be avoided, and signaling interaction and resource waste can be reduced.

[0015] In an optional mode, the first notification comprises identification information of the first API.

[0016] Based on this, it can be determined which API call performs the check of the resource owner consent, per API ROC check control can be implemented, ROC check on non-RNAA type API can be avoided, and signaling interaction and resource waste can be reduced.

[0017] In an optional mode, the first notification further comprises at least one of the following: check of the resource owner consent indication information on the call of the first API, check range of the resource owner consent on the call of the first API, or check entity information of the resource owner consent, the check range indicating check items of the call of the first API.

[0018] It should be noted that when the first notification includes the check indication information of the resource owner consent for the call of the first API, the second network function or the third network function can explicitly need to perform the check of the resource owner consent for the call of the first API. When the first notification includes the check range of the resource owner consent for the call of the first API, the second network function or the third network function can explicitly perform the check of the resource owner consent for which call of the first API or which resource. When the first notification includes the entity information of performing the check of the resource owner consent, so that the second network function or the third network function further confirms whether the check of the resource owner consent for the call of the first API needs to be performed, the control of the per API ROC check can be realized, the ROC check for the API of the non-RNAA type is avoided, and the signaling interaction and resource waste are reduced.

[0019] In an optional mode, the first network function determines the first device according to one or more of the following information: the resource owner consent capability information of the second network function, the resource owner consent capability information of the third network function, the second information, or the policy preconfigured by the first network function, the second information being used to indicate the preference of checking the resource owner consent for the call of the first API.

[0020] It should be noted that the first network function can explicitly determine whether the second network function or the third network function can perform the check of the resource owner consent for the call of the first API based on the resource owner consent capability information of the second network function and the resource owner consent capability information of the third network function. Based on the second information, which call of the first API or which resource performs the check of the resource owner consent can be determined, the content of the API access can be controlled in a more fine-grained manner, and the security is improved.

[0021] In an optional mode, the first network function receives the resource owner consent capability information of the second network function, and / or the resource owner consent capability information of the third network function.

[0022] Based on this, the first network function can obtain the resource owner consent capability information of the second network function and the resource owner consent capability information of the third network function. According to the resource owner consent capability information, the selected entity performing the ROC check can be more accurate, and the selection of a network function that cannot support the ROC check and finally leads to the failure of the ROC check is avoided.

[0023] In an optional mode, the first information is first attribute information of the first API, and the first attribute information represents the check of the resource owner consent for the call of the first API; or the first information is check indication information of the resource owner consent for the call of the first API.

[0024] It should be noted that when the first information is the first attribute information of the first API, the first network function can determine that the check of the resource owner consent needs to be triggered for the call of the first API after analyzing the first attribute information. When the first information is the check indication information of the resource owner consent for the call of the first API, the first network function can directly determine that the check of the resource owner consent needs to be triggered for the call of the first API. It can be ensured that the ROC check is only performed on the API that needs RNAA / ROC, and signaling and resource waste are reduced.

[0025] In an optional mode, the first message further includes second information, and the second information is used to indicate the preference of the check of the resource owner consent for the call of the first API.

[0026] Based on this, the first network function can explicitly select which entity to perform the check of the resource owner consent for the call of the first API. More flexible ROC checkpoint control can be achieved.

[0027] In an optional mode, the second information includes one of the following:

[0028] The second network function performs the check of the resource owner consent for the call of the first API; or, the third network function performs the check of the resource owner consent for the call of the first API; or, the priority of the check of the resource owner consent for the call of the first API performed by the second network function and the check of the resource owner consent for the call of the first API performed by the third network function.

[0029] Based on this, which entity to perform the check of the resource owner consent for the call of the first API can be explicitly selected. More flexible ROC checkpoint control can be achieved.

[0030] In an optional mode, the first message further includes: the check range of the resource owner consent of the first API, and the check range indicates the check items of the call of the first API.

[0031] Based on this, it can be explicitly determined which calls of the first API or which resources perform the check of the resource owner consent, and the content of API access can be controlled in a more fine-grained manner, and the security is improved.

[0032] In an optional mode, the check range includes: the caller of the call of the first API, the operation item of the call of the first API, and / or the operation resource of the call of the first API.

[0033] Based on this, it can be explicitly determined which calls of the first API or which resources perform the check of the resource owner consent, and the content of API access can be controlled in a more fine-grained manner, and the security is improved.

[0034] In an optional mode, the first message is from a fourth network function, the fourth network function is configured to publish API information, and the first message is an API publishing message; or, the first message is from a fifth network function, the fifth network function is configured to manage API information, and the first message is configured to configure a calling checking policy of the API.

[0035] Based on this, the ROC check on the calling of the first API can be performed. Through the API publishing or API management message, the information of performing the ROC check on the calling of the first API can be obtained more flexibly, and more flexibility is provided.

[0036] In a second aspect, the present application provides a communication method applied to a second network function, wherein the second network function is configured to provide an API calling total entry, for example, a boundary AEF, and the second network function is exemplarily illustrated herein but not specifically limited, and in actual application, the second network function can be a specific device, chip or circuit, etc. The following is performed:

[0037] receiving a first notification from a first network function, the first notification being configured to trigger the second network function to perform a resource owner consent check on a calling of a first API, the second network function being configured to provide an API calling total entry; receiving a calling request of the first API from a sixth network function, the sixth network function being an API calling entity; and performing the resource owner consent check on the calling of the first API according to the first notification.

[0038] In an optional mode, the first notification includes identification information of the first API.

[0039] In an optional mode, the first notification further includes at least one of the following:

[0040] the first API, or the resource owner consent check range of the first API, or the entity information of performing the resource owner consent check.

[0041] In an optional mode, after the second network function performs the resource owner consent check on the calling of the first API, the second network function sends indication information of completing the resource owner consent check on the calling of the first API to a third network function, and the third network function is configured to provide the first API.

[0042] Based on this, the third network function can explicitly not need to check the resource owner consent on the calling of the first API. The flexible selection of the service API checking node can be realized, the ROC check is avoided from being repeatedly performed, and the signaling interaction and resource waste are reduced.

[0043] In an optional mode, the first network function is a core function or an authorization function of a common API framework (CAPIF).

[0044] In a third aspect, the application provides a communication method applied to a second network function, wherein the second network function is configured to provide a total API calling entry, for example, a border AEF, and the second network function is exemplarily but not specifically limited to a specific device, chip or circuit, etc. The following is performed:

[0045] receiving a second message, the second message being configured to negotiate an entity performing a resource owner consent check on a first application program interface (API), the second message including information of the first API, and the second network function being configured to provide a total API calling entry; and determining, according to the second message, whether the second network function performs the resource owner consent check on the calling of the first API.

[0046] In the application, which API performs the resource owner consent check and which device is used to check the resource owner consent on the API calling is determined based on negotiation, and the scheme is more flexible. The scheme can realize that one AEF performs the ROC check on the service API, and reduces signaling interaction and resource waste.

[0047] In an optional mode, the second message further includes first information, and the first information is configured to indicate that the resource owner consent check is performed on the calling of the first API.

[0048] In an optional mode, the second message further includes second information, and the second information is configured to indicate a preference of the resource owner consent check on the calling of the first API.

[0049] In an optional mode, the second information includes one of the following:

[0050] The second network function performs the resource owner consent check on the calling of the first API; or the third network function performs the resource owner consent check on the calling of the first API, and the third network function is configured to provide the first API; or the second network function and the third network function perform the resource owner consent check on the calling of the first API, and the priority of the second network function and the third network function is determined.

[0051] In an optional mode, the second message further includes a checking range of the resource owner consent of the first API, and the checking range is configured to indicate a checking item of the calling of the first API.

[0052] In an optional mode, the checking range includes a caller calling the first API, an operation item of the calling of the first API, and / or an operation resource of the calling of the first API.

[0053] In an alternative way, the second network function sends a response message of the second message, the response message indicating that the checking of the resource owner consent for the first API is performed by the first device, the first device being the second network function or the third network function.

[0054] Based on this, other network functions can explicitly know which devices perform the checking of the resource owner consent for the first API. It can be achieved that one AEF performs the ROC check for a service API, reducing signaling interactions and resource waste.

[0055] In a fourth aspect, the present disclosure provides a communication apparatus, which can be the first network function, the second network function, etc. The communication apparatus has the functions of the first aspect to the third aspect, e.g., the communication apparatus includes modules or units or means corresponding to the steps of the first aspect to the third aspect. The functions or units or means can be implemented by software or by hardware, or by a combination of hardware and software.

[0056] In a possible design, the communication apparatus includes a processing unit and a transceiver. The transceiver can be configured to transceive signals to implement communication between the communication apparatus and another apparatus. The processing unit can be configured to perform some internal operations of the communication apparatus. The transceiver can be referred to as an input / output unit, a communication unit, etc. The transceiver can be a transceiver. The processing unit can be a processor, a processing circuit, a logic circuit, etc. When the communication apparatus is a module (e.g., a chip) in a communication device, the transceiver can be an input / output interface, an input / output circuit, an input / output pin, etc. The transceiver can also be referred to as an interface, a communication interface, or an interface circuit, etc. The processing unit can be a processor, a processing circuit, a logic circuit, etc.

[0057] In another possible design, the communication apparatus includes a processor, and can include a transceiver. The transceiver can be configured to transceive signals. The processor can execute program instructions to perform the methods in any possible design or implementation of the first aspect to the third aspect. The communication apparatus can further include one or more memories coupled to the processor. The memories can store the necessary computer programs or instructions for implementing the functions related to the first aspect to the third aspect. The processor can execute the computer programs or instructions stored in the memories. When the computer programs or instructions are executed, the communication apparatus can perform the methods in any possible design or implementation of the first aspect to the third aspect.

[0058] In yet another possible design of the communication apparatus, the communication apparatus includes a processor, which can be configured to be coupled with a memory. The memory can store computer programs or instructions necessary for implementing the functions related to the first aspect to the third aspect. The processor can execute the computer programs or instructions stored in the memory, and when the computer programs or instructions are executed, the communication apparatus can implement the method in any possible design or implementation manner of the first aspect to the third aspect.

[0059] In yet another possible design of the communication apparatus, the communication apparatus includes a processor and an interface circuit, where the processor is configured to communicate with other apparatuses through the interface circuit, and execute the method in any possible design or implementation manner of the first aspect to the third aspect.

[0060] It can be understood that, in the fourth aspect, the processor can be implemented by hardware or software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, or the like. When implemented by software, the processor can be a general-purpose processor, which implements the functions by reading software codes stored in the memory. In addition, the processor can be one or more, and the memory can be one or more. The memory can be integrated with the processor, or the memory and the processor can be separately arranged. In a specific implementation process, the memory and the processor can be integrated on the same chip, or can be separately arranged on different chips. The type of the memory and the arrangement manner of the memory and the processor are not limited in the embodiments of the present application.

[0061] In a fifth aspect, the embodiments of the present application provide a communication system, which includes the first network function, the second network function, the third network function, the fourth network function, the fifth network function, and the sixth network function, and the like. The first network function or the second network function is configured to implement the method in any possible design or implementation manner of the first aspect to the third aspect.

[0062] In a sixth aspect, the embodiments of the present application provide a chip system, which includes a processor and can further include a memory. The processor is configured to implement the method in the first aspect to the third aspect. The chip system can be composed of a chip, or can include the chip and other discrete devices. The memory is configured to store data related to the implementation of any possible design of the first aspect to the third aspect, for example, the association relationship. The processor is configured to implement the processing procedure related to any possible design of the first aspect or the second aspect. The chip system is not specifically limited herein.

[0063] In a seventh aspect, the present application provides a computer readable storage medium, which can be a volatile storage medium or a non-volatile storage medium, and the computer readable storage medium stores computer readable instructions, when the computer readable instructions are run on a computer, the computer is caused to perform the method in the first aspect to the third aspect.

[0064] In an eighth aspect, the present application provides a computer program product containing instructions, when the computer program product is run on a computer, the computer is caused to perform the method in the embodiments of the first aspect to the third aspect.

[0065] The technical effects achieved by the second aspect to the eighth aspect can refer to the technical effects achieved by the corresponding possible design schemes in the first aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0066] FIG. 1 shows a schematic diagram of a CAPIF architecture provided by the present application;

[0067] FIG. 2 shows a schematic diagram of another CAPIF architecture provided by the present application;

[0068] FIG. 3 shows a schematic diagram of still another CAPIF architecture provided by the present application;

[0069] FIG. 4 shows a flowchart of a communication method provided by the present application;

[0070] FIG. 5 shows a flowchart of a communication method provided by the present application;

[0071] FIG. 6 shows a flowchart of a communication method provided by the present application;

[0072] FIG. 7 shows a flowchart of a communication method provided by the present application;

[0073] FIG. 8 shows a flowchart of a communication method provided by the present application;

[0074] FIG. 9 shows a flowchart of a communication method provided by the present application;

[0075] FIG. 10 shows a flowchart of a communication method provided by the present application;

[0076] FIG. 11 shows a flowchart of a communication method provided by the present application;

[0077] FIG. 12 shows a structural diagram of a communication apparatus provided by the present application;

[0078] FIG. 13 shows a structural diagram of a communication apparatus provided by the present application. DETAILED DESCRIPTION

[0079] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings. The specific operation methods in the method embodiments can also be applied to the device embodiments or system embodiments. In the description of the present application, unless otherwise specified, the meaning of "a plurality of" is two or more. Therefore, the implementation of the device and the method can be referred to each other, and the repeated parts will not be described again.

[0080] The technical solutions provided by the embodiments of the present application can be applied to a 5G system or other similar communication systems. In addition, the technical solutions provided by the embodiments of the present application can be applied to a cellular link, a public land mobile network (PLMN), a machine to machine (M2M) network, an internet of things (IoT) network or other networks. It can also be applied to the link between devices, such as a device to device (D2D) link. The D2D link can also be referred to as a sidelink, and the sidelink can also be referred to as an edge link or a secondary link. In the embodiments of the present application, the above-mentioned terms all refer to the link established between devices of the same type, and have the same meaning. The so-called devices of the same type can be the link between terminal devices, or the link between base stations, or the link between relay nodes, etc., which are not limited by the embodiments of the present application.

[0081] As shown in FIG. 1, FIG. 1 is a CAPIF, and the network structure can be applied to a 4G or 5G communication system, and obviously can also be applied to other communication systems, which are not limited. The following briefly introduces each component in the CAPIF as follows:

[0082] API invoker: can also be referred to as API caller, generally a third-party application that signs a service agreement with a PLMN operator, such as an M2M application, an IoT application, a vehicle-to-everything (V2X) application, etc. These applications can run in a terminal device or a network device. For example, the API invoker can be a device in a PLMN network, such as a mobility management entity (MME) in a 4G communication system, a radio access network (RAN) node, or a policy and charging rules function (PCRF), etc. In a 5G communication system, the API invoker can be an access and mobility management function (AMF), a session management function (SMF), a user plane function (UPF), a policy control function (PCF), or an application function (AF) entity, etc. The API invoker can be used for: authenticating the API invoker by authenticating the identity and / or other information of the API invoker, obtaining authorization for calling an API before calling the API, discovering the API, and calling the API, etc.

[0083] CCF: can be used for authenticating an API invoker based on the identity and other information of the API invoker, for example, checking whether the API invoker is legal; supporting mutual authentication with the API invoker; providing authorization information for calling an API to the API invoker before the API invoker calls the API; publishing, storing, and supporting discovery of the API; performing access control of the API based on a policy of a PLMN operator; storing logs of API invocations and providing the logs to a function entity that is authorized to obtain the logs; performing charging based on logs of the API; detecting invocations of the API; registration of the API invoker; storing a configuration policy; supporting auditing of invocations and logs, etc.

[0084] API exposing function (application program interface exposing function, AEF): can provide APIs, and can also be an entrance for API calling entities to call APIs, for example, authenticating API calling entities based on the identification of the API calling entities and information provided by the CCF, receiving authentication and authorization information provided by the CCF, and synchronizing API logs to the CCF.

[0085] API publishing function (application program interface publishing function, APF): used to provide the function of API publishing, so that API calling entities can discover APIs.

[0086] API management function (application program interface management function, APIMF): used to provide management of APIs, for example, auditing API calling logs provided by the CCF, monitoring events reported by the CCF, configuring access and charging policies for APIs, detecting the state of APIs, and registering API calling entities.

[0087] CCF APIs refer to APIs provided by the CCF, which can be discovered and called by API calling entities, and mainly include some general type APIs, including registration type APIs, security authentication and authorization type APIs, API discovery type APIs, and the like.

[0088] Service APIs refer to APIs exposed by the AEF, which can be referred to as APIs on the AEF, and can be discovered and called by API calling entities. Mainly include some specific service type APIs, which can be used by API calling entities to use resources and services provided by operators, for example, QoS control type APIs, broadcast type APIs, IoT type APIs, and the like.

[0089] The API calling entity within the PLMN trusted domain can communicate with the CCF through CAPIF-1, and the API calling entity outside the PLMN trusted domain can communicate with the CCF through CAPIF-1e. CAPIF-1e needs to verify more information than CAPIF-1 to ensure the reliability of the API calling entity. The API calling entity within the PLMN trusted domain can communicate with the AEF through CAPIF-2, and the API calling entity outside the PLMN trusted domain can communicate with the AEF through CAPIF-2e. CAPIF-2e needs to verify more information than CAPIF-2 to ensure the reliability of the API calling entity. The AEF can communicate with the CCF through CAPIF-3. The APF can communicate with the CCF through CAPIF-4. The APIMF can communicate with the CCF through CAPIF-5.

[0090] It should be understood that if the AEF is a real API-providing AEF (which can be understood as an AEF that operates the API), the logic of the AEF for the API call is that the AEF provides the API for the API calling entity. If the AEF is not a real API-providing AEF, the logic of the AEF for the API call is that the AEF sends the API call request message to the real API-providing AEF. This is because when deploying CAPIF, the CCF can determine to use a topology hiding strategy for the API, that is, to select a topology-hidden entry point AEF (generally referred to as a border AEF, also referred to as a border AEF, which can be equally replaced in the following text) for the API. The border AEF, also known as the AEF entry point, is a special instance of the AEF, which serves as an entry point for all API calls in the system. The border AEF can implement a function of providing topology hiding for API invokers, and implement a function of dynamically routing API calls for other AEFs. When the API calling entity calls the API, the border AEF can determine the AEF that actually provides the API, and send the API call request to the AEF.

[0091] Based on this, the architecture of FIG. 1 is refined to obtain the architecture shown in FIG. 2. Among them, AEF-1 corresponds to a boundary AEF, through which Service API X can be called through AEF-2, and Service API Y can be called through AEF-3, wherein AEF-1 and AEF-2 (or AEF-3) can communicate through CAPIF-7 interface. The CAPIF-3 interface between CCF and AEF-2 is optional. When the CAPIF-3 interface exists between CCF and AEF-2, the access strategy control is completely controlled by AEF-1. When the CAPIF-3 interface does not exist between CCF and AEF-2, the access strategy control of AEF-2 can be controlled by AEF-2 itself. In the above two modes, when the application API topology is hidden, AEF-1 is the entry point (or interface point, interface) of the topology hiding, that is, the call of Service Y API must first contact AEF-1, and then AEF-1 performs real address hiding, finds the AEF that really provides the Service API, sends the call request to the corresponding AEF to execute the API logic, receives the call response sent by the corresponding AEF after execution, and AEF-1 performs internal node address hiding transformation and returns the call response to the API call entity.

[0092] It should be noted that in specific applications, CCF and boundary AEF can be arranged in one network element or device (CCF and boundary AEF (or gateway AEF) are deployed together to form an API gateway, and API callers (i.e., API call entities) discover service APIs from CCF in the API gateway, and then call service APIs from AEF functions in the API gateway), APF and AEF can be arranged in one network element or device (for example, each AEF can internally have the function of APF, and each AEF independently publishes its supported APIs to CCF), and APF and APIMF can be arranged in one network element or device (APF and APIMF can be two functional modules in an API management system). The present application does not specifically limit this and can be understood in combination with specific application scenarios.

[0093] The following first introduces three processes related to calling APIs in combination with the architectures of FIGS. 1 and 2.

[0094] 1. API publishing process

[0095] Step one, APF sends an API publishing request message to CCF.

[0096] The API publishing request message includes information of the API, which can include API name, AEF information (e.g., AEF identifier, version number, protocol used by the API, data format) of the AEF providing the API, interface description (IP address, port number, security method), API description information (e.g., application scenarios of the API, game acceleration, location acquisition, etc.), supported features of the API (e.g., features corresponding to different versions of the API), and the like.

[0097] Step two, after receiving the API publishing request message from the APF, the CCF checks whether the APF is authorized to publish the API. If the check passes, the CCF saves the information of the API received from the APF.

[0098] Step three, the CCF returns an API publishing response message to the APF.

[0099] The API publishing response message is used to indicate success or failure of the API publishing. In addition, the CCF can also send a notification message to an API calling entity subscribing to the API to notify the API calling entity of a new API or an API of interest to the API calling entity.

[0100] 2. API discovery process

[0101] In a case where the API calling entity has logged in and obtained an identifier of the API calling entity, and the CCF has configured a discovery strategy of the API calling entity, the following steps can be performed:

[0102] Step one, the API calling entity sends an API discovery request message to the CCF.

[0103] The API discovery request message includes an identifier of the API calling entity and API discovery filtering conditions.

[0104] Step two, the CCF receives the API discovery request message from the API calling entity, and authenticates the identity of the API calling entity according to the identifier of the API calling entity. If the API calling entity passes the authentication, the CCF searches for information of published APIs according to the API discovery filtering conditions and the strategy information of the API calling entity.

[0105] Step three, the CCF sends an API discovery response message to the API calling entity.

[0106] The API response message includes information of an API allowed to be used by the API calling entity. It should be understood that the information of the API can be information of one API, or information of multiple APIs.

[0107] 3. API calling process

[0108] Step one, the API calling entity sends an API calling request message to the AEF.

[0109] The API calling request message includes the identity (or security token token) of the API calling entity and the information of the API (such as the identity of the API).

[0110] Step two, the AEF receives the API calling request message from the API calling entity, and authenticates the identity of the API calling entity according to the identity of the API calling entity. If the API calling entity passes the authentication, the AEF executes the corresponding API logic.

[0111] Step three, the AEF sends an API calling response message to the API calling entity.

[0112] Specifically, in the above API publishing process, the APF sends an API publishing request message to the CCF, the CCF stores the information of the API included in the API publishing request message, and decides to apply a topology hiding policy to the API requested to be published by the APF. In this case, the CCF can select an AEF as the boundary AEF of the API. The CCF sends an API topology hiding notification message to the boundary AEF, which is used for the forwarding of the API calling request that may exist later. The API topology hiding notification message includes the information of the API and the information of the AEF providing the API. The boundary AEF receives the above topology hiding notification message from the CCF and saves the information therein. The CCF sends an API publishing response message to the APF. It should be understood that the topology hiding policy can be applied to all API calling entities or applied to part of the API calling entities.

[0113] Due to the application of the topology hiding policy, the CCF changes the information of the AEF actually providing the API to the information of the boundary AEF, and correspondingly modifies the interface information thereof, and provides it to the API calling entity in the API discovery process. At this time, the API calling entity obtains the boundary AEF and its interface information. The API calling entity can only send an API calling request to the boundary AEF. For a scenario where an API is provided by only one AEF, the boundary AEF can determine the AEF actually providing the API according to the identity of the API, and directly send an API calling request to the AEF actually providing the API.

[0114] For the scenario that one API can be provided by multiple AEFs (i.e. multiple AEFs can provide the same API), the border AEF can get the information of multiple AEFs providing the API after the API publishing procedure. It should be understood that one API or the same API referred to in this application refers to the API name and / or the API function is the same API. If the CCF does not apply the topology hiding policy to the above-mentioned API, the API calling entity can obtain the information of multiple AEFs providing the API, and then the API calling entity can decide which AEF to use and its interface information by itself. If the CCF applies the topology hiding policy to the above-mentioned API, the API calling entity can only send an API calling request to the border AEF.

[0115] In the subsequent standard evolution, the API call considering resource owner consent (resource owner consent aware, ROC) is considered, and the CAPIF architecture model is enhanced, and a resource owner client is added to the architecture of FIG. 1 or FIG. 2 to obtain the permission of the user for accessing the user's own resource from the resource owner. An authorization function is introduced in the CCF to save the permission (consent) of the user for accessing the user's own resource. FIG. 3 illustrates the case of adding a resource owner client to the architecture of FIG. 2 and introducing an authorization function in the CCF. In addition, the API accessed by the API invoker needs the consent of the resource owner, and more detailed granularity includes the consent of the resource owner to use which operation (for example, GET, PUT, PATCH, etc.), and the consent of the resource owner to access which resource. The AEF is responsible for checking the ROC of the API calling by the API invoker, and optionally, the ROC of the API calling by the API invoker is checked by including the interaction with the Authorization function in the CCF and the resource owner client, and after the check is passed, the authorized operation can be used to access the authorized resource.

[0116] There are many service APIs in the existing CAPIF system, but not all of them need to perform ROC checks, and the prior art performs ROC checks on each service API, introducing additional signaling and resource consumption. In addition, the related art can only allow the border AEF to perform ROC checks, which is not flexible enough and cannot guarantee that other AEFs do not perform ROC. Based on this, the present application provides a communication method to determine which APIs to perform resource owner consent checks on, and whether to use a border AEF or other AEFs for the checking strategy. Referring to FIG. 4, the method can be performed based on data interaction between a first network function, a fourth network function (or a fifth network function), and optionally a second network function (or a third network function), wherein the first network function is a core function or an authorization function of a general API framework CAPIF, such as a CCF. The fourth network function is used to publish API information, such as an APF. The fifth network function is used for API information management, such as an APIMF. The second network function is used to provide a total entry for API calls, such as an AEF of the border AEF type (which can also be understood as an AEF with a Border AEF function or role). The third network function is used to provide APIs for resource owner consent checks, such as an AEF that actually provides APIs, i.e., an AEF of the API-AEF type. In addition, the first network function and the second network function described above can be deployed in the same device, and the first network function and the second network function can transmit information through an interface inside the device, which will not be described here. The second network function and the third network function described above can exist in multiple CAPIF systems, and only one will be described below. The communication method performs as follows:

[0117] Step 401A, the first network function receives a first message from the fourth network function.

[0118] Step 401B, the first network function receives a first message from the fifth network function.

[0119] Among them, the steps 401A and 401B are executed alternatively. If the step 401A is executed, the first message is an API publishing message. If the step 401B is executed, the first message is used to configure the call checking strategy of the API, wherein the call checking strategy can indicate which API calls to perform resource owner consent (ROC for short, which can be understood equivalently below) checks, which API call operations to perform ROC checks, etc., which will not be described here, and can be understood by referring to the specific description below. Based on this, the ROC check can be performed on the first API call. Through the API publishing or API management message, the information that the ROC check is performed on the first API call can be obtained more flexibly, providing more flexibility.

[0120] It should be noted that when the first message is used to configure the API invocation checking policy, before receiving the first message, the first network function can also receive an API publishing message from the fourth network function, which can be understood with reference to step one in the above API publishing process, and will not be described here.

[0121] The first message includes first information, and the first information is used to indicate that the invocation of the first API checks the resource owner consent. The checking includes checking the API invocation itself (such as a signature token related to the resource owner consent) or further interacting with the resource owner function or the authentication function in the CCF to obtain the necessary permission. The interaction with the resource owner function can be through the authentication function in the CCF. Only the first API is taken as an example for description here, and in actual application, the first information can also indicate whether the invocations of multiple APIs check the resource owner consent, which is not specifically limited here and can be flexibly determined in actual application. The following describes how the first information indicates that the invocation of the first API checks the resource owner consent by taking the first API as an example and by considering different cases.

[0122] Case 1: The first information directly indicates that the invocation of the first API checks the resource owner consent

[0123] In one example, the first information can include multiple APIs, and the first information indicates that the invocations of the multiple APIs all check the resource owner consent, wherein the multiple APIs include the first API. In another example, the first information can include multiple APIs, and the first information indicates that the invocations of a part of the multiple APIs all need to check the resource owner consent, and the invocations of another part of the multiple APIs do not need to check the resource owner consent, wherein the part of the multiple APIs includes the first API. Based on the above examples, it can be known that the invocation of the first API checks the resource owner consent, and only exemplary descriptions are given here, and different indication cases of the first information are not specifically limited.

[0124] In a specific application, the first information can be first attribute information of the first API, and the first attribute information indicates that the call of the first API needs to check the resource owner consent. For example, the first API is an API of a resource owner-aware northbound API access (RNNA) type. When the first network function parses the first API and finds that the first API contains the first attribute information, the first network function determines that the call of the first API needs to check the resource owner consent. Alternatively, the first information is indication information of checking the resource owner consent for the call of the first API, for example, a user consent indication or a resource owner consent indication. This is only an example and does not specifically limit the specific form of the first information.

[0125] When the first information is the first attribute information of the first API, the first network function can determine, after parsing the first attribute information, that the call of the first API needs to check the resource owner consent. When the first information is the indication information of checking the resource owner consent for the call of the first API, the first network function can directly determine that the call of the first API needs to check the resource owner consent.

[0126] Case 2: The first information indirectly indicates that the call of the first API needs to check the resource owner consent

[0127] In an example, the first information can include a plurality of APIs, and the first information indicates that the calls of the plurality of APIs do not need to check the resource owner consent, where the plurality of APIs do not include the first API. The first network function determines, based on the first information, that the call of an API other than the plurality of APIs in the first information needs to check the resource owner consent, where the API other than the plurality of APIs in the first information includes the first API. Based on the above example, it can be known that the call of the first API needs to check the resource owner consent. This is only an example and does not specifically limit different indication situations of the first information.

[0128] In a specific application, the first information is other attribute information of the first API, and the other attribute information indicates that the call of the first API does not check the resource owner consent, for example, the first API is a non-resource owner-aware northbound API access (non-RNNA). When the first network function determines that the first API is not the API of the first attribute, or the information of the first API does not contain the non-RNAA attribute information, it is determined that the call of the first API does not check the resource owner consent. Alternatively, the first information is indication information that the call of the first API does not perform the check of the resource owner consent. Herein, only an example is illustrated, and the specific form of the first information is not specifically limited.

[0129] It should be noted that, by equivalent replacement, the first information is used to indicate that the call of the first API does not check the resource owner consent, and then the first network function determines, according to the first information, that there is no need to trigger the check of the resource owner consent for the call of the first API. In a specific application, a second notification can be sent, which is used to indicate that there is no need (or skip or omit) to perform the check of the resource owner consent for the call of the first API, or no notification can be sent, and then the second network function or the third network function can default that there is no need to perform the check of the resource owner consent for the call of the first API. In a specific application, when the first information indicates that the calls of a plurality of APIs do not check the resource owner consent, the first API is included in the plurality of APIs, and then the call of the first API does not check the resource owner consent. When the first information indicates that the calls of a part of the plurality of APIs do not check the resource owner consent, and the calls of another part of the plurality of APIs check the resource owner consent, the first API is included in the part of the plurality of APIs, and then the call of the first API does not check the resource owner consent.

[0130] When the first information is used to indicate that the call of the first API checks the resource owner consent, the first message further includes second information, which is used to indicate the preference of the call of the first API to check the resource owner consent. Based on this, the first network function can explicitly select which entity to perform the check of the resource owner consent for the call of the first API. The second information includes one of the following cases:

[0131] Case 1, the second network function performs a resource owner consent check for the first API call (for example, the border AEF performs a ROC check for the first API call). Exemplarily, the second information is identification information of the border AEF (for example, an identity of the border AEF, a communication address (IP address, MAC address, etc.) of the border AEF) or the type of the AEF is a border AEF. Involving specific applications, multiple border AEFs can be included in the CAPIF system, and multiple border AEFs can be used as an entry for the first API call. Then, the second information can specify which border AEF performs the resource owner consent check for the first API call. It can also be indicated that the AEF of the border AEF type performs the resource owner consent check for the first API call. The first network function selects a border AEF to perform the resource owner consent check for the first API call based on a preconfigured policy (or pre-stored information). For example, the border AEF1 is closer to the API-AEF corresponding to the first API or has lower call complexity, and the first network function can select the border AEF1 to perform the resource owner consent check for the first API call. The above is only illustrative and is not specifically limited.

[0132] Case 2, the third network function performs a check of resource owner consent for the invocation of the first API (e.g., the API-AEF corresponding to the first API performs a ROC check for the invocation of the first API). Exemplarily, the second information is identification information of the API-AEF (e.g., an identity of the API-AEF or a type of the API-AEF (API-AEF, i.e., the AEF providing the first API), a communication address of the API-AEF (IP address, MAC address, etc.)). In a specific application, there can be multiple API-AEFs providing the first API in the CAPIF system, and the first API can be invoked through the multiple API-AEFs. Then, the second information can indicate that the AEF of the API-AEF category performs a check of resource owner consent for the invocation of the first API. The second information can also indicate which API-AEF specifically performs the check of resource owner consent for the invocation of the first API. Correspondingly, the first network function can select all API-AEFs providing the first API to perform the check of resource owner consent for the invocation of the first API. Alternatively, the first network function can select one API-AEF to perform the check of resource owner consent for the invocation of the first API based on a preconfigured policy (or pre-stored information), e.g., API-AEF1 has a lower invocation complexity, and the first network function can select API-AEF1 to perform the check of resource owner consent for the invocation of the first API. The above is only exemplarily explained and is not specifically limited.

[0133] Case 3, the second network function performs the check of the resource owner consent for the first API and the third network function performs the check of the resource owner consent for the first API has priority. Exemplarily, the second information is a priority list of the border AEF and the API-AEF. Assuming that the priority level is sequentially increasing, priority 1 corresponds to the information of the second network function, and priority 2 corresponds to the information of the third network function, then the third network function is preferentially selected to perform the check of the resource owner consent for the first API. Herein, the indication manner of the priority is exemplarily described and is not specifically limited. When applied to a specific application, the CAPIF system can include multiple API-AEFs providing the first API, and the first API can be called through the multiple API-AEFs, and multiple border AEFs also exist, and the multiple border AEFs can be used as the total entry of the call of the first API. Then, the priority of each AEF in the multiple border AEFs and the multiple API-AEFs can be explicitly indicated in the second information, so that the first network function can determine which API-AEF is used to perform the check of the resource owner consent for the first API. Only the priority of the AEF of the border AEF type and the API-AEF type can be indicated, and correspondingly, the first network function can select all API-AEFs providing the first API to perform the check of the resource owner consent for the first API. The first network function selects an API-AEF (or a border AEF) to perform the check of the resource owner consent for the first API based on a preconfigured strategy (or pre-stored information), for example, the priority of the AEF of the border AEF type is lower than the API-AEF type, and the API-AEF1 has a lower call complexity, and the first network function can select the API-AEF1 to perform the check of the resource owner consent for the first API. The above is exemplarily described and is not specifically limited.

[0134] It is also to be noted that the preference of the check of the resource owner consent for the call of different APIs is usually different, and the preference of the check of the resource owner consent for the call of the API can be the same except for individual cases. For example, the preference of the first API for the check of the resource owner consent is the AEF of the border AEF type, and the preference of the second API for the check of the resource owner consent is the AEF of the API-AEF type. Herein, the above is exemplarily described and is not specifically limited.

[0135] Further, the first message can further comprise a check range of resource owner consent of the first API, the check range indicating check items of checking the call of the first API. Based on this, it can be determined which information needs to perform the check of resource owner consent when calling the first API. In addition, the check range of resource owner consent of the first API can also be indicated by the first information, which is not specifically limited here.

[0136] For example, the check range comprises a caller (such as an API invoker calling the first API) calling the first API, an operation item of the call of the first API, and / or an operation resource of the call of the first API.

[0137] For example, the operation item of the call of the first API is publishing (POST), obtaining (GET), placing (PUT), and deleting (DELETE), etc. For example, the first API is a QoS acceleration API, so the publishing of the first API needs to perform the ROC check; the first API is a positioning API, so the obtaining of the first API needs to perform the ROC check; the first API is a service parameter configuration, so the placing of the first API needs to perform the ROC check; the first API is a QoS acceleration, so the deleting of the first API needs to perform the ROC check. The above is only an example and is not specifically limited. When it comes to specific applications, for an API related to sensitive data (such as the location information of a party, the identity information of a party, etc.), the obtaining of the API needs to perform the ROC check (i.e., obtaining the permission of the party).

[0138] For example, the operation resource of the first API is location, QOS, etc. For example, the first API is a positioning API, so the location of the first API needs to perform the ROC check; the first API is a QoS acceleration, so the QOS of the first API needs to perform the ROC check. The above is only an example and is not specifically limited. When it comes to specific applications, for an API related to sensitive data (such as the identity information of a party, etc.), the operation resource of the API needs to perform the ROC check (i.e., obtaining the permission of the party).

[0139] When the first message is an API publishing message, the first information, the second information, and the check range of the resource owner's consent of the first API can be added as an extension parameter in a service API information element (i.e., service API information), or as a parameter of a new information element which can be parallel to the service API information element. The API publisher information element (i.e., API publisher information) can include identity information, authentication information, and authorization information of the published API, as shown in Table 1. In addition to the existing related description information such as service API name, service API type information, service API communication type, etc., the service API information element can also include the first information (wherein the check range of the resource owner's consent of the first API is indicated by the first information) and the second information. Alternatively, the indication information of the ROC check can indicate the first information (wherein the check range of the resource owner's consent of the first API is indicated by the first information), and the ROC check preference indicates the second information. In Table 1, the first information and the second information are indicated separately, but in actual application, the first information and the second information can also be indicated by one information element. This is only an example and is not limited thereto. In actual application, the API publishing information can also include other contents, which are not described herein and can be understood with reference to the prior art.

[0140] Table 1

[0141] In addition, it should be noted that when the first information indicates that the first API call does not check the resource owner's consent, the first information in Table 1 above cannot indicate the check range of the resource owner's consent of the first API, and the second information is not included in Table 1.

[0142] At step 402, the first network function sends a first notification according to the first information.

[0143] The first notification is used to trigger the second network function or the third network function to perform the check of the resource owner's consent on the call of the first API. It should be noted that the second network function or the third network function herein can specifically refer to a certain AEF, for example, a border AEF identified as 1 or an API-AEF identified as X. It can also refer to a type of second network function or a type of third network function, for example, any border AEF or any API-AEF providing the first API.

[0144] The first notification can be carried in a message sent by the CCF to the border AEF, for example, the message can be a ROC policy configuration / notification, also referred to as an access policy control with ROC check message. The first notification includes identification information of the first API, so that the second network function or the third network function knows which API call to perform resource owner consent check. In addition, the first notification further includes at least one of the following: indication information of performing resource owner consent check on the call of the first API, the scope of the resource owner consent check of the call of the first API, or entity information (for example, identification information of the second network function or the third network function) of performing the resource owner consent check. Based on this, it can be determined which calls of the first API need to perform resource owner consent check, and which network function performs resource owner consent check on the calls of the first API.

[0145] Specifically, the first network function can determine a first device that performs resource owner consent check on the call of the first API, the first device being the second network function or the third network function; and send the first notification to the first device, the first notification being used to trigger the first device to perform resource owner consent check on the call of the first API. For example, after obtaining the first information, the first network function determines that the second network function needs to be triggered to perform resource owner consent check on the call of the first API, and then sends the first notification to the second network function. Based on this, the first network function can determine to which device to send the first notification, so as to determine the device that performs resource owner consent check on the call of the first API, and the service API check node can be flexibly selected.

[0146] It should be noted that the first network function can determine the first device according to one or more of the following information: resource owner consent capability information of the second network function, resource owner consent capability information of the third network function, the second information, or a policy pre-configured by the first network function.

[0147] The first network function can obtain and store the resource owner consent capability information of the second network function from the registration information of the second network function when the second network function (herein specifically referring to a certain border AEF, rather than a border AEF) registers, and / or obtain and store the resource owner consent capability information of the third network function from the registration information of the second network function when the third network function (herein specifically referring to a certain API-AEF, rather than an API-AEF) registers. The first network function can also receive the resource owner consent capability information of the second network function from the second network function or other network functions (for example, an API management function), and / or receive the resource owner consent capability information of the third network function from the third network function or other network functions (for example, an API management function). The other network functions store the resource owner consent capability information of the second network function or the resource owner consent capability information of the third network function. In this case, how to obtain the resource owner consent capability information of the second network function and the resource owner consent capability information of the third network function is not specifically limited. For example, the first network function can obtain the information of the second network function / third network function from the registration request sent by the fifth network function to the first network function, wherein the information of the second network function / third network function contains the check capability information of whether to support the resource owner consent. For example, the first network function can obtain the information of the second network function / third network function from the registration request sent by the second network function (or the third network function), wherein the information of the second network function / third network function contains the check capability information of whether to support the resource owner consent.

[0148] Taking the resource owner consent capability information of the second network function as an example, the resource owner consent capability information of the third network function can be understood by reference. The resource owner consent capability information of the second network function can include the check of the resource owner consent supported by the second network function for the first API call, and the check range of the resource owner consent supported by the second network function for the first API, and the capability of the second network function to locally verify the token carried in the first API call request by the calling entity of the first API and related to the resource owner consent permission.

[0149] The strategy for the first network function's pre-configuration may involve a second network function (here referring to a type of border AEF) performing resource owner consent checks on calls to the first API, or a corresponding third network function (here referring to a type of API-AEF or a specific API-AEF, without limitation) performing resource owner consent checks on calls to the first API, or setting priorities for the second and third network functions, determining which network function performs resource owner consent checks on calls to the first API based on these priorities. This is merely an example and does not specifically limit the strategy for the first network function's pre-configuration.

[0150] For example, if the second network function does not support the capability to check resource owner consent, the first network function sends a first notification to the third network function. If the second network function supports the capability to check resource owner consent, and the first network function determines, based on its local call checking policy, that the second network function needs to perform the resource owner consent check, the first network function sends a first notification to the second network function. If the second network function supports the capability to check resource owner consent, and the first network function determines, based on its local call checking policy, that the second network function needs to perform the resource owner consent check, but the first message includes second information, the second information indicates that the first API's preference for checking resource owner consent is the third network function, and the first network function then sends a first notification to the third network function. If the second network function supports the capability to check resource owner consent, and the first network function determines, based on its local call checking policy, that the second network function needs to perform the resource owner consent check, but the first message includes second information and the scope of the first API's resource owner consent check, the second information indicates that the first API's preference for checking resource owner consent is the third network function, and the first network function then sends a first notification to the third network function, and through the first notification, indicates the scope of the first API's resource owner consent check. The above is merely illustrative and does not specifically limit how the first network function determines the first device or the specific information of the first notification sent to the first device.

[0151] Optionally, after the first network function sends a first notification to the second network function, the second network function receives a call request for the first API from the sixth network function, where the sixth network function is the API call entity. The second network function performs a check on the consent of the call resource owner for the first API based on the first notification, and then sends an indication message to the third network function indicating that the check on the consent of the call resource owner for the first API is complete. Based on this, the third network function may explicitly not need to perform (or skip, omit) the check on the consent of the call resource owner for the first API.

[0152] Optionally, the first network function further sends a second notification to a second device (wherein the second device is a device other than the first device among the second network function and the third network function), and the second notification is used to indicate that the check of the resource owner consent for the call of the first API is performed by the first device, or to indicate that the check of the resource owner consent for the call of the first API is not required to be performed (or skipped or omitted) by the second device. For example, the first device is the second network function, and the second device is the third network function. It should be noted that when multiple API-AEFs provide the first API, and the first network function determines that the check of the resource owner consent for the call of the first API is performed by the border AEF, the first network function sends the second notification to all API-AEFs providing the first API. In addition, when multiple border AEFs provide the first API call entry, and the first network function determines that the check of the resource owner consent for the call of the first API is performed by the API-AEF, the first network function sends the second notification to all border AEFs providing the first API call entry.

[0153] The second notification includes identification information of the first API, so that the third network function knows which API call does not perform the check of the resource owner consent. In addition, the second notification further includes at least one of the following: indication information of not performing the check of the resource owner consent for the call of the first API, or entity information (for example, identification information of the third network function) of performing the check of the resource owner consent. In the present application, the sending order of the first notification and the second notification is not limited. Based on this, it can be determined which device does not perform the check of the resource owner consent for the call of the first API, the flexible selection of the service API check node can be realized, the repeated ROC check can be avoided, and the signaling interaction and resource waste can be reduced.

[0154] In the present application, after the first network function receives the first message and obtains the information used to indicate the check of the resource owner consent for the call of the first API, the first network function sends the first notification according to the first information, so as to trigger the second network function or the third network function to perform the check of the resource owner consent for the call of the first API. Based on this, it can be determined which API performs the check of the resource owner consent, the ROC check can be avoided for the API of the non-RNAA type, the signaling interaction and resource waste can be reduced, and it can be determined which device checks the resource owner consent for the call of the API, the multiple ROC checks for the API of the same RNAA can be avoided, and the signaling interaction and resource waste can be reduced.

[0155] The following describes the data interaction between the API calling entity (i.e., the sixth network function), the CCF (i.e., the first network function), the APF (i.e., the fourth network function), the border AEF (i.e., the second network function), and the API-AEF (i.e., the third network function). The following description about FIGS. 5-7 is a specific description based on the APF sending a first message. FIG. 5 is a method for the CCF configuring the ROC calling checking policy of each API to the border AEF. One or more APIs that need ROC checking are indicated to the CCF by the APF at the time of API publishing, and then the CCF can determine the checking entity of a unique ROC check according to different local policies, AEF capabilities, etc., and respectively notify the border AEF and the API-AEF whether to perform ROC checking. In specific applications, other network functions can also be involved, which are not described here. After the following step 505, the API-AEF is only used to provide the calling entry of API-X, and the following is performed with reference to FIG. 5:

[0156] Step 501, the APF sends a first message to the CCF, and the first message includes first information (the first information can be understood with reference to the description above, which is not described here).

[0157] The first message is an API publishing message, for example, an API publish request. The specific information (the first information, the second information, etc.) included in the first message can be understood with reference to the corresponding description of steps 401A and 401B above, which is not described here.

[0158] Step 502, the CCF determines, according to the ROC capability information of the border AEF, the ROC capability information of the API-AEF, and the first information, that the border AEF performs the ROC check of the calling of one or more APIs.

[0159] The description of step 402 above can be understood, which is not described here.

[0160] Step 503, the CCF sends a response message of the first message to the APF.

[0161] The response message of the first message can be an API publish response.

[0162] The execution order of the above steps 502 and 503 is not limited. They can be executed simultaneously, or step 503 can be executed first and then step 502, or step 502 can be executed first and then step 503.

[0163] Step 504A, the CCF sends a first notification to the border AEF.

[0164] The first notification can indicate to the border AEF which API needs to perform the ROC check, and the scope of the resource owner consent check for the API invocation. Optionally, the first notification can further include the indication information for the API invocation to perform the ROC check. The above description of the first notification can be referred to for further understanding.

[0165] At step 504B, the CCF sends a second notification to the API-AEF.

[0166] The second notification can indicate to the API-AEF that the API-AEF does not need to perform (or skip, omit) the resource owner consent check for the API-X invocation, or the second notification can indicate to the API-AEF that the API-X invocation is subject to the ROC check by the border AEF. Optionally, the second notification can further include the indication information for the API invocation not to perform the ROC check. The above description of the second notification can be referred to for further understanding.

[0167] The indication information for the API invocation to perform the ROC check in step 504A or the indication information for the API invocation not to perform the ROC check in step 504B is to indicate to the peer whether the ROC check is performed or not performed for the indicated set of API invocations.

[0168] Further, the above steps 504A and 504B can be configured in API granularity, i.e. one API corresponds to one independent ROC check for the API invocation, or in multiple API granularity, i.e. one ROC check is effective for multiple APIs, or in other words, multiple APIs share one ROC check rule. For example, the first notification in step 504A triggers the border AEF to perform the ROC check for the API1 invocation.

[0169] At step 505, the API invocation entity initiates an API (e.g. API-X) invocation request message.

[0170] The destination address of the invocation request message is the border AEF.

[0171] At step 506, the border AEF determines, according to the first notification, that the API-X needs to perform the ROC check at the border AEF.

[0172] At step 507, the border AEF performs the ROC check for the API-X invocation.

[0173] Wherein, the ROC check includes checking the API call itself (e.g. signed token related to resource owner consent) or further interacting with resource owner function or authentication function in CCF to get necessary permission.

[0174] Wherein, the interaction with resource owner function can be through the authentication function in CCF.

[0175] In particular, it can be understood with reference to the existing related protocols, which are not expanded here.

[0176] Step 508, the border AEF sends (or forwards) the API call request message to the API-AEF.

[0177] Step 509, the API-AEF determines according to the second notification that the API-AEF does not need to perform ROC check, or skips ROC check, or omits ROC check for API-X.

[0178] Step 510, the API-AEF returns the call result of API-X.

[0179] In particular, the API-AEF can return the call result of API-X to the API call entity through the border AEF.

[0180] Through this scheme, the identification and policy configuration of API granularity API ROC check can be realized, so that in the CAPIF system, the service API of RNAA / ROC and the API of non-ROC / non-RNAA type can be distinguished, so that only the API of RNAA / ROC service API can be executed. Through the notification, only one entity performing ROC check can be determined, avoiding multiple entities performing multiple times respectively, avoiding the waste of signaling interaction and resources.

[0181] Figure 6 is a method for CCF to configure ROC call check policy of API-X for API-AEF. The APF indicates to the CCF when publishing the API that the API needs ROC check, and then the CCF can determine a unique ROC check entity according to different local policies, AEF capabilities, etc., and notify the AEF providing API-X whether to perform ROC check. In specific applications, other network functions can also be involved, which are not expanded here. Referring to Figure 6, the following is performed:

[0182] Step 601, the APF sends a first message to the CCF, and the first message includes first information (the first information can be understood with reference to the above description, which is not expanded here).

[0183] The first message is an API publish message, for example, an API publish request. The specific information (first information, second information, etc.) included in the first message can be understood with reference to the corresponding description of steps 401A and 401B described above, which will not be repeated here.

[0184] In step 602, the CCF determines, according to the ROC capability information of the boundary AEF, the ROC capability information of the API-AEF, and the first information, that the ROC check of the call of the API-X is performed by the AEF.

[0185] The description of step 402 described above can be understood, which will not be repeated here.

[0186] In step 603, the CCF sends a response message of the first message to the APF.

[0187] The response message of the first message can be an API publish response.

[0188] The execution order of steps 602 and 603 described above is not limited. They can be executed simultaneously, or step 503 can be executed first, then step 602, or step 602 can be executed first, then step 603.

[0189] In step 604A, the CCF sends a first notification to the API-AEF.

[0190] The first notification can indicate to the API-AEF that the ROC check is performed on the call of the API-X. Optionally, the first notification includes the check range of the resource owner's consent for the call of the API-X (usually the API-AEF knows the attribute information and characteristics of the API it provides, so the first notification can not carry the check range information). Optionally, it can also include the check indication information for performing the ROC on the call of the API-X. The related description of the first notification can be understood, which will not be repeated here.

[0191] Optionally, step 604B is executed.

[0192] In step 604B, the CCF sends a second notification to the boundary AEF.

[0193] The second notification can indicate to the boundary AEF that the boundary AEF does not need to perform (or skip, omit) the check of the resource owner's consent for the call of the API-X, or the second notification can indicate to the boundary AEF that the ROC check of the call of the API-X is performed by the API-AEF. Optionally, it can also include the check indication information for not performing the ROC on the call of the API-X. The related description of the second notification can be understood, which will not be repeated here.

[0194] Here, if no ROC check policy for API-X is configured on the CCF, the CCF does not perform any ROC check by default.

[0195] The specific description of steps 604A and 604B can be understood with reference to the description of steps 504A and 504B described above, and is not repeated here.

[0196] Step 605: The API calling entity initiates an API (e.g., API-X) calling request message.

[0197] The destination address of the calling request message is the API-AEF.

[0198] Optionally, step 606 is performed.

[0199] Step 606: The border AEF determines, according to the second notification, that the API-X does not need to perform ROC check at the border AEF.

[0200] Step 607: The border AEF sends (or forwards) the API calling request message to the API-AEF.

[0201] Step 608: The API-AEF determines, according to the first notification, that the API-X needs to perform ROC check at the AEF.

[0202] Step 609: The API-AEF performs ROC check on the API-X calling.

[0203] The ROC check includes checking the API calling itself (e.g., a signed token related to the resource owner consent) or further interacting with the resource owner function or the authentication function in the CCF to obtain necessary permissions. The interaction with the resource owner function can be through the authentication function in the CCF.

[0204] Step 610: The API-AEF returns the calling result of the API-X.

[0205] Specifically, the AEF can return the calling result of the API-X to the API calling entity through the border AEF.

[0206] Through the scheme, the API granularity API ROC check identification and policy configuration can be implemented, so that in the CAPIF system, the RNAA / ROC service API and the non-ROC / non-RNAA type API can be distinguished, and thus the ROC check can be performed only on the API of the RNAA / ROC service API. Through the notification, only one entity performing the ROC check can be determined, multiple entities performing multiple times can be avoided, and the waste of signaling interaction and resources can be avoided.

[0207] Figure 7 is a method for configuring a ROC checking policy for each API by the CCF to the border AEF. The API is indicated to the CCF by the APF at the API publishing that the API needs ROC checking, and then the CCF can determine a unique checking entity for the ROC checking according to different local policies, AEF capabilities, etc., and notify the border AEF to perform the ROC checking. After the border AEF performs the ROC checking, the border AEF sends the indication information of the completion of the ROC checking to the AEF. In specific applications, other network functions can also be involved, which are not described here. Referring to Figure 7, the following is performed:

[0208] Steps 701-704 are the same as the execution process of steps 501-504A described above, and are not described here and can be understood by reference. Steps 705-707 are the same as the execution process of steps 505-507 described above, and are not described here and can be understood by reference.

[0209] Step 708, the border AEF sends (or forwards) the service API calling request message to the AEF, and the calling request message includes the indication information of the completion of the ROC checking.

[0210] Step 709, the API-AEF determines that there is no need to perform ROC checking for API-X according to the indication information of the completion of the ROC checking.

[0211] Step 710, the API-AEF returns the calling result of API-X.

[0212] Specifically, the API-AEF can return the calling result of API-X to the API calling entity through the border AEF.

[0213] Through this scheme, the identification and policy configuration of API ROC checking at the API granularity can be realized, so that in the CAPIF system, the service API and the non-ROC / non-RNAA type API of the RNAA / ROC can be distinguished, and thus the ROC checking can be performed only on the API of the service API of the RNAA / ROC. By notifying the border AEF and the border AEF indicating the completion / skipping of the ROC to the AEF, a unique entity for performing the ROC checking for a service API can be realized, and the ROC checking is performed only once, avoiding excessive signaling interaction and waste of resources.

[0214] The above embodiments related to Figures 5-7 can reduce signaling overhead and avoid introducing additional messages by using the API publishing process to let the CCF know which APIs need ROC checking. A unique entity for performing the ROC checking for a service API can be realized, and the ROC checking is performed only once, avoiding excessive signaling interaction and waste of resources.

[0215] The following describes the data interaction between the API calling entity (i.e., the sixth network function), the CCF (i.e., the first network function), the APF (i.e., the fourth network function), the APIMF (i.e., the fifth network function), the border AEF (i.e., the second network function), and the API-AEF (i.e., the third network function) in combination with the API calling entity. The following description about FIGS. 8-10 is a specific description based on the APIMF sending a first message. FIG. 8 is a method for the CCF to configure the ROC calling check policy of each API for the border AEF. The API is indicated by the APIMF to the CCF to require ROC check, and then the CCF can determine a unique check entity of the ROC check according to different local policies, AEF capabilities, etc., and respectively notify the border AEF and the API-AEF providing the API whether to perform the ROC check. In specific applications, other network functions can also be involved, which are not described here. After the following step 805, the API-AEF is only used to provide the calling entry of API-X, and the following is performed with reference to FIG. 8:

[0216] Step 801, the APF sends a set of APIs to the CCF.

[0217] The prior art can be understood with reference to the above-described API publishing process. It should be noted that the set of APIs includes RNAA type APIs.

[0218] Step 802, the APIMF sends a first message to the CCF, and the first message includes first information (the first information can be understood with reference to the description above, which is not described here).

[0219] The first message is used for API information management, for example, API ROC policy configuration request. The specific information (first information, second information, etc.) included in the first message can be understood with reference to the corresponding description of steps 401A and 401B above, which is not described here.

[0220] The following describes the specific implementation when the first message is sent by the APIMF:

[0221] 1) There is a set of service APIs, and all the service APIs in the set require ROC check. At this time, the first message contains the information (such as API name) of the set of service APIs, the first information, and the second information.

[0222] 2) There is a set of service APIs, and the set of service APIs does not require ROC check. At this time, the first message contains the information (such as API name) of the set of service APIs, and an indication that no ROC check is performed.

[0223] 3) There is a set of service APIs, in which {service API X, service API Y} are APIs that need ROC check, and {service API A, service API B} is a set of APIs that do not need ROC check. At this time, the first message contains the information (such as API name) of the {service API X, service API Y}, the first information, the second information; {service API A, service API B}, no ROC check indication.

[0224] Herein is only illustrative and not specifically limited.

[0225] Step 803, the CCF determines the ROC check of the call of one or more APIs executed by the border AEF according to the ROC capability information of the border AEF, the ROC capability information of the API-AEF and the first information.

[0226] The description of the above step 402 can be referred to for understanding, which is not repeated here.

[0227] Steps 804A-810 are the same as the execution process of the above steps 504A-510, which are not repeated here and can be understood by reference.

[0228] Using the independent API ROC policy configuration message, better feature independence and function independence can be achieved, which is convenient for independent evolution in the future. Only one entity for performing ROC check for a service API can be implemented, which is performed only once, avoiding excessive signaling interaction and resource waste.

[0229] FIG. 9 is a method for CCF to configure the ROC call check policy of API-X to AEF. The API MF indicates to the CCF that the API needs ROC check, and then the CCF can determine a unique ROC check entity according to different local policies, AEF capabilities, etc., and notify the API-AEF providing API-X whether to perform ROC check. In specific applications, other network functions can also be involved, which are not described here. Referring to FIG. 9, the following is performed:

[0230] Steps 901-902 are the same as the execution process of the above steps 801-802, which are not repeated here and can be understood by reference. Step 903 is the same as the execution process of step 602, which is not repeated here and can be understood by reference. Steps 904A-910 are the same as the execution process of the above steps 604A-610, which are not repeated here and can be understood by reference.

[0231] The independent API ROC policy configuration message can achieve better feature independence and function independence, and facilitate independent evolution in the future. There is only one entity performing ROC check for one service API, and the ROC check is performed only once, thereby avoiding excessive signaling interaction and resource waste.

[0232] FIG. 10 is a method for CCF to configure the ROC call check policy of each API to the border AEF. The API MF indicates to the CCF that the API needs ROC check, and then the CCF can determine a unique ROC check entity according to different local policies, AEF capabilities, etc., and respectively notify the border AEF to perform ROC check. After the border AEF performs ROC check, the border AEF sends the indication information of ROC check completion to the AEF. In specific application, other network functions can also be involved, which are not described here. Referring to FIG. 10, the following is performed:

[0233] Steps 1001-1004 are the same as the execution process of steps 801-804A described above, and are not described here and can be understood with reference.

[0234] Step 1008, the border AEF sends (or forwards) the service API call request message to the AEF, and the call request message includes the indication information of ROC check completion.

[0235] Step 1009, the API-AEF determines that there is no need to perform ROC check for API-X according to the indication information of ROC check completion.

[0236] Step 1010, the API-AEF returns the call result of API-X.

[0237] Specifically, the API-AEF can return the call result of API-X to the API call entity through the border AEF.

[0238] There is only one entity performing ROC check for one service API, and the ROC check is performed only once, thereby avoiding excessive signaling interaction and resource waste.

[0239] It should be further noted that in addition to the above-mentioned schemes of Fig. 4-10 for explicitly indicating which API performs the resource owner consent check and which device performs the API call check for resource owner consent, there is also a scheme for determining the scheme by negotiation with the second network function. The following is described in connection with the data interaction between the API call entity (i.e., the sixth network function), the CCF (i.e., the first network function), the border AEF (i.e., the second network function), and the target network function, which can be the APF (i.e., the fourth network function), the APIMF (i.e., the fifth network function), or the API-AEF (i.e., the third network function), which is not specifically limited here. After step 1104 in Fig. 11, the target network function is the API-AEF, and the following is performed with reference to Fig. 11:

[0240] At step 1101, the border AEF receives a second message from the target network function.

[0241] The second message is used to negotiate the entity that performs the resource owner consent check for the first API, and the second message includes information of the first API (such as identification information of the first API). Optionally, the second message further includes first information, which is used to indicate that the call of the first API checks the resource owner consent. The description of the first information can be understood with reference to the description of Fig. 4, which is not repeated here. Optionally, the second message can further include the second message, the range of the resource owner consent check for the first API, which can be understood with reference to the related description of Fig. 4, which is not repeated here.

[0242] At step 1102, the border AEF determines whether the border AEF performs the resource owner consent check for the call of the first API according to the second message.

[0243] For example, the border AEF can determine whether to perform the ROC check based on the locally pre-configured call check policy and the ROC capability information of the border AEF. For example, the border AEF does not support the resource owner consent check capability, and the border AEF determines that the AEF performs the ROC check. The border AEF supports the resource owner consent check capability, and the border AEF determines that the AEF performs the ROC check based on the local call check policy. The border AEF supports the resource owner consent check capability, and the border AEF determines that the AEF performs the ROC check based on the local call check policy, but the second message includes the second information and the range of the resource owner consent check for the first API, and the second information indicates that the preference of the first API for checking the resource owner consent is the AEF, and the border AEF determines that the AEF performs the ROC check. The above is only an example.

[0244] Step 1103, the border AEF sends a response message to the target network function for the second message, the response message indicates that the check of the resource owner consent for the first API is performed by the first device, the first device is the border AEF or the API-AEF.

[0245] For example, when the second message in step 1101 indicates that the ROC check is performed by the API-AEF, and the border AEF accepts the ROC check performed by the API-AEF, the response message can also be only a successful response message, without carrying additional information of the ROC check execution entity selected by the border AEF.

[0246] Step 1104, the API calling entity initiates a service API (for example, API-X) calling request message.

[0247] Wherein, the destination address of the calling request message is the border AEF.

[0248] Step 1105, the border AEF determines whether the API-X needs to perform the ROC check in the border AEF. If yes, step 1106 is performed, and if not, step 1107 is performed.

[0249] Step 1106, the border AEF performs the ROC check for the API-X calling.

[0250] Wherein, the ROC check includes checking the API calling itself (for example, the signature token related to the resource owner consent) or further interacting with the resource owner function or the authentication function in the CCF to obtain the necessary permission.

[0251] Wherein, the interaction with the resource owner function can be through the authentication function in the CCF.

[0252] Specifically, it can be understood with reference to the existing related protocols, which are not expanded here.

[0253] Step 1107, the border AEF sends (or forwards) the service API calling request message to the API-AEF. After step 1107 is performed, step 1108 is performed.

[0254] Step 1108, the API-AEF determines to perform the ROC check for the API-X.

[0255] Specifically, if the above step 1106 is performed, the ROC check is not needed to be performed, and if the step 1106 is not performed, the ROC check needs to be performed.

[0256] Step 1109, the API-AEF performs the ROC check for the API-X calling.

[0257] The specific check information can be understood with reference to step 1106, which will not be described herein.

[0258] The above steps 1106 and 1109 can be executed alternatively, and can be determined in combination with the specific negotiation information. In addition, if the above steps 1106, 1108 and 1109 are executed, steps 1108 and 1109 can not be executed. If step 1106 is not executed, steps 1108 and 1109 are executed.

[0259] In step 1110, the API-AEF returns the calling result of the API-X.

[0260] Specifically, the AEF can return the calling result of the API-X to the API calling entity through the boundary AEF.

[0261] In the scheme shown in FIG. 11, which APIs perform the resource owner consent check, and which device is used to check the resource owner consent of the API call are determined based on negotiation, and the scheme is more flexible. It can be achieved that one AEF performs the ROC check for the service API, reducing signaling interaction and resource waste.

[0262] The above mainly introduces the scheme provided by the embodiments of the present application from the perspective of device interaction. It can be understood that, in order to implement the above functions, each device can include a corresponding hardware structure and / or software module for performing each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of the examples described in the embodiments disclosed herein, the embodiments of the present application can be realized in the form of hardware or a combination of hardware and computer software. Whether a certain function is driven by hardware or computer software to drive hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0263] The embodiments of the present application can divide the functional units of the device according to the above method examples, for example, each functional unit can be divided according to each function, or two or more functions can be integrated into one unit. The integrated unit can be realized in the form of hardware or software functional unit.

[0264] In the case of employing the integrated unit, FIG. 12 shows a possible exemplary block diagram of the communication apparatus involved in the embodiments of the present application. As shown in FIG. 12, the communication apparatus 1200 can include a processing module 1210 and a transceiver module 1220. The processing module 1210 is configured to control and manage the actions of the communication apparatus 1200. The transceiver module 1220 is configured to support the communication of the communication apparatus 1200 with other devices. Optionally, the transceiver module 1220 can include a receiving unit and / or a transmitting unit, which are configured to perform the receiving and transmitting operations, respectively. Optionally, the communication apparatus 1200 can further include a storage unit configured to store the program code and / or data of the communication apparatus 1200. The transceiver unit can be referred to as an input / output unit, a communication unit, etc., and can be a transceiver; the processing unit can be a processor. When the communication apparatus is a module (e.g., a chip) in a communication device, the transceiver unit can be an input / output interface, an input / output circuit, or an input / output pin, etc., and can also be referred to as an interface, a communication interface, or an interface circuit, etc.; the processing unit can be a processor, a processing circuit, or a logic circuit, etc. Specifically, the communication apparatus can be the CCF, the API invocation entity, the APF, the AEF, or the APIMF, etc. described above.

[0265] In one embodiment, the communication apparatus is a first network function, wherein the transceiver module 1220 is configured to receive a first message, the first message including first information, the first information being used to indicate that a check of resource owner consent is performed for an invocation of a first API; and the processing module 1210 is configured to send a first notification according to the first information, the first notification being used to trigger the second network function or the third network function to perform the check of the resource owner consent for the invocation of the first API, the second network function being configured to provide a total entry of API invocations, and the third network function being configured to provide the first API.

[0266] In an optional manner, the processing module 1210 is configured to determine a first device that performs the check of the resource owner consent for the invocation of the first API, the first device being the second network function or the third network function; and the transceiver module 1220 is configured to send a first notification to the first device, the first notification being used to trigger the first device to perform the check of the resource owner consent for the invocation of the first API.

[0267] In an optional manner, the transceiver module 1220 is further configured to send a second notification to a second device, the second notification being used to indicate that the check of the resource owner consent for the invocation of the first API is performed by the first device, or to indicate that the second device does not need to perform the check of the resource owner consent for the invocation of the first API, or to indicate that the second device skips the check of the resource owner consent for the invocation of the first API, the second device being the second network function and a device other than the first device among the second network function.

[0268] In an optional mode, the first notification comprises identification information of the first API.

[0269] In an optional mode, the first notification further comprises at least one of the following: indication information of performing a check of resource owner consent for the call of the first API, a check range of resource owner consent for the call of the first API, or entity information of performing the check of resource owner consent, the check range indicating a check item of checking the call of the first API.

[0270] In an optional mode, the processing module 1210 is configured to determine the first device according to one or more of the following information: resource owner consent capability information of the second network function, resource owner consent capability information of the third network function, the second information, or a policy preconfigured by the first network function, the second information being used to indicate a preference of checking resource owner consent for the call of the first API.

[0271] In an optional mode, the transceiver module 1220 is further configured to receive the resource owner consent capability information of the second network function, and / or the resource owner consent capability information of the third network function.

[0272] In an optional mode, the first information is first attribute information of the first API, the first attribute information being used to indicate checking resource owner consent for the call of the first API; or, the first information is indication information of performing a check of resource owner consent for the call of the first API.

[0273] In an optional mode, the first message further comprises second information, the second information being used to indicate a preference of checking resource owner consent for the call of the first API.

[0274] In an optional mode, the second information comprises one of the following:

[0275] The second network function performs a check of resource owner consent for the call of the first API; or, the third network function performs a check of resource owner consent for the call of the first API; or, the second network function performs a check of resource owner consent for the call of the first API and the third network function performs a check of resource owner consent for the call of the first API with a priority.

[0276] In an optional mode, the first message further comprises a check range of resource owner consent for the first API, the check range indicating a check item of checking the call of the first API.

[0277] In an optional mode, the check range comprises: a caller of calling the first API, an operation item of the call of the first API, and / or an operation resource of the call of the first API.

[0278] In an optional mode, the first message is from a fourth network function, the fourth network function is configured to publish API information, and the first message is an API publishing message; or the first message is from a fifth network function, the fifth network function is configured to manage API information, and the first message is configured to configure a calling check policy of the API.

[0279] In yet another embodiment, the communication apparatus is a second network function, wherein the transceiver 1220 is configured to receive a first notification from a first network function, the first notification is configured to trigger the second network function to perform a resource owner consent check on a call of a first API, and the second network function is configured to provide a total API calling entry; receive a call request of the first API from a sixth network function, the sixth network function is an API calling entity; and the processor 1210 is configured to perform the resource owner consent check on the call of the first API according to the first notification.

[0280] In an optional mode, the first notification includes identification information of the first API.

[0281] In an optional mode, the first notification further includes at least one of the following:

[0282] The first API calling performs resource owner consent check indication information, or the first API resource owner consent check range, or the resource owner consent check entity information.

[0283] In an optional mode, after the second network function performs the resource owner consent check on the call of the first API, the transceiver 1220 is further configured to send indication information of completion of the resource owner consent check on the call of the first API to a third network function, and the third network function is configured to provide the first API.

[0284] In an optional mode, the first network function is a core function or an authorization function of a common API framework (CAPIF).

[0285] In yet another embodiment, the communication apparatus is a second network function, wherein the transceiver 1220 is configured to receive a second message, the second message is configured to negotiate an entity performing a resource owner consent check on a first application program interface (API), the second message includes information of the first API, and the second network function is configured to provide a total API calling entry; and the processor 1210 is configured to determine whether the second network function performs the resource owner consent check on the call of the first API according to the second message.

[0286] In an optional mode, the second message further includes first information, and the first information is configured to indicate a call check of the first API.

[0287] In an optional mode, the second message further comprises second information, the second information being used to indicate a preference of checking resource owner consent for the call of the first API.

[0288] In an optional mode, the second information comprises one of the following:

[0289] The second network function performs the checking of the resource owner consent for the call of the first API; or, the third network function performs the checking of the resource owner consent for the call of the first API, the third network function being used to provide the first API; or, the second network function and the third network function have a priority for performing the checking of the resource owner consent for the call of the first API.

[0290] In an optional mode, the second message further comprises a checking range of the resource owner consent for the first API, the checking range being used to indicate checking items for checking the call of the first API.

[0291] In an optional mode, the checking range comprises a caller of the call of the first API, an operation item of the call of the first API, and / or an operation resource of the call of the first API.

[0292] In an optional mode, the transceiver 1220 is further used to send a response message of the second message, the response message being used to indicate that the checking of the resource owner consent for the first API is performed by a first device, the first device being the second network function or the third network function.

[0293] FIG. 13 is a schematic block diagram of a communication apparatus 1300 provided by an embodiment of the present application. The communication apparatus 1300 can be a terminal device or a network device in the above embodiments. For example, the communication apparatus 1300 can be a chip (system) in the CCF, the API calling entity, the APF, the AEF or the APIMF in FIG. 1. In an embodiment of the present application, the chip system can be composed of a chip, or can include the chip and other discrete devices. For specific functions, refer to the description in the above method embodiments. In an embodiment of the present application, the chip system can be composed of a chip, or can include the chip and other discrete devices. For specific functions, refer to the description in the above method embodiments.

[0294] The communication device 1300 includes one or more processors 1301 configured to implement or support implementation of the method in the embodiments of the present application. For example, the processor 1301 can be configured to implement or support the implementation of the functions of the CCF, API invoking entity, APF, AEF, or APIMF in the method. For details, refer to the detailed description of the method examples, which will not be repeated here. The processor 1301 can also be referred to as a processing unit or a processing module, and can implement certain control functions. The processor 1301 can be a general-purpose processor or a special-purpose processor. For example, it includes a baseband processor, a central processing unit, an application processor, a modem processor, a graphics processor, an image signal processor, a digital signal processor, a video coding and decoding processor, a controller, a memory, and / or a neural network processor, etc. The baseband processor can be configured to process communication protocols and communication data. The central processing unit can be configured to control the communication device 1300 (such as a network device or a terminal device), execute software programs, and / or process data. Different processors can be independent devices or integrated into one or more processors, such as integrated into one or more application-specific integrated circuits.

[0295] In one design, the processor 1301 can include a program (which can also be referred to as code or instructions) that can be run on the processor 1301 to cause the communication device 1300 to perform the methods described in the above embodiments. In another possible design, the communication device 1300 includes circuitry (not shown in FIG. 13) configured to implement the functions of the CCF, API invoking entity, APF, AEF, or APIMF in the above embodiments.

[0296] In one design, the communication device 1300 can include one or more memories 1302 having a program (which can also be referred to as code or instructions) stored thereon, which can be run on the processor 1301 to cause the communication device 1300 to perform the methods described in the above embodiments.

[0297] In one design, the processor 1301 and / or the memory 1302 can include an artificial intelligence (AI) module configured to implement AI-related functions. The AI module can be implemented by software, hardware, or a combination of software and hardware. For example, the AI module can include a RAN intelligent controller (RIC) module. For example, the AI module can be a near-real-time RIC or a non-real-time RIC.

[0298] In one possible design, the processor 1301 and / or the memory 1302 can also store data. The processor and the memory can be separately arranged or integrated together.

[0299] In a possible design, the communication apparatus 1300 further includes a transceiver 1305 and / or an antenna 1306. The processor 1301 can also be referred to as a processing unit, and controls the communication apparatus 1300. The transceiver 1305 can also be referred to as a transceiving unit, a transceiver, a transceiving circuit, or a transceiver, etc., and is configured to implement the transceiving function of the communication apparatus 1300 through the antenna 1306.

[0300] In a possible design, the communication apparatus 1300 further includes one or more of the following components: a wireless communication module, an audio module, an external storage interface, an internal storage, a universal serial bus (USB) interface, a power management module, an antenna, a speaker, a microphone, an input / output module, a sensor module, a motor, a camera, or a display screen, etc. It can be understood that, in some embodiments, the communication apparatus 1300 can include more or less components, or some components are integrated, or some components are split. These components can be implemented in hardware, software, or a combination of software and hardware.

[0301] The communication device in the above embodiments can be a function of the CCF, the API calling entity, the APF, the AEF, or the APIMF, can be a circuit, or can be a chip or other combination device or component having the functions of the CCF, the API calling entity, the APF, the AEF, or the APIMF. When the communication device is a terminal device or a network device, the transceiver module can be a transceiver and can include an antenna and a radio frequency circuit, and the processing module can be a processor, for example, a CPU. When the communication device is a chip system, the communication device can be an FPGA, can be a dedicated ASIC, can also be a system on chip (SoC), can also be a CPU, can also be a network processor (NP), can also be a DSP, can also be a micro controller unit (MCU), can also be a programmable logic device (PLD) or other integrated chip. The processing module can be a processor of the chip system. The transceiver module or the communication interface can be an input / output interface or an interface circuit of the chip system. For example, the interface circuit can be a code / data read / write interface circuit. The interface circuit can be used to receive code instructions (the code instructions are stored in a memory and can be directly read from the memory or can be read from the memory through other devices) and transmit the code instructions to the processor; the processor can be used to run the code instructions to perform the method in the above method embodiments. For another example, the interface circuit can also be a signal transmission interface circuit between a communication processor and a transceiver.

[0302] The embodiments of the present application also provide a communication system including the functions of the CCF, the API calling entity, the APF, the AEF, or the APIMF.

[0303] The embodiments of the present application also provide a computer readable storage medium including instructions, when the instructions are executed on a computer, causing the computer to perform the method executed by the functions of the CCF, the API calling entity, the APF, the AEF, or the APIMF in the above communication method.

[0304] The embodiments of the present application also provide a computer program product including computer program code, when the computer program code is executed, causing a computer to perform the method executed by the functions of the CCF, the API calling entity, the APF, the AEF, or the APIMF in the above communication method.

[0305] The chip system can be composed of a chip, or can include a chip and other discrete devices.

[0306] To implement the functions of the communication apparatus, the embodiments of the present application further provide a chip including a processor for supporting the communication apparatus to implement the functions of the terminal device or the network device involved in the method embodiments. In a possible design, the chip is connected with a memory or the chip includes the memory, and the memory is used to store the computer programs or instructions and data necessary for the communication apparatus.

[0307] It should be understood that, in the various embodiments of the present application, the size of the serial number of each process described above does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0308] Those of ordinary skill in the art can realize that the various illustrative logical blocks and steps described in connection with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0309] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the system, apparatus and unit described above can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0310] In the embodiments of the present application, "at least one" means one or more, and "multiple" means two or more. The "and / or" describes the association relationship between the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the following three cases: A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it. "At least one of the following" or similar expressions means any combination of the ten or more items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, and c can be single or multiple.

[0311] Also, unless otherwise stated, the ordinal numbers "first", "second", etc. used in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the order, time sequence, priority, or importance of the multiple objects. For example, a first waveform and a second waveform are merely used to distinguish different types, and do not represent different priorities or importance of the two sizes.

[0312] In the embodiments of the present application, "sending" and "receiving" represent the direction of signal transmission. For example, "sending information to XX" can be understood as that the destination of the information is XX, which can include direct sending through the air interface, or indirect sending through the air interface by other units or modules. "Receiving information from YY" can be understood as that the source of the information is YY, which can include direct receiving from YY through the air interface, or indirect receiving from YY through the air interface by other units or modules. "Sending" can also be understood as "output" of a chip interface, and "receiving" can also be understood as "input" of a chip interface. In other words, sending and receiving can be between devices, such as between network devices and terminal devices, or within a device, such as between components, modules, chips, software modules or hardware modules in a device through a bus, wire or interface. It can be understood that the information between the source and the destination of the information transmission can be processed as necessary, such as encoding and modulation, but the destination can understand the valid information from the source. Similar expressions in the present application can be similarly understood, and will not be repeated here.

[0313] In the embodiments of the present application, "when", "if" and "whether" all refer to the objective situation that the device will make corresponding processing, and are not limited to time, and do not require the device to have a judgment action when implemented, nor does it mean that there are other limitations. Unless otherwise stated, "if" and "whether" can be replaced, "when" and "in the case of" can be replaced. "When" and "if" / "whether" can be replaced. "*" in the embodiments of the present application can be used to represent "multiplication".

[0314] The ordinal numbers "first", "second", etc. used in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the size, content, order, time sequence, priority, or importance of the multiple objects. For example, a first sequence and a second sequence refer to two different sequences, and do not represent different contents, priorities, or importance of the two sequences. The words "exemplary" or "for example" are used to represent an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words "exemplary" or "for example" are used to present the relevant concept in a specific manner.

[0315] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. For example, the division of the units is only a logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0316] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purposes of the embodiments.

[0317] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on such understanding, the essential part of the technical solutions of the present application or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, and various program codes that can be stored in the medium.

[0318] Obviously, those skilled in the art can make various modifications and variations to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application also intends to include these modifications and variations.

Claims

1. A communication method characterized by comprising: The method is applied to a first network function, and comprises: receiving a first message, the first message comprising first information indicating that a call to a first application programming interface (API) is to be checked for resource owner consent; sending a first notification based on the first information, the first notification triggering a second network function or a third network function to perform a check for resource owner consent for the call to the first API, the second network function being configured to provide a total entry point for API calls, and the third network function being configured to provide the first API.

2. The method of claim 1, wherein, The sending of the first notification based on the first information comprises: determining a first device to perform the check for resource owner consent for the call to the first API, the first device being the second network function or the third network function; sending the first notification to the first device, the first notification triggering the first device to perform the check for resource owner consent for the call to the first API.

3. The method of claim 2, wherein, The method further comprises: sending a second notification to a second device, the second notification indicating that the check for resource owner consent for the call to the first API is performed by the first device, or indicating that the second device is not required to perform the check for resource owner consent for the call to the first API, or indicating that the second device is to skip the check for resource owner consent for the call to the first API, the second device being the second network function and a device other than the first device among the second network function.

4. The method according to claim 2 or 3, characterized in that, The first notification comprises identification information of the first API.

5. The method of claim 4, wherein, The first notification further comprises at least one of: information indicating that the call to the first API is to be checked for resource owner consent, a range of the call to the first API to be checked for resource owner consent, or an entity performing the check for resource owner consent, the range indicating a check item for the call to the first API.

6. The method according to any one of claims 2-5, characterized in that, The determining of the first device to perform the check for resource owner consent for the call to the first API comprises: determining the first device based on one or more of the following: resource owner consent capability information of the second network function, resource owner consent capability information of the third network function, second information indicating a preference for the call to the first API to be checked for resource owner consent, or a policy pre-configured for the first network function.

7. The method according to any one of claims 1 to 6, characterized in that, The method further comprises: receiving the resource owner consent capability information of the second network function, and / or the resource owner consent capability information of the third network function.

8. The method according to any one of claims 1 to 7, characterized in that, The first information is first attribute information of the first API, the first attribute information indicating that the call to the first API is to be checked for resource owner consent; or the first information is information indicating that the call to the first API is to be checked for resource owner consent.

9. The method of any one of claims 1-8, wherein, The first message further comprises second information indicating a preference for the call to the first API to be checked for resource owner consent.

10. The method of claim 9, wherein, The second information comprises one of: The second network function performs a check of resource owner consent on the call of the first API; or The third network function performs a check of resource owner consent on the call of the first API; or The second network function performs a check of resource owner consent on the call of the first API and the priority of the check of resource owner consent on the call of the first API performed by the third network function.

11. The method of any one of claims 1-10, wherein, The first message further comprises: a check range of resource owner consent of the first API, the check range indicating check items of the call of the first API.

12. The method of claim 11, wherein, The check range comprises: a caller of the call of the first API, an operation item of the call of the first API, and / or an operation resource of the call of the first API.

13. The method of any one of claims 1-12, wherein, The first message is from a fourth network function, the fourth network function being configured to publish API information, and the first message being an API publishing message; or The first message is from a fifth network function, the fifth network function being configured to manage API information, and the first message being configured to configure a call check policy of an API.

14. The method of any one of claims 1-13, wherein, The first network function is a core function or an authorization function of a common API framework (CAPIF).

15. A method of communication, comprising: Applied to a second network function, comprising: receiving a first notification from a first network function, the first notification being configured to trigger the second network function to perform a check of resource owner consent on a call of a first API, the second network function being configured to provide a total entry of API call; receiving a call request of the first API from a sixth network function, the sixth network function being an API call entity; performing a check of resource owner consent on the call of the first API according to the first notification.

16. The method of claim 15, wherein, The first notification comprises: identification information of the first API.

17. The method of claim 16, wherein, The first notification further comprises at least one of the following: indication information of performing a check of resource owner consent on the call of the first API, or a check range of resource owner consent of the first API, or entity information of performing a check of resource owner consent.

18. The method of any one of claims 15-17, wherein, The method further comprises: after performing the check of resource owner consent on the call of the first API, sending indication information of completion of the check of resource owner consent on the call of the first API to a third network function, the third network function being configured to provide the first API.

19. The method of any one of claims 15-18, wherein, The first network function is a core function or an authorization function of a common API framework (CAPIF).

20. A method of communication, comprising: Applied to a second network function, comprising: receiving a second message, the second message being configured to negotiate an entity performing a check of resource owner consent on a first application program interface (API), the second message comprising information of the first API, the second network function being configured to provide a total entry of API call; determining whether the second network function performs a check of resource owner consent on the call of the first API according to the second message.

21. The method of claim 20, wherein, The second message further comprises first information, the first information being configured to indicate a check of resource owner consent on the call of the first API.

22. The method of claim 21, wherein, The second message further comprises second information indicating a preference of the first API to check resource owner consent.

23. The method of claim 22, wherein, The second information comprises one of: The second network function performs a check of resource owner consent for the call of the first API; or, A third network function performs a check of resource owner consent for the call of the first API, the third network function being configured to provide the first API; or, The second network function performs a check of resource owner consent for the call of the first API and a priority of the third network function performing a check of resource owner consent for the call of the first API.

24. The method of any one of claims 20-23, wherein, The second message further comprises a scope of resource owner consent check for the first API, the scope of check indicating check items for the call of the first API.

25. The method of claim 24, wherein, The scope of check comprises a caller of the call of the first API, an operation item of the call of the first API, and / or an operation resource of the call of the first API.

26. The method of any one of claims 20-25, wherein, The method further comprises: sending a response message of the second message, the response message indicating that the check of resource owner consent for the first API is performed by a first device, the first device being the second network function or the third network function.

27. A communications device, characterized by comprises: at least one processor and a memory; the memory is configured to store computer programs or data; the at least one processor is configured to run part or all of the computer programs or data to cause the method of any one of claims 1-26 to be performed.

28. A communication system, characterized by The system comprises a first network function and a second network function; wherein the first network function is configured to perform the method of any one of claims 1-14, the second network function is configured to perform the method of any one of claims 15-19; or the second network function is configured to perform the method of any one of claims 20-26.

29. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions which, when executed by a computer, cause the method of any one of claims 1-26 to be performed.

30. A computer program product comprising computer programs or instructions, characterized in that, The computer program or instructions, when running on a computer, cause the method of any one of claims 1-26 to be performed.

Images