Communication method and device

Abstract

The invention provides a communication method and device, and the method comprises the steps that a first device obtains first information, and the first information indicates a first API to call a second API in the process of providing a first service; the first device obtains the processing time delay of the instance of the first API and the processing time delay of one or more instances corresponding to the second API according to the first information, and obtains the transmission time delay corresponding to the at least one topological combination. And the first device determines the time delay performance of the first API according to the processing time delay of the instance of the first API, the processing time delay of one or more instances corresponding to the second API and the transmission time delay corresponding to the at least one topological combination. By adopting the method, the first device can accurately determine the time delay performance of the first API, and the first API can provide various selectable time delay performance for the equipment requesting the first service.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication, and in particular to a communication method and device. BACKGROUND

[0002] Currently, after a service invoker invokes an application programming interface (API), the service invoker can count a plurality of parameters of performance of the API, for example, a request response time, a throughput, a transaction per second, a query per second, and a concurrency, and the like, and the service invoker can know the performance of the API based on the above parameters. That is, the service invoker does not know the performance of the API before invoking the API, and can only know the performance of the API after invoking the API. Therefore, the invoked API can provide a corresponding service, but can not meet the performance requirement of the service invoker for the service, and is only a best-effort service without any service level agreement (SLA) guarantee. For example, it is assumed that the service invoker expects a time delay of service A to be less than 50 ms, but after the service invoker invokes an API providing the service A, the service invoker can determine that the API provides the time delay of the service A to be greater than 50 ms.

[0003] In summary, how to enable the service invoker to invoke an API meeting the performance requirement to provide a service for the service invoker, instead of being able to perceive the performance of the API after invoking the API, is a problem worth attention. SUMMARY

[0004] Embodiments of the present application provide a communication method and device, to enable a service invoker to invoke an API meeting a performance requirement to provide a service for the service invoker.

[0005] In a first aspect, a method for communication is provided. The method can be applied to a first device, such as a core function network element, or a capability exposure gateway, or an external API instance. In an example where the method is applied to the first device, the method includes: obtaining, by the first device, first information indicating that a first API invokes a second API in a process of providing a first service; obtaining, by the first device, a processing delay of an instance of the first API and processing delays of one or more instances of the second API corresponding to the second API according to the first information; obtaining, by the first device, transmission delays corresponding to at least one topology combination respectively, wherein each topology combination includes the instance of the first API and one of the one or more instances of the second API corresponding to the second API; and determining, by the first device, a latency performance of the first API according to the processing delay of the instance of the first API, the processing delays of the one or more instances of the second API corresponding to the second API, and the transmission delays corresponding to the at least one topology combination respectively.

[0006] With the above method, the first device can accurately determine the latency performance of the first API according to the processing delay of the instance of the first API, the processing delays of the one or more instances of the second API corresponding to the second API, and the transmission delays corresponding to the at least one topology combination respectively, where the latency performance of the first API can be at least one, i.e., the first API can guarantee at least one latency. Therefore, before a device requesting the first service invokes the first API, at least one latency that the first API can guarantee has been determined, i.e., the first API can provide multiple selectable latency performances for the device requesting the first service, so that the device requesting the first service can invoke an API satisfying the latency requirement to provide a service.

[0007] In a possible design, in determining the latency performance of the first API according to the processing delay of the instance of the first API, the processing delays of the one or more instances of the second API corresponding to the second API, and the transmission delays corresponding to the at least one topology combination respectively, the latency performance of the first API is determined according to the processing delay of the instance of the first API, the processing delays of the one or more instances of the second API corresponding to the second API, the transmission delays corresponding to the at least one topology combination respectively, and a transmission delay between the instance of the first API and a first capability exposure gateway, where the first capability exposure gateway is a first hop node invoking the instance of the first API.

[0008] With the above design, the latency performance of the first API can be determined in combination with the transmission delay between the instance of the first API and the first capability exposure gateway, so as to more accurately reflect the latency performance of the first API.

[0009] In a possible design, when the first device is a core function network element, the first device acquires a topological relationship between at least one capability exposure gateway and the instance of the first API; and selects the first capability exposure gateway from the at least one capability exposure gateway according to the topological relationship.

[0010] With the above design, the capability exposure gateway can be selected for the instance of the first API.

[0011] In a possible design, when the first device is a core function network element or the instance of the first API, the first device sends a first notification message to the first capability exposure gateway, where the first notification message includes an identifier of the instance of the first API, or the first notification message indicates a latency performance of the first API.

[0012] In a possible design, when the first device is the first capability exposure gateway or the instance of the first API, the first device sends a second notification message to a core function network element, where the second notification message indicates a latency performance of the first API. Correspondingly, the core function network element receives the second notification message from the first device.

[0013] In a possible design, when the first device is a core function network element or the first capability exposure gateway, the first device sends configuration information of the instance of the first API to the instance of the first API, where the configuration information of the instance of the first API indicates a latency performance of the first API.

[0014] With the above design, the instance of the first API can learn the latency performance of the first API.

[0015] In a possible design, the first information further indicates that the first API invokes a third API in providing the first service, and a calling sequence of the first API, the second API and the third API; each topological combination includes the instance of the first API, one of one or more instances corresponding to the second API, and one of one or more instances corresponding to the third API; and a transmission latency corresponding to each topological combination is determined according to the calling sequence and transmission latencies between instances in the topological combination.

[0016] With the above design, the calling sequence of the first API, the second API and the third API can be notified, and the transmission latency corresponding to each topological combination can be accurately determined based on the calling sequence.

[0017] In one possible design, when determining the latency performance of the first API based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination, the processing latency of one or more instances corresponding to the third API is obtained based on the first information; the latency performance of the first API is determined based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, the processing latency of one or more instances corresponding to the third API, and the transmission latency corresponding to the at least one topology combination.

[0018] In one possible design, when determining the latency performance of the first API based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination, the latency performance of the at least one topology combination is determined based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination; wherein, the latency performance corresponding to each topology combination is determined based on the transmission latency and the processing latency corresponding to the topology combination, and the processing latency corresponding to the topology combination is determined based on the processing latency corresponding to each instance included in the topology combination; the latency performance of the first API is determined based on the latency performance of the at least one topology combination.

[0019] The above design enables accurate determination of the latency performance corresponding to each topology combination, wherein the latency performance of the first API can include one or more of the latency performance of at least one topology combination.

[0020] In one possible design, a first request message is received, which requests the discovery of a capability discovery gateway corresponding to the first API. The first request message includes first indication information indicating latency requirements for the first API. A first capability opening gateway is determined based on the first request message and the latency performance of the first API. The first capability opening gateway is the first-hop functional node of the instance calling the first API, and the latency performance of the instance of the first API meets the latency requirements indicated by the first indication information. A first response message is sent, which includes the address of the first capability opening gateway.

[0021] The above design enables a gateway to discover devices that request the first service.

[0022] In one possible design, a second request message is received, the second request message being used to request a call to the first API, the second request message including second indication information indicating a latency requirement for the first API; an instance of the first API is determined based on the second request message; a call request is sent to the instance of the first API, the call request including third indication information, the third indication information being used to determine one of the at least one topology combination, wherein the third indication information is determined based on the second indication information.

[0023] The above design enables the device that requests the first service to accept, process, and / or forward the call request.

[0024] In one possible design, when obtaining the first information, the first information is obtained from a first network element, wherein the first network element is any one of the following: an instance of the first API, an API publishing function network element, a network storage function network element, or an API storage function network element.

[0025] In one possible design, the processing latency for obtaining an instance of the first API from the first network element.

[0026] In one possible design, the processing latency of one or more instances corresponding to the second API is obtained from a second network element, which is a network storage function network element, a network function NF management system, or an API management system.

[0027] In one possible design, the processing latency of the first API instance is the latency between receiving a request to call the first APF instance and sending a corresponding call request to the next-hop second API instance, or the latency between receiving a request to call the first API instance and providing a response or result to the request; the processing latency of the second APF instance is the latency between receiving a call request to the second API instance and sending a corresponding call request to the next-hop instance, or the latency between receiving a request to call the second API instance and providing a response or result to the request.

[0028] Secondly, this application provides a communication method, the method comprising: obtaining a topological relationship between at least one capability open gateway and an instance of a first API; selecting a first capability open gateway from the at least one capability open gateway according to the topological relationship, wherein the first capability open gateway is a first-hop node of an instance calling the first API; obtaining the processing latency of the instance of the first API; and determining the latency performance of the instance of the first API based on the processing latency of the instance of the first API and the transmission latency between the instance of the first API and the first capability open gateway.

[0029] Using the above method, the first device can accurately determine the latency performance of the first API based on the processing latency of the first API instance and the transmission latency between the first API instance and the first capability opening gateway. The latency performance of the first API can be at least one type, meaning the first API can guarantee at least one type of latency. Therefore, before a device requesting the first service calls the first API, at least one guaranteed latency of the first API has already been determined. In other words, the first API can provide multiple optional latency performances for the device requesting the first service, thereby enabling the device requesting the first service to call an API that meets its latency requirements to provide services. This method is generally applicable to scenarios where the first API does not depend on other APIs.

[0030] In one possible design, a notification message is sent to the first capability open gateway, the notification message including an identifier of an instance of the first API, or the notification message indicating the latency performance of an instance of the first API.

[0031] In one possible design, when obtaining the processing latency of an instance of the first API, the processing latency of the instance of the first API is obtained from a first network element, wherein the first network element is any one of the following: the instance of the first API, the API publishing function network element, the network storage function network element, and the API storage function network element.

[0032] In one possible design, the processing latency of an instance of the first API is the latency from receiving a request to invoke an instance of the first API to providing a response or result to the request.

[0033] Thirdly, this application provides a communication device, which may be a first device, or a module or unit (e.g., a chip, a chip system, or a circuit) in the first device that performs the methods / operations / steps / actions described in any of the first or second aspects above, or a device that can be used in conjunction with the first device.

[0034] Fourthly, this application provides a communication device including at least one processing element, wherein at least one storage element is used to store programs and data, and the at least one processing element is used to read and execute the programs and data stored in the storage element so that the method described in any of the foregoing aspects of this application is implemented.

[0035] In one possible design, the communication device further includes the at least one storage element.

[0036] Fifthly, this application also provides a computer program that, when run on a computer, causes the computer to perform the method described in any of the preceding aspects.

[0037] In a sixth aspect, this application provides a communication device comprising: an interface circuit and at least one processor; the interface circuit being configured to provide input and / or output of a program or instructions to the at least one processor; the at least one processor being configured to execute the program or instructions such that the communication device can implement the method described in any of the preceding aspects.

[0038] In one possible embodiment, the communication device includes at least one memory for storing the program or instructions.

[0039] In a seventh aspect, this application provides a computer storage medium storing a software program that, when read and executed by one or more processors, can implement the method described in any one of the preceding aspects.

[0040] Eighthly, this application provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method described in any of the preceding aspects.

[0041] Ninthly, this application provides a chip system comprising at least one chip and a memory, wherein the at least one chip is configured to read and execute a program stored in the memory to implement the method described in any of the preceding aspects.

[0042] Based on the implementations provided in the above aspects, this application can be further combined to provide more implementations. Attached Figure Description

[0043] Figure 1 A schematic diagram of a 5G network architecture based on a service-oriented architecture is shown.

[0044] Figure 2A A diagram illustrating the dependencies between external APIs and multiple internal APIs is shown.

[0045] Figure 2B This diagram illustrates the call order of external APIs and multiple internal APIs.

[0046] Figure 3 A diagram showing instances of external APIs and instances of internal APIs is provided.

[0047] Figure 4A and Figure 4B A schematic diagram of the API system architecture is shown;

[0048] Figure 5 A schematic diagram of the CAPIF architecture is shown;

[0049] Figure 6 A flowchart outlining a communication method is shown.

[0050] Figure 7 A flowchart outlining a communication method is shown.

[0051] Figure 8 A flowchart outlining a communication method is shown.

[0052] Figure 9 A flowchart outlining a communication method is shown.

[0053] Figure 10 A flowchart outlining another communication method is shown;

