Network element discovery method and apparatus

Abstract

A network element discovery method and apparatus. The method is applied to a second network element and comprises: receiving a first request message from a first network element, the first request message being used for requesting an address of a third network element, and the first request message carrying performance requirements of a first service API, and an identifier of the first service API and / or the type of the first service API; and sending an address of a target third network element to the first network element, the target third network element being capable of providing the first service API, the first service API being associated with a network API, and the calling performance of the network API satisfying the performance requirements of the first service API. In the network element discovery solution provided by the present application, a network element that provides a service API can be discovered, and the discovered network element can further satisfy the performance requirements of the service API.

Description

A network element discovery method and apparatus

[0001] Cross-reference to Related Applications

[0002] The present application claims priority to the Chinese patent application No. 202411361965.3, filed on September 26, 2024, and entitled "A network element discovery method and apparatus", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] The present application relates to the field of communication technology, and in particular to a network element discovery method and apparatus. BACKGROUND

[0004] In a mobile communication system, for example, in a 5th generation (5G) communication system, a network exposure function network element (NEF) can open 5G network functions to a third-party application in the form of an application programming interface (API), and correspondingly, an application function (AF) can obtain relevant information of a terminal by calling the API in the NEF.

[0005] Before the AF calls the API in the NEF, the AF needs to first discover the NEF in the network that can provide the corresponding service. The currently defined discovery scheme of the NEF mostly takes distance as the priority factor, and the AF can discover the NEF closest to the AF. However, in the process of calling the API by the AF, there is a certain demand for performance such as latency, and the NEF closest to the AF selected by the current discovery scheme of the NEF may not be able to meet the performance demand of the AF. SUMMARY

[0006] The present application proposes a network element discovery method and apparatus for discovering a network element that can provide a service API and meet the performance demand of the service API.

[0007] In a first aspect, the present application proposes a network element discovery method, which is applied to a second network element and includes: receiving a first request message from a first network element, the first request message being used to request an address of a third network element, the first request message carrying a performance demand of a first service API and an identifier of the first service API and / or a type of the first service API; and sending, to the first network element, an address of a target third network element, the target third network element being capable of providing the first service API, the first service API being associated with a network API, and a calling performance of the network API being capable of meeting the performance demand of the first service API.

[0008] Based on the above scheme, when the first network element needs to call a service API in the network, the second network element in the network queries a target third network element capable of providing the service API and meeting the performance requirement of the first network element, the target third network element decomposes the service API into network APIs, and triggers scheduling of the network APIs. In the prior art, the network element performing scheduling based on distance discovery cannot meet the performance requirement of the first network element, while the scheme of the present application discovers the target third network element performing scheduling based on the performance requirement of the first network element, so the target third network element can not only provide the corresponding service API, but also meet the performance requirement of the service API.

[0009] In a possible implementation, the method further includes: receiving information of at least one third network element; the target third network element is one of the at least one third network element; and the information of the third network element includes at least one of the following: a service API supported by the third network element, an address of the third network element, a type of the third network element, an identifier of the third network element, a deployment position of the third network element, or a service area of the third network element.

[0010] Based on the above scheme, the second network element maintains information of each third network element, so that the target third network element capable of providing the first service API can be quickly determined according to the maintained information.

[0011] In a possible implementation, the method further includes: sending a third request message to the at least one third network element; the third request message is used to request the at least one third network element to judge whether the at least one third network element meets the performance requirement of the first service API, the third request message carries the performance requirement of the first service API, and the identifier and / or the type of the first service API; receiving a response message of the third request message sent by the at least one third network element, the response message indicating whether the performance requirement of the first service API is met; and determining the target third network element according to the response message.

[0012] Based on the above scheme, the second network element requests the third network element to judge whether the performance requirement of the first service API is met, and determines the target third network element capable of meeting the performance requirement according to the response information returned by each third network element.

[0013] In a possible implementation, the method further includes: sending a third request message to a fourth network element; the third request message is used to request to judge whether the at least one third network element meets the performance requirement of the first service API, and the third request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API; receiving a response message of the third request message sent by the fourth network element, the response message indicating whether the performance requirement of the first service API is met; and determining the target third network element according to the response message.

[0014] Based on the above scheme, the second network element judges whether each third network element can meet the performance requirement through the fourth network element, that is, the calling performance of each network API is uniformly maintained by the fourth network element, and the security of the calling performance information is improved.

[0015] In a possible implementation, the information of the third network element further includes the calling performance of the third network element for the first service API.

[0016] Based on the above scheme, the calling performance of each third network element is maintained by the second network element, so that the target third network element that can meet the calling performance can be quickly determined according to the stored information.

[0017] In a possible implementation, the first request message further carries the type of the third network element requested by the first network element and the location information of the first network element.

[0018] In a possible implementation, the method further includes: receiving a fifth request message from the target third network element, the fifth request message being used to request a target instance of the network API, and the fifth request message carrying the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API; determining the target instance of the network API according to the stored mapping relationship between the first service API and the network API, the performance requirement and the calling performance of at least one instance of the network API; and sending an address of the target instance to the target third network element.

[0019] In a possible implementation, the third network element is an API exposure function network element (AEF) or a border API exposure function network element (border AEF), the second network element is a CAPIF core function network element (CCF), and the fourth network element is an API publishing function entity (APF).

[0020] In a second aspect, the present application provides another network element discovery method, applied to a target third network element, comprising: receiving a second request message from a first network element; the second request message requests to invoke a first service API; wherein the second request message carries a performance requirement of the first service API, and an identifier of the first service API and / or a type of the first service API; determining a target instance of a network API corresponding to the first service API, and invoking the network API of the target instance; wherein an invocation performance of the network API of the target instance can meet the performance requirement of the first service API.

[0021] In a possible implementation manner, the method further comprises: sending an invocation result of the first service API; the invocation result of the first service API is determined according to an invocation result of the network API.

[0022] In a possible implementation manner, the method further comprises: sending information of the target third network element to a second network element; wherein the information of the target third network element comprises at least one of the following: a service API supported by the target third network element, an address of the target third network element, a type of the target third network element, an identifier of the target third network element, a deployment location of the target third network element, or a service area of the target third network element.

[0023] In a possible implementation manner, the method further comprises: receiving a third request message from the second network element; the third request message is used to request to judge whether the target third network element meets the performance requirement of the first service API, and the third request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API.

[0024] sending the fourth request message to a fourth network element; the fourth request message is used to request an address, an identifier and / or a type of at least one instance of the network API meeting the performance requirement of the first service API;

[0025] when the address, the identifier and / or the type of the at least one instance are received from the fourth network element, sending a response message of the third request message to the second network element; the response message indicates that the target third network element meets the performance requirement of the first service API.

[0026] In a possible implementation manner, the fourth request message carries the performance requirement of the first service API; or the fourth request message carries a performance requirement of the network API, and the performance requirement of the network API is obtained by dividing the performance requirement of the first service API.

[0027] In a possible implementation, the information reported by the target third network element further includes a calling performance of the target third network element for the first service API.

[0028] In a possible implementation, the determining the target instance of the network API corresponding to the first service API specifically includes:

[0029] determining a target instance from the at least one instance according to the stored mapping relationship between the first service API and the network API, the performance requirement, and the calling performance of the at least one instance; or

[0030] sending a fifth request message to the second network element, where the fifth request message is used to request an instance of the network API, and the fifth request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API;

[0031] receiving an address of the target instance from the second network element.

[0032] In a third aspect, the present application provides another network element discovery method, which is applied to a first network element and includes: sending a first request message to a second network element, where the first request message is used to request an address of a third network element, and the first request message carries a performance requirement of a first service application program interface (API), and an identifier of the first service API and / or a type of the first service API;

[0033] receiving an address of a target third network element from the second network element, where the target third network element can provide the first service API for the first network element, and the target third network element meets the performance requirement of the first service API.

[0034] In a possible implementation, the method further includes: sending a second request message to the target third network element based on the address of the target third network element, where the second request message is used to request calling the first service API, and the second request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API.

[0035] In a possible implementation, the method further includes: obtaining a calling result of the first service API, where the first service API is associated with a network API, and the calling result of the first service API is determined according to a calling result of the network API.

[0036] In a possible implementation, the first request message further carries a type of a third network element requested by the first network element, and / or location information of the first network element.

[0037] In a possible implementation, the third network element is an API exposure function network element AEF or a border API exposure function network element border AEF, the second network element is a CAPIF core function network element CCF, and the fourth network element is an API publishing function entity APF.

[0038] In a fourth aspect, the present application provides another network element discovery method, which is applied to a first network element and includes the following steps: sending a first request message to a nearest third network element, the first request message being used to request an address of a target third network element that can provide a first service API and meet a performance requirement of the first service API; the first request message carrying the performance requirement of the first service API, and an identifier of the first service API and / or a type of the first service API; and receiving the address of the target third network element from the nearest third network element.

[0039] In a possible implementation, when the nearest third network element can meet the performance requirement, the address of the target third network element is the address of the nearest third network element; or when the nearest third network element cannot meet the performance requirement, the address of the target third network element is obtained from a second network element by the nearest third network element.

[0040] In a possible implementation, after receiving the address of the target third network element from the nearest third network element, the method further includes the following steps:

[0041] sending a second request message to the target third network element based on the address of the target third network element, the second request message being used to request calling the first service API; wherein the second request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API;

[0042] receiving a calling result of the first service API from the target third network element.

[0043] In a fifth aspect, the present application provides another network element discovery method, which is applied to a sixth network element and includes the following steps:

[0044] receiving a second request message from a first network element, the sixth network element being a nearest third network element to the first network element; the second request message being used to request calling a first service API; wherein the second request message carries a performance requirement of the first service API, and an identifier of the first service API and / or a type of the first service API;

[0045] sending a first request message to a second network element, the first request message being used to request an address of a target third network element capable of providing a first service API and satisfying a performance requirement of the first service API; the first request message carrying the performance requirement of the first service API, and an identity of the first service API and / or a type of the first service API;

[0046] receiving the address of the target third network element from the second network element; the target third network element being capable of providing the first service API for the first network element, and the target third network element satisfying the performance requirement of the first service API.

[0047] In a possible implementation, after receiving the address of the target third network element from the second network element, the method further includes:

[0048] sending the second request message to the target third network element.

[0049] In a sixth aspect, another network element discovery method is provided, and is applied to a sixth network element, and includes:

[0050] receiving a first request message from a first network element, the sixth network element being a nearest third network element to the first network element; the first request message being used to request an address of a target third network element capable of providing a first service API and satisfying a performance requirement of the first service API; the first request message carrying the performance requirement of the first service API, and an identity of the first service API and / or a type of the first service API;

[0051] sending the address of the target third network element to the first network element.

[0052] In a possible implementation, the sending of the address of the target third network element to the first network element specifically includes:

[0053] when the sixth network element is capable of satisfying the performance requirement, sending an address of the sixth network element to the first network element;

[0054] when the sixth network element is incapable of satisfying the performance requirement, sending the first request message to a second network element, receiving the address of the target third network element from the second network element, and sending the address of the target third network element to the first network element.

[0055] In a seventh aspect, another network element discovery method is provided, and is applied to a second network element, and includes:

[0056] receiving a first request message from a sixth network element; the first request message is used to request an address of a target third network element capable of providing a first service API and satisfying a performance requirement of the first service API; the sixth network element is a third network element closest to the first network element, and the sixth network element is incapable of satisfying the performance requirement; the first request message carries the performance requirement of the first service API, and an identity of the first service API and / or a type of the first service API;

[0057] sending the address of the target third network element to the sixth network element.

[0058] In an eighth aspect, the present application provides a network element discovery apparatus, which is applied to a second network element or is the second network element, and includes a storage unit and a transceiver unit:

[0059] The storage unit is configured to store computer program instructions.

[0060] The transceiver unit is configured to receive a first request message from a first network element based on the computer program instructions, the first request message is used to request an address of a third network element, and the first request message carries a performance requirement of a first service API and an identity of the first service API and / or a type of the first service API.

[0061] The transceiver unit is further configured to send an address of a target third network element to the first network element, the target third network element is capable of providing the first service API, the first service API is associated with a network API, and a calling performance of the network API is capable of satisfying the performance requirement of the first service API.

[0062] In a possible implementation manner, the transceiver unit is further configured to:

[0063] receive information of at least one third network element; the target third network element is one of the at least one third network element; and the information of the third network element includes at least one of the following: a service API supported by the third network element, an address of the third network element, a type of the third network element, an identity of the third network element, a deployment position of the third network element, or a service area of the third network element.

[0064] In a possible implementation, the transceiver unit is further configured to: send a third request message to the at least one third network element, the third request message being used to request to determine whether the at least one third network element meets the performance requirement of the first service API, the third request message carrying the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API; receive a response message of the third request message sent by the at least one third network element, the response message indicating whether the performance requirement of the first service API is met; and determine the target third network element according to the response message.

[0065] In a possible implementation, the transceiver unit is further configured to: send a third request message to the fourth network element, the third request message being used to request to determine whether the at least one third network element meets the performance requirement of the first service API, the third request message carrying the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API; receive a response message of the third request message sent by the fourth network element, the response message indicating whether the performance requirement of the first service API is met; and determine the target third network element according to the response message.

[0066] In a possible implementation, the information of the third network element further includes the calling performance of the third network element for the first service API.

[0067] In a possible implementation, the first request message further carries the type of the third network element requested by the first network element and the location information of the first network element.

[0068] In a possible implementation, the apparatus further includes a processing unit,

[0069] The transceiver unit is further configured to receive a fifth request message from the target third network element, the fifth request message being used to request a target instance of the network API, the fifth request message carrying the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API.

[0070] The processing unit is configured to determine the target instance of the network API according to the stored mapping relationship between the first service API and the network API, the performance requirement, and the calling performance of at least one instance of the network API.

[0071] The transceiver unit is further configured to send an address of the target instance to the target third network element.

[0072] In a possible implementation, the third network element is an API exposure function network element (AEF) or a border API exposure function network element (border AEF), the second network element is a CAPIF core function network element (CCF), and the fourth network element is an API publishing function entity (APF).

[0073] In a ninth aspect, the present application provides a network element discovery apparatus, which is applied to a target third network element or is the target third network element, and includes:

[0074] a transceiver, configured to receive a second request message from a first network element, where the second request message requests to invoke a first service API, and the second request message carries a performance requirement of the first service API, and an identifier of the first service API and / or a type of the first service API;

[0075] a processing unit, configured to determine a target instance of a network API corresponding to the first service API, and invoke the network API of the target instance, where an invocation performance of the network API of the target instance is capable of meeting the performance requirement of the first service API.

[0076] In a possible implementation, the transceiver is further configured to send an invocation result of the first service API, where the invocation result of the first service API is determined according to an invocation result of the network API.

[0077] In a possible implementation, the transceiver is further configured to send information of the target third network element to a second network element, where the information of the target third network element includes at least one of the following: a service API supported by the target third network element, an address of the target third network element, a type of the target third network element, an identifier of the target third network element, a deployment location of the target third network element, or a service area of the target third network element.

[0078] In a possible implementation, the transceiver is further configured to receive a third request message from the second network element, where the third request message is used to request to judge whether the target third network element meets the performance requirement of the first service API, and the third request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API.

[0079] send the fourth request message to a fourth network element, where the fourth request message is used to request an address, an identifier, and / or a type of at least one instance of the network API that meets the performance requirement of the first service API;

