METHOD AND NETWORK ENTITY FOR SERVICE API ISSUANCE - Patent application

Abstract

To provide a method (400) at a first network entity for issuing a service application programming interface (API).SOLUTION: A method (400) includes receiving (410) an API issuance request for issuing a service API, including a list of identifiers of network entities that have issued the service API, from a second network entity; and, if the identifier of a first network entity is included in the list, transmitting (420) an API issuance response indicating failure to issue the service API to the second network entity, without generating a new resource for the service API at the first network entity and without issuing the service API to any network entity.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present disclosure relates to communication technologies, and more particularly, to a method and network entity for service application programming interface (API) publishing. [Background technology]

[0002] With the growing interest in the 3rd Generation Partnership Project (3GPP) to develop northbound APIs, the Common API Framework (CAPIF) enables consistent development of northbound APIs across multiple working groups, i.e., defines northbound APIs to expose or abstract underlying 3GPP network functions to third-party applications. CAPIF provides a common framework for northbound APIs with respect to API registration, authentication, discovery, logging, and accounting.

[0003] In 3GPP Release 16, CAPIF is extended by interconnection between different CAPIF provider domains or within the same CAPIF provider domain. Figure 1 shows an architecture model of CAPIF interconnection, allowing API callers of a CAPIF provider to utilize service APIs from third-party CAPIF providers. Figure 2 shows an architecture model of CAPIF interconnection within the same CAPIF provider domain, whereby API callers of CAPIF Core Function (CCF) 1 can utilize service APIs from CCF 2, both CCFs hosted within the trust domain of CAPIF provider A. In Figure 1, the two CCFs are interconnected via a CAPIF-6e interface (reference point), whereas in Figure 2, the two CCFs are interconnected via a CAPIF-6 interface (reference point). The CAPIF-6 / 6e interface supports publishing and discovering service API information. In the case of service API publication, the API Publication Function (APF) (which allows API providers to publish service API information to the CCF to enable discovery of the service API by API callers) or the CCF may indicate shareable information in the API Publication Request or Interconnection API Publication Request, such information indicating whether the service API can be shared and, if so, with which CAPIF provider domains. For details of these and other functional entities, interfaces (reference points), API Publication Requests and Responses, and Interconnection API Publication Requests and Responses, reference may be made to 3GPP® Technical Specification (TS) 23.222, V16.6.0, which is incorporated herein by reference in its entirety. Summary of the Invention [Problem to be solved by the invention]

[0004] An object of the present disclosure is to provide a method and a network entity for service API publishing. [Means for solving the problem]

[0005] According to a first aspect of the present disclosure, a method in a first network entity for service API publishing is provided, the method includes: receiving a first API publishing request for publishing a service API from a second network entity, the first API publishing request including a list of identifiers of network entities that published the service API, the method further includes: if the identifier of the first network entity is included in the list, sending an API publishing response to the second network entity indicating failure of publishing the service API without creating a new resource for the service API at the first network entity and without publishing the service API to any network entity, and if the identifier of the first network entity is not included in the list, sending a second API publishing request to a third network entity for publishing the service API, the second API publishing request including a second list of identifiers of network entities obtained by adding the identifier of the first network entity to the first list.

[0006] In one embodiment, the second API issuance request may be sent in response to determining that the identifier of the third network entity is not included in the first list.

[0007] In one embodiment, the method further includes creating a new resource for the service API at the first network entity if the identifier of the first network entity is not included in the first list, and sending an API issuance response to the second network entity indicating successful issuance of the service API and including an identifier of the new resource created.

[0008] In one embodiment, each of the first network entity, the second network entity, the third network entity and the network entity that issued the service API may be a CCF entity.

[0009] In one embodiment, the first network entity, the second network entity, the third network entity and the network entity that issued the service API may all be within a single CAPIF provider domain.

[0010] According to a third aspect of the present disclosure, a method in a first network entity for service API publishing is provided, the method including: receiving, from a function entity, a first API publishing request for publishing a service API; and sending, to a second network entity, a second API publishing request for publishing the API, where the second API publishing request includes an identifier of the first network entity.