[0054] Figure 11 A schematic diagram of the structure of a communication device is shown;

[0055] Figure 12 A schematic diagram of another communication device is shown. Detailed Implementation

[0056] The specific implementations of this application are described below with reference to the accompanying drawings in the embodiments. However, the implementations of this application may also include combining these embodiments without departing from the scope of this application, such as using other embodiments and making structural changes. Therefore, the detailed description of the following embodiments should not be understood in a limiting sense. The terminology used in the embodiment section of this application is only used to explain the specific embodiments of this application and is not intended to limit this application.

[0057] The embodiments of this application can be applied to various communication systems, such as: Global System for Mobile Communications (GSM) system, Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD) system, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WIMAX) communication system, 5th Generation (5G) system or New Radio (NR), or future communication systems or other similar communication systems, etc.

[0058] Figure 1 This is a schematic diagram of a 5G network architecture based on a service-oriented architecture. Figure 1The 5G network architecture shown may include terminals, access network equipment, and core network equipment. Terminals access the data network (DN) through access network equipment and core network equipment. The core network equipment includes various network functions (NFs) or network elements, such as some or all of the following network elements: unified data management (UDM) network elements, unified data repository (UDR) network elements, application function (AF) network elements, policy control function (PCF) network elements, access and mobility management function (AMF) network elements, session management function (SMF) network elements, user plane function (UPF) network elements, network repository function (NRF) network elements, and network data analytics function (NWDAF) network elements, etc.

[0059] Access network equipment can be radio access network (RAN) equipment. Examples include: base stations, evolved NodeBs (eNodeBs), transmission reception points (TRPs), next-generation NodeBs (gNBs) in 5G mobile communication systems, next-generation base stations in future mobile communication systems, or access nodes in wireless fidelity (WiFi) systems. It can also be modules or units that perform some of the functions of the access network equipment; for example, it can be a central unit (CU) or a distributed unit (DU). Access network equipment can be macro base stations, micro base stations, indoor stations, relay nodes, or donor nodes. The embodiments of this application do not limit the specific technologies or equipment forms used in the access network equipment.

[0060] Terminals can be user equipment (UE), mobile stations, mobile terminals, etc. Terminals can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), the Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, etc. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, urban air mobility vehicles (such as drones, helicopters, etc.), ships, robots, robotic arms, smart home devices, etc.

[0061] Access network devices and terminals can be fixed in location or mobile. They can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can be deployed in the air on aircraft, balloons, and artificial satellites. The embodiments of this application do not limit the application scenarios of the access network devices and terminals.

[0062] The following is a brief introduction to some core network equipment:

[0063] The AMF (Active Mobility Filter) element, or AMF for short, includes functions such as mobility management and access authentication / authorization. It is also responsible for transmitting user policies between the terminal and the PCF (Programmable Component Filter).

[0064] The SMF network element, or SMF for short, includes functions such as session management, execution of control policies issued by the PCF, selection of the UPF, and allocation of Internet Protocol (IP) addresses to terminals.

[0065] UPF (User Plane Filter) network elements serve as interfaces with data networks and include functions such as user plane data forwarding, session / flow-based billing and statistics, and bandwidth limiting.

[0066] UDM network elements, or UDM for short, include functions such as managing contracted data and authorizing user access.

[0067] UDR network element, or UDR for short, includes functions for storing and retrieving data of various types, such as contract data, policy data, and application data.

[0068] NEF (Network Element for short) is used to support the opening of capabilities and events.

[0069] An AF (Application Provider) network element, or AF for short, conveys application-side requests to the network side, such as Quality of Service (QoS) requirements or user state event subscriptions. An AF can be a third-party functional entity or an application server deployed by the operator.

[0070] PCF network element, or PCF for short, includes policy control functions such as billing at the session and service flow levels, QoS bandwidth guarantee and mobility management, and terminal policy decision-making.

[0071] NRF network elements, or NRF for short, can be used to provide network element discovery functionality, providing network element information corresponding to the network element type based on requests from other network elements. NRF network elements also provide network element management services, such as network element registration, updates, deregistration, and network element status subscription and push.

[0072] It is understood that the above network elements are merely examples of one implementation method. This application does not preclude the possibility that future communication systems or other similar communication systems may contain network elements or devices with the above-mentioned network element functions but with other names or forms. Furthermore, the above-mentioned network elements or functions can be network components in hardware devices, software functions running on dedicated hardware, or virtualized functions instantiated on a platform (e.g., a cloud platform). As one possible implementation method, the above-mentioned network elements or functions can be implemented by one device, multiple devices working together, or a functional module within a single device; this application does not specifically limit this.

[0073] The following content mainly uses the performance metrics on latency provided by the API as an example. In addition, NF or API may also provide performance metrics on other aspects, which are not limited in this application.

[0074] This application primarily concerns two types of APIs: external APIs and internal APIs. External APIs, also known as service APIs, refer to APIs provided by the operator's network to applications. Examples include extended reality (XR) transport APIs and industrial high-reliability data transmission APIs. Internal APIs, also known as network APIs, refer to APIs provided by network entities or network elements within the operator's network or controlled by the operator. These network entities or network elements can be access network equipment, core network elements, or operator application servers. Examples include quality of service (QoS) request APIs and network transmission quality analysis APIs.

[0075] In providing services, an external API may need to call one or more internal APIs. Alternatively, an external API may have dependencies on one or more internal APIs; or, an external API may have a mapping relationship with one or more internal APIs.

[0076] For example, the external API is the service API for XR transmission. In the process of providing XR transmission services, the external API needs to call multiple internal APIs, such as the QoS request API and the network transmission quality analysis API.

[0077] For example, see Figure 2A It can be seen that external API_a depends on internal API_1, internal API_2, and internal API_4. It should be noted that Figure 2 does not show the calling order of external API_a, internal API_1, internal API_2, and internal API_4.

[0078] For example, when an external API depends on multiple internal APIs, the order in which the external API and the multiple internal APIs are called can be sequential, parallel, or a directed acyclic graph, etc. The external API and / or internal APIs may be called once or multiple times.

[0079] For example, external API_a depends on internal API_1 and internal API_2. The calling order can be external API_a -> internal API_1 -> internal API_2, such as... Figure 2B 1. Alternatively, the calling order can be external API_a -> internal API_1 -> internal API_2 -> external API_a, such as... Figure 2B 2. Alternatively, the calling order can be external API_a -> internal API_1 -> internal API_2 -> internal API_1 -> external API_a, such as... Figure 2B 3. Alternatively, the calling order can be external API_a -> internal API_1 and internal API_2 (i.e., internal API_1 and internal API_2 in parallel) -> external API_a, such as... Figure 2B In the 4th case, the timing represented by the straight line precedes the timing represented by the dashed line.

[0080] Understandably, an API can correspond to one or more instances, each with the same functionality and API name, but each instance can have different performance. For example, an external API can correspond to one or more instances of an external API, and an internal API can correspond to one or more instances of an internal API. See, for example, [link to relevant documentation]. Figure 3 It can be seen that external API_a can correspond to multiple instances of external API_a, and internal API_1 can correspond to multiple instances of internal API_1.

[0081] The following describes the system architecture that may be adopted in this application:

[0082] I. API System Architecture.

[0083] The API system architecture can include the following functional entities: API management system, external API instance, capability opening gateway, core functional network element, and API invoker.

[0084] The number of external API instances can be one or more, as follows: Figure 4A and Figure 4B This example uses only one external API instance for illustration.

[0085] 1) Capability Opening Gateway: A capability opening gateway is an entry point for external API calls, enabling functions such as topology hiding and dynamic routing. Upon receiving a call request from an API calling entity, the capability opening gateway selects a suitable instance of an external API from one or more instances and forwards or routes the call request to the selected instance. It can also perform checks on resource owner consent. Capability opening gateways can also be API gateways, NEF (Network Element Framework), or API exposing function (AEF) network elements. Capability opening gateways can be divided into two types: local capability opening gateways and central capability opening gateways, with different deployment locations. Local capability opening gateways have a smaller coverage area than central capability opening gateways. Generally, local capability opening gateways are deployed closer to terminals and access network devices, and are more numerous and densely distributed, while central capability opening gateways are generally deployed on aggregation and backbone networks, with fewer deployments and a sparser distribution.

[0086] The external API instance can be deployed in the same network element or device as the capability open gateway. In this case, the transmission latency between the external API instance and the capability open gateway is negligible. Alternatively, the external API instance can also be deployed in a different network element or device than the capability open gateway; this application does not limit this. The following... Figure 4A and Figure 4B This example only illustrates the deployment of external API instances and capability open gateways on different network elements or devices.

[0087] (ii) Core Functional Network Elements: These can be the core function of the Universal Application Programming Interface Framework (CAPIF, CCF) or other network elements with similar functions. This application does not limit their names; the following description uses CCF as an example. The functions of CCF can be found below. Figure 5 The relevant description of CCF in China.

[0088] (iii) API calling entities are generally third-party application function entity software programs that have signed service agreements with public land mobile network (PLMN) operators. These third-party applications can be, for example, machine-to-machine (M2M) applications, Internet of Things (IoT) applications, or vehicle-to-everything (V2X) applications. These applications can run on terminals or access network equipment. Additionally, API calling entities can also refer to AF (Automatic Front-End) network elements. API calling entities can be in the same trust domain as the API provider (e.g., the PLMN operator) or belong to different trust domains. API calling entities support the following capabilities: triggering the online or offline status of API calling entities; supporting API calling entity authentication by providing the API calling entity's identifier and other information; supporting mutual authentication with the Common API Framework (CAPIF); obtaining authorization between access / access APIs; requesting API discovery; requesting gateway discovery; and requesting API invocation.

[0089] 4) API Management System: Responsible for managing the resources required and used by APIs, such as scheduling container resources for APIs, fetching API code packages, and installing API code packages.

[0090] The API management system can be a separate functional entity.

[0091] 5) External API Instances: External API instances are functional entities that provide specific API functions for third parties (such as applications) to call. They can be deployed on physical servers, virtual machines, or containers.

[0092] This architecture may include, but is not limited to, the following functions:

[0093] 1. External API Repository Function: Responsible for storing information about external APIs.

[0094] This function can be a standalone functional entity, or it can be part of a core functional network element, NRF, or capability open gateway.

[0095] 2. External API discovery function: responsible for discovering available APIs.

[0096] This function can be a standalone functional entity, or it can be part of a CCF or Capability Open Gateway.

[0097] Specifically, this function is responsible for handling external API discovery requests from API call entities, and can also authorize and authenticate external API discovery, and return external API information to API call entities.

[0098] 3. External API Account Management Function: Responsible for registration, billing, acquisition and updating of security tokens, as well as management of third-party accounts, including user order history, billing records, API usage statistics, etc.

[0099] This function can be a standalone functional entity or it can be part of the CCF.

[0100] 4. Gateway discovery function: Responsible for discovering available capability-opening gateways.

[0101] 5. External API Publishing Function: Responsible for registering instances of external APIs to the external API repository. This function can be part of an API management system, external API instances, or a capability exposure gateway.

[0102] It's important to note that the NRF can manage the network element profiles registered with it, enabling granular management at the network element level. Furthermore, the NRF can manage service functions, such as IMS AS functional entities, and third-party services deployed within the operator's network that they wish to expose externally (e.g., AI models). In addition, the NRF can manage service information; that is, it can maintain service-level information, including information on NF services, service services, and API services.

[0103] II. Common API Framework (CAPIF) Architecture

[0104] See Figure 5 The diagram shown is a schematic of the CAPIF architecture.

[0105] The CAPIF architecture includes API call entities, CCF network elements, and API publishing function (APF) network elements. It may also include AEF network elements and API management function network elements.

[0106] The API call entity can refer to the above-mentioned content.

[0107] The CCF network element supports the following functions: authenticating API calling entities based on their identifiers and other information; supporting mutual authentication between API calling entities; providing authorization for API calling entities before they access / access APIs; supporting API publishing, storage, and discovery functions; controlling API access / access based on policies configured in the operator's PLMN; storing API call log information and providing these logs to other authorized entities; performing billing based on API call log information; monitoring API call activity; performing API calling entity online / offline functions; storing CAPIF or API-related configuration policy information; supporting access to / access to API logs for auditing functions; and supporting interconnection with another CCF to achieve API publishing and discovery functions.

