Patent Description:
With the growing interest in the <NUM>rd Generation Partnership Project (3GPP) to develop northbound APIs, a Common API Framework (CAPIF) allows for a consistent development of northbound APIs across multiple working groups, i.e., for defining northbound APIs to abstract or expose the underlying 3GPP network capabilities to the <NUM>rd party applications. The CAPIF offers a common framework for northbound APIs with respect to API registration, authentication, discovery, logging, and charging.

In the 3GPP Release <NUM>, the CAPIF is enhanced with interconnection between different CAPIF provider domains or within the same CAPIF provider domain. <FIG> shows an architectural model for the CAPIF interconnection which allows API invokers of a CAPIF provider to utilize service APIs from the <NUM>rd party CAPIF provider. <FIG> shows an architectural model for the CAPIF interconnection within the same CAPIF provider domain, which allows API invokers of CAPIF Core Function (CCF) <NUM> to utilize service APIs from CCF <NUM>, where both CCFs are hosted within the trust domain of the CAPIF provider A. In <FIG>, the two CCFs are connected with each other via a CAPIF-6e interface (reference point); while in <FIG>, the two CCFs are connected with each other via a CAPIF-<NUM> interface (reference point). The CAPIF-<NUM>/6e interface supports publishing and discovering service API information. For service API publishing, the API Publishing Function (APF) (which enables the API provider to publish service API information to the CCF in order to enable discovery of service APIs by API invokers) or CCF can indicate Shareable Information in an API publish request or interconnection API publish request, such information indicates whether the service API can be shared and if shared, shared with which CAPIF provider domains. For further details of these and other functional entities, interfaces (reference points), API publish request and response, and interconnection API publish request and response, reference can be made to 3GPP Technical Specification (TS) <NUM>, V16. Said document 3GPP TS <NUM> V16. <NUM> discloses the architecture, procedures and information flows necessary for the CAPIF. Aspects of this document include identifying architecture requirements for the CAPIF (e.g. registration, discovery, identity management) that are applicable to any service APIs when used by northbound entities, as well as any interactions between the CAPIF and the service APIs themselves. The common API framework applies to both EPS and 5GS, and is independent of the underlying 3GPP access (e.g. E-UTRA, NR).

Document "API publish and API discover for CAPIF interconnection", Huawei et. , 3GPP change request, S6-<NUM>, discloses details on the CAPIF interconnection functional model. Regarding CAPIF-<NUM> between the CAPIF instances in the same trust domain, the service API publish and service API discovery should be supported. Regarding CAPIF-6e between the CAPIF instances in the different trust domain, the service API publish should be supported. Compared with API publish from API publish function to CCF, the API published between two CCFs may be the high level information such as API type, rather than the details of the service API especially the CCFs belonging to different trust domain. Corresponding to the API publish for CCF interconnection, a CCF may get the CCF identity which publishes the high level information of service APIs rather than the details of service APIs.

It is an object of the present disclosure to provide a method and a network entity for service API publishing.

According to the present disclosure, there are provided methods, a first network entity and a computer-readable storage medium according to the independent claims. Further developments are set forth in the dependent claims.

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, from a second network entity, a first API publish request for publishing a service API, the first API publish request containing a list of identifiers of network entities that have published the service API; and transmitting, when an identifier of the first network entity is included in the list, an API publish response indicating failure of publishing of the service API to the second network entity.

Preferably, the second API publish request is transmitted in response to determining that an identifier of the third network entity is not included in the first list.

Preferably, the method further includes, when 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; and transmitting, to the second network entity, an API publish response indicating success of publishing of the service API and containing an identifier of the created new resource.

Preferably, each of the first network entity, the second network entity, the third network entity, and the network entities that have published the service API is a CCF entity.

Preferably, the first network entity, the second network entity, the third network entity, and the network entities that have published the service API all are in one single CAPIF provider domain.