[0011] In one embodiment, each of the first network entity and the second network entity may be a CCF entity, and the functional entity may be an APF entity.

[0012] In one embodiment, the first network entity and the second network entity may both be within a single CAPIF provider domain.

[0013] According to a fourth aspect of the present disclosure there is provided a first network entity comprising a communications interface, a processor and a memory, the memory storing instructions executable by the processor such that the first network entity is operative to perform a method according to the first, second and / or third aspects.

[0014] According to a fifth aspect of the present disclosure there is provided a computer readable storage medium storing computer program instructions which, when executed by a processor of a first network entity, cause the first network entity to perform a method according to the first, second and / or third aspect.

[0015] According to a sixth aspect of the present disclosure, there is provided a communication system, comprising: an APF entity and a plurality of CCF entities, the APF entity configured to send an API issuing request for issuing a service API to one of the plurality of CCF entities, each of the plurality of CCF entities configured to perform a method according to the first aspect, the second aspect and / or the third aspect.

[0016] According to an embodiment of the present disclosure, upon receiving an API issuance request for issuing a service API, the network entity can determine whether the identifier is included in a list of identifiers of network entities that issued the service API (included in the API issuance request). If the identifier is included in the list, the network entity responds with a result indicating failure of issuing the service API without creating new resources for the service API and without issuing the service API to any network entity. On the other hand, only if the identifier is not included in the list, the CCF entity sends a further API issuance request to create new resources for the service API and / or issue the service API to another network entity. The further API issuance request may include an updated list of identifiers of network entities that issued the service API, with the identifier of the network entity added to the list. In this way, the network entity can avoid creating redundant resources for the same service API and prevent loops for issuing serving APIs.

[0017] The above and other objects, features and advantages will become apparent from the following detailed description of the embodiments with reference to the accompanying drawings. [Brief description of the drawings]

[0018] [Figure 1] Schematic diagram showing an architectural model of CAPIF interconnection between different CAPIF provider domains. [Diagram 2] Schematic diagram showing an architectural model of CAPIF interconnection within one CAPIF provider domain. [Diagram 3] FIG. 13 is a schematic diagram showing an example of a service API issuance loop. [Figure 4] 1 is a flow chart illustrating a service API publishing method according to an embodiment of the present disclosure. [Diagram 5] 11 is a flowchart illustrating a service API publishing method according to another embodiment of the present disclosure. [Figure 6] 4 is a sequence diagram illustrating an example process of service API publishing according to an embodiment of the present disclosure. [Figure 7] 2 is a block diagram of a network entity according to one embodiment of the present disclosure. [Figure 8] 4 is a block diagram of a network entity according to another embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] References herein to "one embodiment," "embodiment," "exemplary embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, implementing such feature, structure, or characteristic in connection with other embodiments is presented as being within the knowledge of one of ordinary skill in the art, whether or not explicitly stated.

[0020] As used herein, terms such as "first" and "second" may be used to describe various elements, but it should be understood that these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element can be referred to as a second element, and similarly, a second element can be referred to as a first element, without departing from the scope of the example embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms.

[0021] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. The singular forms are intended to include the plural forms unless the context clearly indicates otherwise. As used herein, the terms "including," "having," "comprising," and the like specify the presence of stated features, elements, and / or components, but do not exclude the presence of one or more other features, elements, components, and / or combinations thereof.

[0022] In the following description and claims, unless defined otherwise, all technical and scientific terms used have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0023] As shown in Figure 3, in the case of service API issuance via CAPIF-6 / 6e interface, an API may be first issued from CCF1 to CCF2, then from CCF2 to CCF3, and then from CCF3 to CCF1. In this case, CCF1 creates a new service API resource for the API in addition to the service API resource it created when the API was originally issued, for example, from the APF. This way, CCF1 has redundant resources occupied by the same API. More seriously, CCF1 may issue the API again to CCF2, which issues the API to CCF3, and so on, resulting in a service API issuance loop.