[0080] when receiving the address, the identity and / or the type of the at least one instance from the fourth network element, sending a response message of the third request message to the second network element; the response message indicates that the target third network element meets the performance requirement of the first service API.

[0081] In a possible implementation, the fourth request message carries the performance requirement of the first service API; or the fourth request message carries the performance requirement of the network API, which is obtained by dividing the performance requirement of the first service API.

[0082] In a possible implementation, the information reported by the target third network element further includes the calling performance of the target third network element for the first service API.

[0083] In a possible implementation, the processing unit is specifically configured to:

[0084] determine a target instance in the at least one instance according to the stored mapping relationship between the first service API and the network API, the performance requirement and the calling performance of the at least one instance; or

[0085] send a fifth request message to the second network element, the fifth request message being used for requesting an instance of the network API, the fifth request message carrying the performance requirement of the first service API, and the identity of the first service API and / or the type of the first service API;

[0086] receive the address of the target instance from the second network element.

[0087] In a tenth aspect, another network element discovery apparatus is provided, which is applied to a first network element or is the first network element, and includes a storage unit and a transceiver unit:

[0088] the storage unit is configured to store computer program instructions;

[0089] the transceiver unit is configured to send a first request message to a second network element based on the computer program instructions, the first request message being used for requesting an address of a third network element, the first request message carrying a performance requirement of a first service API, and an identity of the first service API and / or a type of the first service API;

[0090] the transceiver unit is further configured to receive an address of a target third network element from the second network element; the target third network element is capable of providing the first service API for the first network element, and meets the performance requirement of the first service API.

[0091] In a possible implementation, the transceiver unit is further configured to: send, to the target third network element, a second request message based on the address of the target third network element, where the second request message is used to request invoking the first service API; and the second request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API.

[0092] In a possible implementation, the transceiver unit is further configured to: obtain an invoking result of the first service API, where the first service API is associated with a network API, and the invoking result of the first service API is determined according to an invoking result of the network API.

[0093] In a possible implementation, the first request message further carries the type of the third network element requested by the first network element, and / or the location information of the first network element.

[0094] In a possible implementation, the third network element is an API exposure function network element (AEF) or a border API exposure function network element (border AEF), the second network element is a CAPIF core function network element (CCF), and the fourth network element is an API publishing function entity (APF).

[0095] In a first aspect, a network element discovery method is provided, including:

[0096] The storage unit is configured to store computer program instructions.

[0097] The transceiver unit is configured to: send, to a nearest third network element, a first request message based on the computer program instructions, where the first request message is used to request an address of a target third network element that is capable of providing a first service API and meeting a performance requirement of the first service API; the first request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API; and receive the address of the target third network element from the nearest third network element.

[0098] In a possible implementation, when the nearest third network element is capable of meeting the performance requirement, the address of the target third network element is the address of the nearest third network element; or when the nearest third network element is incapable of meeting the performance requirement, the address of the target third network element is obtained from a second network element by the nearest third network element.

[0099] In a possible implementation, the transceiver unit is further configured to:

[0100] sending a second request message to the target third network element based on the address of the target third network element, the second request message requesting to invoke the first service API; wherein the second request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API;

[0101] receiving the invocation result of the first service API from the target third network element.

[0102] In a twelfth aspect, another network element discovery apparatus is provided, which is applied to or is a sixth network element, and the apparatus comprises:

[0103] a transceiver, configured to receive a second request message from a first network element, the sixth network element being a third network element closest to the first network element; the second request message requesting to invoke a first service API; wherein the second request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API;

[0104] a processing unit, configured to, when the performance requirement of the first service API cannot be met, send a first request message to a second network element through the transceiver, the first request message being used to request an address of a target third network element capable of providing the first service API and meeting the performance requirement of the first service API; the first request message carrying the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API;

[0105] the transceiver is further configured to receive the address of the target third network element from the second network element; the target third network element is capable of providing the first service API for the first network element, and the target third network element meets the performance requirement of the first service API.

[0106] In a possible implementation manner, the transceiver is further configured to send the second request message to the target third network element.

[0107] In a thirteenth aspect, another network element discovery apparatus is provided, which is applied to or is a sixth network element, and the apparatus comprises:

[0108] a storage unit, configured to store computer program instructions;

[0109] The transceiver unit is configured to receive a first request message from a first network element based on computer program instructions, the sixth network element is the third network element closest to the first network element; the first request message is used to request an address of a target third network element capable of providing a first service API and meeting performance requirements of the first service API; the first request message carries the performance requirements of the first service API, and the identifier of the first service API and / or the type of the first service API; and the address of the target third network element is sent to the first network element.

[0110] In a possible implementation manner, the transceiver unit is specifically configured to:

[0111] When the sixth network element is capable of meeting the performance requirements, the address of the sixth network element is sent to the first network element;

[0112] When the sixth network element is incapable of meeting the performance requirements, the first request message is sent to a second network element, the address of the target third network element is received from the second network element, and the address of the target third network element is sent to the first network element.

[0113] In a fourteenth aspect, another network element discovery device is provided, which is applied to a second network element or is the second network element, and the device comprises:

[0114] The storage unit is configured to store computer program instructions.

[0115] The transceiver unit is configured to receive a first request message from a sixth network element based on the computer program instructions; the first request message is used to request an address of a target third network element capable of providing a first service API and meeting performance requirements of the first service API; the sixth network element is the third network element closest to the first network element, and the sixth network element is incapable of meeting the performance requirements; the first request message carries the performance requirements of the first service API, and the identifier of the first service API and / or the type of the first service API; and the address of the target third network element is sent to the sixth network element.

[0116] In a fifteenth aspect, another network element discovery device is provided, which comprises a processor and a memory; the memory is configured to store a program; and the processor is configured to execute the program stored in the memory, so that the device implements the method according to any possible design of the first aspect to the seventh aspect.

[0117] In a sixteenth aspect, a network element discovery system is provided, which comprises the network element discovery device according to any one of the eighth aspect to the fourteenth aspect.

[0118] In a seventeenth aspect, a computer readable storage medium is provided, which stores a program code, and when the program code is run on a computer, the computer is caused to perform the method of any possible design of the first aspect to the seventh aspect.

[0119] In an eighteenth aspect, a computer program product is provided, and when the computer program product is run on a computer, the computer is caused to perform the method of any possible design of the first aspect to the seventh aspect.

[0120] In a nineteenth aspect, a chip system is provided, which includes a processor coupled with a memory, and the processor is configured to invoke a computer program or computer instruction stored in the memory, so as to cause the processor to perform the method of any possible design of the first aspect to the seventh aspect.

[0121] In a twentieth aspect, a processor is provided, which is configured to invoke a computer program or computer instruction stored in a memory, so as to cause the processor to perform the method of any possible design of the first aspect to the seventh aspect.

[0122] On the basis of the implementation provided in the above aspects, the embodiments of the present application can be further combined to provide more implementations. The technical effects that can be achieved by any possible design in the second aspect to the twentieth aspect can be described with reference to the technical effects that can be achieved by any possible design in the first aspect, and the repeated parts will not be discussed. BRIEF DESCRIPTION OF DRAWINGS

[0123] FIG. 1 exemplarily shows a network architecture diagram provided by the present application;

[0124] FIG. 2 exemplarily shows a CAPIF network architecture diagram provided by the present application;

[0125] FIG. 3 exemplarily shows a multi-access edge computing application network architecture diagram provided by the present application;

[0126] FIG. 4 exemplarily shows a process diagram of invoking an API provided by the present application;

[0127] FIG. 5 exemplarily shows another process diagram of invoking an API provided by the present application;

[0128] FIG. 6 exemplarily shows another process diagram of invoking an API provided by the present application;

[0129] FIG. 7 exemplarily shows an architecture diagram of an application scenario provided by the present application;

[0130] Figure 8 illustrates a flow diagram of a network element discovery method according to an embodiment of the present application;

[0131] Figure 9 illustrates an architecture diagram of another application scenario according to an embodiment of the present application;

[0132] Figure 10 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0133] Figure 11 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0134] Figure 12 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0135] Figure 13 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0136] Figure 14 illustrates an architecture diagram of another application scenario according to an embodiment of the present application;

[0137] Figure 15 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0138] Figure 16 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0139] Figure 17 illustrates an architecture diagram of another application scenario according to an embodiment of the present application;

[0140] Figure 18 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0141] Figure 19 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0142] Figure 20 illustrates an architecture diagram of another application scenario according to an embodiment of the present application;

[0143] Figure 21 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0144] Figure 22 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0145] Figure 23 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0146] Figure 24 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0147] Figure 25 illustrates a flow diagram of another network element discovery method according to an embodiment of the present application;

[0148] FIG. 26 exemplarily shows a flow diagram of another network element discovery method provided in the present application;

[0149] FIG. 27 exemplarily shows a flow diagram of another network element discovery method provided in the present application;

[0150] FIG. 28 exemplarily shows a network element discovery apparatus provided in the present application;

[0151] FIG. 29 exemplarily shows another network element discovery apparatus provided in the present application. DETAILED DESCRIPTION

[0152] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0153] First of all, it needs to be explained that the method provided in the embodiments of the present application can be applied to a 5G communication system, such as 5G new radio (NR), and can also be applied to various future communication systems, such as a 6th generation (6G) communication system. The part of the various communication systems operated by the operator can be referred to as an operator network. The operator network can also be referred to as a public land mobile network (PLMN) network, which is a network established and operated by the government or the government-approved operator for the purpose of providing land mobile communication services for the public, mainly a public network in which a mobile network operator (MNO) provides mobile broadband access services for users. The operator network or PLMN network described in the embodiments of the present application can be a network that meets the requirements of the 3rd generation partnership project (3GPP) standard, referred to as a 3GPP network. Generally, the 3GPP network is operated by an operator, including but not limited to a 5th-generation (5G) network, a 4th-generation (4G) network or a 3rd-generation (3G) network. It also includes a future 6th-generation (6G) network. Of course, the scheme of the present application can be used for an operator network and can also be used for a non-operator network. For the convenience of description, the embodiments of the present application will be described taking the operator network as an example.

[0154] In the following, some terms in the present application are explained and described. It needs to be explained that these explanations are for the convenience of those skilled in the art to understand, and do not constitute a limitation on the scope of protection required by the present application.

[0155] (1) Service and system aspects (SA2) 5G architecture: 3GPP SA2 defines the 5G system architecture to be divided into two parts, access network and core network, and the specific network architecture diagram can be referred to as FIG. 1. As shown in FIG. 1, the key logical network elements of the core network part include: access and mobility management network element (access and mobility management function, AMF), session management network element (session management function, SMF), user plane function network element (user plane function, UPF), policy control network element (policy control function, PCF) and unified data management network element (unified data management, UDM). Next, the various constituent units included in the system architecture shown in FIG. 1 are introduced:

[0156] A user equipment (UE), which can also be referred to as a terminal device, a mobile station (MS), a mobile terminal (MT), etc., is a device that provides voice and / or data connectivity to a user. For example, the terminal device can include a handheld device having wireless connection capability, a car-mounted device, etc. Currently, the terminal device can be a device-to-device (D2D) terminal device, a vehicle to everything (V2X) terminal device (V2X can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and vehicle-to-network (V2N) communication, etc.), a machine-to-machine / machine-type communications (M2M / MTC) terminal device, an internet of things (IoT) terminal device, a subscriber unit, a subscriber station, a mobile station, a remote station, an access point (AP), a remote terminal, an access terminal, a user terminal, a user agent, or a user device, etc. For example, it can include a mobile telephone (also known as a "cellular" telephone), a computer with mobile termination, a portable, pocket, handheld, computer-included mobile device, etc. For example, it can include a personal communication service (PCS) phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), etc. The terminal device can also be a tablet or a computer with wireless transceiver function.The terminal device can also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in unmanned driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in a smart city, a wireless terminal in a smart home, and the like. It also includes limited devices, such as devices with low power consumption, or devices with limited storage capacity, or devices with limited computing capacity, and the like. For example, it includes information sensing devices such as bar codes, radio frequency identification (RFID), sensors, global positioning system (GPS), laser scanners, and the like. By way of example and not limitation, in embodiments of the present application, the terminal device can also be a wearable device. The wearable device can also be referred to as a wearable smart device or a smart wearable device, and the like. It is a general term for devices that are designed and developed by applying wearable technology to daily wear, such as glasses, gloves, watches, clothing, and shoes, and the like. The wearable device is a portable device that is directly worn on the body or integrated into the user's clothes or accessories. The wearable device is not only a hardware device, but also achieves powerful functions through software support and data interaction, cloud interaction. Broadly defined, a wearable smart device includes a full range of functions, large size, and can achieve complete or partial functions without relying on a smart phone, such as smart watches or smart glasses, and the like, and focuses on a specific application function, and needs to be used with other devices such as a smart phone, such as various smart wristbands, smart helmets, smart jewelry, and the like, which monitor vital signs.

[0157] A radio access network (RAN) device (e.g., a base station) can refer to a device in an access network that communicates with a wireless terminal device through one or more cells over an air interface. For example, the access network device can include an evolved Node B (eNB or e-NodeB) in an LTE system or long term evolution-advanced (LTE-A) system, or can include a next generation Node B (gNB) in a 5G NR system, or can include a centralized unit (CU) and a distributed unit (DU) in a cloud radio access network (Cloud RAN) system, and embodiments of the present application are not limited thereto. The eNB can include various forms of macro base stations, micro base stations (also referred to as small stations), relay stations, access points, wearable devices, and vehicle-mounted devices. The eNB can also be a transmission and reception point (TRP). The gNB can include various forms of macro base stations, micro base stations (also referred to as small stations), relay stations, access points, wearable devices, and vehicle-mounted devices. The gNB can also be a TRP and a transmission measurement function (TMF). The gNB can include a CU and a DU integrated on the gNB. A terminal device and a serving base station can communicate through a Uu link, such as an LTE-Uu link with an Ng-eNB or an NR-Uu link with a gNB. The Ng-eNB is a base station of LTE, and the gNB is a base station of NR. Base stations can communicate with each other through an Xn interface.

[0158] The UPF network element is responsible for processing user packets, such as forwarding packets, charging, and the like.

[0159] The AMF network element is responsible for mobility management in a mobile network, such as user location update, user registration network, user handover, and the like.

[0160] The SMF network element is responsible for session management in a mobile network, such as session establishment, modification, and release. In the process of establishing a session, the SMF network element specifically performs operations such as allocating an IP address for a user, selecting a UPF that provides packet forwarding functions, and the like.

[0161] The PCF network element is responsible for providing packet processing policies to the AMF and SMF network elements, such as quality of service (QoS) policies and slice selection policies.

[0162] The UDM network element is used to store user data, which can include user subscription information, authorization and authentication information, etc.

[0163] The network slice selection (network slice selection function, NSSF) network element is used to determine the network slice instance that the UE is allowed to access according to the slice selection assistance information, subscription information, etc. of the UE.

[0164] The authentication server function (authentication server function, AUSF) network element is responsible for 3GPP and non-3GPP access authentication.

[0165] The application function (application function, AF) network element is responsible for providing services to 3GPP, such as affecting service routing, interacting with the PCF network element for policy control, etc.