[0108] The AEF network element, or API open function entity, is the API provider and also the entry point for API call entities to make API calls. The AEF network element supports the following functions: performing API call entity authentication based on the API call entity's identifier and other information; confirming the authorization provided by CCF; and synchronizing API call logs to CCF.

[0109] The APF network element's API publishing function enables API providers to publish API information, thereby supporting API call entities to discover API information. The APF network element supports the following functions: publishing the API information of API providers to the CCF; and providing API publishing functionality so that API call entities can discover APIs.

[0110] The Application Programming Interface (API) Management network element manages APIs for API providers. This element offers the following functions: auditing API call logs received from the CCF (Content Controller Center); monitoring relevant events reported by the CCF; configuring API provider policy information to the CCF; monitoring API status; supporting the online / offline status of API call entities; and supporting the registration and maintenance of API provider domain functions.

[0111] The CAPIF architecture involves numerous interfaces, which can be broadly categorized into two types: communication interfaces within the trusted domain and communication interfaces outside the trusted domain, such as... Figure 5 As shown, the former includes the CAPIF-1 interface, CAPIF-2 interface, CAPIF-3 interface, CAPIF-4 interface, and CAPIF-5 interface, while the latter includes the CAPIF-1e interface and CAPIF-2e interface. Specifically, the CAPIF-1 interface is the interface between the API calling entity within the trusted domain and the CCF. The CAPIF-2 interface is the interface between the API calling entity within the trusted domain and the AEF network element. The CAPIF-3 interface is the interface between the AEF network element and the CCF. The CAPIF-4 interface is the interface between the APF network element and the CCF. The CAPIF-5 interface is the interface between the application programming interface management function network element and the CCF. The CAPIF-1e interface is the interface between the API calling entity outside the trusted domain and the CCF, and the CAPIF-2e interface is the interface between the API calling entity outside the trusted domain and the AEF network element. It is understood that the above interfaces are merely examples and are not intended to limit the scope of this application.

[0112] Based on the above, this application provides a communication method to enable service callers to invoke APIs that meet performance requirements to provide services. In such cases... Figure 6 In the illustrated embodiment, the first device is used as the execution subject for explanation. (In conjunction with the above...) Figure 4A or Figure 4B The first device can be a core functional network element (such as CCF), a capability open gateway, or an external API instance. It is understood that the aforementioned execution entity can also be replaced by a device with corresponding equipment functions, or a chip, unit, or module inside a communication device with corresponding functions.

[0113] Step 600: The first device acquires the first information.

[0114] The first information indicates that the first API calls the second API in the process of providing the first service. For example, the first API is an external API, and the second API is an internal API. The first API is used to provide the first service, and in the process of providing the first service, the first API needs to call the second API; in other words, the first API and the second API have a mapping relationship, or the first API depends on the second API.

[0115] For example, the first information includes information about a first API and information about a second API, wherein the information about the first API includes the identifier and / or name of the first API. The information about the second API includes the identifier and / or name of the second API. The identifier of the API is a combination of letters, numbers, and / or special characters that identify a specific API, and the name of the API can be a Uniform Resource Locator (URL) or a Uniform Resource Identifier (URI).

[0116] In one possible implementation, the first information may also instruct the first API to call the third API during the provision of the first service, and specify the order in which the first, second, and third APIs are called. For details regarding the call order, please refer to the above. Figure 2B Examples.

[0117] The third API differs from the second API; it is also an internal API. In other words, the first API can call one or more APIs while providing the first service. When the first API calls multiple APIs while providing the first service, the first information also indicates the order in which the first API and the multiple APIs are called, such as sequentially or in parallel.

[0118] Step 610: The first device obtains the processing latency of the first API instance and the processing latency of one or more instances corresponding to the second API based on the first information.

[0119] For example, the processing latency of the first API instance can also be referred to as the response latency or response time of the first API instance. The processing latency of the first API instance is the latency between receiving a request to call the first APF instance and sending a corresponding call request to the next-hop second API instance, or the latency between receiving a request to call the first API instance and providing a response or result. For example, the processing latency of the first API instance can be determined based on the processing time of the first API instance for a unit of data or the amount of data processed by the first API instance per unit time. That is, the first device can obtain the processing time of the first API instance for a unit of data or the amount of data processed by the first API instance per unit time, and further estimate the processing latency of the first API instance accordingly.

[0120] For example, the above-mentioned unit of data can be one bit, one byte, or 1 MB, etc., and the above-mentioned unit of time can be 1 millisecond, 1 second, etc.

[0121] Similarly, the processing latency of the second API instance can also be called the response latency or response time of the second API instance. The processing latency of the second APF instance is the latency between receiving the call request of the second API instance and sending the corresponding call request to the next hop instance, or the latency between receiving the request to call the second API instance and giving the response or result of the request.

[0122] For example, the processing latency of an instance of the second API can be determined based on the processing time per unit of data of the second API instance or the amount of data processed per unit of time of the second API instance. That is, the first device can obtain the processing time per unit of data of the second API instance or the amount of data processed by the second API instance per unit of time, and further estimate the processing latency of the second API instance accordingly.

[0123] For example, the processing delay mentioned above can be a specific numerical value, such as 20ms. Alternatively, the processing delay can also be a delay range, such as 25ms to 50ms. Or, the processing delay can also be delay indication information, such as the number 1 indicating a delay range of 20ms to 30ms, the number 2 indicating a delay range of 30ms to 40ms, the letter 'a' indicating a delay range of 20ms to 30ms, and the letter 'b' indicating a delay range of 30ms to 40ms, etc.

[0124] It is understood that the first API can correspond to one or more instances, and the second API can correspond to one or more instances. The following explanation only uses the example of the first API corresponding to one instance. When the first API corresponds to multiple instances, the first device can perform the following steps for each instance of the first API; for details, please refer to [reference needed]. Figure 7 The relevant content in the illustrated embodiment.

[0125] The processing latency for the first device to obtain an instance of the first API and the processing latency for obtaining one or more instances corresponding to the second API are described below:

[0126] I. Processing latency of the first device acquiring an instance of the first API

[0127] For example, the processing latency of an instance of the first API can be a fixed value. Alternatively, the processing latency of an instance of the first API can be a variable value, for example, the processing latency of an instance of the first API can be the processing latency of the most recent instance of the first API, or the processing latency of an instance of the first API can be the average of the processing latencies of the most recent K instances of the first API, where K is a positive integer.

[0128] In one example, the first device can simultaneously obtain the first information and the processing latency of the first API instance, without needing to obtain the processing latency of the first API instance based on the first information after obtaining the first information. This example is generally applicable to scenarios where the processing latency of the first API instance is a fixed value.

[0129] In another example, the first device can obtain the processing latency of an instance of the first API based on the first information after receiving the first information. The above example is generally applicable to scenarios where the processing latency of an instance of the first API is a variable value.

[0130] In one possible implementation, the first device can obtain the processing latency of the first information and the instance of the first API from the first network element. The processing latency of the first information and the instance of the first API can be carried by one message or by two different messages; this application does not limit this. Exemplarily, the first network element can be any one of the following: an instance of the first API, an API publishing function network element, a network storage function network element, or an API storage function network element.

[0131] For example, an instance of the first API can send its own processing latency and first information to the first device.

[0132] For example, an instance of the first API or a network element that publishes an independent API sends its processing latency and first information to a network storage network element or an API storage network element. The instance of the first API can read the guaranteed processing latency based on its configuration information (generally information in the configuration file provided by the API management system when instantiating the instance). The API management system can provide one or more instances of the first API with different processing latencies based on empirical or statistical values. The API management system can also determine the instances of the first API with one or more different processing latencies based on the network conditions corresponding to the topology location of the first API instance to be deployed (e.g., average network latency, statistical network latency, 99% latency range value), so that the latency performance of the finally determined first API meets the end-to-end latency requirements of the business. The independent API publishing function can be part of the API management system. The independent API publishing function has information on one or more processing latencies supported by all instances of the first API. This information can be obtained from the API management system, or the system administrator can pre-configure one or more processing latency information remotely or locally into the independent API publishing function. The network storage function network element or API storage function network element stores the processing latency of the first information and the instance of the first API, and can send the first information and the processing latency of the instance of the first API to the first device. In addition, the network storage function network element or API storage function network element can also store the mapping relationship between other external APIs and internal APIs, as well as the processing latency of instances of various APIs.

[0133] In another possible implementation, the first device can obtain the first information from the first network element and then obtain the processing latency of the first API instance from other network elements. That is, the first device may obtain the first information and the processing latency of the first API instance from different network elements respectively.

[0134] For example, an instance of the first API or an API publishing function network element can send first information to a network storage function network element or an API storage function network element. The network storage function network element or the API storage function network element stores the first information and can send the first information to a first device. Then, the first device obtains the processing latency of the first API instance from the first API instance based on the first information.

[0135] In one possible design, the processing latency of an instance can be understood as the upper bound of the instance's processing latency, or in other words, the maximum processing latency of the instance. If the instance cannot guarantee this processing latency, the API management system can be triggered to create a new instance or to expand the current instance.

[0136] For example, the processing latency of an instance can be determined based on the instance's own capabilities. For instance, the instance can determine its own processing latency based on the processing time per unit of data volume and the maximum amount of data it can process, or based on the amount of data processed per unit of time and the maximum amount of data it can process.

[0137] In another possible design, the first device obtains the processing time for each instance per unit of data or the amount of data processed per unit of time. The first device can estimate the processing latency of each instance based on the estimated amount of data provided by the device that calls the first API.

[0138] For example, an instance of the first API can send its processing time per unit of data or the amount of data it processes per unit of time to the first device. An instance of the second API can provide its processing time per unit of data or the amount of data it processes per unit of time when registering with the NRF, and then the NRF can send the processing time per unit of data or the amount of data processed per unit of time of the second API instance to the first device.

[0139] For example, the first device can calculate the processing latency of each instance based on the estimated amount of data provided by the device calling the first API and the processing time of each instance for a unit amount of data (or the amount of data processed per unit time).

[0140] In this context, the processing time for each instance per unit of data volume can be understood as the maximum processing time for that instance per unit of data volume, or the amount of data processed by each instance per unit of time can be understood as the minimum amount of data processed by that instance per unit of time.

[0141] II. Processing latency of the first device acquiring one or more instances corresponding to the second API

[0142] For example, the first device can obtain the processing latency of one or more instances corresponding to the second API from the second network element based on the first information, wherein the second network element is a network storage function network element, or an NF management system, or an API management system.

[0143] For example, the first device sends information about the second API to the second network element based on the first information. This information may include the identifier and / or name of the second API. The second network element queries the processing latency of one or more instances corresponding to the second API based on the second API information, and then sends the processing latency of the one or more instances corresponding to the second API to the first device. Furthermore, the second network element may also send other information to the first device, which is not limited in this application.

[0144] For example, during the registration process of an instance of the second API, the instance of the second API provides its processing latency to the network storage function element. For instance, the instance of the second API can send a registration message to the network storage function element. The registration message may include the processing latency of the second API instance. Furthermore, the registration message may also include the identifier of the second API, the name of the second API, the version number of the second API, the communication address of the second API instance (e.g., the IP address and port number of the second API instance), and the type of the second API instance. The type of the second API instance can be a network function instance, a business service instance, a third-party deployed service instance, etc. For example, a network function instance can be denoted as NFx, a business service instance can be denoted as ANFy, and a third-party deployed service instance can be denoted as AFz. Optionally, the registration message may also indicate the service area of ​​the second API instance, etc.

[0145] It is understandable that if the first API calls the second API and the third API in the process of providing the first service, the first device also needs to obtain the processing latency of one or more instances corresponding to the third API. The specific process is similar to the first device obtaining the processing latency of one or more instances corresponding to the second API, and will not be repeated here.