[0024] 4 is a flow chart illustrating a method 400 for service API publishing according to an embodiment of the present disclosure. The method 400 may be performed by a first network entity, for example, a CCF entity.

[0025] At block 410, a first API publishing request for publishing a service API is received from a second network entity (e.g., a CCF entity). The first API publishing request includes a first list of identifiers of the network entities (e.g., CCF entities) that published the service API. In this context, the list may also be referred to as "published API paths" or "API paths" for short.

[0026] Here, the first API issuance request may be an interconnection API issuance request as specified in section 8.25.2 of TS 23.222. Table 8.25.2.1-1 of TS 23.222 defines information elements (IEs) of the interconnection API issuance request, and is listed as Table 1 below.

[0027] [Table 1]

[0028] The service API information in Table 8.25.2.1-1 above is defined in detail in Table 8.2.4.2.2-1 of TS 29.222, V16.1.0, and may be modified to include the API path as shown in Table 2 below.

[0029] [Table 2]

[0030] The attribute "pubApiPath" contains the identifier of the CCF entity that published the API. For example, the data type "PublishedApiPath" may be defined in Table 3 below.

[0031] [Table 3]

[0032] For details of other IEs in Table 1 and other attributes in Table 2, please refer to Table 8.25.2.1-1 in TS23.222 and Table 8.2.4.2.2-1 in TS29.222, respectively, and they are omitted here.

[0033] If the identifier of the first network entity is included in the first list, in block 420, an API issuance response indicating failure of the service API issuance is sent to the second network entity without generating new resources for the service API in the first network entity and without further issuing the service API to any network entity. That is, when the identifier of the first network entity is included in the API path, it means that the service API issued in the first API issuance request is the service API issued by the first entity. In this case, the first network entity does not create new resources for the same service API or further issue the service API to any network entity, so that resource waste and API issuance loop can be avoided. Here, the API issuance response can be an interconnection API issuance response specified in section 8.25.2.2 of TS 23.222.

[0034] On the other hand, if the identifier of the first network entity is not included in the first list, a second API issuance request for issuing the service API is sent to a third network entity (e.g., a CCF entity) in block 430. The second API issuance request includes a second list of identifiers of the network entities obtained by adding the identifier of the first network entity to the first list.

[0035] In one example, the second API issuance request may be sent in response to determining that the identifier of the third network entity is not included in the first list in block 430. In other words, if the first network entity knows the identifier of the third network entity and determines that the identifier of the third network entity is included in the first list, it means that the service API is a service API issued by the third entity, and the first network entity does not send a second API issuance request to further issue the same service API to the third network entity, thereby avoiding resource waste and API issuance loops.

[0036] Further, if the identifier of the first network entity is not included in the first list, the first network entity may create a new resource for the service API at the first network entity and send an API publication response to the second network entity indicating successful publication of the service API and including the identifier of the new resource created, where the API publication response may be an interconnection API publication response as specified in section 8.25.2.2 of TS 23.222.

[0037] In one example, the first network entity, the second network entity, the third network entity, and the network entity that issued the service API may all be within a single CAPIF provider domain, while in another example, these network entities may belong to different CAPIF provider domains.

[0038] In one implementation, the method 400 may include only blocks 410 and 420. In another implementation, the method 400 may include only blocks 410 and 430. In yet another implementation, the method 400 may include blocks 410, 420, and 430.

[0039] 5 is a flow chart illustrating a method 500 for service API publishing according to an embodiment of the present disclosure. The method 500 may be performed by a first network entity, for example, a CCF entity.

[0040] In block 510, a first API issuance request for issuing a service API is received from a functional entity (e.g., an APF entity). The first API issuance request may be a service API issuance request as specified in section 8.3.2.1 of TS 23.222.

[0041] In block 520, a second API publishing request for publishing the API is sent to a second network entity (e.g., a CCF entity), e.g., in response to the first API publishing request that does not include an API path. The second API publishing request includes, e.g., an identifier of the first network entity in the API path. The second API publishing request may be an interconnection API publishing request according to Table 1 and may include a “pubApiPath” according to Table 2.