[0166] The data network (data network, DN) refers to an operator network that provides data transmission services for users, such as IP multi-media services (IP multi-media service, IMS), Internet, etc. The UE accesses the DN by establishing a session between the UE-RAN-UPF-DN.

[0167] (2) NEF network element: a network element in the 5G core network for opening network capabilities to third-party applications, realizing the connection of network capabilities and services, and improving service experience. The northbound interface of the NEF network element is an open API interface, located between the NEF network element and the AF, and the southbound interface is an interface for connecting with the 5G core network, used for service scheduling and information interaction with the network elements in the 5G core network. The functions of the NEF network element include:

[0168] Supporting the opening of capabilities and time within the 5G network to external AFs, for example, through the NEF, the mobility information related to the UE within the 5G network can be opened, such as UE location, UE reachability, UE roaming state, and UE connectivity loss information, etc. Through the NEF, the performance of the 5G network can also be opened, for example, through the QoS monitoring mechanism, the delay, congestion, etc. within the 5G network can be opened to third-party applications.

[0169] Supports authorization authentication of AF, and provides relevant information or parameters of AF to 5G network in a secure manner. For example, AF can provide expected behavior information of UE to 5G network through NEF, such as including UE mobile path information, UE movement or static information, for 5G network to configure mobility management or session management parameters related to UE. AF can also provide 5G network with parameters for generating QoS policy, access mobility control policy, etc. through NEF.

[0170] Supports conversion of the identity of external AF to corresponding data network name (DNN) and single network slice selection assistance information (S-NSSAI).

[0171] (3) Common API framework (CAPIF) architecture: 3GPP SA6 defines a CAPIF framework, as shown in FIG. 2. The CAPIF architecture includes an API invoker network element, a common API framework core function (CCF) network element, and an API publishing function (APF) network element, and can further include an API exposing function (AEF) network element, and can further include an API management function network element.

[0172] Among them, the AEF network element, the APF network element and the API management function network element can be provided by a capability exposure node (such as NEF in 5G network), and the API invoker network element (such as a third-party application) can obtain services related to terminals in 5G network and / or EPS network by invoking APIs of CAPIF. For example, when the AEF, the APF and the API management function are provided by the NEF in the 5G network, the API invoker network element is the AF, and the AF can obtain the identifier of the UPF through the NEF, thereby invoking the API service of the UPF.

[0173] The CCF can also be provided by a capability exposure node (such as NEF in 5G network). The capability exposure node (such as NEF in 5G network) can simultaneously provide the functions of CCF, APF, AEF and API management function.

[0174] Wherein, CAPIF-1 is a reference point between API invocation network element and CCF, used for API invocation network element to find API, authentication with CCF and obtaining authorization within a public land mobile network (PLMN) trust domain. CAPIF-1 supports the following functions: authentication of API invocation network element based on the identification and security credentials of the API invocation network element; bidirectional authentication of API invocation network element and CCF; providing authorization for API invocation network element to access API; discovering API information, etc.

[0175] CAPIF-1e is used for API invocation network element to find API, authentication with CCF and obtaining authorization outside the PLMN trust domain. CAPIF-1e supports the same functions as CAPIF-1.

[0176] CAPIF-2 is a reference point between API invocation network element and API exposure network element, used for API communication of API invocation network element within the PLMN trust domain. CAPIF-2 supports the following functions: authentication of API invocation network element based on the identification and security credentials of the API invocation network element; authorization verification when API invocation network element accesses API; API invocation, etc.

[0177] CAPIF-2e is used for API communication of API invocation network element within the PLMN trust domain. CAPIF-2e supports the same functions as CAPIF-2.

[0178] CAPIF-3 is a reference point between API exposure function network element and CCF, used for performing access and policy related control of API communication initiated by API invocation network element. CAPIF-3 supports the following functions: supporting API exposure function network element to authenticate API invocation network element based on the identification and security credentials of the API invocation network element; supporting API exposure function network element to provide authorization for API invocation network element before API invocation network element accesses API; supporting API exposure function network element to verify authorization when API invocation network element accesses API; supporting API exposure function network element to control API access based on the policy configured by the PLMN operator; supporting API exposure function network element to log API invocation; supporting API exposure function network element to charge API invocation, etc.

[0179] CAPIF-4 is a reference point between API publishing network element and CCF, used for publishing API information. CAPIF-4 supports the following API publishing functions: publishing API.

[0180] CAPIF-5 is a reference point between API management function network element and CCF, used for management of API and API invocation network element information. CAPIF-5 supports the following functions: support API management function network element to access API invocation log; support API management function network element to monitor API invocation event; support API invocation network element to configure API invocation network element information in CCF to support registration of API invocation network element; support API management function network element to configure policies in CCF, such as upper limit of API invocation, temporary disable API for a period of time; support API provider to monitor the status of API, etc.

[0181] API invocation network element, also known as API invocation entity or consumer entity, is generally a third-party application function entity software program that signs a service agreement with a PLMN operator. The third-party application can be, for example, a machine to machine (M2M) application, an internet of things (IoT) application, a vehicle to everything (V2X) application, etc. These applications can run in terminal devices or network devices. In addition, the API invocation network element can also refer to an application function (AF) network element. The API invocation network element can be in the same trust domain as the API provider (such as a PLMN operator) that provides the API, or can belong to different trust domains. The API invocation network element supports the following capabilities: support authentication of API invocation network element, authenticate the identity and other information of API invocation network element; support mutual authentication with CAPIF; obtain authorization before accessing API; find and invoke API, etc.

[0182] The CCF network element supports the following functions: authenticates API invocation network element based on the identity and other information of API invocation network element; supports mutual authentication with API invocation network element; provides authorization to API invocation network element before API invocation network element accesses API; publishes, stores and supports API search; responsible for API access control based on PLMN operator's policy; stores API invocation log and provides it to authorized entities; charges based on API log; detects API invocation; registration of API invocation network element; stores configuration policies; supports audit of invocation and log, etc.

[0183] The AEF network element provides API and is also an entry for API invocation network element to invoke API, and supports the following functions: authenticates API invocation network element based on the identity of API invocation network element and other information provided by CCF network element; confirms authorization provided by CCF network element; synchronizes API log to CCF.

[0184] An APF network element provides API publishing functions so that API-invoking network elements can discover APIs.

[0185] An AMF network element provides management of APIs, supporting the following functions: auditing of API-invoking logs provided by a CCF network element; monitoring of events reported by a CCF network element; providing policies to API-configured API providers; detecting the status of APIs; registering API-invoking network elements, and the like.

[0186] In the LTE system, the AEF network element can be deployed in a service capability exposure function (SCEF) network element; the CCF can be implemented to be deployed in a separate network entity; or the CCF and entities within an API service provider (such as the AEF, the APF, and the AMF) can be deployed together in the SCEF. In addition, in the 5G mobile communication system, the AEF network element can be deployed in a network exposure function (NEF) network element or an SCEF+NEF, which refers to a network device provided with an SCEF function module and an NEF function module; the CCF network element can be implemented to be deployed in a separate network entity; or the CCF and network elements within an API service provider (such as the AEF, the APF, and the AMF) can be deployed together in the NEF or the SCEF+NEF.

[0187] (4) Edge computing: refers to an open platform that fuses network, computing, storage, and application core capabilities on the network edge close to a thing or a data source, and provides edge intelligent services in proximity, to meet key requirements of industry digitization in terms of agile connection, real-time business, data optimization, application intelligence, security and privacy protection, and the like. In other words, edge computing is to analyze data collected from terminal devices directly on a local device or network close to the data source, without the need to transmit the data to a cloud data processing center.

[0188] As shown in FIG. 3, a multi-access edge computing (MEC) application network architecture is shown, which includes, but is not limited to, a terminal device, a 3rd generation partnership project (3GPP) core network, an edge data network (EDN), and an edge configuration server (ECS), for example. The terminal device can include an application client (AC) and an edge enabler client (EEC), and the edge data network can include an edge application server (EAS) and an edge enabler server (EES).

[0189] The edge data network EDN, in one possible scenario, contains only one data network, which is a local data network (local DN), contains edge enabler functions, can use a data network access identifier (DNAI) and a data network name (application instance / edge) identifier, and is a network logical concept. In another understanding, the EDN is a peer concept of the central cloud, which can be understood as a local data center (geographical location concept), can be identified by a DNAI, and can contain multiple local data networks.

[0190] The application client AC refers to the corresponding entity of the edge application on the terminal device side. The application client is used by the user of the application to obtain application services from the application server. The application client is a client program of the application on the terminal device side. The application client can connect to the application server on the cloud to obtain application services, or can connect to the edge application server EAS deployed in one or more EDNs to obtain application services.

[0191] The edge enabler server EES is used to provide some enabling capabilities, which can better support the deployment of applications in MEC, can support the registration of edge applications, the authentication and authorization of terminal devices, provide application instance information for terminal devices, and further send the identification and address information of the application instance to the edge configuration server ECS.

[0192] Edge Enabling Client (EEC) is used to register information of EEC and application client to EES to perform security authentication and authorization. It is also used to obtain address of EAS from EES and provide edge computing enabling capability to application client, which is the corresponding entity on terminal device side of EES.

[0193] Edge Configuration Server (ECS) is used to be responsible for configuration of EDN, such as providing information of EES to terminal device, and also can directly provide information of application to terminal device, or used to interact with domain name server (DNS) of application to obtain information of application instance.

[0194] (5) Service API and network API: Network API refers to API directly provided by network entity or network element in operator network or controllable by operator, wherein the network entity or network element can be base station, core network element or operator application server, etc. Network API can be QoS request API, network transmission quality analysis API, etc. Service API is API provided by operator network to application, such as XR transmission API, industrial high-reliability data transmission API, etc. Network API combination implements a service API, such as XR transmission API provided by operator network, which needs QoS request API and network transmission quality analysis API to be implemented together. Therefore, it can also be that one service API corresponds to one network API list, and network API list includes network API combination to implement corresponding service API. It needs to be noted that the introduction of the scheme of the present application is taken as an example in the scenario of operator network, and in the scenario of non-operator network, network API can also be called internal API, and service API can also be called external API.

[0195] As described in the background art, before the third-party application calls the API provided by the network, it first needs to discover the network element (such as NEF network element in 5G core network or AEF network element in CAPIF architecture) that provides the open API function. Next, taking 5G core network architecture as an example, the way to discover NEF network element provided in the prior art is introduced. The ways to discover NEF network element supported in the current standard include the following three ways:

[0196] 1. Discovery based on pre-configuration.

[0197] The NEF network element address that can be invoked by the AF is pre-configured in the AF, or the address information of the corresponding NEF network element is configured in the AF for a service API name or a list of service API names. The address information of the NEF network element can include the IP address and port number of the NEF network element, etc. As an example, in the pre-configuration-based manner, the process of invoking the API can refer to FIG. 4. The AF determines the corresponding NEF network element according to the service API to be invoked and the pre-configuration information, and sends an invocation request to the determined NEF network element.

[0198] 2. DNS server-based discovery manner.

[0199] The domain name, address, etc. of the NEF network element in the network are pre-configured in the DNS server. As shown in FIG. 5, when performing discovery, the AF sends a discovery request of the NEF to the DNS server, and the discovery request carries the domain name information of the requested NEF network element, the UE identifier, or the ECS option information representing the UE location, etc. The DNS server receives the discovery request and returns the address information of the NEF network element closest to the UE to the AF. For example, the address information can include the IP address and port number of the NEF network element, etc. The AF receives the address information of the NEF network element sent by the DNS server, and sends an invocation request to the NEF network element based on the address information.

[0200] 3. Network repository function (NRF) network element-based discovery manner.

[0201] The NRF network element supports the service discovery function in the network, receives the discovery request of other network elements from the network element instance, and provides the information of the discovered other network elements to the network element instance sending the request. The NRF network element is also used to maintain the available network element instances and their configuration files, and the configuration file of the network element includes the address information of the network element, the type of the network element, the PLMN ID, etc. The NEF network element in the network registers the name of the supported service API or the list of service API names and the address information of the NEF network element to the NRF, and the NRF stores the service API supported by the NEF network element and the address information of the NEF network element. When the AF is an application trusted by the operator network, the NEF can be discovered based on the NRF network element.

[0202] As shown in FIG. 6, when performing discovery, the AF sends a discovery request of the NEF to the NRF, and the discovery request carries the domain name information of the requested NEF network element and the type of the requested NEF network element. The NRF selects the closest NEF network element for the AF based on the location of the AF, and returns the address information of the NEF network element to the AF. The AF sends an invocation request to the corresponding NEF network element based on the received address information.

[0203] In the prior art, it can be found that the NEF has a specific service API, but when the AF calls the service API, there are certain requirements for the call performance such as delay and bandwidth, and the NEF discovered based on the existing NEF discovery scheme may not meet the performance requirements of the AF. Based on this, the present application proposes a network element discovery method. Taking the 5G core network architecture as an example, the present application proposes that an independent network element maintains the address information of the NEF network element in the network and the information of the supported service API. The AF sends a NEF network element discovery request carrying performance requirements to the independent network element. The independent network element selects a NEF network element that can provide the corresponding service API and meet the performance requirements according to the discovery request, and returns the address information of the network element to the AF. The AF initiates a service API call request to the corresponding NEF network element. The NEF network element converts the service API into one or more network APIs, and executes the call of one or more network APIs.

[0204] In order to facilitate understanding of the network element discovery scheme proposed in the present application, first, the scenario applicable to the present application is introduced. For example, referring to FIG. 7, an architecture schematic diagram of an application scenario provided by an embodiment of the present application is shown, which includes a first network element, a second network element and a plurality of third network elements. The first network element, the second network element and the third network element can be network elements in the 3GPP core network, such as network elements in the 5G core network, or network elements in the CAPIF architecture, or devices in the edge computing architecture. The present application does not limit the architecture to which each network element in the application scenario belongs, and does not limit the number of network elements in the application scenario. For example, in FIG. 7, one first network element is exemplarily shown, but it should be understood that the application scenario can include a plurality of first network elements, and FIG. 7 is only an example.

[0205] Optionally, the first network element is a network element for initiating API call, which can also be an API consumer network element for initiating a call request of a service API or a network API to the third network element, such as calling a service API or a network API to publish business information to the network and obtain network performance from the network. As an example, the first network element can be an AF in the 5G core network, an API calling network element in the CAPIF architecture, or an application client AC in the edge computing architecture.

[0206] Optionally, the second network element is a third network element in the network for discovering the execution of the API call, and the second network element maintains address information of the third network element in the network and a service API supported by the third network element. When the first network element needs to call a certain service API, the first network element will first discover the third network element capable of supporting the API call through the second network element. For example, when the first network element needs to call a service API, the first network element sends a discovery request to the second network element. After receiving the discovery request sent by the first network element, the second network element can determine the third network element capable of providing the service API call from a plurality of third network elements according to the stored information, and send the address information of the determined third network element to the first network element. Exemplarily, the second network element can be an existing network element in the core network, or can be a newly added network element, which is not limited in the present application. For example, the second network element can be a CCF network element in the CAPIF architecture, or can be an EES or an ECS in the edge computing architecture.