According to a second aspect of the present disclosure, a method in a first network entity for service API publishing is provided. The method includes: receiving, from a second network entity, a first API publish request for publishing a service API, the first API publish request containing a first list of identifiers of network entities that have published the service API; and when an 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.

According to a third aspect of the present disclosure, a first network entity is provided. The first network entity includes a communication interface, a processor and a memory. The memory stores instructions executable by the processor whereby the first network entity is operative to perform the method according to the above first and/or second aspect.

According to a fourth aspect of the present disclosure, a computer readable storage medium is provided. The computer readable storage medium has computer program instructions stored thereon. The computer program instructions, when executed by a processor in a first network entity, cause the first network entity to perform the method according to the above first and/or second aspect.

With the embodiments of the present disclosure, upon receiving an API publish request for publishing a service API, a network entity can determine whether its identifier is included in a list of identifiers of network entities that have published the service API (if contained in the API publish request). When its identifier is included in the list, the network entity will respond with a result indicating failure of publishing of the service API, without creating a new resource for the service API or further publishing the service API to any network entity. On the other hand, only when its identifier is not included in the list, the CCF entity will create a new resource for the service API and/or transmit a further API publish request for publishing the service API to another network entity. The further API publish request can contain an updated list of identifiers of network entities that have published 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 can prevent a loop for publishing the serving API.

Hereinabove and in the following, "examples" pertain to principles underlying the claimed subject-matter and/or being useful for understanding the claimed subject-matter, while "embodiments" pertain to the claimed subject-matter within the claim scope. The above and other objects, features and advantages will be more apparent from the following description of embodiments with reference to the figures, in which:.

Whenever in the following disclosure the term "embodiment" occurs, reference is to be made to the figure description above to clarify whether an embodiment or an example is meant.

For service API publishing via CAPIF-<NUM>/6e interfaces, as shown in <FIG>, it is possible that an API is first published from CCF <NUM> to CCF <NUM>, then from CCF <NUM> to CCF <NUM>, and then from CCF <NUM> back to CCF <NUM>. In this case, CCF <NUM> will create a new service API resource for the API, in addition to the service API resource it has created when the API is initially published, e.g., from an APF. Thus, CCF <NUM> will have redundant resources occupied by the same API. More seriously, CCF <NUM> may again publish the API to CCF <NUM>, which then may publish the API to CCF <NUM>, and so on and so forth, resulting in a loop of service API publishing.

<FIG> is a flowchart illustrating a method <NUM> for service API publishing according to an embodiment of the present disclosure. The method <NUM> can be performed at a first network entity, e.g., a CCF entity.

At block <NUM>, a first API publish request for publishing a service API is received from a second network entity (e.g., a CCF entity). The first API publish request contains a first list of identifiers of network entities (e.g., CCF entities) that have published the service API. In this context, the list can also be referred to as a "published API path", or "API path" for short.

Here, the first API publish request can be an interconnection API publish request as specified in Section <NUM>. <NUM> of TS <NUM>. Table <NUM>. <NUM>-<NUM> of TS <NUM> defines Information Elements (IEs) in the interconnection API publish request, which is reproduced as Table <NUM> below:.

The service API information in the above Table <NUM>. <NUM>-<NUM> is defined in detail in Table <NUM>. <NUM>-<NUM> of TS <NUM> V16. <NUM>, which can be changed to include the API path, as shown in Table <NUM> below:.

The attribute "pubApiPath" contains identifiers of CCF entities that have published the API. For example, the data type "PublishedApiPath" can be defined in Table <NUM> below:.

For further details of other IEs in Table <NUM> and other attributes in Table <NUM>, reference can be made to Table <NUM>. <NUM>-<NUM> of TS <NUM> and Table <NUM>. <NUM>-<NUM> of TS <NUM>, respectively, and details thereof will be omitted here.