[0146] Step 620: The first device obtains the transmission delay corresponding to at least one topology combination, wherein each topology combination includes one of an instance of the first API and one or more instances corresponding to the second API.

[0147] For example, the first device can obtain the topological relationship between an instance of the first API and one or more instances corresponding to the second API, and determine at least one topological combination based on the topological relationship between the instances of the first API and the one or more instances corresponding to the second API. For example, assuming there is one instance of the first API and M instances corresponding to the second API, where M is a positive integer, the first device can determine M topological combinations. Each topological combination includes an instance of the first API, but the instances of the second API are different in different topological combinations. Further, the transmission latency corresponding to each topological combination can be determined based on the transmission latency between the instances of the first API and the instances of the second API in that topological combination.

[0148] Example 1: Suppose that the first API calls the second API while providing the first service. Instances of the second API include NFx1 and NFx2, and the instance of the first API is denoted as external API instance a. The following two topology combinations can be formed:

[0149] The topology combination (1) includes the following instances: external API instance a, NFx1;

[0150] The topology combination (2) includes the following instances: external API instance a, NFx2;

[0151] If external API instance a and NFx1 are each called once, that is, the calling order of instances in topology combination (1) is external API instance a->NFx1, the transmission delay corresponding to topology combination (1) is the transmission delay between external API instance a and NFx1.

[0152] If the calling order of instances within topology combination (1) is external API instance a->NFx1->external API instance a, the transmission delay corresponding to topology combination (1) is twice the transmission delay between external API instance a and NFx1.

[0153] The order in which the first API and the second API are called (or the order in which instances within each topology combination are called) can be indicated by the first information or configured in advance; this application does not limit this.

[0154] Furthermore, in one possible implementation, if the first API calls the second API and the third API in the process of providing the first service, each topology combination includes an instance of the first API, one of one or more instances corresponding to the second API, and one of one or more instances corresponding to the third API.

[0155] Example 2: Suppose that the first API calls the second and third APIs while providing the first service. Instances of the second API include NFx1 and NFx2, and instances of the third API include ANFy1 and ANFy2. The instance of the first API is denoted as external API instance b. In this case, the following four topology combinations can be formed:

[0156] The topology combination (1) includes the following instances: external API instance b, NFx1, ANFy1;

[0157] The topology combination (2) includes the following instances: external API instance b, NFx1, ANFy2;

[0158] The topology combination (3) includes the following instances: external API instance b, NFx2, ANFy1;

[0159] The topology combination (4) includes the following instances: external API instance b, NFx2, and ANFy2.

[0160] It is understandable that the above four topology combinations represent all possible topology combinations. If the first device can obtain other parameters about each instance, the final number of topology combinations may be less than the total number of possible topology combinations. For example, if the service area of ​​ANFy2 is different from the service areas of other instances, and the service areas of other instances are the same, then the topology combination including ANFy2 is invalid, that is, topology combination (2) and topology combination (4) are invalid. In this case, the final number of topology combinations is 2, that is, only topology combination (1) and topology combination (3) are valid. Or, if the distance between ANFy2 and NFx2 is greater than a preset distance threshold, or the transmission delay between ANFy2 and NFx2 is greater than a preset delay threshold, then topology combination (4) is invalid. In this case, the final number of topology combinations is 3.

[0161] Furthermore, if the first API calls the second and third APIs while providing the first service, the transmission latency for each topology combination depends not only on the transmission latency between the instances in that topology combination, but also on the calling order of the first, second, and third APIs. Alternatively, if the first API calls multiple APIs while providing the first service, the transmission latency for each topology combination depends not only on the transmission latency between the instances in that topology combination, but also on the calling order of the first API and the multiple APIs.

[0162] For example, if the calling order is first API -> second API -> third API, that is, the first API, second API, and third API are called in sequence, the transmission latency corresponding to each topology combination can be determined based on the transmission latency between instances of the first API and instances of the second API, and the transmission latency between instances of the second API and instances of the third API in that topology combination.

[0163] Referring to Example 2, if the calling order of instances within topology combination (1) is external API instance b->NFx1->ANFy1, the transmission delay of topology combination (1) is the sum of the transmission delay between external API instance b and NFx1 and the transmission delay between NFx1 and ANFy1.

[0164] For example, if the calling order is first API -> second API -> third API -> first API, that is, calling first API, second API, third API, and first API in sequence, then the transmission latency corresponding to each topology combination can be determined based on the transmission latency between instances of the first API and instances of the second API, the transmission latency between instances of the second API and instances of the third API, and the transmission latency between instances of the third API and instances of the first API in that topology combination.

[0165] Referring to Example 2, if the calling order of instances in topology combination (1) is external API instance b->NFx1->ANFy1->external API instance b, the transmission delay of topology combination (1) is the sum of the transmission delay between external API instance b and NFx1, the transmission delay between NFx1 and ANFy1, and the transmission delay between external API instance b and ANFy1.

[0166] For example, if the calling order is that the first API calls the second API and the third API simultaneously, that is, the second API and the third API are in parallel, then the transmission delay corresponding to each topology combination can be determined based on the maximum value of the transmission delay between the instances of the first API and the second API in that topology combination and the transmission delay between the instances of the first API and the third API.

[0167] Referring to Example 2, if the transmission delay between external API instance b and NFx1 is greater than or equal to the transmission delay between external API instance b and ANFy1, the transmission delay of topology combination (1) is the transmission delay between external API instance b and NFx1. If the transmission delay between external API instance b and NFx1 is less than the transmission delay between external API instance b and ANFy1, the transmission delay of topology combination (1) is the transmission delay between external API instance b and ANFy1.

[0168] It should be noted that the transmission latency between any two instances in each topology combination can be understood as the time required for one instance to send a message and for another instance to receive it. The transmission latency between any two instances can be estimated based on the specific network deployment and / or the transmission medium used between nodes in the network. For example, if instance A and instance B are connected via several hops of switches or routers, the transmission latency between instance A and instance B can be estimated based on prior knowledge or a fixed algorithm. As another example, if instance A and instance B are directly connected, and the transmission medium between instance A and instance B is optical fiber, the transmission latency between instance A and instance B can be estimated based on the length of the optical fiber.

[0169] In addition, the transmission latency between instances can be dynamically updated based on the current network load. For example, if the load increases by X%, the transmission latency between instances will increase by Y%, where X and Y are positive numbers.

[0170] The transmission delay between any two instances in each of the above topology combinations can be sent to the first device by the network management device or other devices, or configured into the first device manually.

[0171] Step 630: The first device determines the latency performance of the first API based on the processing latency of an instance of the first API, the processing latency of one or more instances of the second API, and the transmission latency corresponding to at least one topology combination.

[0172] In one possible implementation, if the first API calls the second API while providing the first service, the first device can determine the latency performance of at least one topology combination based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to each of the at least one topology combination. Specifically, the latency performance of each topology combination is determined based on the transmission latency and processing latency of that topology combination, and the processing latency of that topology combination is determined based on the processing latency of each instance included in that topology combination.

[0173] For example, if the first API calls the second API while providing the first service, the transmission latency corresponding to each topology combination can be the transmission latency between instances of the first API and the second API in that topology combination. The processing latency corresponding to each topology combination can be the sum of the processing latency of instances of the first API and instances of the second API in that topology combination. The latency performance corresponding to each topology combination can be represented by the sum of the transmission latency and processing latency corresponding to that topology combination. Alternatively, multiple latency ranges can be preset in advance, and the first device can determine the latency range in which the sum of the transmission latency and processing latency corresponding to each topology combination falls, based on the sum of the transmission latency and processing latency corresponding to each topology combination. The latency performance corresponding to each topology combination can then be represented by the latency range in which the sum of the transmission latency and processing latency corresponding to that topology combination falls. Furthermore, the latency performance corresponding to each topology combination can also be represented in other ways, which are not limited in this application.

[0174] Furthermore, when the first device determines the latency performance of the first API based on the latency performance of at least one topology combination, the latency performance of the first API may indicate part or all of the latency performance of at least one topology combination.

[0175] For example, assuming there is one instance of the first API and M instances of the second API (where M is a positive integer), the first device can determine the latency performance corresponding to each of the M topology combinations. The latency performance of each topology combination can be represented by the sum of its transmission latency and processing latency. For ease of description, the sum of the transmission latency and processing latency corresponding to the M topology combinations is denoted as M latency values. If m latency values ​​among the M latency values ​​do not meet a preset condition (e.g., m latency values ​​are greater than or equal to a preset threshold), then the latency performance of the first API can include Mm latency values, but excludes the m latency values ​​greater than or equal to the preset threshold (where m is a positive integer and less than M). In other words, the first device can filter based on the latency performance of at least one topology combination, excluding topology combinations with higher latency.

[0176] Referring to Example 1, if the calling order of instances within topology combination (1) is external API instance a->NFx1, the transmission latency corresponding to topology combination (1) is the transmission latency between external API instance a and NFx1, and the processing latency corresponding to topology combination (1) is the sum of the processing latency of external API instance a and the processing latency of NFx1. The latency performance corresponding to topology combination (1) can be represented by the sum of the transmission latency and processing latency corresponding to topology combination (1). Similarly, the latency performance corresponding to topology combination (2) can be represented by the sum of the transmission latency and processing latency corresponding to topology combination (2). Among them, the latency performance of external API instance a can be two types, namely the latency performance corresponding to topology combination (1) and the latency performance corresponding to topology combination (2).

[0177] Furthermore, if the first API calls the second API and the third API during the provision of the first service, the processing latency of one or more instances corresponding to the third API is obtained based on the first information, and the latency performance of the first API is determined based on the processing latency of the instances of the first API, the processing latency of one or more instances corresponding to the second API, the processing latency of one or more instances corresponding to the third API, and the transmission latency corresponding to at least one topology combination.

[0178] For example, if the first API calls the second API and the third API in the process of providing the first service, the first device obtains the processing latency of one or more instances corresponding to the third API according to the first information, and then determines the latency performance of the first API according to the processing latency of the instances of the first API, the processing latency of one or more instances corresponding to the second API, the processing latency of one or more instances corresponding to the third API, and the transmission latency corresponding to at least one topology combination.

[0179] Referring to Example 2, if the calling order of instances within topology combination (1) is external API instance b->NFx1->ANFy1, the transmission latency of topology combination (1) is the sum of the transmission latency between external API instance b and NFx1, and the transmission latency between NFx1 and ANFy1. The processing latency of topology combination (1) is the sum of the processing latency of external API instance b, the processing latency of NFx1, and the processing latency of ANFy1. The latency performance of topology combination (1) can be represented by the sum of the transmission latency and processing latency of topology combination (1).

[0180] The latency performance of external API instance b can be four types, represented by the latency performance corresponding to topology combination (1), topology combination (2), topology combination (3), and topology combination (4). Alternatively, if the latency performance corresponding to topology combination (2) does not meet the preset conditions, for example, if the sum of the transmission latency and processing latency corresponding to topology combination (2) is greater than or equal to a preset threshold, then the latency performance of external API instance b can be three types, namely the latency performance corresponding to topology combination (1), topology combination (3), and topology combination (4).

[0181] For example, when determining the latency performance of the first API based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to at least one topology combination, the first device can determine the latency performance of the first API based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second APF, the transmission latency corresponding to at least one topology combination, and the transmission latency between the instance of the first API and the first capability open gateway, wherein the first capability open gateway is the first hop node of the instance calling the first API.

[0182] Alternatively, it can be understood that, in addition to the transmission latency corresponding to at least one topology combination and the processing latency of the instance in each topology combination, when determining the latency performance of the first API, the first device can also combine the transmission latency between the instance of the first API and the first capability open gateway.

[0183] Therefore, before determining the latency performance of the first API, the first device can first determine the capability open gateway corresponding to the instance of the first API, i.e., the first capability open gateway. For example, the first device can obtain the topology relationship between at least one capability open gateway and the instance of the first API, and select the first capability open gateway from at least one capability open gateway based on this topology relationship. Furthermore, the first device can also combine parameters such as the service area of ​​at least one capability open gateway, the service area of ​​the instance of the first API, and the service area of ​​one or more instances corresponding to the second API to jointly determine the first capability gateway.