[0207] Optionally, the third network element is a network element for opening network capabilities to third-party applications, that is, a network element supporting the call of the first service API. Wherein, the call of the first service API includes the execution of the first service API by the third network element, and also includes the triggering of the execution of the first service API by the third network element through other network elements. For example, when the third network element is a network element for specifically executing the first service API call, the third network element can also be called a first service API instance, and the third network element can receive a call request from the first network element and call the first service API according to the call request. For another example, when the third network element executes the call of the first service API through other network elements, the network element capable of executing the first service API can be called a first service API instance, and the third network element can forward the call request from the first network element to the network element capable of executing the first service API call, and the network element can execute the call of the first service API according to the call request. As an example, the third network element can be a NEF network element in the 5G core network, or the third network element can be an AEF or a border AEF network element in the CAPIF architecture, or the third network element can be an EAS in the edge computing architecture.

[0208] It should be noted that the specific implementation of the first network element, the second network element and the third network element in the different architectures described above is only an example, and the first network element, the second network element and the third network element can be the network elements introduced in the above various architectures, or can be newly added network elements in the network.

[0209] Next, the network element discovery scheme proposed in the present application is introduced in combination with the architecture shown in FIG. 7. Exemplarily, referring to FIG. 8, a flowchart of a network element discovery method provided in an embodiment of the present application is shown. The steps shown in FIG. 8 are only exemplary, and a person skilled in the art can select some or all of the steps shown in FIG. 8 as an embodiment. For example, steps 801-802 can be selected to implement the discovery method of the target third network element. For another example, steps 803-805 can be selected to implement the calling method of the service API. Exemplarily, the method flow shown in FIG. 8 specifically includes:

[0210] 801. The first network element sends a first request message to the second network element. Correspondingly, the second network element receives the first request message.

[0211] The first request message carries the performance requirement of the first service API to be called by the first network element, and the identifier and / or type of the first service API. The first request message is used to request the address of the third network element capable of providing the first service API calling and meeting the performance requirement indicated by the first request message. Exemplarily, the performance requirement of the first service API is used to indicate the performance requirement of the time delay, bandwidth or throughput for the first service API calling process, such as the time delay requirement, which refers to the requirement of the time length required for the first service API calling process, that is, the requirement of the time length between the sending of the calling request and the receiving of the calling result, which can also be called the response time requirement. The bandwidth requirement refers to the bandwidth required for the first service API calling.

[0212] Exemplarily, the first request message can also carry the type of the third network element requested by the first network element, or can also carry the location information of the first network element, so that the second network element can quickly determine the third network element capable of providing the first service API.

[0213] 802. The second network element sends the address of the target third network element to the first network element.

[0214] Exemplarily, the second network element maintains information of one or more third network elements, and the information of the third network elements includes but is not limited to: a service API supported by the third network element, an address of the third network element, a type of the third network element, an identifier of the third network element, a deployment location of the third network element, or a service area of the third network element. Exemplarily, the information of the one or more third network elements stored in the second network element can be reported by the third network elements to the second network element in advance, for example, each third network element can report its own information to the second network element after being started. Among them, the information of the service API supported by the third network element can also be a mapping relationship between the service API supported by the third network element and a network API, that is, the network API and the service API supported by the third network element can be stored in the second network element at the same time, and the mapping relationship between the two can be stored. The mapping relationship between the service API and the network API is used to indicate that each service API is implemented by calling one or more corresponding network APIs, or can be understood as that the implementation of a service API depends on the corresponding network API. For example, the XR transmission service API provided by the operator network needs to call the QoS request network API and the network quality analysis network API to implement. The address of the third network element can include the IP address or port number of the third network.

[0215] Optionally, after receiving the first request message from the first network element, the second network element can obtain the calling performance of the one or more third network elements for the first service API, determine a target third network element whose calling performance can meet the performance requirement carried in the first request message, and return the address of the target third network element to the first network element. The specific method of obtaining the calling performance of the third network element and determining the target third network element can refer to the description of the following mode one to mode three.

[0216] As an optional mode, after discovering the target third network element through the above steps 801-802, the following steps 803-805 can be further executed to initiate the calling process of the first service API. It should be noted that the initiator of the first service API calling can be the first network element introduced in the above steps, or other network elements or calling entities that need to call the first service API, and in the following introduction, only the first network element initiating the first service API calling is taken as an example for introduction.

[0217] 803, the first network element sends a second request message to the target third network element. Correspondingly, the target third network element receives the second request message.

[0218] It should be noted that the second request message can be sent by the first network element, or can be sent by other network elements or entities that need to call the first service API. The application does not limit the subject that sends the second request message to the target third network element. For the convenience of description, the first network element is taken as an example in FIG. 8.

[0219] The second request message is used to request to call the first service API. The second request message carries the performance requirement of the first service API, and the type of the first service API and / or the type of the first service API.

[0220] 804, the target third network element determines the network API corresponding to the first service API, and calls the network API.

[0221] Optionally, each service API can correspond to (or be associated with) one network API or multiple network APIs. For example, in the above example, the XR transmission service API corresponds to two network APIs, i.e., the QoS request and the network quality analysis. The network API can be provided by different instances (or network elements, or network element instances), and the calling performance of the network API provided by different instances can be the same or different. The calling performance of the first service API is determined by the calling performance of the network API corresponding to the first service API. Therefore, the target instance of the network API corresponding to the first service API can be determined based on the performance requirement of the first service API.

[0222] In a possible case, the first service API corresponds to one network API, and the target third network element can obtain one or more instances that can provide the network API, and determine the target instance from the one or more instances according to the performance requirement of the first service API. For example, the calling performance includes the calling time delay, and the process of determining the target instance is introduced as follows: instance a and instance b can both provide the network API, the calling time delay of the network API provided by instance a is 10 seconds, the calling time delay of the network API provided by instance b is 6 seconds, and the time delay requirement of the first service API is 8 seconds. It is determined that instance b can meet the time delay requirement, and instance b is determined as the target instance.

[0223] In another possible case, the first service API corresponds to multiple network APIs, the target third network element can obtain one or more instances capable of providing each of the network APIs, and determine target instances providing each of the network APIs according to performance requirements of the first service API, so that the target instances of the multiple network APIs can provide calling performance satisfying the performance requirements of the first service API. At this time, the calling sequence of the multiple network APIs can also affect the performance of the first service API. As an example, the first service API is associated with network API X and network API Y, and network API X and network API Y are called in parallel, at this time, the performance of the first service API depends on the worst performance of network API X and network API Y. In order to improve the performance of the first service API, a highest performance instance of network API Y can be selected as a target instance, and network API Y is called to the target instance.

[0224] As another example, the first service API is implemented by combination of network API1 and network API2, wherein instance a and instance b can both provide network API1 (here, instance a and instance b can be instances of the same type or instances of different types), and instance c provides network API2. Taking the requirement of latency as an example, the latency requirement of the first service API is 10 seconds, the calling latency of network API2 provided by instance c is 6 seconds, the calling latency of network API1 provided by instance a is 3 seconds, and the calling latency of network API1 provided by instance b is 5 seconds. Then, network API1+network API2 provided by instance a+instance c can satisfy the latency requirement of the first service API, and therefore, the target third network element can determine instance a and instance c as target instances.

[0225] Exemplarily, after the target instances are determined, the target third network element can trigger calling of the network API to the target instances.

[0226] 805, the target third network element sends the calling result of the first service API to the first network element. Correspondingly, the first network element receives the calling result of the first service API.

[0227] It should be noted that the calling result of the first service API can be sent to the first network element from the target third network element, or can be sent to the first network element from other network elements, such as the calling result of the network API can be sent to the first network element by an instance providing the network API, so that the first network element obtains the calling result of the first service API according to the calling result of the network API. In the embodiments of the present application, only the case that the calling result is sent by the target third network element is introduced. In addition, it should be noted that, as introduced in step 803, the second request message can be sent by the first network, or can be sent by other network elements or entities requiring to call the first service API. Correspondingly, in step 805, if the second request message is sent by the first network element, the target third network element (or the instance providing the network API) returns the calling result to the first network element; if the second request message is sent by other entities or network elements, the target third network element (or the instance providing the network API) returns the calling result to the other entities or network elements. FIG. 8 is only an exemplary illustration, and the case that the second request message is sent by the first network element and the calling result is sent to the first network element by the target third network element is introduced.

[0228] Exemplarily, the calling result of the first service API can be used to indicate whether the first service API is successfully called, and the calling result of the first service API is determined according to the calling result of the network API corresponding to the first service API. For example, in the case that the first service API corresponds to one network API, when the network API is successfully called, it can be determined that the calling result of the first service API is a successful call; on the contrary, when the network API fails to be called, it can be determined that the calling result of the first service API is a call failure. The calling result of the first service API contains the result after the first service API is executed. For another example, in the case that the first service API corresponds to multiple network APIs, when the multiple network APIs are all successfully called, it can be determined that the calling result of the first service API is a successful call; on the contrary, when any one of the multiple network APIs fails to be called, it can be determined that the calling result of the first service API is a call failure.

[0229] Based on the above scheme, when the first network element needs to call the service API in the network, the first network element queries the target third network element capable of providing the service API and meeting the performance requirement of the first network element through the second network element in the network, and the target third network element decomposes the service API into network APIs and executes the calling of the network APIs. In the prior art, the network element performing scheduling based on distance cannot meet the performance requirement of the first network element, while the scheme of the present application discovers the target third network element performing scheduling based on the performance requirement of the first network element, so the target third network element not only can provide the corresponding service API, but also can meet the performance requirement of the service API.

[0230] As introduced in step 802, when discovering the target third network element, the second network element first determines the third network elements capable of providing the first service API according to the type and / or the identifier of the first service API, and further determines the target third network element from the third network elements capable of providing the first service API according to the performance requirement of the first service API. Optionally, the second network element can determine the target third network element from the third network elements capable of providing the first service API in the following three ways:

[0231] In the first way, the second network element maintains the calling performance of one or more third network elements for each service API supported by the third network element. Thus, the second network element can determine the calling performance of the third network elements capable of providing the first service API from the information stored by itself, and determine the target third network element capable of meeting the performance requirement of the first service API from the third network elements capable of providing the first service API according to the calling performance of each third network element.

[0232] In the second way, as not shown in FIG. 7, the application scenario architecture can further include a fourth network element for maintaining the calling performance of one or more third network elements for each service API supported by the third network element. The second network element can obtain the calling performance of the third network elements capable of providing the first service API for the first service API from the fourth network element, and determine the target third network element from the third network elements capable of providing the first service API according to the obtained calling performance. Exemplarily, the fourth network element in the communication architecture can be an NRF network element in a 5G core network, or the fourth network element can also be an APF network element in a CAPIF architecture, or the fourth network element can also be a CCF network element in an edge computing architecture.

[0233] In the third way, the second network element can determine the target third network element capable of meeting the performance requirement of the first service API from the third network elements capable of providing the first service API. Exemplarily, there can be one or more third network elements capable of providing the first service API, and the following takes a third network element a as an example to introduce the execution process of the third way:

[0234] The second network element can send a third request message to the third network element a, and the third request message is used to request the third network element a to judge whether the third network element a meets the performance requirement of the first service API. The third request message can carry the performance requirement of the first service API, the identifier of the first service API and / or the type of the first service API.

[0235] In a possible implementation, the third network element a can store the calling performance for the first service API, so that when receiving the third request message, the third network element a can directly determine whether the performance requirement of the first service API can be met, and thus send response information indicating whether the performance requirement of the first service API can be met to the second network element.

[0236] In another possible implementation, the third network element a does not store the performance of the call of the first service API, and upon receiving the third request message, the third network element a can send a fourth request message to the fourth network element, where the fourth request message is used to request the address, identity and / or type of the network API that meets the first service API. For example, the fourth request message can carry the performance requirement of the first service API, or when the first service API corresponds to multiple network APIs, the third network element a can decompose the performance requirement of the first service API into the performance requirements of the multiple network APIs, and the fourth request message carries the performance requirements of the multiple network APIs.

[0237] Optionally, if the third network element a receives the address, identity and / or type of the network API returned by the fourth network element in response to the fourth request message, the third network element a determines that the performance requirement of the first service API can be met, and returns response information indicating that the performance requirement of the first service API can be met to the second network element. Conversely, if the fourth network element returns information indicating that there is no network API that can meet the performance requirement of the first service API to the third network element a, the third network element a determines that the performance requirement of the first service API cannot be met, and returns response information indicating that the performance requirement of the first service API cannot be met to the second network element.

[0238] Further, the second network element can determine the target third network element according to the response information returned by the third network element that can provide the first service API. As an optional way, if there are two or more third network elements that can meet the performance requirement of the first service API, the second network element can select the third network element closest to the first network element (which can be the physical distance or the network topology distance) from the two or more third network elements as the target third network element according to the location information of the first network element. Or the second network element can also select the third network element with the optimal performance from the two or more third network elements as the target third network element according to the scheduling performance that can be provided by the two or more third network elements. For example, taking the time delay requirement as the performance requirement, when there are third network element a and third network element b that can meet the time delay requirement of the first service API, the third network element with the lowest time delay can be selected from the third network element a and the third network element b as the target third network element.

[0239] It should be noted that the above-described way of selecting the target third network element is only an example, and the present application does not limit the way of selecting the target third network element. For example, when there are multiple third network elements that can meet the performance requirement of the first service API, the second network element can also randomly select one as the target third network element.

[0240] Based on the above scheme, the second network element can select the target third network element with the optimal calling performance for the first network element, and improve the calling efficiency of the service API.

[0241] In some embodiments, as introduced in step 804 above, after receiving the second request message, the target third network element can determine the network API corresponding to the first service API according to the stored mapping relationship between the service API and the network API, and further determine the target instance providing the network API. Alternatively, the target third network element can also obtain the network API corresponding to the first service API and the target instance providing the network API from the second network element. The two ways are introduced as follows:

[0242] In one possible way, the target third network element stores the supported service API and the network API corresponding to each supported service API. For example, the target third network element can store the mapping relationship between the service API and the network API. Alternatively, the mapping relationship between the service API and the network API can also be referred to as the conversion rule, the orchestration rule or the combination rule between the service API and the network API. The target third network element can also store the address of one or more instances providing the network API and the calling performance of the network API provided by each instance. After receiving the second request message, the network API corresponding to the first service API can be determined according to the stored mapping relationship. Further, the target instance can be determined from the one or more instances providing the network API according to the performance requirement of the first service API and the calling performance of the one or more instances. Alternatively, the process of determining the target instance can refer to the example introduced in step 804 above, which will not be described here.

[0243] In another possible way, the target third network element does not store the mapping relationship between the first service API and the network API, but the second network element maintains the mapping relationship and the calling performance of the instance of the network API, and the second network element performs the conversion of the service API to the network API. After receiving the second request message, the target third network element can send a fifth request message to the second network element. The fifth request message is used to request the network API corresponding to the first service API and the address of the target instance providing the network API, and the fifth request message carries the identifier and / or the type of the first service API, and carries the performance requirement of the first service API.

[0244] After receiving the fifth request message, the second network element first determines the network API corresponding to the first service API according to the stored mapping relationship between the first service API and the network API. Further, the second network element can determine the target instance from the one or more instances according to the stored calling performance of the one or more instances providing the network API and the calling performance of the first service API, and return the address of the target instance of the network API to the target third network element. After determining the network API corresponding to the first service API and the target instance of the network API, the target third network element can trigger the calling of the network API to the target instance.

[0245] In a possible case, as introduced in the above Figure 7, the target third network element is the network element actually performing the calling of the first service API, and the target third network element can be referred to as the first service API instance. In this case, after determining the network API corresponding to the first service API, the target third network element can trigger the calling of the network API according to the stored address of the target instance of the network API, or trigger the calling of the network API according to the address of the target instance obtained from the second network element.