When an identifier of the first network entity is included in the first list, at block <NUM>, an API publish response indicating failure of publishing of the service API is transmitted to the second network entity, without creating a new resource for the service API at the first network entity or further publishing the service API to any network entity. That is, when the identifier of the first network identity is included the API path, it means that the service API published in the first API publish request is a service API the first entity has published. In this case, the first network entity will not create any new resource for the same service API or further publish the service API to any network entity, thereby avoiding a waste of resources and a loop for API publishing. Here, the API publish response can be an interconnection API publish response as specified in Section <NUM>. <NUM> of TS <NUM>.

On the other hand, when the identifier of the first network entity is not included in the first list, at block <NUM>, a second API publish request for publishing the service API is transmitted to a third network entity (e.g., a CCF entity). The second API publish request contains a second list of identifiers of network entities obtained by adding the identifier of the first network entity to the first list.

In an example, in the block <NUM>, the second API publish request can be transmitted in response to determining that an identifier of the third network entity is not included in the first list. 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, meaning that the service API is a service API the third entity has published, the first network entity may not transmit the second API publish request to further publish the same service API to the third network entity, thereby avoiding a waste of resources and a loop for API publishing.

Further, when the identifier of the first network entity is not included in the first list, the first network entity can create a new resource for the service API at the first network entity; and transmit, to the second network entity, an API publish response indicating success of publishing of the service API and containing an identifier of the created new resource. Here, the API publish response can be an interconnection API publish response as specified in Section <NUM>. <NUM> of TS <NUM>.

In an example, the first network entity, the second network entity, the third network entity, and the network entities that have published the service API may all be in one single CAPIF provider domain. In another example, these network entities may belong to different CAPIF provider domains.

In an implementation, the method <NUM> may include only the blocks <NUM> and <NUM>. In another implementation, the method <NUM> may include only the blocks <NUM> and <NUM>. In yet another implementation, the method <NUM> may include the blocks <NUM>, <NUM> and <NUM>.

At block <NUM>, a first API publish request for publishing a service API is received from a function entity (e.g., an APF entity). The first API publish request can be e.g., a service API publish request as specified in Section <NUM>. <NUM> of TS <NUM>.

At block <NUM>, a second API publish request for publishing the API is transmitted to a second network entity (e.g., a CCF entity), e.g., in response to the first API publish request containing no API path. The second API publish request contains an identifier of the first network entity, e.g., in an API path. The second API publish request can be an interconnection API publish request according to Table <NUM> and contain "pubApiPath" according to Table <NUM>.

Here, as the first API publish request contains no API path, the first network entity can create a new resource for the service API at the first network entity, and transmit, to the function entity, an API publish response indicating success of publishing of the service API and containing an identifier of the created new resource. Here, the API publish response can be a service API publish response as specified in Section <NUM>. <NUM> of TS <NUM>.

In an example, the first network entity and the second network entity can be both in one single CAPIF provider domain. In another example, these network entities may belong to different CAPIF provider domains.

<FIG> is a sequence diagram showing an exemplary process for service API publishing according to an embodiment of the present disclosure. The process can be performed in a communication system including at least an APF entity and a plurality of CCF entities (e.g., CCF1, CCF2, and CCF3).

At <NUM>, the APF entity transmits a service API publish request for publishing a service API to CCF1. As the service API publish request from the APF entity contains no API path, CCF1 creates a new resource for the service API and transmits a service API publish response indicating success of publishing of the service API and containing an identifier of the created new resource to the APF entity at <NUM>. At <NUM>, if the service API is to be shared with CCF2 (depending on Sharable Information in the service API publish request), CCF1 transmits an interconnection API publish request for publishing the service API to CCF2, containing an API path including an identifier of CCF1. Upon receiving the interconnection API publish request, CCF2 checks the API path and determines that an identifier of CCF2 is not included in the API path. Accordingly, CCF2 creates a new resource for the service API and transmits an interconnection API publish response indicating success of publishing of the service API and containing an identifier of the created new resource to CCF1 at <NUM>. If the service API is to be shared with CCF3 (depending on Sharable Information in the interconnection API publish request from CCF1), CCF2 may first determine whether an identifier of CCF3 is included in the API path, if it is known to CCF2. If the identifier of CCF3 is known and not included in the API path, or if the identifier of CCF3 is unknown to CCF2, at <NUM>, CCF2 transmits an interconnection API publish request for publishing the service API to CCF3, containing an API path including the identifiers of CCF1 and CCF2. Upon receiving the interconnection API publish request, CCF3 checks the API path and determines that the identifier of CCF3 is not included in the API path. Accordingly, CCF3 creates a new resource for the service API and transmits an interconnection API publish response indicating success of publishing of the service API and containing an identifier of the created new resource to CCF2 at <NUM>.