[0184] Referring to Example 1, assuming that the capability open gateway corresponding to external API instance a is capability open gateway 1, if the calling order of instances in topology combination (1) is external API instance a->NFx1, the transmission delay corresponding to topology combination (1) is the transmission delay between external API instance a and NFx1, and the processing delay corresponding to topology combination (1) is the sum of the processing delay of external API instance a and the processing delay of NFx1.

[0185] The latency performance corresponding to topology combination (1) can be determined based on sequence 1, where sequence 1 is capability open gateway 1 -> external API instance a -> NFx1. The latency performance corresponding to topology combination (1) can be expressed as the sum of the transmission latency corresponding to topology combination (1), the processing latency corresponding to topology combination (1), and the transmission latency between external API instance a and capability open gateway 1.

[0186] Alternatively, the latency performance corresponding to topology combination (1) can be determined based on sequence 2, where sequence 2 is capability open gateway 1 -> external API instance a -> NFx1 -> capability open gateway 1. The latency performance corresponding to topology combination (1) can be expressed as the sum of the transmission latency corresponding to topology combination (1), the processing latency corresponding to topology combination (1), the transmission latency between external API instance a and capability open gateway 1, and the transmission latency between NFx1 and capability open gateway 1. That is, in one possible implementation, when determining the latency performance of the first API, the first device can also combine the transmission latency between the last invoked instance in the topology combination and the first capability open gateway to determine the mobility latency performance of the topology combination.

[0187] Referring to Example 2, if the capability open gateway corresponding to external API instance b is capability open gateway 2, and if the calling order of instances within topology combination (1) is external API instance b->NFx1->ANFy1, the transmission latency of topology combination (1) is the sum of the transmission latency between external API instance b and NFx1, and the transmission latency between NFx1 and ANFy1. The processing latency of topology combination (1) is the sum of the processing latency of external API instance b, the processing latency of NFx1, and the processing latency of ANFy1.

[0188] The latency performance corresponding to topology combination (1) can be determined based on sequence 1, where sequence 1 is capability open gateway 2 -> external API instance b -> NFx1 -> ANFy1. The latency performance corresponding to topology combination (1) can be expressed as the sum of the transmission latency corresponding to topology combination (1), the processing latency corresponding to topology combination (1), and the transmission latency between external API instance b and capability open gateway 2.

[0189] Alternatively, the latency performance corresponding to topology combination (1) can be determined based on sequence 2, where sequence 2 is Capability Open Gateway 2 -> External API Instance b -> NFx1 -> ANFy1 -> Capability Open Gateway 2. The latency performance corresponding to topology combination (1) can be expressed as the sum of the transmission latency corresponding to topology combination (1), the processing latency corresponding to topology combination (1), the transmission latency between external API instance b and capability open gateway 2, and the transmission latency between ANFy1 and capability open gateway 2.

[0190] Furthermore, if the first device is a core functional network element, the first device may also send a first notification message to the first capability open gateway, the first notification message including an identifier of the first API instance. Alternatively, if the first device is a core functional network element or an instance of the first API, after the first device determines the latency performance of the first API, the first device may also send a first notification message to the first capability open gateway indicating the latency performance of the first API. For example, the first notification message may indicate part or all of the latency performance of at least one topology combination corresponding to the latency performance of the first API.

[0191] For example, in conjunction with Example 1, the first notification message indicates one or more of the following: topology combination (1) and the latency performance of topology combination (1), and topology combination (2) and the latency performance of topology combination (2).

[0192] For example, in conjunction with Example 2, the first notification message indicates one or more of the following: topology combination (1) and the latency performance of topology combination (1), topology combination (2) and the latency performance of topology combination (2), topology combination (3) and the latency performance of topology combination (3), and topology combination (4) and the latency performance of topology combination (4).

[0193] If the first device is an instance of a first capability-opening gateway or a first API, the first device may also send a second notification message to the core functional network element, the second notification message indicating the latency performance of the first API. For example, the second notification message may indicate part or all of the latency performance of at least one topology combination corresponding to the latency performance of the first API.

[0194] In one possible implementation, if the first device is a core functional network element or a first capability open gateway, after determining the latency performance of the first API instance, the first device can send the configuration information of the first API instance to the first API instance, and the configuration information of the first API instance indicates the latency performance of the first API.

[0195] For example, in conjunction with Example 1, the configuration information of the instance of the first API indicates one or more of the following: topology combination (1) and the latency performance of topology combination (1), and topology combination (2) and the latency performance of topology combination (2).

[0196] For example, in conjunction with Example 2, the configuration information of the first API instance indicates one or more of the following: topology combination (1) and the latency performance of topology combination (1), topology combination (2) and the latency performance of topology combination (2), topology combination (3) and the latency performance of topology combination (3), and topology combination (4) and the latency performance of topology combination (4).

[0197] Using the above method, the first device can accurately determine the latency performance of the first API based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to at least one topology combination. The latency performance of the first API can be at least one type, meaning the first API can guarantee at least one type of latency. Therefore, before a device requesting the first service calls the first API, at least one type of latency guaranteed by the first API has already been determined. In other words, the first API can provide multiple optional latency performances for the device requesting the first service, thereby enabling the device requesting the first service to call an API that meets its latency requirements to provide services.

[0198] In one possible scenario, the first device is a core functional network element. The first device can discover capability discovery gateways for devices requesting the first service. These capability discovery gateways can invoke instances of APIs that meet latency requirements.

[0199] For example, the first device may receive a first request message from a device requesting the first service (e.g., an API call entity). The device requesting the first service may also be referred to as the device requesting the first API.

[0200] The first request message is used to request the discovery of the capability discovery gateway corresponding to the first API. The first request message includes first indication information, which indicates the latency requirement for the first API. This latency requirement for the first API can also be understood as the end-to-end latency requirement for the first API, or the latency requirement for the first service. The first indication information indicating the latency requirement for the first API can also be replaced by indicating the latency requirement of the device requesting the first API for the first API, or indicating the latency performance that the device requesting the first API expects to achieve, or indicating the latency performance requested by the device requesting the first API.

[0201] For example, the first request message includes the name or identifier of the first API. The latency requirement for the first API can be a specific value or a latency range, or an indication of a specific value or latency range, which is agreed upon by the caller of the first API (i.e., the device requesting the first API) and the operator and / or provider of the first API before the call. For example, the latency requirement for the first service is 50ms, meaning the device requesting the first service expects the maximum latency of the first service to be no more than 50ms. As another example, the latency requirement for the first service is 30ms to 50ms, meaning the device requesting the first service expects the latency of the first service to be between 30ms and 50ms.

[0202] Then, the first device determines the first capability opening gateway based on the latency performance of the first request message and the first API.

[0203] For example, the first device queries the latency performance of the first API based on its name or identifier, and determines whether the latency performance of the first API meets the latency requirements indicated by the first indication information, that is, whether the latency performance of the first API meets the latency requirements of the device requesting the first API (or the first service) (or whether the latency performance of the first API meets the latency requirements requested by the device requesting the first API). For example, the first device may determine whether there exists a topology combination that meets the latency requirements indicated by the first indication information. If there exists a topology combination that meets the latency requirements indicated by the first indication information, then the capability opening gateway corresponding to the instance of the first API in that topology combination is determined to be the capability discovery gateway.

[0204] Wherein, the latency performance of the first API meets the latency requirement indicated by the first indication information, that is, the latency performance of an instance of the first API meets the latency requirement indicated by the first indication information, or it can also be understood that the latency performance of at least one topology combination meets the latency requirement indicated by the first indication information.

[0205] For example, in conjunction with Example 1 above, the first device can query the latency performance of the first API based on the name or identifier of the first API, and can determine whether there is a topology combination that meets the latency requirement indicated by the first indication information based on the first indication information, that is, whether the latency performance corresponding to the topology combination (1) or the latency performance corresponding to the topology combination (2) meets the latency requirement indicated by the first indication information.

[0206] For example, if the first API corresponds to at least two instances, and the capability open gateways corresponding to the at least two instances are different, then the first device determines the instance among the at least two instances that meets the latency requirements indicated by the first indication information, and takes the capability open gateway corresponding to that instance as the discovered capability open gateway. For details, please refer to the following... Figure 7 The illustrated embodiment. In this case, the latency performance of the first API includes the latency performance corresponding to at least two instances.

[0207] After determining the first capability gateway, the first device can send a first response message to the device requesting the first service. The first response message includes the address of the first capability gateway. The first response message can instruct the first capability gateway to invoke an instance of the first API that meets the latency requirements indicated by the first indication information.

[0208] In another possible scenario, the first device is a first capability opening gateway. The first device can accept, process, and / or forward call requests for the device requesting the first API.

[0209] For example, the first device may receive a second request message from a device requesting the first service. The second request message may also be understood as an invocation request.

[0210] The second request message is used to request an invocation of the first API, or to request the first API to provide a first service (or it can be understood as a call message for the first API, or an I-access message for the first API). The second request message includes second indication information, which indicates the latency requirements for the first API. The second indication information is similar to the first indication information and will not be described again here. For example, the second request message may include the name or identifier of the first API.

[0211] Then, the first capability open gateway determines an instance of the first API based on the second request message. For example, the first capability open gateway determines the instance of the first API based on its name or identifier. After determining the instance of the first API, the first capability open gateway sends a call request to the instance of the first API. The call request may include third indication information, which is used to determine one or more topology combinations. The third indication information is determined based on the second indication information. Then, the instance of the first API provides the first service to the device requesting the first service.

[0212] For example, if the first capability-opening gateway only knows the identifier of the first API instance but not the latency performance of the first API instance, the third indication information can indicate the latency requirements for the first API. The third indication information can be the same as the second indication information. Furthermore, the first API instance can select a topology combination that meets the latency requirements based on the latency requirements indicated by the third indication information and the configuration information of the first API instance, and then make calls based on instances within that topology combination.

[0213] If the first capability open gateway learns the latency performance of an instance of the first API, it can determine a topology combination that satisfies the latency requirement indicated by the second indication information based on the latency performance of the first API instance and the latency requirement indicated by the second indication information. Then, the third indication information can indicate one or more determined topology combinations whose latency performance satisfies the latency requirement indicated by the second indication information. Subsequently, the instance of the first API is invoked based on an instance within one of the topology combinations indicated by the third indication information.

[0214] The following Figures 7 to 9 A detailed flowchart is provided to determine the latency performance of the first API, for further explanation. Figure 6 The embodiment shown. Wherein, in... Figures 7 to 9 In the illustrated embodiment, instances of CCF, Capability Open Gateway, NRF, and the first API are used as examples to illustrate the execution of the interaction.

[0215] exist Figure 7 In the illustrated embodiment, CCF corresponds to Figure 6 The first device in the illustrated embodiment.

[0216] S701: The first API instance 1 sends the first information to CCF and the processing delay of the first API instance 1.

[0217] For example, when instance 1 of the first API goes online and starts providing the first service, instance 1 of the first API sends the first information and the processing delay of instance 1 of the first API to CCF.

[0218] Furthermore, the above S701 can also be replaced by: the API publishing function network element can send first information and the processing latency of at least one instance of the first API to the CCF. For example, if instance 1 and instance 2 of the first API are online at the same time, the API publishing function network element can send first information, the processing latency of instance 1 of the first API, and the processing latency of instance 2 of the first API to the CCF.

[0219] The first information indicates that the first API calls the second API in the process of providing the first service. For example, the first information includes the name and / or identifier of the first API, and the name and / or identifier of the second API.

[0220] S702: CCF sends information about the second API to NRF.

[0221] For example, the CCF sends information about the second API to the NRF based on the first information.

[0222] S703: NRF sends the processing latency of one or more instances corresponding to the second API to CCF.

[0223] For example, the NRF can query the instances of the second API registered with the NRF based on the information of the second API, and send the processing latency of the instances of the second API to the CCF. The instances of the second API provide their own processing latency to the NRF during the registration process. For details, please refer to the relevant content on obtaining the processing latency of one or more instances corresponding to the second API by the first device mentioned above, which will not be repeated here.