[0246] As another optional way, as introduced in the above Figure 7, the target third network element can also perform the calling of the first service API through other network elements (entities, instances or network element instances). In order to facilitate the description, in the following introduction, the network element capable of performing the calling of the first service API will be referred to as the fifth network element. That is, what is not shown in the architecture shown in Figure 7 is that the application scenario also includes the fifth network element performing the calling of the first service API, and the fifth network element can also be referred to as the first service API network element, the first service API instance or the first service API entity, etc. The target third network element can trigger the fifth network element to perform the calling of the first service API. For example, when the target third network element receives the calling request for the first service API, the target third network element can forward the calling request to the fifth network element, and the fifth network element performs the calling of the first service API.

[0247] Exemplarily, the target third network element can pre-receive the information reported by the fifth network element, the information reported by the fifth network element including an address of the fifth network element, such as including an IP address and a port number of the fifth network element and the like. The information reported by the fifth network element further includes an identification of the first service API that can be invoked by the fifth network element, and includes a calling performance of the fifth network element calling the first service API. The target third network element can forward the calling request for the first service API to the fifth network element according to the information reported by the fifth network element, and the fifth network element performs the calling. When the fifth network element performs the calling of the first service API, the fifth network element can first determine the network API corresponding to the first service API, further determine the target instance of the network API according to the performance requirement of the first service API, and more further, the fifth network element triggers the calling of the network API according to the address of the target instance. Details in the process of the fifth network element performing the calling of the first service API can be referred to the process of the target third network element performing the calling of the first service API introduced in the above embodiments, and will not be introduced here.

[0248] Next, the implementation process of the scheme in each scenario will be introduced in combination with a specific application scenario.

[0249] Scenario one: as an example, referring to FIG. 9, an architecture schematic diagram of another application scenario provided by the embodiments of the present application is shown, which includes a first network element, a second network element, a target third network element, a fourth network element and multiple seventh network elements. Exemplarily, the first network element shown in FIG. 9 is a network element corresponding to a third-party application, which is used to initiate the calling of the API provided in the network, so as to obtain the related information in the network and publish the related information of the application to the network. Exemplarily, the related introduction of the first network element can also be referred to the first network element introduced in FIG. 7. The second network element shown in FIG. 9 is used to discover the target third network element in the network that can perform the calling of the service API and can meet the requirement of the calling of the service API, and the introduction of the second network element can also be referred to the second network element introduced in FIG. 7. The target third network element shown in FIG. 9 is a network element that performs the calling of the first service API, and the target third network element can be one of the multiple third network elements shown in FIG. 7.

[0250] Exemplarily, the fourth network element in FIG. 9 is configured to maintain the network API provided by each seventh network element in the network, such as maintaining and storing the information of the identity of the network API provided by each seventh network element, the type of the network API, the name of the network API, and the address of the network API, and the like. The fourth network element can also be configured to maintain the mapping relationship between the network API and the service API, such as maintaining the combination of multiple network APIs corresponding to each service API, and the mapping relationship between the service API and the network API can be stored in the form of a list. The fourth network element can also be configured to maintain the calling performance of the network API and the service API. The calling performance of the service API is determined according to the calling performance of the network API corresponding thereto. Optionally, when the calling performance of a certain network API changes, the fourth network element can also update the stored calling performance of the network API and update the calling performance of the service API associated with the network API. For example, due to the change of the network environment or the performance of the seventh network element, the calling performance of the network API provided by the seventh network element changes. In this case, the seventh network element reports the changed calling performance of the network API to the fourth network element, and the fourth network element updates the stored calling performance of the network API according to the received calling performance of the network API, and simultaneously updates the calling performance of the service API associated with the network API.

[0251] The multiple seventh network elements shown in FIG. 9 are network elements that specifically provide network APIs in the network. For example, taking the 5G core network as an example, the seventh network element can be an AMF, an SMF, and the like. Exemplarily, the seventh network element is also referred to as the instance of providing the network API in the above embodiments, that is, the seventh network element can also be referred to as an instance. In order to facilitate the description, in the following introduction, the instance of providing the network API is uniformly referred to as the seventh network element. After each seventh network element is online, the network API that can be provided by the local machine, the calling address of the network API, and the calling performance of the network API can be registered in the fourth network element.

[0252] Next, in combination with scenario one, the network element discovery method proposed in the present application is introduced through different embodiments, and specific reference can be made to embodiments one to four below.

[0253] Embodiment one: taking the third network element as the NEF network element in the 5G core network as an example for introduction under the 5G core network architecture. In order to facilitate the description, in embodiment one, the target third network element introduced in FIG. 9 is referred to as the target NEF network element. Exemplarily, referring to FIG. 10, a flowchart of a network element discovery method provided by the present embodiment is shown, which specifically includes:

[0254] 1001, the first network element sends a first request message to the second network element.

[0255] The first request message carries a type of the first service API or an identifier of the first service API to be invoked by the first network element, and further carries performance requirements of the first network element for the invocation performance of the first service API, such as requirements for invocation latency, requirements for invocation bandwidth, and the like. The first request message is used to request to discover a NEF network element capable of executing the first service API and capable of meeting the performance requirements of the first service API. Optionally, the first request message can further carry a location of the first network element, and an identifier of the NEF network element requested by the first network element or a type of the NEF network element requested by the first network element, so as to enable the second network element to more accurately discover the NEF network element capable of providing the first service API.

[0256] Exemplarily, in the network scenario to which the first embodiment is applied, a plurality of NEF network elements are included, and before step 1001, the plurality of NEF network elements report information of themselves to the second network element. The information reported by the NEF network element can include but is not limited to: an identifier of the NEF network element, an address of the NEF network element, a deployment location of the NEF network element, a service area of the NEF network element, a service API (including a type, an identifier or a name of the service API) capable of being provided by the NEF network element, and invocation performance of the NEF network element for the service API. The invocation performance of the NEF network element for the service API can include invocation performance such as invocation latency and invocation bandwidth, and the invocation latency can also be a time required for the invocation of the service API, indicating a time between receiving an invocation request of the service API from the NEF network element and receiving an invocation result of a corresponding network API by the NEF network element.

[0257] In an optional manner, the related information about the service API reported by the NEF network element can be from a fourth network element. As introduced in the above FIG. 9, the fourth network element maintains the mapping relationship between the network API and the service API provided by each seventh network element in the network, and the calling performance of the network API and the service API. Further, the fourth network element can send the related information of the network API and the service API that can be called by each NEF to the NEF network element according to the deployment position of each NEF or the service area of each NEF. Thus, the NEF network element can obtain the related information of the service API that can be supported by itself, such as the mapping relationship between the service API and the network API, the calling performance of the service API, and the calling performance of the network API, and the like. In another optional manner, the NEF network element can maintain the mapping relationship between the network API and the service API provided by each seventh network element in its service area, and the calling performance of the network API and the service API. That is, each seventh network element in the service area of the NEF network element can register the network API and the performance of the network API that can be provided by itself to the NEF network element after being online. The network API is arranged and combined by the NEF network element to obtain the corresponding service API and the calling performance of the service API.

[0258] 1002. The second network element determines a target NEF network element from the plurality of NEF network elements based on the first request message.

[0259] As introduced in the above step 1001, the plurality of NEF network elements in the network will report their information to the second network element in advance. Therefore, the second network element can select a target NEF network element from the plurality of NEF network elements according to the content carried by the first request message and the information reported by the plurality of NEF network elements. The target NEF network element can provide the first service API and meet the performance requirement of the first service API.

[0260] Exemplarily, when selecting the target NEF network element, the second network element can first determine one or more NEF network elements that can provide the first service API from the plurality of NEF network elements according to the information of the service API that can be provided by the plurality of NEF network elements reported and the identification of the first service API or the type of the first service API carried by the first request message. Further, the second network element can select a target NEF network element that can meet the performance requirement of the first service API from the one or more NEF network elements according to the calling performance of the first service API reported by the one or more NEF network elements and the performance requirement of the first service API carried by the first request message.

[0261] In a possible case, when there are multiple NEF network elements capable of providing the first service API, there can be two or more NEF network elements in the multiple NEF network elements that can meet the performance requirement of the first service API. For this case, the second network element can select, from the two or more NEF network elements, an NEF network element closest to the first network element as the target NEF network element. Alternatively, the second network element can also select, from the two or more NEF network elements, an NEF network element with optimal calling performance for the first service API as the target NEF network element. For example, the target NEF network element can be an NEF network element with the shortest calling latency for the first service API among the two or more NEF network elements. Alternatively, the second network element can also randomly select an NEF network element from the two or more NEF network elements as the target NEF network element. The application does not limit the manner of selecting the target NEF network element, and the above manners are only exemplary descriptions.

[0262] Optionally, as described in step 1001 above, when the first request message also carries the identifier of the NEF network element requested by the first network element or the type of the requested NEF network element, the second network element can determine one or more NEF network elements capable of providing the first service API from the multiple NEF network elements in combination with the identifier of the NEF or the type of the NEF and the information of the first service API. Optionally, as described in step 1001 above, when the first request message also carries the location of the first network element, after determining the one or more NEF network elements capable of providing the first service API, the second network element can determine an NEF network element capable of providing the first service API from the one or more NEF network elements based on the location of the first network element and the service area of the one or more NEF network elements. Further, the second network element selects the target NEF network element from the NEF network element capable of providing the first service API.

[0263] 1003. The second network element sends, to the first network element, an address of the target NEF network element.

[0264] Exemplarily, the address of the target NEF network element can include an IP address or a port number of the target NEF network element, etc. Optionally, the second network element can also send, to the first network element, an identifier of the target NEF network element.

[0265] 1004. The first network element sends, to the target NEF network element, a second request message.

[0266] The second request message can also be a calling request message, used to request execution of calling of the first service API. The second request message carries the identifier of the first service API, or the name of the first service API, or the type of the first service API, and the second request message also carries the performance requirement of the first service API.

[0267] 1005, the target NEF network element determines the network API corresponding to the first service API according to the second request message.

[0268] Exemplarily, the mapping relationship between the service API and the network API can be maintained in the target NEF network element, and the calling performance of the seventh network element providing each network API is maintained. The target NEF network element can determine the network API corresponding to the first service API and the address of the seventh network element providing the network API according to the maintained information and the performance requirement of the first service API. The specific determination process can refer to the content of the target instance of the network API described in the above step 804 and the other related embodiments, which will not be described here in detail.

[0269] For ease of description, in the subsequent introduction of FIG. 10, the first service API corresponding to network API_1 and network API_2 are taken as examples for description, wherein the network API_1 is provided by the seventh network element X (or, in combination with the above embodiments, it can be understood that the target instance of the network API_1 is the seventh network element X), and the network API_2 is provided by the seventh network element Y. It should be noted that this is only an example, and the number of network APIs corresponding to the first service API and the seventh network element providing the network API are not limited in the present application.

[0270] 1006, the target NEF network element sends a calling instruction for the network API_1 to the seventh network element X.

[0271] 1007, the target NEF network element sends a calling instruction for the network API_2 to the seventh network element Y.

[0272] It should be noted that the present application does not limit the execution order of step 1006 and step 1007.

[0273] Not shown in FIG. 10 is that after receiving the calling instruction for API_1, the seventh network element X will execute the function corresponding to API_1 and determine whether the execution is successful. Similarly, after receiving the calling instruction for API_2, the seventh network element Y will execute the function corresponding to API_2 and determine whether the execution is successful.

[0274] Not shown in FIG. 10 is that after the execution is completed, the seventh network element X and the seventh network element Y will return the execution result indicating whether the network API_1 and the network API_2 are successfully executed to the target NEF network element. The target NEF network element will generate the execution result of the first service API according to the execution result of the network API_1 and the network API_2, and feed back to the first network element.

[0275] Embodiment Two: Taking the second network element as the CCF network element, the third network element as the AEF network element, and the fourth network element as the APF network element as an example for introduction under the CAPIF architecture. In the CAPIF architecture, the third network element can also be a border AEF network element, and the third network element is taken as the AEF network element as an example for introduction in Embodiment Two. For ease of description, the target third network element introduced in FIG. 9 is referred to as the target AEF network element in Embodiment Two. Exemplarily, referring to FIG. 11, a network element discovery method provided by the embodiments of the present application specifically includes:

[0276] 1101. The first network element sends a first request message to the CCF network element.

[0277] The first request message carries the type of the first service API to be invoked by the first network element or the identifier of the first service API, and also carries the performance requirement of the first network element for the calling performance of the first service API. The first request message is used to request to discover the AEF network element capable of executing the first service API and capable of meeting the performance requirement of the first service API. Optionally, the first request message can also carry the location of the first network element, and the identifier of the AEF network element requested by the first network element or the type of the AEF network element requested by the first network element, so as to enable the CCF network element to more accurately discover the AEF network element capable of providing the first service API.

[0278] Exemplarily, before step 1101 is performed, the APF network element (that is, the fourth network element in FIG. 9) can send the information of a plurality of AEF network elements in the network maintained by the APF network element to the CCF network element, which can include, for example, the identifier, address, deployment location, and service area of the AEF network element. Exemplarily, the APF network element can also send the information of the service API provided by the plurality of AEF network elements in the network maintained by the APF network element and the calling performance of the service API that can be implemented to the CCF network element. Optionally, the information sent by the APF to the CCF can also refer to the content of the information reported by the NEF network element to the second network element in step 1001 described above, which will not be described herein again.

[0279] 1102. The CCF network element determines the target AEF network element from the plurality of AEF network elements based on the first request message.

[0280] The specific process can refer to step 1002 described above.

[0281] 1103. The CCF network element sends the address of the target AEF network element to the first network element.

[0282] 1104. The first network element sends a second request message to the target AEF network element.

[0283] The introduction of the second request message can refer to step 1004 described above.

[0284] 1105. The target AEF network element sends a fifth request message to the CCF network element.

[0285] The fifth request message is used to request a network API corresponding to the first service API, and carries the performance requirement of the first service API, and carries the identity of the first service API and / or the type of the first service API.

[0286] Exemplarily, in Embodiment Two, the mapping relationship between the service API and the network API can be maintained and stored by the CCF, and when the target AEF network element receives the calling request for the first service API, the target AEF network element can request the CCF network element to provide the network API corresponding to the first service API.

[0287] 1106. The CCF network element determines the network API corresponding to the first service API according to the fifth request message.

[0288] Exemplarily, the process of determining the network API corresponding to the first service API and determining the seventh network element providing the network API can refer to the description in steps 804 and other related embodiments described above, and will not be described in detail here.

[0289] 1107. The CCF network element sends the address of the seventh network element providing the network API to the target AEF network element.

[0290] Exemplarily, the address of the seventh network element can include the IP address and port number of the seventh network element, etc.

[0291] For ease of description, in the subsequent description of FIG. 11, the first service API corresponds to network API_1 and network API_2 are taken as examples for description, wherein the network API_1 is provided by the seventh network element X, and the network API_2 is provided by the seventh network element Y. It should be noted that this is only an example, and the number of network APIs corresponding to the first service API and the seventh network element providing the network API are not limited in the present application.

[0292] 1108. The target AEF network element sends a calling instruction for the network API_1 to the seventh network element X.