If the service API is to be shared with CCF1 (depending on Sharable Information in the interconnection API publish request from CCF2), CCF3 may first determine whether the identifier of CCF1 is included in the API path, if it is known to CCF3. If the identifier of CCF1 is known and included in the API path, CCF3 will not further publish the service API back to CCF1 and there will be no loop accordingly. However, if the identifier of CCF1 is unknown to CCF3, at <NUM>, CCF3 transmits an interconnection API publish request for publishing the service API to CCF1, containing an API path including the identifiers of CCF1, CCF2, and CCF3. Upon receiving the interconnection API publish request, CCF1 checks the API path and determines that the identifier of CCF1 is included in the API path. Accordingly, CCF1 transmits an interconnection API publish response indicating failure of publishing of the service API to CCF3 at <NUM>, without creating a new resource for the service API at CCF1 or further publishing the service API to any network entity. In this case, there will be no loop for publishing the service API.

Correspondingly to the method <NUM> or <NUM> as described above, a first network entity is provided. <FIG> is a block diagram of a first network entity <NUM> according to an embodiment of the present disclosure.

The first network entity <NUM> can be operative to perform the method <NUM> as shown in <FIG>. As discussed above in connection with the method <NUM>, in an implementation, the first network entity <NUM> can be operative to perform only the blocks <NUM> and <NUM> in the method <NUM>. In another implementation, the first network entity <NUM> can be operative to perform only the blocks <NUM> and <NUM> in the method <NUM>. In yet another implementation, the first network entity <NUM> can be operative to perform the blocks <NUM>, <NUM> and <NUM> in the method <NUM>.

As shown in <FIG>, the first network entity <NUM> includes a receiving unit <NUM> configured to receive, from a second network entity, a first API publish request for publishing a service API, the first API publish request containing a first list of identifiers of network entities that have published the service API.

The first network entity <NUM> further includes a transmitting unit <NUM> configured to transmit, when an identifier of the first network entity is included in the first list, an API publish response indicating failure of publishing of the service API to the second network entity. In this case, the first network entity <NUM> will not create a new resource for the service API at the first network entity or further publish the service API to any network entity.

Alternatively or additionally, the transmitting unit <NUM> can be configured to transmit, when an identifier of the first network entity is not included in the first list, a second API publish request for publishing the service API to a third network entity, the second API publish request containing a second list of identifiers of network entities obtained by adding the identifier of the first network entity to the first list. In this case, the second API publish request may be transmitted in response to determining that an identifier of the third network entity is not included in the first list. The first network entity <NUM> can further include a creating unit configured to create a new resource for the service API at the first network entity, and the transmitting unit <NUM> can be further configured to transmit, to the second network entity, an API publish response indicating success of publishing of the service API and containing an identifier of the created new resource.

In an embodiment, each of the first network entity, the second network entity, the third network entity, and the network entities that have published the service API may be a CCF entity.

In an embodiment, the first network entity, the second network entity, the third network entity, and the network entities that have published the service API may all be in one single CAPIF provider domain.

Alternatively, the network entity <NUM> can be operative to perform the method <NUM> as shown in <FIG>. As shown in <FIG>, the network entity <NUM> includes a receiving unit <NUM> configured to receive, from a function entity, a first API publish request for publishing a service API. The network entity <NUM> further includes a transmitting unit <NUM> configured to transmit a second API publish request for publishing the API to a second network entity, the second API publish request containing an identifier of the first network entity.