[0224] In addition, the CCF can send subscription messages to the NRF. These subscription messages are used to subscribe to information about instances of the second API, enabling the CCF to obtain the latest information about these instances in a timely manner. For example, if the processing latency of an instance of a second API is updated, the NRF can send the updated processing latency of that instance to the CCF. Similarly, if the service area of ​​an instance of a second API changes, the NRF can send the updated service area of ​​that instance to the CCF. Furthermore, if a new instance of a second API registers with the NRF, the NRF can send the processing latency of the newly registered instance of the second API to the CCF.

[0225] S704: CCF selects the first capability open gateway for instance 1 of the first API.

[0226] For example, the CCF selects a first capability open gateway from at least one capability open gateway based on the topology relationship between instance 1 of the first API and at least one capability open gateway. For instance, the CCF can obtain the topology relationship between instance 1 of the first API and at least one capability open gateway, and select the capability open gateway closest to instance 1 of the first API based on this topology relationship, or select the capability open gateway with the shortest transmission latency to instance 1 of the first API based on this topology relationship. Furthermore, the CCF can also obtain the service area of ​​instance 1 of the first API, and the service areas corresponding to the at least one capability open gateway, to ensure that the service area of ​​the selected capability open gateway includes the service area of ​​instance 1 of the first API. The topology relationship between instance 1 of the first API and at least one capability open gateway, the service area of ​​instance 1 of the first API, and the service areas corresponding to the at least one capability open gateway can be obtained from the NRF or other network elements, and this application does not limit this.

[0227] Furthermore, if instance 1 and instance 2 of the first API go online simultaneously, the API publishing function network element sends the first information, the processing latency of instance 1 of the first API, and the processing latency of instance 2 of the first API to the CCF. Similar to the above-mentioned selection of a first capability opening gateway by the CCF for instance 1 of the first API, the CCF can also select a second capability opening gateway for instance 2 of the first API. The first capability opening gateway and the second capability opening gateway can be the same or different.

[0228] S705: CCF determines the latency performance of the first API.

[0229] For example, the CCF determines the latency performance of instance 1 of the first API based on the processing latency of instance 1 of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to at least one topology combination including instance 1 of the first API. Alternatively, the CCF determines the latency performance of instance 1 of the first API based on the processing latency of instance 1 of the first API, the processing latency of one or more instances corresponding to the second API, the transmission latency corresponding to at least one topology combination including instance 1 of the first API, and the transmission latency between instance 1 of the first API and the first capability open gateway. The latency performance of instance 1 of the first API is used to represent part or all of the latency performance corresponding to at least one topology combination including instance 1 of the first API.

[0230] For details, please refer to step 630 above, which will not be repeated here. The transmission delays corresponding to at least one topology combination including the first API instance 1, and the at least one topology combination including the first API instance 1, can be obtained from the NRF or other network elements; this application does not limit this.

[0231] If the instances of the first API include only instance 1 of the first API, then the latency performance of instance 1 of the first API is the latency performance of the first API.

[0232] Similarly, if the instance of the first API also includes instance 2 of the first API, the CCF determines the latency performance of instance 2 of the first API based on the processing latency of instance 2 of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to at least one topology combination including instance 2 of the first API. Alternatively, the CCF determines the latency performance of instance 2 of the first API based on the processing latency of instance 2 of the first API, the processing latency of one or more instances corresponding to the second API, the transmission latency corresponding to at least one topology combination including instance 2 of the first API, and the transmission latency between instance 2 of the first API and the second capability open gateway. The latency performance of instance 2 of the first API is used to represent part or all of the latency performance corresponding to at least one topology combination including instance 2 of the first API.

[0233] At this point, the latency performance of the first API can be of two types, including the latency performance of instance 1 of the first API and the latency performance of instance 2 of the first API.

[0234] S706: CCF sends the first notification message to the first capability open gateway.

[0235] For example, the first notification message includes an identifier of instance 1 of the first API. Alternatively, the first notification message indicates the latency performance of instance 1 of the first API.

[0236] Optionally, the CCF sends a second notification message to the second capability gateway, the second notification message including the identifier of instance 2 of the first API. Alternatively, the second notification message indicates the latency performance of instance 2 of the first API.

[0237] S707: CCF sends the configuration information of instance 1 of the first API to instance 1 of the first API.

[0238] For example, the configuration information of instance 1 of the first API indicates the latency performance of instance 1 of the first API.

[0239] Optionally, the CCF sends the configuration information of instance 2 of the first API to instance 2 of the first API. The configuration information of instance 2 of the first API indicates the latency performance of instance 2 of the first API.

[0240] S708: AF sends its first request message to CCF.

[0241] The first request message is used to request a first API to provide a first service. The first request message includes first indication information, which indicates the latency requirement for the first API. For example, the first request message includes the name or identifier of the first API.

[0242] S709: CCF determines the first capability opening gateway based on the first request message.

[0243] For example, the CCF queries the latency performance of the first API based on the name or identifier of the first API, determines whether the latency performance of the first API meets the latency requirements indicated by the first indication information based on the first indication information, that is, determines whether there is a topology combination that meets the latency requirements indicated by the first indication information. If there is a topology combination that meets the latency requirements indicated by the first indication information, then the capability opening gateway corresponding to the instance of the first API in the topology combination is determined.

[0244] For example, as described above, the CCF queries the latency performance of the first API based on its name or identifier. It can then determine whether a topology combination meets the latency requirements indicated by the first indication information. For instance, if a topology combination including instance 1 of the first API meets the latency requirements indicated by the first indication information, the first capability open gateway is determined. Similarly, if a topology combination including instance 1 of the second API meets the latency requirements indicated by the first indication information, the second capability open gateway is determined. The following explanation uses the CCF's determination of the first capability open gateway as an example.

[0245] S710: CCF sends the first response message to AF.

[0246] The first response message includes the address of the first capability-opening gateway.

[0247] S711: AF sends a second request message to the first capability open gateway.

[0248] The second request message is used to request the first API to provide a first service. The second request message includes second indication information, which indicates the latency requirement for the first API. For example, the second request message may include the name or identifier of the first API.

[0249] S712: The first capability open gateway determines instance 1 of the first API based on the second request message.

[0250] For example, the first capability open gateway determines instance 1 of the first API based on the name or identifier of the first API.

[0251] S713: The first capability open gateway sends a call request to instance 1 of the first API. The call request includes third indication information, which is used to determine one or more topology combinations.

[0252] S714: Instance 1 of the first API provides the first service for AF.

[0253] For example, if the first notification message in S706 only includes the identifier of the first API instance and does not indicate the latency performance of the first API instance, then the second indication information can indicate the latency requirement for the first API. Furthermore, the first API instance 1 can select a topology combination based on the latency requirement indicated by the second indication information and the configuration information of the first API instance 1, and make invocations based on instances within that topology combination.

[0254] If the first notification message in S706 indicates the latency performance of instance 1 of the first API, the first capability opening gateway can determine a topology combination that satisfies the latency requirement indicated by the second indication information based on the latency performance of instance 1 of the first API and the latency requirement indicated by the second indication information. Then, the third indication information can indicate one or more determined topology combinations, wherein the latency performance of the one or more topology combinations satisfies the latency requirement indicated by the second indication information. Subsequently, instance 1 of the first API makes a call based on an instance within a topology combination indicated by the third indication information.

[0255] Using the above method, CCF can accurately determine the latency performance of the first API. Therefore, when AF calls the first API, CCF can notify AF of the address of the capability open gateway that can call the instance of the first API that meets the latency requirements based on the latency performance of the first API. Thus, AF can send a second request message to the capability open gateway, thereby realizing the call to the instance of the first API that meets the latency requirements.

[0256] exist Figure 8 In the embodiment shown, the first capability gateway corresponds to Figure 6 The first device in the illustrated embodiment.

[0257] S801: The first API instance 1 sends the first information to CCF and the processing delay of the first API instance 1.

[0258] For details, please refer to S701 above.

[0259] S802: CCF sends information about the second API to NRF.

[0260] For example, the CCF sends information about the second API to the NRF based on the first information.

[0261] S803: NRF sends the processing latency of one or more instances corresponding to the second API to CCF.

[0262] For details, please refer to S703 above.

[0263] S802 and S803 are optional steps.

[0264] S804: CCF selects the first capability open gateway for instance 1 of the first API.

[0265] For details, please refer to S804 above.

[0266] S805: CCF sends the first notification message to the first capability open gateway.

[0267] For example, the first notification message includes an identifier of instance 1 of the first API. Furthermore, the first notification message also includes first information, the processing latency of instance 1 of the first API, and the processing latency of one or more instances corresponding to the second API. Alternatively, the first notification message also includes first information, allowing the first capability open gateway to obtain the processing latency of one or more instances corresponding to the second API from the NRF based on the first information, and the first capability open gateway can also obtain the processing latency of instance 1 of the first API from instance 1 of the first API based on the first information.

[0268] Optionally, S801 to S805 above can also be replaced by: Instance 1 of the first API sending first information and the processing latency of instance 1 of the first API to the first capability open gateway. The first capability open gateway can obtain the processing latency of one or more instances corresponding to the second API from the NRF based on the first information.

[0269] S806: The first capability open gateway determines the latency performance of instance 1 of the first API.

[0270] For example, the first capability open gateway determines the latency performance of instance 1 of the first API based on the processing latency of instance 1 of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to at least one topology combination including instance 1 of the first API. Alternatively, the first capability open gateway determines the latency performance of instance 1 of the first API based on the processing latency of instance 1 of the first API, the processing latency of one or more instances corresponding to the second API, the transmission latency corresponding to at least one topology combination including instance 1 of the first API, and the transmission latency between instance 1 of the first API and the first capability open gateway, wherein the latency performance of instance 1 of the first API is represented by the latency performance corresponding to at least one topology combination including instance 1 of the first API.

[0271] For details, please refer to step 630 above, which will not be repeated here. The transmission delays corresponding to at least one topology combination including the first API instance 1, and the at least one topology combination including the first API instance 1, can be obtained from the NRF or other network elements; this application does not limit this.

[0272] S807: The first capability open gateway sends the configuration information of instance 1 of the first API to instance 1 of the first API.

[0273] For example, the configuration information of instance 1 of the first API indicates the latency performance of instance 1 of the first API.

[0274] Optionally, S808: The first capability open gateway can also send a second notification message to the CCF, which indicates the latency performance of instance 1 of the first API.

[0275] This application does not specify the order of S807 and S808.

[0276] S809: AF sends its first request message to CCF.

[0277] The first request message is used to request the first API to provide the first service. The first request message includes first indication information, which indicates the latency requirement for the first API.

[0278] S810: CCF determines the first capability opening gateway based on the first request message.

[0279] If the CCF obtains the latency performance of instance 1 of the first API through S808, it can refer to S709 above for details.

[0280] If the CCF does not know the latency performance of instance 1 of the first API, the CCF may randomly select a capability opening gateway.

[0281] S811: CCF sends the first response message to AF.

[0282] The first response message includes the address of the first capability-opening gateway.

[0283] S812: AF sends a second request message to the first capability open gateway.

[0284] The second request message is used to request the first API to provide a first service. The second request message includes second indication information, which indicates the latency requirement for the first API. For example, the second request message may include the name or identifier of the first API.

[0285] S813: The first capability open gateway determines instance 1 of the first API based on the second request message.

[0286] If the latency performance of instance 1 of the first API meets the latency requirement indicated by the second indication information, then S814 continues to be executed; otherwise, the first capability discovery gateway can notify the first API instance 1 that the latency performance does not meet the latency requirement indicated by the second indication information. Then, the AF can request the CCF to rediscover the capability discovery gateway for it.

[0287] S814: The first capability open gateway sends a call request to instance 1 of the first API. The call request includes third indication information, which is used to determine one of at least one topology combination.

[0288] For example, the first capability open gateway can determine a topology combination that satisfies the latency requirement indicated by the second indication information based on the latency performance of instance 1 of the first API and the latency requirement indicated by the second indication information. Then, the third indication information can indicate one or more topology combinations whose latency performance satisfies the latency requirement indicated by the second indication information. Alternatively, the third indication information can be the same as the second indication information.