[0293] 1109. The target AEF network element sends a calling instruction for the network API_2 to the seventh network element Y.

[0294] The description of steps 1108 and 1109 can refer to steps 1006 and 1007 described above, and will not be described in detail here.

[0295] Embodiment three: in the 5G core network architecture, taking the third network element as the NEF network element in the 5G core network as an example, in order to facilitate description, in embodiment one, the target third network element introduced in FIG. 9 is called target NEF network element. Exemplarily, referring to FIG. 12, a flowchart of a network element discovery method provided in the embodiment of the application, specifically comprising:

[0296] 1201, the first network element sends a first request message to the second network element.

[0297] The first request message carries the type of the first service API to be called by the first network element or the identifier of the first service API, and also carries the performance requirement of the first network element for the calling performance of the first service API, such as the requirement for the calling delay, the requirement for the calling bandwidth, etc. The first request message is used to request to discover the NEF network element capable of executing the first service API and capable of meeting the performance requirement of the first service API. Optionally, the first request message can also carry the location of the first network element, and the identifier of the NEF network element requested by the first network element or the type of the NEF network element requested, so as to enable the second network element to more accurately discover the NEF network element capable of providing the first service API.

[0298] Exemplarily, in the network scenario applied in embodiment three, containing multiple NEF network elements, before step 1201, the multiple NEF network elements will report the information of themselves to the second network element. The information reported by the NEF network element can include but is not limited to: the identifier of the NEF network element, the address of the NEF network element, the deployment location of the NEF network element, the service area of the NEF network element, the service API (including the type, identifier or name of the service API) capable of being provided by the NEF network element.

[0299] 1202, the second network element determines at least one NEF network element capable of providing the first service API from the multiple NEF network elements based on the first request message.

[0300] Exemplarily, the process of determining the at least one NEF network element can refer to the above-mentioned step 1002. It should be known that the target NEF network element is one of the at least one NEF network element, in order to facilitate description, the target NEF network element in the at least one NEF network element is taken as an example for introduction in the subsequent steps of FIG. 12.

[0301] 1203, the second network element sends a third request message to the target NEF network element.

[0302] The third request message is used to request to judge whether the target NEF network element can meet the performance requirement of the first service API, and the third request message carries the performance requirement of the first service API, and carries the type of the first service API or the identifier of the first service API.

[0303] It should be noted that the second network element actually sends the third request message to at least one NEF network element capable of providing the first service API, and here only the target NEF network element is taken as an example.

[0304] 1204, the target NEF network element sends a fourth request message to the fourth network element.

[0305] The fourth request message is used to request a network API corresponding to the first service API, and to request an address, an identifier and / or a type of a seventh network element providing the network API.

[0306] As an optional manner, the fourth request message can carry a performance requirement of the first service API, and the fourth network element determines the seventh network element providing the network API according to the performance requirement. Alternatively, as another optional manner, the target NEF network element can also convert the performance requirement of the first service API into a performance requirement of the corresponding network API according to a preset rule, a calling logic of the network API and a distance feature of the network API. For example, taking network API_1 and network API_2 corresponding to the first service API as an example, the time delay performance requirement of the first service API is 10 seconds, and then the target NEF network element can split the 10 seconds according to the preset rule, the calling logic of the network API and the distance feature of the network API to determine the time delay performance requirements of network API_1 and network API_2 respectively. Further, the target NEF network element can send the fourth request message carrying the performance requirement of the network API to the fourth network element.

[0307] 1205, the fourth network element sends an address, an identifier and / or a type of the seventh network element providing the network API to the target NEF network element.

[0308] It should be noted that the target NEF network element is an NEF network element capable of meeting the performance requirement of the first service API in FIG. 12, so the fourth network element returns the information of the seventh network element to the target NEF network element in step 1205. However, for other NEF network elements except the target NEF network element in the at least one NEF network element capable of providing the first service API, the fourth network element does not return the information of the seventh network element, and can return information indicating that the performance cannot be met to the other NEF network element.

[0309] 1206, the target NEF network element sends response information to the second network element.

[0310] The response information carries an address, an identifier and / or a type of the seventh network element, and is used to indicate that the target NEF network element can meet the performance requirement of the first service API.

[0311] It should be further explained that, for other NEF network elements described in step 1205, the other NEF network elements can send information indicating query failure to the second network element.

[0312] 1207, the second network element sends the address of the target NEF network element to the first network element.

[0313] 1208-1211 can be referred to steps 1004-1007 in the above-mentioned FIG. 10, which will not be described here.

[0314] Embodiment four: taking the second network element as the CCF network element, the third network element as the AEF network element, and the fourth network element as the APF network element as an example for introduction in the CAPIF architecture. The network architecture applied in embodiment three also includes the AMF network element in the CAPIF architecture, which is used to maintain the calling performance of the service API. Among them, in the CAPIF architecture, the third network element can also be a border AEF network element, and the third network element is taken as an AEF network element in embodiment four. For ease of description, in embodiment four, the target third network element introduced in FIG. 9 is referred to as a target AEF network element. Exemplarily, referring to FIG. 13, a network element discovery method provided by the present application embodiment, specifically comprising:

[0315] 1301, the first network element sends a first request message to the CCF network element.

[0316] For details, please refer to the above-mentioned step 1101, and different from the introduction in step 1101, in embodiment four, the information sent by the APF to the CCF does not include the calling performance of the service API that can be implemented by the plurality of AEF network elements.

[0317] 1302, the CCF network element sends a sixth request message to the AMF network element.

[0318] The sixth request message is used to request the calling performance of the first service API by the plurality of AEF network elements in the network. The sixth request message can carry the type of the first service API or the identifier of the first service API, and can also carry the address of the first service API, etc.

[0319] 1303, the AMF network element sends the calling performance of the first service API by the plurality of AEF network elements to the CCF network element.

[0320] 1304-1311 can be referred to steps 1102-1109 in the above-mentioned FIG. 11.

[0321] Scenario two: as an example, referring to FIG. 14, an architecture schematic diagram of another application scenario provided by the embodiment of the present application is shown, which includes a first network element, a second network element, a target third network element, a fourth network element, a fifth network element and a plurality of seventh network elements. The description of the first network element, the second network element, the target third network element, the fourth network element and the plurality of seventh network elements can be referred to the description of FIG. 9. The fifth network element shown in FIG. 14 can also be referred to as a first service API network element or a first service API instance, etc. The fifth network element is configured to provide a first service API and maintain a mapping relationship between the first service API and a network API.

[0322] Next, the network element discovery method provided by the present application is introduced through different embodiments in combination with scenario two shown in FIG. 14. For details, please refer to the following embodiment five to embodiment six.

[0323] Embodiment five: taking the third network element as an example, i.e., the NEF network element in the 5G core network. In order to facilitate the description, the target third network element introduced in embodiment one is referred to as a target NEF network element. Before introducing the network element discovery process, the process of pre-configuring information is introduced first. Optionally, in embodiment five, the fourth network element maintains the network API provided by the plurality of seventh network elements in the network, which can include the address of the network API, the identifier of the network API, etc. The fourth network element can send the related information of the network API in different regions to the corresponding fifth network element according to the service area of the fifth network element. For example, the related information of the network API can include the address of the network API, the identifier of the network API, etc. The calling performance of the network API can also be included.

[0324] The fifth network element determines the first service API that can be provided according to the network API, and determines the calling performance of the first service API according to the calling performance of the network API. Further, the fifth network element can send the identifier of the first service API, the calling performance of the first service API and the address of the fifth network element to the NEF network element. Therefore, in embodiment five, the NEF network element maintains the address of the fifth network element and the identifier of the fifth network element, and also maintains the information of the first service API that can be provided by the fifth network element.

[0325] The above describes the process of pre-configuring information of various network elements in embodiment five. Next, the process of network element discovery is introduced. For example, referring to FIG. 15, a flowchart of a network element discovery method provided by the embodiment of the present application is shown, which includes the following steps:

[0326] 1501-1504 can be referred to the steps 1001-1004 in FIG. 10.

[0327] 1505, the target NEF network element determines the fifth network element according to the second request message.

[0328] Exemplarily, the target NEF network element can determine that the fifth network element can provide the first service API and can meet the performance requirement of the first service API according to the information reported by the fifth network element and the performance requirement of the first service API.

[0329] 1506, the target NEF network element sends a calling request for the first service API to the fifth network element.

[0330] Exemplarily, the calling request for the first service API can carry the identification of the first service API, the type of the first service API and other information, and can also include the performance requirement of the first service API.

[0331] 1507, the fifth network element determines the network API corresponding to the first service API.

[0332] Exemplarily, according to the description in embodiment five, the fourth network element sends the information related to the network API to the fifth network element before performing the network element discovery process. Based on this, the fifth network element can determine the network API corresponding to the first service API according to the information received in advance. The specific determination process can be referred to the introduction of step 1005 above, and will not be described here.

[0333] For ease of description, in the subsequent introduction of FIG. 15, the first service API corresponds to network API_1 and network API_2 are taken as examples for description, wherein the network API_1 is provided by the seventh network element X, and the network API_2 is provided by the seventh network element Y. It should be noted that this is only an example, and the number of network APIs corresponding to the first service API and the seventh network element providing the network API are not limited.

[0334] 1508, the fifth network element sends a calling instruction for the network API_1 to the seventh network element X.

[0335] 1509, the fifth network element sends a calling instruction for the network API_2 to the seventh network element Y.

[0336] Embodiment six: the same as embodiment five, before performing the network element discovery process, it is necessary to pre-configure information in various network elements. Different from embodiment five, the fourth network element maintains the network API, and the fourth network element will not send the calling performance of the network API to the fifth network element. The configuration process of other information can be referred to the introduction in embodiment five above, and will not be described here. Next, the process of network element discovery is introduced. Exemplarily, referring to FIG. 16, a flowchart of a network element discovery method provided by the embodiment of the application is shown, which specifically includes:

[0337] 1601, the first network element sends a first request message to a second network element.

[0338] The first request message carries a type of the first service API or an identifier of the first service API to be invoked by the first network element, and further carries performance requirements of the first network element for performance of invocation of the first service API, such as requirements for invocation latency, requirements for invocation bandwidth, and the like. The first request message is used to request discovery of an NEF network element that is capable of executing the first service API and capable of meeting the performance requirements of the first service API. Optionally, the first request message can further carry a location of the first network element, and an identifier of the NEF network element requested by the first network element or a type of the NEF network element requested by the first network element, so as to enable the second network element to more accurately discover the NEF network element that can provide the first service API.

[0339] 1602, the second network element determines at least one NEF network element that is capable of providing the first service API from a plurality of NEF network elements based on the first request message.

[0340] Exemplarily, the process of determining the at least one NEF network element can refer to the above-described step 1002. It is to be known that the target NEF network element is one of the at least one NEF network element, and for the convenience of description, the target NEF network element of the at least one NEF network element is taken as an example for introduction in subsequent steps of FIG. 12.

[0341] 1603, the second network element sends a third request message to the target NEF network element.

[0342] The third request message is used to request judgment of whether the target NEF network element is capable of meeting the performance requirements of the first service API, and the third request message carries the performance requirements of the first service API, and further carries a type of the first service API or an identifier of the first service API.

[0343] It is to be known that the second network element actually sends the third request message to each of the at least one NEF network element that is capable of providing the first service API, and here, only the target NEF network element is taken as an example.

[0344] 1604, the target NEF network element sends a fourth request message to a fifth network element.

[0345] The fourth request message is used to request an address, an identifier, and / or a type of at least one network API that meets the performance requirements of the first service API. The fourth request message can refer to the above-described step 1204, and will not be described herein.

[0346] 1605, the fifth network element sends the fourth request message to a fourth network element.

[0347] 1606. The fourth network element sends, to the fifth network element, an address, an identity, and / or a type of the seventh network element providing the network API.

[0348] 1607. The fifth network element sends, to the target NEF network element, the address, the identity, and / or the type of the seventh network element providing the network API.

[0349] 1608. The target NEF network element sends, to the second network element, response information.

[0350] The response information carries the address, the identity, and / or the type of the seventh network element, and is used to indicate that the target NEF network element is capable of meeting the performance requirement of the first service API.

[0351] 1609-1610 can be seen in steps 1207-1208 in FIG. 12 described above, and will not be described again here.

[0352] 1611-1614 can be seen in steps 1506-1509 in FIG. 15 described above, and will not be described again here.

[0353] Scenario three: as an example, referring to FIG. 17, another architecture schematic diagram of a scenario provided by the embodiment of the present application is shown, which includes a first network element, a second network element, a target third network element and a plurality of seventh network elements. The description of the first network element, the second network element and the plurality of seventh network elements can be referred to the description of FIG. 9, which will not be repeated here. The function of the target third network element shown in FIG. 17 can also be referred to the description of FIG. 9. In addition to the above, the third network element in FIG. 17 is also used to maintain the network API provided by each seventh network element in its service area, such as maintaining and storing the identification, type, name and address of the network API provided by each seventh network element. The target third network element can also be used to maintain the mapping relationship between the network API and the service API, such as maintaining the combination of a plurality of network APIs corresponding to each service API, and the mapping relationship between the service API and the network API can be stored in the form of a list. The target third network element can also be used to maintain the calling performance of the network API and the service API. The calling performance of the service API is determined according to the calling performance of its corresponding network API. Optionally, when the calling performance of a certain network API changes, the target third network element can also update the stored calling performance of the network API and update the calling performance of the service API associated with the network API. For example, due to changes in network environment or performance of the seventh network element, the calling performance of the network API provided by the seventh network element changes. In this case, the seventh network element reports the changed calling performance of the network API to the target third network element, and the target third network element updates the stored calling performance of the network API according to the received calling performance of the network API, and updates the calling performance of the service API associated with the network API at the same time.

[0354] The network element discovery method proposed by the present application will be introduced through different embodiments in combination with scenario three. For details, please refer to the following embodiment seven to embodiment eight.

[0355] Embodiment seven: under the 5G core network architecture, the third network element is taken as the NEF network element in the 5G core network as an example for introduction. In order to facilitate description, in embodiment seven, the target third network element introduced in FIG. 17 is referred to as a target NEF network element. Exemplarily, referring to FIG. 18, a flowchart of a network element discovery method provided by the embodiment of the present application is shown, which specifically includes:

[0356] 1801, the first network element sends a first request message to the second network element.

[0357] Exemplarily, the introduction of the first request message can be referred to step 1001.

[0358] Exemplarily, before step 1801 is performed, a plurality of NEF network elements in the network report their own information to the second network element. The specific content of the reported information can be referred to the introduction in step 1001. The information reported by each NEF network element can be the seventh network element pre-reported within the service area range thereof.

[0359] 1802, the second network element determines a target NEF network element from the plurality of NEF network elements based on the first request message, and determines a network API corresponding to the first service API.

[0360] Exemplarily, the process in which the second network element determines the target NEF network element can be referred to step 1002 described above. The second network element can maintain the mapping relationship between the service API and the network API, and maintain the calling performance of each network API. Therefore, the second network element can determine the network API corresponding to the first service API according to the performance requirement of the first service API carried by the first request message.

[0361] 1803, the second network element sends the address of the target NEF and the address and / or identifier of the seventh network element providing the network API to the first network element.

[0362] 1804, the first network element sends a second request message and the address and / or identifier of the seventh network element providing the network API to the target NEF network element.