In an embodiment, each of the first network entity and the second network entity may be a CCF entity, and the function entity may be an APF entity.

In an embodiment, the first network entity and the second network entity may both be in one single CAPIF provider domain.

The units <NUM> and <NUM> can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component(s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in <FIG> or <FIG>.

<FIG> is a block diagram of a first network entity <NUM> according to another embodiment of the present disclosure.

The first network entity <NUM> includes a communication interface <NUM>, a processor <NUM> and a memory <NUM>. The memory <NUM> may contain instructions executable by the processor <NUM> whereby the first network entity <NUM> is operative to perform the actions, e.g., of the procedure described earlier in conjunction with <FIG>. As discussed above in connection with the method <NUM>, in an implementation, the first network entity <NUM> can be operative to perform only the blocks <NUM> and <NUM> in the method <NUM>. In another implementation, the first network entity <NUM> can be operative to perform only the blocks <NUM> and <NUM> in the method <NUM>. In yet another implementation, the first network entity <NUM> can be operative to perform the blocks <NUM>, <NUM> and <NUM> in the method <NUM>.

Particularly, the memory <NUM> contains instructions executable by the processor <NUM> whereby the first network entity <NUM> is operative to receive, from a second network entity, a first API publish request for publishing a service API, the first API publish request containing a first list of identifiers of network entities that have published the service API.

The memory <NUM> may further contain instructions executable by the processor <NUM> whereby the first network entity <NUM> is operative to transmit, when an identifier of the first network entity is included in the first list, an API publish response indicating failure of publishing of the service API to the second network entity, without creating a new resource for the service API at the first network entity or further publishing the service API to any network entity.

Alternatively or additionally, the memory <NUM> may further contain instructions executable by the processor <NUM> whereby the first network entity <NUM> is operative to transmit, when an identifier of the first network entity is not included in the first list, a second API publish request for publishing the service API to a third network entity, the second API publish request containing a second list of identifiers of network entities obtained by adding the identifier of the first network entity to the first list. In an embodiment, the second API publish request may be transmitted in response to determining that an identifier of the third network entity is not included in the first list. In an embodiment, the memory <NUM> may further contain instructions executable by the processor <NUM> whereby the first network entity <NUM> is operative to, when the identifier of the first network entity is not included in the first list: create a new resource for the service API at the first network entity; and transmit, to the second network entity, an API publish response indicating success of publishing of the service API and containing an identifier of the created new resource.

Alternatively, the memory <NUM> may contain instructions executable by the processor <NUM> whereby the first network entity <NUM> is operative to perform the actions, e.g., of the procedure described earlier in conjunction with <FIG>. Particularly, the memory <NUM> contains instructions executable by the processor <NUM> whereby the first network entity <NUM> is operative to receive, from a function entity, a first API publish request for publishing a service API; and transmit a second API publish request for publishing the API to a second network entity, the second API publish request containing an identifier of the first network entity.

The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, e.g., a non-transitory computer readable storage medium, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a flash memory and a hard drive. The computer program product includes a computer program. The computer program includes: code/computer readable instructions, which when executed by the processor <NUM> causes the network entity <NUM> to perform the actions, e.g., of the procedure described earlier in conjunction with <FIG> or <FIG>.

The computer program product may be configured as a computer program code structured in computer program modules. The computer program modules could essentially perform the actions of the flow illustrated in <FIG> or <FIG>.

Claim 1:
A method (<NUM>) in a first network entity for service Application Programming Interface, API, publishing, comprising:
receiving (<NUM>), from a second network entity, a first API publish request for publishing a service API, the first API publish request containing a list of identifiers of network entities that have published the service API; and
transmitting (<NUM>), when an identifier of the first network entity is included in the list, an API publish response indicating failure of publishing of the service API to the second network entity.