[0042] Here, since the first API issuance request does not include an API path, the first network entity can create a new resource for the service API at the first network entity, and send an API issuance response to the functional entity indicating successful issuance of the service API and including an identifier of the created new resource, where the API issuance response can be a service API issuance response specified in section 8.3.2.2 of TS 23.222.

[0043] In one example, the first network entity and the second network entity may both be within a single CAPIF provider domain, while in another example, these network entities may belong to different CAPIF provider domains.

[0044] 6 is a sequence diagram illustrating an exemplary process for service API issuance according to an embodiment of the present disclosure. The process may be performed in a communication system including at least an APF entity and multiple CCF entities (e.g., CCF1, CCF2, and CCF3).

[0045] In 6.1, the APF entity sends a service API issuance request to CCF1 to issue the service API. Because the service API issuance request from the APF entity does not include an API path, CCF1 creates a new resource for the service API and sends a service API issuance response indicating success of the issuance of the service API and including an identifier of the new resource created to the APF entity in 6.2. In 6.3, if the service API is shared with CCF2 (according to the shareable information of the service API issuance request), CCF1 sends an interconnection API issuance request to CCF2 to issue the service API, including an API path including an identifier of CCF1. Upon receiving the interconnection API issuance request, CCF2 checks the API path and determines that the identifier of CCF2 is not included in the API path. In response, CCF2 creates a new resource for the service API and sends an interconnection API issuance response indicating success of the issuance of the service API and including an identifier of the new resource created to CCF1 in 6.4. When sharing a service API with CCF3 (in response to the sharable information of the interconnection API issuance request from CCF1), CCF2 may first determine whether the identifier of CCF3 is included in the API path if it knows the identifier of CCF3. If it knows the identifier of CCF3 but it is not included in the API path, or if CCF2 does not know the identifier of CCF3, CCF2 sends an interconnection API issuance request to issue the service API to CCF3, which includes an API path including the identifiers of CCF1 and CCF2, at 6.5. Upon receiving the interconnection API issuance request, CCF3 checks the API path and determines that the identifier of CCF3 is not included in the API path. In response, CCF3 creates a new resource for the service API and sends an interconnection API issuance response to CCF2, at 6.6, indicating the success of the issuance of the service API and including the identifier of the new resource created.

[0046] When sharing a service API with CCF1 (in response to the sharable information of the interconnection API issuance request from CCF2), CCF3 may first determine whether the identifier of CCF1 is included in the API path if it knows the identifier of CCF1. If the identifier of CCF1 is known and included in the API path, CCF3 will not further issue the service API to CCF1, so there is no loop. However, if the identifier of CCF1 is not known by CCF3, CCF3 will send an interconnection API issuance request to issue the service API to CCF1 in 6.7, which includes an API path including the identifiers of CCF1, CCF2, and CCF3. Upon receiving the interconnection API issuance request, CCF1 will check the API path and determine that the identifier of CCF1 is included in the API path. Therefore, CCF1 will send an interconnection API issuance response indicating failure of issuance of the service API in 6.8, without creating a new resource for the service API in CCF1 and without further issuing the service API to any network entity. In this case, there is no service API issuance loop.

[0047] A first network entity is provided corresponding to the above-described method 400 or 500. Figure 7 is a block diagram of a first network entity 700 according to an embodiment of the present disclosure.

[0048] The first network entity 700 may be operable to perform the method 400, as shown in Figure 4. As described above with respect to the method 400, in an implementation, the first network entity 700 may be operable to perform only blocks 410 and 420 of the method 400. In another implementation, the first network entity 700 may be operable to perform only blocks 410 and 430 of the method 400. In yet another implementation, the first network entity 700 may be operable to perform blocks 410, 420, and 430 of the method 400.

[0049] As shown in FIG. 7, the first network entity 700 includes a receiving unit 710 configured to receive a first API issuance request for issuing a service API from a second network entity, where the first API issuance request includes a first list of identifiers of network entities that have issued the service API.