[0363] 1805-1806 can be referred to steps 1006-1007 in FIG. 10 described above, and will not be described in detail here.

[0364] Embodiment eight: under the 5G core network architecture, taking the third network element as the NEF network element in the 5G core network as an example for introduction. In order to facilitate description, in embodiment eight, the target third network element introduced in FIG. 17 is referred to as a target NEF network element. Exemplarily, referring to FIG. 19, a flowchart of a network element discovery method provided by the present application is shown, which specifically includes:

[0365] 1901, the first network element sends a first request message to the second network element.

[0366] Exemplarily, the introduction of the first request message can be referred to step 1001 described above.

[0367] Exemplarily, before step 1801 is performed, a plurality of NEF network elements in the network report their own information to the second network element. The specific content of the reported information can be referred to the introduction in step 1001. The information reported by each NEF network element can be the seventh network element pre-reported within the service area range thereof.

[0368] 1902, the second network element determines at least one NEF network element capable of providing the first service service API from the plurality of NEF network elements based on the first request message.

[0369] For details, see the above step 1202, which will not be described here.

[0370] 1903, the second network element sends a third request message to the target NEF network element.

[0371] For details, see the above step 1203, which will not be described here.

[0372] 1904, the target NEF network element sends response information to the second network element.

[0373] The response information carries the address, identifier and / or type of the seventh network element providing the network API, and is used to indicate that the target NEF network element can meet the performance requirements of the first service API.

[0374] 1905, the second network element sends the address of the target NEF and the address, identifier and / or type of the seventh network element providing the network API to the first network element.

[0375] 1906, the first network element sends the second request information and the address, identifier and / or type of the seventh network element providing the network API to the target NEF network element.

[0376] 1907-1908 can refer to steps 1006-1007 in FIG. 10, which will not be described here.

[0377] Next, another network element discovery scheme proposed in the present application is introduced. In this scheme, the second network element uses the network element discovery method in the prior art to discover the third network element according to the first request message sent by the first network element, such as the method introduced in FIG. 5 or FIG. 6 to discover the third network element closest to the first network element. Further, in the case that the third network element discovered by the prior art cannot meet the performance requirements of the first service API, the third network element discovered by the prior art will trigger the discovery process of the target third network element as shown in any one of FIG. 8-FIG. 19 to the second network element, and the re-discovered target third network element will execute the call of the first service API.

[0378] To facilitate understanding of another network element discovery scheme proposed in the present application, the scenario to which the network element discovery scheme is applied is first introduced below. Exemplarily, referring to FIG. 20, an architecture schematic diagram of another application scenario provided in an embodiment of the present application is shown, which includes a first network element, a second network element, a target third network element and a sixth network element. The sixth network element is the third network element closest to the first network element in the another network element discovery scheme proposed in the present application. The target third network element is a third network element discovered by using the network element discovery method introduced above with reference to FIG. 8 in the case that the sixth network element cannot meet the performance requirement raised by the first network element. Exemplarily, the target third network element can be one of the multiple third network elements included in the scenario shown in FIG. 7, and the sixth network element can also be one of the multiple third network elements included in the scenario shown in FIG. 7. It should be noted that not shown in the architecture of FIG. 20 is that, in addition to the target third network element and the sixth network element, the application scenario can also include multiple other third network elements. Moreover, the scenario shown in FIG. 20 is only an example, and the present application does not limit the number of each type of network element in the scenario.

[0379] Next, the another network element discovery method proposed in the present application is introduced in combination with the scenario architecture shown in FIG. 20. Exemplarily, referring to FIG. 21, a flow schematic diagram of a network element discovery method provided in an embodiment of the present application is shown, which specifically includes the following steps.

[0380] 2101. The first network element sends a second request message to the sixth network element.

[0381] The second request message is used to request calling the first service API. The second request message carries the performance requirement of the first service API, and the type of the first service API and / or the type of the first service API. The sixth network element is a third network element discovered by the second network element through an existing network element discovery method (such as the schemes introduced above with reference to FIG. 5 or FIG. 6), and the sixth network element is the third network element closest to the first network element and capable of providing the first service API among the multiple third network elements.

[0382] 2102. The sixth network element sends a first request message to the second network element when it cannot meet the performance requirement of the first service API.

[0383] Exemplarily, not shown in FIG. 21 is that, if the sixth network element can meet the first service API, the calling of the first service API can be performed, and the specific calling process can be referred to the introduction in the above embodiments, which will not be described herein again.

[0384] When the sixth network element cannot meet the performance requirement of the first service API, the sixth network element can request the second network element to re-discover a target third network element that can meet the requirement of the first service API. That is, the first request message is used to request the second network element for a target third network element that can provide the first service API and meet the performance requirement of the first service API. The first request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API.

[0385] 2103. The second network element sends, to the sixth network element, an address of the target third network element.

[0386] Exemplarily, after receiving the first request message, the second network element can determine the target third network element based on the first request message. The specific determination process can be referred to the description in the above embodiments, which will not be repeated here.

[0387] 2104. The sixth network element sends, to the target third network element, a second request message.

[0388] Optionally, the sixth network element can send, to the target third network element, the second request message to request the target third network element to perform the invocation of the first service API. Alternatively, the sixth network element can also send, to the first network element, the address of the target third network element, so that the first network element sends, to the target third network element, the second request message, which is not shown in FIG. 21.

[0389] 2105. The target third network element determines a network API corresponding to the first service API, and invokes the network API.

[0390] The specific process can be referred to the description of step 804, which will not be repeated here.

[0391] 2106. The target third network element returns, to the first network element, the invocation result of the first service API.

[0392] Based on the above scheme, the third network element is first discovered by using the traditional distance-based method. If the discovered third network element can invoke the service API and meet the performance requirement of the service API, the third network element discovered by using the traditional scheme directly performs the invocation. Otherwise, if the discovered third network element cannot meet the performance requirement of the service API, the second network element in the network can be used to query a target third network element that can provide the service API and meet the performance requirement of the first network element, and the target third network element performs the invocation of the service API.

[0393] Next, another network element discovery scheme proposed in the present application will be introduced in combination with specific embodiments.

[0394] Embodiment Nine: Taking the third network element as the NEF network element in the 5G core network as an example for introduction under the 5G core network architecture. For ease of description, in Embodiment Nine, the third network element closest to the first network element is referred to as the sixth NEF network element, and the target third network element is referred to as the target NEF network element. Exemplarily, refer to FIG. 22 for a flowchart of a network element discovery method provided by an embodiment of the present application, which specifically includes:

[0395] 2201. The first network element sends a seventh request message to the second network element.

[0396] The seventh request message carries the type of the first service API to be invoked by the first network element or the identifier of the first service API. The seventh request message is used to request discovery of the NEF network element capable of executing the first service API. Optionally, the seventh request message can also carry the location of the first network element, and the identifier of the NEF network element requested by the first network element or the type of the NEF network element requested.

[0397] 2202. The second network element sends the address of the sixth NEF network element to the first network element.

[0398] Exemplarily, the sixth NEF network element is the NEF network element discovered by the second network element through the existing network element discovery manner (such as the schemes introduced in FIG. 5 or FIG. 6), and the sixth NEF network element is the NEF network element closest to the first network element and capable of providing the first service API among the plurality of NEF network elements.

[0399] 2203. The first network element sends a second request message to the sixth NEF network element.

[0400] Exemplarily, the introduction of the second request message can refer to the introduction of step 1004 in FIG. 10 above, and no more details are given here.

[0401] 2204. The sixth NEF network element determines that the performance requirement of the first service API cannot be met according to the second request message.

[0402] It should be noted that the sixth NEF network element cannot meet the performance requirement of the first service API is taken as an example for introduction in FIG. 22, and it should be understood that if the sixth NEF network element can meet the performance requirement of the first service API, steps 1005-1007 above can be executed to complete the invocation of the first service API.

[0403] 2205. The sixth NEF network element sends a first request message to the second network element.

[0404] 2206. The second network element determines the target NEF network element from the plurality of NEF network elements according to the first request message.

[0405] Exemplarily, the process of determining the target NEF network element can refer to step 1002.

[0406] 2207. The second network element sends an address of the target NEF network element to the sixth NEF network element.

[0407] 2208. The sixth NEF network element sends a second request message to the target NEF network element.

[0408] 2209-2211 can refer to steps 1005-1007 in FIG. 10 described above, and will not be described here in detail.

[0409] Embodiment Ten: Taking the second network element as the CCF network element, the third network element as the AEF network element, and the fourth network element as the APF network element as an example for introduction under the CAPIF architecture. In the CAPIF architecture, the third network element can also be a border AEF network element, and in Embodiment Ten, the third network element is taken as an AEF network element for introduction. For ease of description, in Embodiment Ten, the target third network element introduced in FIG. 20 is referred to as a target AEF network element, and the sixth network element introduced in FIG. 20 is referred to as a sixth AEF network element. Exemplarily, referring to FIG. 23, a network element discovery method provided by the present application embodiment specifically includes:

[0410] 2301. The first network element sends a seventh request message to the CCF network element.

[0411] The seventh request message carries the type of the first service API to be invoked by the first network element or the identifier of the first service API. The seventh request message is used to request to discover an AEF network element capable of executing the first service API. Optionally, the seventh request message can also carry the location of the first network element, and the identifier of the AEF network element requested by the first network element or the type of the AEF network element requested.

[0412] 2302. The CCF network element sends the address of the sixth AEF to the first network element.

[0413] Exemplarily, the sixth AEF network element is an AEF network element discovered by the second network element through an existing network element discovery manner (such as the schemes introduced in FIG. 5 or FIG. 6), and the sixth AEF network element is the AEF network element closest to the first network element and capable of providing the first service API among multiple AEF network elements.

[0414] 2303. The first network element sends a second request message to the sixth AEF network element.

[0415] 2304. The sixth AEF network element sends a fifth request message to the CCF network element.

[0416] The fifth request message is used to request a network API corresponding to the first service API, and carries the performance requirement of the first service API, and carries the identity of the first service API and / or the type of the first service API.

[0417] 2305, the CCF network element determines that the sixth AEF network element cannot meet the performance requirement of the first service API, and determines a target AEF network element capable of meeting the performance requirement of the first service API.

[0418] It should be noted that in FIG. 23, the case that the sixth AEF cannot meet the performance requirement of the first service API is taken as an example for introduction. If the sixth AEF network element can meet the performance requirement of the first service API, the CCF network element will perform steps 1106 and 1107 in FIG. 11 described above, and the first service API is executed by the sixth AEF network element.

[0419] 2306, the CCF network element sends the address of the target AEF network element to the sixth AEF network element.

[0420] 2307, the sixth AEF network element sends second request information to the target AEF network element.

[0421] 2308-2312 can be referred to steps 1105-1109 in FIG. 11 described above, and will not be described here.

[0422] Embodiment eleven: in the 5G core network architecture, taking the third network element as the NEF network element in the 5G core network as an example, for the convenience of description, in embodiment eleven, the target third network element introduced in FIG. 20 is referred to as a target NEF network element, and the sixth network element introduced in FIG. 20 is referred to as a sixth NEF network element. Exemplarily, referring to FIG. 24, a flowchart of a network element discovery method provided by the embodiment of the application is shown, which specifically includes:

[0423] 2401-2402 can be referred to the introduction of steps 2201-2202 described above, and will not be described here.

[0424] 2403, the first network element sends a first request message to the sixth NEF network element.

[0425] Exemplarily, the introduction of the first request message can be referred to the introduction in step 1001 described above, and will not be described here.

[0426] After performing 2403, there are two cases:

[0427] In case one, the sixth NEF network element can meet the performance requirement of the first service API, then the following steps 2404a-2408a can be continued.

[0428] In case two, the sixth NEF network element cannot meet the performance requirement of the first service API, then the following steps 2404b-2411b can be continued.

[0429] 2404a, the sixth NEF network element sends the address of the sixth NEF network element to the first network element.

[0430] 2405a, the first network element sends a second request message to the sixth NEF network element.

[0431] The steps performed by the sixth NEF in 2406a-2408a can refer to the steps performed by the target NEF network element in steps 1005-1007 in FIG. 10 described above, and will not be described in detail here.

[0432] 2404b, the sixth NEF network element sends the first request message to the second network element.

[0433] 2405b, the second network element returns the address of the target NEF network element to the sixth NEF network element.

[0434] 2406b, the sixth NEF network element sends the first request message to the target NEF network element.

[0435] 2407b, the target NEF network element sends the address of the target NEF network element to the first network element.

[0436] 2408b, the first network element sends a second request message to the target NEF network element.

[0437] 2409b-2411b can refer to steps 1005-1007 in FIG. 10 described above, and will not be described in detail here.

[0438] Embodiment twelve: in the 5G core network architecture, taking the third network element as an example of the NEF network element in the 5G core network, for the convenience of description, in embodiment twelve, the target third network element introduced in FIG. 20 is called target NEF network element, and the sixth network element introduced in FIG. 20 is called sixth NEF network element. Exemplarily, referring to FIG. 25, a flowchart of a network element discovery method provided by the embodiment of the application is shown, which specifically includes:

[0439] 2501, the first network element sends a seventh request message to the second network element.

[0440] The seventh request message carries the type of the first service API to be called by the first network element or the identifier of the first service API. The seventh request message is used to request to discover the NEF network element capable of executing the first service API. Optionally, the seventh request message can also carry the location of the first network element, and the identifier of the NEF network element requested by the first network element or the type of the NEF network element requested.

[0441] 2502. The second network element sends, to the first network element, an address of the sixth NEF.

[0442] 2503. The first network element sends, to the sixth NEF network element, a second request message.

[0443] 2504. The sixth NEF network element determines, according to the second request message, that the performance requirement of the first service API cannot be met.

[0444] It should be noted that in FIG. 25, the sixth NEF network element is taken as an example to introduce that the performance requirement of the first service API cannot be met. It should be noted that if the sixth NEF network element can meet the performance requirement of the first service API, the calling of the first service API can be directly performed.

[0445] 2505. The sixth NEF network element sends, to the second network element, the first request message.

[0446] 2506-2510 can be referred to steps 1202-1206 in FIG. 12 described above, and will not be described in detail here.

[0447] 2511. The second network element sends, to the sixth NEF network element, an address of a target NEF.

[0448] 2512. The sixth NEF network element sends, to the target NEF network element, the second request message.

[0449] 2513-2515 can be referred to steps 1005-1007 in FIG. 10 described above, and will not be described in detail here.

[0450] Embodiment 13: Taking the second network element as the CCF network element, the third network element as the AEF network element, and the fourth network element as the APF network element as an example to introduce under the CAPIF architecture. In the CAPIF architecture, the third network element can also be a border AEF network element, and in embodiment 13, the third network element is taken as an example to introduce the AEF network element. For ease of description, in embodiment 13, the target third network element introduced in FIG. 20 is referred to as a target AEF network element, and the sixth network element introduced in FIG. 20 is referred to as a sixth AEF network element. In the network architecture applied in embodiment 13, an AMF network element in the CAPIF architecture is also included, which is used to maintain the calling performance of the service API. Illustratively, referring to FIG. 26, a network element discovery method provided in the embodiment of the application, specifically comprising:

[0451] 2601-2604 can be referred to steps 2301-2304 in FIG. 23 described above, and will not be described in detail here.

[0452] 2605. The CCF network element sends, to the AMF network element, a sixth request message.