[0289] S815: Instance 1 of the first API provides the first service for AF.

[0290] If the third indication information indicates one or more topology combinations, instance 1 of the first API determines one of the topology combinations and makes a call based on the instance within that topology combination.

[0291] Alternatively, the third instruction information may be the same as the second instruction information, indicating the latency requirements for the first API. Then, instance 1 of the first API can select a topology combination that satisfies the latency requirements indicated by the third instruction information and the configuration information of instance 1 of the first API, and make calls based on instances within that topology combination.

[0292] Using the above method, the first capability open gateway can accurately determine the latency performance of instance 1 of the first API. Therefore, the first capability open gateway can determine whether instance 1 of the first API meets the latency requirements. If it does, it sends a call request to instance 1 of the first API, and thus AF can call the instance of the first API that meets the latency requirements.

[0293] exist Figure 9 In the illustrated embodiment, instance 1 of the first API corresponds to Figure 6 The first device in the illustrated embodiment.

[0294] S901: Instance 1 of the first API sends the first message to the CCF.

[0295] For details, please refer to S701 above.

[0296] S902: CCF selects the first capability open gateway for instance 1 of the first API.

[0297] For details, please refer to S704 above.

[0298] S903: CCF sends information about the first capability open gateway to instance 1 of the first API.

[0299] For example, the information of the first capability open gateway includes the identifier or address of the first capability open gateway.

[0300] S904: Instance 1 of the first API sends information about the second API to the NRF.

[0301] For example, instance 1 of the first API sends information about the second API to the NRF based on the first information.

[0302] S905: NRF sends the processing latency of one or more instances corresponding to the second API to instance 1 of the first API.

[0303] For example, the NRF can query the instances of the second API registered with the NRF based on the information of the second API, and send the processing latency of the second API instances to instance 1 of the first API.

[0304] This application does not specify the order of S901 and S904.

[0305] S906: Instance 1 of the first API determines the latency performance of the first API.

[0306] For example, instance 1 of the first API determines its latency performance based on the processing latency of instance 1 of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to at least one topology combination including instance 1 of the first API. Alternatively, instance 1 of the first API determines its latency performance based on the processing latency of instance 1 of the first API, the processing latency of one or more instances corresponding to the second API, the transmission latency corresponding to at least one topology combination including instance 1 of the first API, and the transmission latency between instance 1 of the first API and the first capability open gateway, wherein the latency performance of instance 1 of the first API is represented by the latency performance corresponding to at least one topology combination including instance 1 of the first API. For details, refer to step 630 above, which will not be repeated here. The at least one topology combination including instance 1 of the first API and the transmission latency corresponding to at least one topology combination including instance 1 of the first API can be obtained from the NRF or other network elements, and this application does not limit this.

[0307] S907: Instance 1 of the first API sends the first notification message to the first capability gateway.

[0308] For example, the first notification message includes an identifier of instance 1 of the first API. Alternatively, the first notification message indicates the latency performance of instance 1 of the first API.

[0309] Optionally, S908: Instance 1 of the first API sends a second notification message to the CCF, the second notification message indicating the latency performance of instance 1 of the first API.

[0310] This application does not specify the order of S907 and S908.

[0311] S909: AF sends its first request message to CCF.

[0312] The first request message is used to request the first API to provide the first service. The first request message includes first indication information, which indicates the latency requirement for the first API.

[0313] S910: CCF determines the first capability opening gateway based on the first request message.

[0314] If the CCF obtains the latency performance of instance 1 of the first API through S908, it can refer to the above-mentioned S709 for details.

[0315] If the CCF does not know the latency performance of instance 1 of the first API, the CCF may randomly select a capability opening gateway.

[0316] S911: CCF sends the first response message to AF.

[0317] The first response message includes the address of the first capability-opening gateway.

[0318] S912: AF sends a second request message to the first capability open gateway.

[0319] The second request message is used to request the first API to provide a first service. The second request message includes second indication information, which indicates the latency requirement for the first API. For example, the second request message may include the name or identifier of the first API.

[0320] S913: The first capability open gateway determines instance 1 of the first API based on the second request message.

[0321] If the first capability opening gateway only obtains the identifier of instance 1 of the first API through S907, it continues to execute S914. The call request in S914 includes third instruction information, which may be the same as the second instruction information.

[0322] If the first capability discovery gateway learns the latency performance of instance 1 of the first API through S907, it can determine whether the latency requirement indicated by the second indication information is met based on the latency performance of instance 1 of the first API. If it is met, it continues to execute S914. The call request in S914 includes third indication information, which can indicate one or more topology combinations, and the latency performance corresponding to each of these topology combinations meets the latency requirement indicated by the second indication information. Otherwise, the first capability discovery gateway can notify the first API instance 1 through AF that the latency performance does not meet the latency requirement indicated by the second indication information. Furthermore, the AF can request the CCF to rediscover the capability discovery gateway for it.

[0323] S914: The first capability open gateway sends a call request to instance 1 of the first API. The call request includes third instruction information.

[0324] S915: Instance 1 of the first API provides the first service for AF.

[0325] If the third indication information indicates one or more topology combinations, instance 1 of the first API determines one of the topology combinations and makes a call based on the instance within that topology combination.

[0326] Alternatively, the third instruction information may be the same as the second instruction information, indicating the latency requirements for the first API. Then, instance 1 of the first API can select a topology combination that satisfies the latency requirements indicated by the third instruction information and the configuration information of instance 1 of the first API, and make calls based on instances within that topology combination.

[0327] Using the above method, instance 1 of the first API can accurately determine its own latency performance. Therefore, instance 1 of the first API can determine whether it meets the latency requirements. If it does, it provides the first server to the AF, and then the AF can call the instance of the first API that meets the latency requirements.

[0328] This application also provides a communication method to enable service callers to invoke APIs that meet performance requirements to provide services. In such cases... Figure 10 In the illustrated embodiment, the first device is used as the execution subject for explanation. (In conjunction with the above...) Figure 4A or Figure 4B The first device can be a core functional network element (such as a CCF) or a chip within a core functional network element. It is understood that the aforementioned executing entity can also be replaced by a device with corresponding equipment functions, or a chip, unit, or module within a communication device with corresponding functions.

[0329] Step 1000: The first device obtains the topological relationship between at least one capability open gateway and an instance of the first API.

[0330] The topology between the instance of the first API and at least one capability open gateway can be obtained from NRF or other network elements, and this application does not limit this.

[0331] Step 1010: The first device selects a first capability open gateway from at least one capability open gateway according to the topology relationship, wherein the first capability open gateway is the first hop node of the instance that calls the first API.

[0332] For example, the first device can select the capability open gateway that is closest to the instance of the first API based on the topology relationship, or select the capability open gateway with the shortest transmission latency to the instance of the first API based on the topology relationship. Furthermore, the first device can also obtain the service area of ​​the instance of the first API, and the service areas corresponding to at least one capability open gateway, to ensure that the service area of ​​the selected capability open gateway includes the service area of ​​the instance of the first API. The service area of ​​the instance of the first API, and the service areas corresponding to at least one capability open gateway, can be obtained from the NRF or other network elements; this application does not limit this information.

[0333] Step 1020: The first device obtains the processing latency of the instance of the first API.

[0334] The processing latency of the first API instance is the time from receiving a request to call the first API instance to providing a response or result to the request.

[0335] For example, the first device can obtain the processing latency of the first API instance from the first network element, which is any one of the first API instance, API publishing function network element, network storage function network element, and API storage function network element.

[0336] Furthermore, the processing latency of how the first device obtains an instance of the first API can be referred to in the relevant content of step 610 above, and will not be repeated here.

[0337] Step 1030: The first device determines the latency performance of the first API instance based on the processing latency of the first API instance and the transmission latency between the first API instance and the first capability opening gateway.

[0338] For example, the latency performance of an instance of the first API can be expressed as the sum of the processing latency of the instance of the first API and the transmission latency between the instance of the first API and the first capability open gateway, or the sum of the processing latency of the instance of the first API and twice the transmission latency between the instance of the first API and the first capability open gateway.

[0339] For example, the first device may also send a notification message to the first capability open gateway, the notification message including an identifier of the first API instance, or the notification message indicating the latency performance of the first API instance.

[0340] The subsequent discovery of the capability gateway and the process of calling the first API are the same as described above. Figure 6 The embodiments shown are similar and will not be described again here.

[0341] Using the above method, the first device can accurately determine the latency performance of the first API based on the processing latency of the first API instance and the transmission latency between the first API instance and the first capability opening gateway. The latency performance of the first API can be at least one type, meaning the first API can guarantee at least one type of latency. Therefore, before a device requesting the first service calls the first API, at least one guaranteed latency of the first API has already been determined. In other words, the first API can provide multiple optional latency performances for the device requesting the first service, thereby enabling the device requesting the first service to call an API that meets its latency requirements to provide services. This method is generally applicable to scenarios where the first API does not depend on other APIs.

[0342] It is understood that, in order to achieve the functions in the above embodiments, each communication device includes hardware structures and / or software modules corresponding to perform each function. Those skilled in the art should readily recognize that, based on the units and method steps of the various examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0343] Figure 11 and Figure 12 The diagram illustrates the possible communication devices provided in the embodiments of this application. These communication devices can be used to implement the functions of the various communication devices in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments.

[0344] like Figure 11 As shown, the communication device 1100 includes a processing unit 1110 and a transceiver unit 1120.

[0345] When the communication device 1100 is used to achieve the above Figures 6 to 9 When the first device (e.g., CCF, first capability open gateway, or instance 1 of the first API) in the illustrated embodiment functions as follows:

[0346] The transceiver unit 1120 is configured to acquire first information, the first information indicating that a first API calls a second API during the provision of a first service; acquire, based on the first information, the processing latency of an instance of the first API and the processing latency of one or more instances corresponding to the second API; and acquire the transmission latency corresponding to at least one topology combination, wherein each topology combination includes an instance of the first API and one or more instances corresponding to the second API.

[0347] Processing unit 1110 is configured to determine the latency performance of the first API based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination.

[0348] In one possible design, the processing unit 1110 is configured to determine the latency performance of the first API based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second APF, the transmission latency corresponding to the at least one topology combination, and the transmission latency between the first API instance and the first capability open gateway when determining the latency performance of the first API based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second APF, the transmission latency corresponding to the at least one topology combination, and the transmission latency between the first API instance and the first capability open gateway, wherein the first capability open gateway is the first hop node of the instance calling the first API.

[0349] In one possible design, the transceiver unit 1120 is further configured to obtain the topological relationship between at least one capability open gateway and an instance of the first API; the processing unit 1110 is further configured to select the first capability open gateway from the at least one capability open gateway according to the topological relationship.

[0350] In one possible design, the transceiver unit 1120 is configured to send a first notification message to the first capability open gateway, the first notification message including an identifier of the instance of the first API, or the first notification message indicating the latency performance of the first API.

[0351] In one possible design, transceiver unit 1120 is configured to send a second notification message to a core functional network element, the second notification message indicating the latency performance of the first API. Correspondingly, the core functional network element receives the second notification message from the first device.

[0352] In one possible design, the transceiver unit 1120 is used to send configuration information of the first API instance to the first API instance, the configuration information of the first API instance indicating the latency performance of the first API.

[0353] In one possible design, the first information also instructs the first API to call the third API in the process of providing the first service, and the order in which the first API, the second API, and the third API are called; each topology combination includes an instance of the first API, one of one or more instances corresponding to the second API, and one of one or more instances corresponding to the third API; the transmission latency corresponding to each topology combination is determined according to the calling order and the transmission latency between the instances in the topology combination.

[0354] In one possible design, the processing unit 1110 is further configured to, when determining the latency performance of the first API based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination, obtain the processing latency of one or more instances corresponding to the third API based on the first information; and determine the latency performance of the first API based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second API, the processing latency of one or more instances corresponding to the third API, and the transmission latency corresponding to the at least one topology combination.