[0050] The first network entity 700 further includes a sending unit 720 configured to send an API issuance response to the second network entity, indicating failure of the issuance of the service API, if the identifier of the first network entity is included in the first list, in which case the first network entity 700 will not create a new resource for the service API in the first network entity or further publish the service API to any network entity.

[0051] Alternatively or additionally, if the identifier of the first network entity is not included in the first list, the sending unit 720 may be configured to send a second API issuance request to the third network entity for issuing the service API, the second API issuance request including a second list of identifiers of the network entities obtained by adding the identifier of the first network entity to the first list. In this case, the second API issuance request may be sent in response to determining that the identifier of the third network entity is not included in the first list. The first network entity 700 may further include a creating unit configured to create a new resource for the service API at the first network entity, and the sending unit 720 may be further configured to send an API issuance response to the second network entity indicating successful issuance of the service API and including an identifier of the created new resource.

[0052] In one embodiment, each of the first network entity, the second network entity, the third network entity and the network entity that issued the service API may be a CCF entity.

[0053] In one embodiment, the first network entity, the second network entity, the third network entity and the network entity that issued the service API may all be within a single CAPIF provider domain.

[0054] Alternatively, the network entity 700 may be operable to perform the method 500 as shown in Fig. 5. As shown in Fig. 7, the network entity 700 includes a receiving unit 710 configured to receive a first API issuance request for issuing a service API from a functional entity. The network entity 700 further includes a sending unit 720 configured to send a second API issuance request for issuing the API to a second network entity, where the second API issuance request includes an identifier of the first network entity.

[0055] In one embodiment, each of the first network entity and the second network entity may be a CCF entity, and the functional entity may be an APF entity.

[0056] In one embodiment, the first network entity and the second network entity may both be within a single CAPIF provider domain.

[0057] Units 710 and 720 may be realized as pure hardware, as a combination of software and hardware, for example by means of a processor or microprocessor, appropriate software, memory for storing the software, a programmable logic device (PLD) and / or other electronic components, or as a processing circuit configured to perform the operations described above, for example as shown in FIG. 4 or 5.

[0058] FIG. 8 is a block diagram of a first network entity 800 according to another embodiment of the present disclosure.

[0059] The first network entity 800 comprises a communication interface 810, a processor 820, and a memory 830. The memory 830 includes instructions executable by the processor 820 such that the first network entity 800 operates to perform actions of the procedures described above in relation to FIG. 4, for example. As described above in relation to the method 400, in an implementation the first network entity 800 may operate to perform only blocks 410 and 420 of the method 400. In another implementation the first network entity 800 may operate to perform only blocks 410 and 430 of the method 400. In yet another implementation the first network entity 800 may operate to perform blocks 410, 420, and 430 of the method 400.

[0060] In particular, the memory 830 includes instructions executable by the processor 820 such that the first network entity 800 operates to receive a first API issuance request for issuing a service API from a second network entity, the first API issuance request including a first list of identifiers of the network entities that issued the service API.

[0061] The memory 830 further includes instructions executable by the processor 820 such that, if the identifier of the first network entity 800 is included in the first list, the first network entity 800 operates to send an API issuance response to the second network entity indicating failure to issue the service API without creating a new resource for the service API at the first network entity or further issuing the service API to any network entity.

[0062] Alternatively or additionally, the memory 830 further includes instructions executable by the processor 820 such that, if the identifier of the first network entity is not included in the first list, the first network entity 800 is operative to send a second API issuance request to a third network entity for issuing the service API, the second API issuance request including a second list of identifiers of the network entities obtained by adding the identifier of the first network entity to the first list. In one embodiment, the second API issuance request may be sent in response to determining that the identifier of the third network entity is not included in the first list. In one embodiment, the memory 830 further includes instructions executable by the processor 820 such that, if the identifier of the first network entity is not included in the first list, the first network entity 800 is operative to create a new resource for the service API at the first network entity and send an API issuance response to the second network entity indicating successful issuance of the service API and including an identifier of the new resource created.