[0453] The sixth request message is used to request the calling performance of the plurality of AEF network elements in the network for the first service API. The sixth request message can carry the type of the first service API or the identifier of the first service API, and can also carry the address of the first service API.

[0454] 2606, the AMF network element sends the calling performance of the plurality of AEF network elements for the first service API to the CCF network element.

[0455] 2607, the CCF network element determines that the sixth AEF network element cannot meet the performance requirement of the first service API, and determines a target AEF network element capable of meeting the performance requirement of the first service API.

[0456] It should be noted that in FIG. 23, the case that the sixth AEF cannot meet the performance requirement of the first service API is taken as an example for introduction. If the sixth AEF network element can meet the performance requirement of the first service API, the CCF network element will perform steps 1106 and 1107 in FIG. 11, and the sixth AEF network element will perform the calling of the first service API.

[0457] 2608-2614 can be referred to steps 2306-2312 in FIG. 23, which will not be described here.

[0458] Embodiment fourteen: in the 5G core network architecture, taking the third network element as the NEF network element in the 5G core network as an example for introduction, for the convenience of description, in embodiment fourteen, the target third network element introduced in FIG. 20 is referred to as a target NEF network element, and the sixth network element introduced in FIG. 20 is referred to as a sixth NEF network element. Exemplarily, referring to FIG. 27, a flowchart of a network element discovery method provided by the embodiment of the application is shown, which specifically includes:

[0459] 2701-2703 can be referred to the introduction of steps 2401-2403 in FIG. 24, which will not be described here.

[0460] After step 2703 is performed, there can be two cases:

[0461] In case one, the sixth NEF network element can meet the performance requirement of the first service API, and then the following steps 2704a-2710a can be continued.

[0462] In case two, the sixth NEF network element cannot meet the performance requirement of the first service API, and then the following steps 2704b-2711b can be continued.

[0463] 2704a, the sixth NEF network element sends a fourth request message to a fourth network element.

[0464] The fourth request message is used for requesting a network API corresponding to the first service API, and an address, an identifier and / or a type of the seventh network element providing the network API.

[0465] 2705a, the fourth network element sends, to a sixth NEF network element, an address, an identifier and / or a type of the seventh network element providing the network API.

[0466] 2706a, the sixth NEF network element sends, to the first network element, an address of the sixth NEF network element.

[0467] 2707a-2710a can refer to steps 2405a-2408a in FIG. 24 described above, and will not be described herein.

[0468] 2704b, the sixth NEF network element sends, to the second network element, the first request message.

[0469] 2705b, the second network element returns, to the sixth NEF network element, an address of a target NEF network element.

[0470] 2706b, the sixth NEF network element sends, to the target NEF network element, the first request message.

[0471] 2707b, the target NEF network element sends, to the fourth network element, the fourth request message.

[0472] The fourth request message is used for requesting a network API corresponding to the first service API, and an address, an identifier and / or a type of the seventh network element providing the network API.

[0473] 2708b, the fourth network element sends, to the target NEF network element, an address, an identifier and / or a type of the seventh network element providing the network API.

[0474] 2709b, the target NEF network element sends, to the first network element, an address of the target NEF network element.

[0475] 2710b, the first network element sends, to the target NEF network element, the second request message.

[0476] 2711b-2713b can refer to steps 1005-1007 in FIG. 10 described above, and will not be described herein.

[0477] Next, the network element discovery device for implementing the method in the embodiments of the present application will be described with reference to the accompanying drawings. Therefore, the content in the foregoing can be used in the subsequent embodiments, and the repeated content will not be described herein.

[0478] FIG. 28 is an exemplary block diagram of a network element discovery apparatus 2800 provided by the embodiments of the present application, which can correspond to the functions or steps implemented by any one of the first network element to the seventh network element in the above-mentioned method embodiments. The network element discovery apparatus 2800 can include a storage unit 2801, a transceiver unit 2802, and a processing unit 2803. The storage unit 2801 can be used to store instructions (codes or programs) and / or data. The transceiver unit 2802 and the processing unit 2803 can be coupled with the storage unit 2801, for example, the transceiver unit 2802 can read the instructions (codes or programs) and / or data in the storage unit to implement the corresponding method. The above-mentioned units can be independently arranged, or partially or entirely integrated.

[0479] In a possible implementation, the network element discovery apparatus 2800 can correspond to the method flowcharts shown in any one of FIG. 8, FIG. 10-FIG. 13, FIG. 15-FIG. 16, FIG. 18-FIG. 19, FIG. 21-FIG. 27. The network element discovery apparatus 2800 can perform the actions performed by any one of the network elements in FIG. 8, FIG. 10-FIG. 13, FIG. 15-FIG. 16, FIG. 18-FIG. 19, FIG. 21-FIG. 27. For more detailed step descriptions performed by the network element discovery apparatus 2800, reference can be made to the related descriptions in the method embodiments shown in FIG. 8, FIG. 10-FIG. 13, FIG. 15-FIG. 16, FIG. 18-FIG. 19, FIG. 21-FIG. 27, which will not be repeated here.

[0480] It should be noted that the division of the units in the embodiments of the present application is illustrative, and is only a logical function division. In actual implementation, another division manner can be used. The functional units in the embodiments of the present application can be integrated in one processing unit, or each unit can be physically present independently, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0481] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such an understanding, the technical solutions of the present application essentially or the part of the prior art that contributes to the present application or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0482] It should be understood that the processing unit 2803 in the embodiments of the present application can be implemented by a processor or a processor-related circuit component, and the transceiving unit 2802 can be implemented by a transceiver or a transceiver-related circuit component or a communication interface. For example, the network element discovery device in the above-described embodiments can also adopt the form shown in FIG. 29. As shown in the device 2900 in FIG. 29, the device 2900 includes at least one processor 2910, a memory 2920, and a communication interface 2930.

[0483] The specific connection medium between the processor 2910 and the memory 2920 in the embodiments of the present application is not limited.

[0484] In the device as shown in FIG. 29, the processor 2910 can perform signal transmission through the communication interface 2930 when communicating with other devices.

[0485] When the network element discovery device adopts the form shown in FIG. 29, the processor 2910 in FIG. 29 can invoke the computer execution instructions stored in the memory 2920, so that the device 2900 can perform the method performed by the network element discovery device in any of the above method embodiments.

[0486] The embodiments of the present application also provide a chip system, which includes a processor for invoking a computer program or computer instructions stored in a memory, so that the processor executes the method of any of the above embodiments.

[0487] In a possible implementation, the processor is coupled with the memory through an interface.

[0488] In a possible implementation, the chip system further includes a memory in which a computer program or computer instructions are stored.

[0489] The embodiments of the present application also relate to a processor configured to invoke a computer program or computer instructions stored in a memory to cause the processor to perform the method of any of the embodiments described above.

[0490] It should be apparent that the embodiments of the present application can be embodied in a method, system, or computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable program code.

[0491] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks and / or flowchart flow or flows and / or block or blocks of the block diagram.

[0492] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks and / or flowchart flow or flows and / or block or blocks of the block diagram.

[0493] Obviously, numerous modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the claims and their equivalents, the present application can be practiced otherwise than as specifically described.

Claims

1. A method of network element discovery, the method comprising: The method applied to a second network element comprises: receiving a first request message from a first network element, the first request message being used for requesting an address of a third network element, the first request message carrying performance requirements of a first service API, and an identity of the first service API and / or a type of the first service API; sending, to the first network element, an address of a target third network element; the target third network element being capable of providing the first service API, and a calling performance of a network API associated with the first service API being capable of meeting the performance requirements of the first service API.

2. The method of claim 1, wherein, The method further comprises: receiving information of at least one third network element; the target third network element being one of the at least one third network element; the information of the third network element comprising at least one of the following: a service API supported by the third network element, an address of the third network element, a type of the third network element, an identity of the third network element, a deployment location of the third network element, or a service area of the third network element.

3. The method of claim 2, wherein, The method further comprises: sending, to the at least one third network element, a third request message; the third request message being used for requesting a judgment on whether the at least one third network element meets the performance requirements of the first service API, the third request message carrying the performance requirements of the first service API, and the identity of the first service API and / or the type of the first service API; receiving a response message of the third request message sent by the at least one third network element, the response message indicating whether the performance requirements of the first service API are met; determining the target third network element according to the response message.

4. The method of claim 2, wherein, The method further comprises: sending, to a fourth network element, a third request message; the third request message being used for requesting a judgment on whether the at least one third network element meets the performance requirements of the first service API, the third request message carrying the performance requirements of the first service API, and the identity of the first service API and / or the type of the first service API; receiving a response message of the third request message sent by the fourth network element, the response message indicating whether the performance requirements of the first service API are met; determining the target third network element according to the response message.

5. The method of claim 2, wherein, The information of the third network element further comprises a calling performance of the third network element for the first service API.

6. The method according to any one of claims 1 to 5, characterized in that, The first request message further carries a type of the third network element requested by the first network element and location information of the first network element.

7. The method according to any one of claims 1 to 6, characterized in that, The method further comprises: receiving a fifth request message from the target third network element, the fifth request message being used for requesting a target instance of the network API, the fifth request message carrying the performance requirements of the first service API, and the identity of the first service API and / or the type of the first service API; determining the target instance of the network API according to a stored mapping relationship between the first service API and the network API, the performance requirements, and a calling performance of at least one instance of the network API; sending, to the target third network element, an address of the target instance.

8. A network element discovery method, characterized by, The method is applied to a target third network element, and the method comprises: receiving a second request message from a first network element; the second request message requests to invoke a first service API; wherein the second request message carries a performance requirement of the first service API, and an identifier of the first service API and / or a type of the first service API; determining a target instance of a network API corresponding to the first service API, and invoking the network API of the target instance; wherein an invocation performance of the network API of the target instance is capable of meeting the performance requirement of the first service API.

9. The method of claim 8, wherein, The method further comprises: sending an invocation result of the first service API; the invocation result of the first service API is determined according to an invocation result of the network API.

10. The method according to claim 8 or 9, characterized in that, The method further comprises: sending information of the target third network element to a second network element; wherein the information of the target third network element comprises at least one of the following: a service API supported by the target third network element, an address of the target third network element, a type of the target third network element, an identifier of the target third network element, a deployment position of the target third network element, or a service area of the target third network element.

11. The method according to claim 8 or 9, characterized in that, The method further comprises: receiving a third request message from the second network element; the third request message is used to request to judge whether the target third network element meets the performance requirement of the first service API, and the third request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API; sending a fourth request message to a fourth network element; the fourth request message is used to request an address, an identifier and / or a type of at least one instance of the network API meeting the performance requirement of the first service API; when receiving the address, the identifier and / or the type of the at least one instance from the fourth network element, sending a response message of the third request message to the second network element; the response message indicates that the target third network element meets the performance requirement of the first service API.

12. The method of claim 11, wherein, The fourth request message carries the performance requirement of the first service API; or the fourth request message carries a performance requirement of the network API, and the performance requirement of the network API is obtained by dividing the performance requirement of the first service API.

13. The method of claim 10, wherein, The information reported by the target third network element further comprises an invocation performance of the target third network element for the first service API.

14. The method according to any one of claims 8-13, characterized in that, The determination of the target instance of the network API corresponding to the first service API specifically comprises: determining the target instance from at least one instance according to a stored mapping relationship between the first service API and the network API, the performance requirement and the invocation performance of the at least one instance; or sending a fifth request message to the second network element; the fifth request message is used to request an instance of the network API, and the fifth request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API; receive, from the second network element, an address of the target instance.

15. A network element discovery method, characterized by, The method is applied to a first network element, and the method comprises: sending, to a second network element, a first request message, the first request message being used to request an address of a third network element, the first request message carrying a performance requirement of a first service application program interface (API), and an identifier of the first service API and / or a type of the first service API; receiving, from the second network element, an address of a target third network element; the target third network element is capable of providing the first service API for the first network element, and the target third network element meets the performance requirement of the first service API.

16. The method of claim 15, wherein, The method further comprises: sending, to the target third network element, a second request message based on the address of the target third network element, the second request message being used to request an invocation of the first service API; wherein the second request message carries the performance requirement of the first service API, and the identifier of the first service API and / or the type of the first service API.

17. The method of claim 16, wherein, The method further comprises: obtaining an invocation result of the first service API; the first service API is associated with a network API, and the invocation result of the first service API is determined according to an invocation result of the network API.

18. The method according to any one of claims 15-17, characterized by, The first request message further carries a type of the third network element requested by the first network element, and / or location information of the first network element.

19. The method according to any one of claims 15-18, characterized in that, The third network element is an API exposure function network element (AEF) or a border API exposure function network element (border AEF), the second network element is a CAPIF core function network element (CCF), and the fourth network element is an API publishing function entity (APF).

20. A network element discovery apparatus, characterized by: The device is applied to a second network element, or the device is the second network element, and the device comprises a storage unit and a transceiver unit: The storage unit is configured to store computer program instructions. The transceiver unit is configured to receive, from a first network element, a first request message based on the computer program instructions, the first request message being used to request an address of a third network element, the first request message carrying a performance requirement of a first service API and an identifier of the first service API and / or a type of the first service API. The transceiver unit is further configured to send, to the first network element, an address of a target third network element, the target third network element being capable of providing the first service API, the first service API being associated with a network API, and an invocation performance of the network API being capable of meeting the performance requirement of the first service API.

21. A network element discovery apparatus, characterized by: The device is applied to a target third network element, or the device is the target third network element, and the device comprises: a transceiver unit configured to receive, from a first network element, a second request message; the second request message requesting an invocation of a first service API; wherein the second request message carries a performance requirement of the first service API, and an identifier of the first service API and / or a type of the first service API. The processing unit is configured to determine a target instance of a network API corresponding to the first service API, and invoke the network API of the target instance; wherein the invocation performance of the network API of the target instance can meet the performance requirement of the first service API.

22. A network element discovery apparatus, characterized by: The device is applied to a first network element, or the device is the first network element, and the device comprises a storage unit and a transceiver unit: The storage unit is configured to store computer program instructions. The transceiver unit is configured to send a first request message to a second network element based on the computer program instructions, the first request message being used to request an address of a third network element, the first request message carrying a performance requirement of a first service application program interface (API), and an identifier of the first service API and / or a type of the first service API. The transceiver unit is further configured to receive an address of a target third network element from the second network element. The target third network element can provide the first service API for the first network element, and the target third network element meets the performance requirement of the first service API.

23. A network element discovery system, characterized by The system comprises the network element discovery device of claim 20, the network element discovery device of claim 21, and the network element discovery device of claim 22.

24. An electronic device, comprising: The electronic device stores computer programs or instructions, and when the instructions run on a computer, the method of any one of claims 1-7, 8-14, or 15-19 is implemented.

25. A chip system, characterized by The electronic device comprises a communication interface and a processor: The communication interface is configured to input and / or output signaling or data. The processor is configured to execute computer executable programs, so that the device installed with the chip system executes the method of any one of claims 1-7, 8-14, or 15-19.

26. A computer readable storage medium, characterized in that, The computer readable storage medium stores computer programs or instructions, and when the instructions run on a computer, the method of any one of claims 1-7, 8-14, or 15-19 is implemented.

27. A computer program product, characterised in that, The computer program code makes the computer execute the method of any one of claims 1-7, 8-14, or 15-19 when the computer program code runs on the computer.

Images