[0355] In one possible design, the processing unit 1110 is further configured to, when determining the latency performance of the first API based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination, determine the latency performance of the at least one topology combination based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination; wherein, the latency performance corresponding to each topology combination is determined based on the transmission latency and the processing latency corresponding to the topology combination, and the processing latency corresponding to the topology combination is determined based on the processing latency corresponding to each instance included in the topology combination; and the latency performance of the first API is determined based on the latency performance of the at least one topology combination.

[0356] In one possible design, the transceiver unit 1120 is further configured to receive a first request message, the first request message being used to request the discovery of a capability discovery gateway corresponding to the first API, the first request message including first indication information indicating latency requirements for the first API; the processing unit 1110 is further configured to determine a first capability opening gateway based on the first request message and the latency performance of the first API, the first capability opening gateway being a first-hop functional node of the instance calling the first API, and the latency performance of the instance of the first API meeting the latency requirements indicated by the first indication information; the transceiver unit 1120 is further configured to send a first response message, the first response message including the address of the first capability opening gateway.

[0357] In one possible design, transceiver unit 1120 is further configured to receive a second request message, the second request message being used to request a call to the first API, the second request message including second indication information indicating a latency requirement for the first API; processing unit 1110 is further configured to determine an instance of the first API based on the second request message; transceiver unit 1120 is further configured to send a call request to the instance of the first API, the call request including third indication information, the third indication information being used to determine one of the at least one topology combination, wherein the third indication information is determined based on the second indication information.

[0358] In one possible design, the transceiver unit 1120 is used to obtain the first information from a first network element when obtaining the first information, wherein the first network element is any one of the following: an instance of the first API, an API publishing function network element, a network storage function network element, or an API storage function network element.

[0359] In one possible design, the transceiver unit 1120 is used to obtain the processing latency of the instance of the first API from the first network element.

[0360] In one possible design, the transceiver unit 1120 is used to obtain the processing latency of one or more instances corresponding to the second API from the second network element, which is a network storage function network element, a network function NF management system, or an API management system.

[0361] In one possible design, the processing latency of the first API instance is the latency between receiving a request to call the first APF instance and sending a corresponding call request to the next-hop second API instance, or the latency between receiving a request to call the first API instance and providing a response or result to the request; the processing latency of the second APF instance is the latency between receiving a call request to the second API instance and sending a corresponding call request to the next-hop instance, or the latency between receiving a request to call the second API instance and providing a response or result to the request.

[0362] When the communication device 1100 is used to achieve the above Figure 10 The function of the first device in the illustrated embodiment is as follows:

[0363] The transceiver unit 1120 is configured to: acquire the topology relationship between at least one capability open gateway and an instance of the first API; select a first capability open gateway from the at least one capability open gateway according to the topology relationship, wherein the first capability open gateway is the first hop node of the instance calling the first API; and acquire the processing latency of the instance of the first API.

[0364] Processing unit 1110 is configured to determine the latency performance of the first API instance based on the processing latency of the first API instance and the transmission latency between the first API instance and the first capability opening gateway.

[0365] In one possible design, the transceiver unit 1120 is configured to send a notification message to the first capability open gateway, the notification message including an identifier of an instance of the first API, or the notification message indicating the latency performance of an instance of the first API.

[0366] In one possible design, the transceiver unit 1120 is used to obtain the processing latency of the first API instance from a first network element when obtaining the processing latency of the first API instance, wherein the first network element is any one of the first API instance, API publishing function network element, network storage function network element, and API storage function network element.

[0367] In one possible design, the processing latency of an instance of the first API is the latency from receiving a request to invoke an instance of the first API to providing a response or result to the request.

[0368] A more detailed description of the processing unit 1110 and the transceiver unit 1120 can be obtained directly from the relevant descriptions in the above method embodiments, and will not be repeated here.

[0369] like Figure 12As shown, the communication device 1200 includes a processor 1210 and an interface circuit 1220. The processor 1210 and the interface circuit 1220 are coupled to each other. It is understood that the interface circuit 1220 can be a transceiver or an input / output interface. Optionally, the communication device 1200 may also include a memory 1230 for storing instructions executed by the processor 1210, or storing input data required by the processor 1210 to execute instructions, or storing data generated after the processor 1210 executes instructions.

[0370] When the communication device 1200 is used to implement the above method embodiment, the processor 1210 is used to implement the function of the processing unit 1110, and the interface circuit 1220 is used to implement the function of the transceiver unit 1120.

[0371] It is understood that the processor in the embodiments of this application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0372] This application provides another example of a device, the notification device including at least one processor and at least one memory, the at least one processor and the at least one memory coupled together, the at least one memory for storing instructions, which, when executed by the at least one processor, cause the communication device to perform the method described above. Taking a communication device including a processor and a memory as an example, such as... Figure 12 As shown, the communication device 1200 includes a processor 1210 and a memory 1230. The processor 1210 and the memory 1230 are coupled. The memory 1230 stores instructions. When the instructions stored in the memory 1230 are executed by the processor 1210, the communication device 1200 executes the methods executed by the various communication devices in the above embodiments.

[0373] The method steps in the embodiments of this application can be implemented in hardware or in software instructions executable by a processor. The software instructions can consist of corresponding software modules, which can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. The storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in the aforementioned terminal or access network device. The processor and storage medium can also exist as discrete components in the terminal or access network device.

[0374] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0375] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0376] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates an "or" relationship between the preceding and following related objects; in the formulas of this application, the character " / " indicates a "division" relationship between the preceding and following related objects. "Including at least one of A, B, and C" can mean: including A; including B; including C; including A and B; including A and C; including B and C; including A, B, and C.

[0377] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

Claims

1. A communication method, characterized in that, The method is applied to a first device, and the method includes: Obtain first information, which instructs a first application programming interface (API) to call a second API while providing a first service; Based on the first information, obtain the processing latency of the first API instance and the processing latency of one or more instances corresponding to the second API; Obtain the transmission delay corresponding to at least one topology combination, wherein each topology combination includes one of the instances of the first API and one or more instances corresponding to the second API; The latency performance of the first API is determined based on the processing latency of an instance of the first API, the processing latency of one or more instances of the second API, and the transmission latency corresponding to the at least one topology combination.

2. The method as described in claim 1, characterized in that, The latency performance of the first API is determined based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second APF, and the transmission latency corresponding to the at least one topology combination, including: The latency performance of the first API is determined based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second APF, the transmission latency corresponding to the at least one topology combination, and the transmission latency between the first API instance and the first capability open gateway, wherein the first capability open gateway is the first hop node of the instance calling the first API.

3. The method as described in claim 2, characterized in that, The first device is a core functional network element, and the method further includes: Obtain the topological relationship between at least one capability-opening gateway and the instance of the first API; The first capability open gateway is selected from the at least one capability open gateway based on the topology relationship.

4. The method as described in claim 3, characterized in that, The method further includes: Send a first notification message to the first capability opening gateway. The first notification message includes the identifier of the instance of the first API, or the first notification message indicates the latency performance of the first API.

5. The method as described in claim 2, characterized in that, The first device is the first capability opening gateway, and the method further includes: A second notification message is sent to the core functional network element, the second notification message indicating the latency performance of the first API.

6. The method according to any one of claims 2-5, characterized in that, The first device is a core functional network element or the first capability open gateway, and the method further includes: Send the configuration information of the first API instance to the first API instance, the configuration information of the first API instance indicating the latency performance of the first API.

7. The method according to any one of claims 1-6, characterized in that, The first information also indicates that the first API calls the third API in the process of providing the first service, and the order in which the first API, the second API, and the third API are called; Each topology combination includes an instance of the first API, one of one or more instances corresponding to the second API, and one of one or more instances corresponding to the third API; The transmission latency for each topology combination is determined based on the calling order and the transmission latency between instances within that topology combination.

8. The method as described in claim 7, characterized in that, The latency performance of the first API is determined based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination, including: Based on the first information, obtain the processing latency of one or more instances corresponding to the third API; The latency performance of the first API is determined based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second API, the processing latency of one or more instances corresponding to the third API, and the transmission latency corresponding to the at least one topology combination.

9. The method according to any one of claims 1-8, characterized in that, The latency performance of the first API is determined based on the processing latency of an instance of the first API, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination, including: The latency performance of the at least one topology combination is determined based on the processing latency of the first API instance, the processing latency of one or more instances corresponding to the second API, and the transmission latency corresponding to the at least one topology combination; wherein, the latency performance of each topology combination is determined based on the transmission latency and the processing latency of the topology combination, and the processing latency of the topology combination is determined based on the processing latency of each instance included in the topology combination. The latency performance of the first API is determined based on the latency performance of the at least one topology combination.

10. The method as described in claims 1-4 or 6-9, characterized in that, The first device is a core functional network element, and the method further includes: Receive a first request message, the first request message is used to request the discovery of the capability opening gateway corresponding to the first API, the first request message includes first indication information, the first indication information indicates the latency requirement for the first API; A first capability opening gateway is determined based on the first request message and the latency performance of the first API. The first capability opening gateway is the first-hop functional node of the instance that calls the first API, and the latency performance of the instance of the first API meets the latency requirements indicated by the first indication information. Send a first response message, which includes the address of the first capability-opening gateway.

11. The method as described in claims 1-2 or 5-9, characterized in that, The first device is the first capability opening gateway, and the method further includes: Receive a second request message, the second request message being used to request a call to the first API, the second request message including second indication information, the second indication information indicating latency requirements for the first API; The instance of the first API is determined based on the second request message; A call request is sent to an instance of the first API, the call request including third indication information, the third indication information being used to determine one of the at least one topology combination, the third indication information being determined based on the second indication information.

12. The method according to any one of claims 1-11, characterized in that, Obtain first information, including: The first information is obtained from the first network element, which is any one of the following: an instance of the first API, an API publishing function network element, a network storage function network element, or an API storage function network element.

13. The method as described in claim 12, characterized in that, The method further includes: Processing latency for obtaining an instance of the first API from the first network element.

14. The method according to any one of claims 1-13, characterized in that, The method further includes: The processing latency of obtaining one or more instances corresponding to the second API from the second network element, wherein the second network element is a network storage function network element, a network function NF management system, or an API management system.

15. The method according to any one of claims 1-14, characterized in that, The processing latency of the first API instance is the latency between receiving a request to call the first APF instance and sending a corresponding call request to the next hop second API instance, or the latency between receiving a request to call the first API instance and giving a response or result to the request. The processing latency of the second APF instance is the latency between receiving the call request from the second API instance and sending the corresponding call request to the next hop instance, or the latency between receiving the request from the instance that calls the second API and giving a response or result to the request.

16. A communication method, characterized in that, The method includes: Obtain the topological relationship between at least one capability-opening gateway and an instance of the first API; A first capability open gateway is selected from the at least one capability open gateway according to the topology relationship, wherein the first capability open gateway is the first hop node of the instance that calls the first API; Obtain the processing latency of the instance of the first API; The latency performance of the first API instance is determined based on the processing latency of the first API instance and the transmission latency between the first API instance and the first capability open gateway.

17. The method as described in claim 16, characterized in that, The method further includes: Send a notification message to the first capability opening gateway, the notification message including the identifier of the first API instance, or the notification message indicating the latency performance of the first API instance.

18. The method as described in claim 16 or 17, characterized in that, Obtain the processing latency of the instance of the first API, including: The processing latency of obtaining an instance of the first API from a first network element, wherein the first network element is any one of the following: an instance of the first API, an API publishing function network element, a network storage function network element, or an API storage function network element.

19. The method according to any one of claims 16-18, characterized in that, The processing latency of the first API instance is the time from receiving a request to call the first API instance to giving a response or result to the request.

20. A communication device, characterized in that, Includes units or modules for performing the method as described in any one of claims 1 to 19.

21. A communication device, characterized in that, The communication device includes at least one processor; the at least one processor is configured to perform the method as described in any one of claims 1 to 19.

22. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a program that, when run on the device, causes the device to perform the method as described in any one of claims 1 to 19.

23. A computer program product, characterized in that, The computer program product includes a program or instructions that, when executed by a device, cause the device to perform the method as described in any one of claims 1 to 19.

Images