[0063] In one embodiment, each of the first network entity, the second network entity, the third network entity and the network entity that issued the service API may be a CCF entity.

[0064] In one embodiment, the first network entity, the second network entity, the third network entity and the network entity that issued the service API may all be within a single CAPIF provider domain.

[0065] Instead, the memory 830 includes instructions executable by the processor 820 such that the first network entity 800 operates to perform actions of a procedure, such as those described above in relation to Figure 5. In particular, the memory 830 includes instructions executable by the processor 820 such that the first network entity 800 operates to receive, from the functional entity, a first API issuance request for issuance of a service API, and to send a second API issuance request to the second network entity for issuance of the API, the second API issuance request including an identifier of the first network entity.

[0066] In one embodiment, each of the first network entity and the second network entity may be a CCF entity, and the functional entity may be an APF entity.

[0067] In one embodiment, the first network entity and the second network entity may both be within a single CAPIF provider domain.

[0068] The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, for example a non-transitory computer readable storage medium, an EEPROM (Electrically Erasable Programmable Read Only Memory), a flash memory, or a hard drive. The computer program product comprises a computer program. The computer program comprises code / computer readable instructions that, when executed by the processor 820, cause the network entity 800 to perform actions of the procedures described above in relation to, for example, FIG. 4 or FIG. 5.

[0069] The computer program product may be configured as a computer program code configured with computer program modules. The computer program modules basically execute the operations of the flow shown in FIG.

[0070] The processor may be a single CPU (Central Processing Unit), but may include two or more processing units. For example, the processor may include a general purpose microprocessor, an instruction set processor, and / or related chipsets, and / or specialized microprocessors such as application specific integrated circuits (ASICs). The processor may include on-board memory for cache purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may include a non-transitory computer readable storage medium that stores the computer program. For example, the computer program product may include a flash memory, a random access memory (RAM), a read only memory (ROM), or an EEPROM, and the computer program modules described above may be distributed in various computer program products of memory type in other embodiments.

[0071] The present disclosure has been described with reference to the embodiments. It should be understood that various modifications, substitutions and additions may be made by those skilled in the art without departing from the scope of the present disclosure. Thus, the scope of the present disclosure is not limited to the specific embodiments described above, but is only defined by the appended claims.

Claims

1. A method (400) in a first network entity for service application programming interface (API) publishing, comprising: receiving (410) a first API publishing request for publishing a service API from a second network entity, the first API publishing request including a first list of identifiers of network entities that published the service API; The method (400) may further comprise: If the identifier of the first network entity is included in the first list, sending (420) an API issuance response to the second network entity indicating failure of the issuance of the service API; and if the identifier of the first network entity is not included in the first list, adding the identifier of the first network entity to the first list to obtain a second list of identifiers of network entities; The method includes:

2. 2. The method (400) of claim 1, further comprising: sending (430) a request to a third network entity, the request including the second list of identifiers of network entities.

3. 3. The method (400) of claim 1 or 2, further comprising: if the identifier of the first network entity is not included in the first list, Creating a new resource for the service API at the first network entity; sending an API issuance response to the second network entity indicating successful issuance of the service API and including an identifier of the new resource created; The method includes:

4. 4. The method (400) of any one of claims 1 to 3, comprising: The method, wherein each of the first network entity, the second network entity, and the network entity that issued the service API is a Common API Framework (CAPIF) Core Functions (CCF) entity.

5. 5. The method (400) of claim 4, comprising: The first network entity, the second network entity, and the network entity that issued the service API are all within a single CAPIF provider domain.

6. A first network entity (800) including a communication interface (810), a processor (820), and a memory (830), The memory (830) includes instructions executable by the processor (820), thereby causing the first network entity (800) to operate to perform a method according to any one of claims 1 to 5.

7. A computer-readable storage medium having computer program instructions stored thereon, comprising: A computer-readable storage medium, the computer program instructions, when executed by a processor of a first network entity, causing the first network entity to perform the method of any one of claims 1 to 5.

Images