用于服务API发布的方法、网络实体和介质

本申请是于2020年11月20日向国际局提交、并于2022年7月29日进入中国国家阶段的申请号为No.202080095200.3、发明名称为“用于服务API发布的方法和网络实体”的PCT发明专利申请的分案申请。

技术领域

本公开涉及通信技术，并且更具体地，涉及用于服务应用编程接口(API)发布的方法和网络实体。

背景技术

随着对第三代合作伙伴计划(3GPP)开发北向API的兴趣日益增长，通用API框架(CAPIF)允许跨多个工作组的北向API的一致开发，即，允许定义北向API以向第三方应用抽象或暴露底层3GPP网络能力。CAPIF提供了针对北向API的关于API注册、认证、发现、日志记录和计费的通用框架。

在3GPP版本16中，CAPIF利用不同CAPIF提供商域之间的互连或相同CAPIF提供商域内的互连来增强。图1示出了针对CAPIF互连的架构模型，其允许CAPIF提供商的API调用器利用来自第三方CAPIF提供商的服务API。图2示出了针对相同CAPIF提供商域内的CAPIF互连的架构模型，其允许CAPIF核心功能(CCF)1的API调用器利用来自CCF 2的服务API，其中，两个CCF都托管在CAPIF提供商A的信任域内。图1中，两个CCF经由CAPIF-6e接口(参考点)彼此连接；而在图2中，两个CCF经由CAPIF-6接口(参考点)彼此连接。CAPIF-6/6e接口支持发布和发现服务API信息。对于服务API发布，API发布功能(APF)(其使API提供商能够向CCF发布服务API信息，以使服务API能够由API调用器发现)或CCF可以在API发布请求或互连API发布请求中指示可共享信息，该信息指示服务API是否可以共享，并且如果可以共享，则指示与哪些CAPIF提供商域共享。对于这些和其他功能实体、接口(参考点)、API发布请求和响应、以及互连API发布请求和响应的进一步细节，可以参考3GPP技术规范(TS)23.222V16.6.0，其全部内容通过引用合并于此。

发明内容

本公开的目的是提供一种用于服务API发布的方法和网络实体。

根据本公开的第一方面，提供了一种第一网络实体中用于服务API发布的方法。该方法包括：从第二网络实体接收用于发布服务API的第一API发布请求，该第一API发布请求包含已发布服务API的网络实体的标识符的列表；并且该方法还包括：当第一网络实体的标识符包括在列表中时，向第二网络实体发送指示服务API发布失败的API发布响应，而不在第一网络实体处针对服务API创建新的资源或进一步向任何网络实体发布服务API，或者当第一网络实体的标识符不包括在第一列表中时，向第三网络实体发送用于发布服务API的第二API发布请求，该第二API发布请求包含通过将第一网络实体的标识符添加到第一列表来获得的网络实体的标识符的第二列表。

在实施例中，可以响应于确定第三网络实体的标识符不包括在第一列表中来发送第二API发布请求。

在实施例中，该方法还可以包括，当第一网络实体的标识符不包含在第一列表中时：在第一网络实体处针对服务API创建新的资源；以及向第二网络实体发送API发布响应，该API发布响应指示服务API发布成功并包含所创建的新的资源的标识符。

在实施例中，第一网络实体、第二网络实体、第三网络实体、以及已发布服务API的网络实体中的每一个可以是CCF实体。

在实施例中，第一网络实体、第二网络实体、第三网络实体、以及已发布服务API的网络实体可以全部都在单个CAPIF提供商域中。

根据本公开的第三方面，提供了一种第一网络实体中用于服务API发布的方法。该方法包括：从功能实体接收用于发布服务API的第一API发布请求；以及向第二网络实体发送用于发布所述API的第二API发布请求，该第二API发布请求包含第一网络实体的标识符。

在实施例中，第一网络实体和第二网络实体中的每一个都可以是CCF实体，并且功能实体可以是APF实体。

在实施例中，第一网络实体和第二网络实体两者可以都在单个CAPIF提供商域中。

根据本公开的第四方面，提供了一种第一网络实体。第一网络实体包括通信接口、处理器和存储器。存储器存储可由处理器执行的指令，从而第一网络实体操作用于执行根据上述第一、第二和/或第三方面的方法。

根据本公开的第五方面，提供了一种计算机可读存储介质。该计算机可读存储介质上存储有计算机程序指令。该计算机程序指令在由第一网络实体中的处理器执行时，使第一网络实体执行根据上述第一、第二和/或第三方面的方法。

根据本公开的第六方面，提供了一种通信系统。该通信系统包括APF实体和多个CCF实体。APF实体被配置为向多个CCF实体中的一个发送用于发布服务API的API发布请求。多个CCF实体中的每一个被配置为执行根据上述第一、第二和/或第三方面的方法。

通过本公开的实施例，在接收用于发布服务API的API发布请求时，网络实体可以确定其标识符是否包括在已发布服务API的网络实体的标识符的列表(如果包含在API发布请求中)中。当其标识符包括在列表中时，该网络实体将以指示服务API发布失败的结果进行响应，而不针对服务API创建新的资源或进一步向任何网络实体发布服务API。另一方面，只有当其标识符不包括在列表中时，CCF实体才将会针对服务API创建新的资源和/或向另一网络实体发送用于发布服务API的另一API发布请求。该另一API发布请求可以包含已发布服务API的网络实体的标识符的更新列表，该列表添加有该网络实体的标识符。这样，该网络实体可以避免针对相同的服务API创建冗余资源，并且可以防止用于发布服务API的循环。

附图说明

根据以下参考附图对实施例的描述，以上及其他目的、特征和优点将更清楚，在附图中：

图1是示出了用于跨不同CAPIF提供商域的CAPIF互连的架构模型的示意图；

图2是示出了用于一个CAPIF提供商域内的CAPIF互连的架构模型的示意图；

图3是示出了用于发布服务API的循环的示例的示意图；

图4是示出了根据本公开的实施例的用于服务API发布的方法的流程图；

图5是示出了根据本公开的另一实施例的用于服务API发布的方法的流程图；

图6是示出了根据本公开的实施例的用于服务API发布的示例性过程的序列图；

图7是根据本公开的实施例的网络实体的框图；以及

图8是根据本公开的另一实施例的网络实体的框图。

具体实施方式

说明书中对“一个实施例”、“实施例”、“示例实施例”等的引用指示所描述的实施例可以包括特定特征、结构或特性，但是不一定每个实施例都包括该特定特征、结构或特性。此外，这些短语不必指相同实施例。此外，当结合实施例描述具体特征、结构或特性时，应认为结合其他实施例(不管是否是显式描述的)来实现这种特征、结构或特性是在本领域技术人员的知识内的。

应理解的是，尽管术语“第一”和“第二”等可以在本文中用于描述各种元素，但是这些元素不应受这些术语的限制。这些术语仅用来将元件彼此区分。例如，不脱离示例实施例的范围，第一元素可以被称为第二元素，并且类似地，第二元素可以被称为第一元素。如本文中使用的，术语“和/或”包括相关列出项中的一个或多个的任意和所有组合。

本文使用的术语仅仅用于描述特定实施例的目的，而不旨在限制示例实施例。如本文使用的，单数形式“一”，“一个”和“所述”意在还包括复数形式，除非上下文明确地给出相反的指示。将进一步理解的是，当在本文中使用时，术语“包括(comprises)”“包括(comprising)”、“具有(has)”、“具有(having)”、“包括(includes)”和/或“包括(including)”指明所陈述的特征、元素和/或组件等的存在，但不排除存在或添加一个或多个其它特征、元素、组件和/或其组合。

在下面的描述和权利要求中，除非另外定义，否则本文中所使用的所有技术和科学术语具有与本公开所属领域的普通技术人员通常理解的含义相同的含义。

对于经由CAPIF-6/6e接口的服务API发布，如图3所示，API可能首先从CCF 1发布到CCF 2，然后从CCF 2发布到CCF 3，然后从CCF 3发布回CCF 1。在这种情况下，除了在API最初例如从APF发布时CCF 1已创建的服务API资源之外，CCF 1还将针对API创建新的服务API资源。因此，CCF 1将具有由相同API占用的冗余资源。更严重的是，CCF 1可以向CCF 2再次发布API，然后CCF 2可以向CCF 3发布API，依此类推，导致服务API发布的循环。

图4是示出了根据本公开的实施例的用于服务API发布的方法400的流程图。方法400可以在第一网络实体(例如，CCF实体)处执行。

在框410处，从第二网络实体(例如，CCF实体)接收用于发布服务API的第一API发布请求。第一API发布请求包含已发布服务API的网络实体(例如，CCF实体)的标识符的第一列表。在这种上下文中，该列表也可以被称为“发布的API路径”，或简称为“API路径”。

这里，第一API发布请求可以是TS 23.222的第8.25.2节中规定的互连API发布请求。TS 23.222的表8.25.2.1-1定义了互连API发布请求中的信元(IE)，其再现为下面的表1：

表1：互连API发布请求

以上表8.25.2.1-1中的服务API信息在TS 29.222V16.1.0的表8.2.4.2.2-1中详细地定义，其可以改变为包括API路径，如下面表2所示：

表2：类型ServiceAPIDescription的定义

属性“pubApiPath”包含已发布API的CCF实体的标识符。例如，数据类型“PublishedApiPath”可以在下面的表3中定义：

表3：类型PublishedApiPath的定义

表1中的其他IE和表2中的其他属性的进一步细节可以分别参考TS 23.222的表8.25.2.1-1和TS 29.222的表8.2.4.2.2-1，并且这里将省略其细节。

当第一网络实体的标识符包括在第一列表中时，在框420处，向第二网络实体发送指示服务API发布失败的API发布响应，而不在第一网络实体处针对服务API创建新的资源或进一步向任何网络实体发布服务API。即，当第一网络标识的标识符包括在API路径中时，意味着第一API发布请求中发布的服务API是第一实体已发布的服务API。在这种情况下，第一网络实体将不针对相同的服务API创建任何新的资源或进一步向任何网络实体发布服务API，从而避免资源浪费和针对API发布的循环。这里，API发布响应可以是如TS 23.222的第8.25.2.2节中规定的互连API发布响应。

另一方面，当第一网络实体的标识符不包括在第一列表中时，在框430处，向第三网络实体(例如，CCF实体)发送用于发布服务API的第二API发布请求。第二API发布请求包含通过将第一网络实体的标识符添加到第一列表来获得的网络实体的标识符的第二列表。

在示例中，在框430中，可以响应于确定第三网络实体的标识符不包括在第一列表中来发送第二API发布请求。换句话说，如果第一网络实体知道第三网络实体的标识符并确定第三网络实体的标识符包括在第一列表中，意味着服务API是第三实体已发布的服务API，则第一网络实体可以不发送第二API发布请求以不进一步向第三网络实体发布相同的服务API，从而避免资源浪费和API发布的循环。

此外，当第一网络实体的标识符不包括在第一列表中时，第一网络实体可以在第一网络实体处针对服务API创建新的资源；以及向第二网络实体发送API发布响应，该API发布响应指示服务API发布成功并包含所创建的新的资源的标识符。这里，API发布响应可以是如TS 23.222的第8.25.2.2节中规定的互连API发布响应。

在示例中，第一网络实体、第二网络实体、第三网络实体、以及已发布服务API的网络实体可以全部在单个CAPIF提供商域中。在另一示例中，这些网络实体可以属于不同的CAPIF提供商域。

在一实施方式中，方法400可以仅包括框410和框420。在另一实施方式中，方法400可以仅包括框410和框430。在又一实施方式中，方法400可以包括框410、框420和框430。

图5是示出了根据本公开的实施例的用于服务API发布的方法500的流程图。方法500可以在第一网络实体(例如，CCF实体)处执行。

在框510处，从功能实体(例如，APF实体)接收用于发布服务API的第一API发布请求。第一API发布请求可以是例如TS 23.222的第8.3.2.1节中规定的服务API发布请求。

在框520处，例如，响应于不包含API路径的第一API发布请求，向第二网络实体(例如，CCF实体)发送用于发布API的第二API发布请求。第二API发布请求包含例如在API路径中的第一网络实体的标识符。第二API发布请求可以是根据表1的互连API发布请求并且包含根据表2的“pubApiPath”。

这里，由于第一API发布请求不包含API路径，第一网络实体可以在第一网络实体处针对服务API创建新的资源，并向功能实体发送API发布响应，该API发布响应指示服务API发布成功并包含所创建的新的资源的标识符。这里，API发布响应可以是如TS 23.222的第8.3.2.2节中规定的服务API发布响应。

在示例中，第一网络实体和第二网络实体两者都可以在单个CAPIF提供商域中。在另一示例中，这些网络实体可以属于不同的CAPIF提供商域。

图6是示出了根据本公开的实施例的用于服务API发布的示例性过程的序列图。该过程可以在至少包括APF实体和多个CCF实体(例如，CCF1、CCF2和CCF3)的通信系统中执行。

在6.1处，APF实体向CCF1发送用于发布服务API的服务API发布请求。由于来自APF实体的服务API发布请求不包含API路径，因此在6.2处，CCF1针对服务API创建新的资源，并向APF实体发送服务API发布响应，该服务API发布响应指示服务API发布成功，并包含所创建的新的资源的标识符。在6.3处，如果服务API要与CCF2共享(取决于服务API发布请求中的可共享信息)，CCF1向CCF2发送用于发布服务API的互连API发布请求，该互连API发布请求包含API路径，该API路径包括CCF1的标识符。在接收互连API发布请求后，CCF2检查API路径，并确定CCF2的标识符不包括在API路径中。因此，在6.4处，CCF2针对服务API创建新的资源，并向CCF1发送互连API发布响应，该互连API发布响应指示服务API发布成功并包含所创建的新的资源的标识符。如果服务API要与CCF3共享(取决于来自CCF1的互连API发布请求中的可共享信息)，如果CCF2已知CCF3的标识符，则CCF2可以首先确定CCF3的标识符是否包括在API路径中。如果CCF3的标识符已知且不包括在API路径中，或者如果CCF2不知道CCF3的标识符，则在6.5处，CCF2向CCF3发送用于发布服务API的互连API发布请求，该互连API发布请求包含API路径，该API路径包括CCF1和CCF2的标识符。在接收互连API发布请求后，CCF3检查API路径，并确定CCF3的标识符不包括在API路径中。因此，在6.6处，CCF3针对服务API创建新的资源，并向CCF2发送互连API发布响应，该互连API发布响应指示服务API发布成功并包含所创建的新的资源的标识符。

如果要与CCF1共享服务API(取决于来自CCF2的互连API发布请求中的可共享信息)，如果CCF3已知CCF1的标识符，则CCF3可以首先确定CCF1的标识符是否包括在API路径中。如果CCF1的标识符已知并包括在API路径中，则CCF3将不进一步将服务API发布回CCF1，因此将不存在循环。然而，如果CCF3不知道CCF1的标识符，则在6.7处，CCF3向CCF1发送用于发布服务API的互连API发布请求，该互连API发布请求包含API路径，该API路径包括CCF1、CCF2和CCF3的标识符。在接收互连API发布请求后，CCF1检查API路径，并确定CCF1的标识符包括在API路径中。因此，在6.8处，CCF1向CCF3发送指示服务API发布失败的互连API发布响应，而不在CCF1处针对服务API创建新的资源或进一步向任何网络实体发布服务API。在这种情况下，将不存在用于发布服务API的循环。

与如上所述的方法400或500相对应，提供了第一网络实体。图7是根据本公开的实施例的第一网络实体700的框图。

第一网络实体700可以操作用于执行如图4所示的方法400。如上面结合方法400所讨论的，在一实施方式中，第一网络实体700可以操作用于仅执行方法400中的框410和框420。在另一实施方式中，第一网络实体700可以操作用于仅执行方法400中的框410和框430。在又一实施方式中，第一网络实体700可以操作用于执行方法400中的框410、框420和框430。

如图7所示，第一网络实体700包括接收单元710，该接收单元710被配置为从第二网络实体接收用于发布服务API的第一API发布请求，该第一API发布请求包含已发布服务API的网络实体的标识符的第一列表。

第一网络实体700还包括发送单元720，该发送单元720被配置为当第一网络实体的标识符包括在第一列表中时，向第二网络实体发送指示服务API发布失败的API发布响应。在这种情况下，第一网络实体700将不在第一网络实体处针对服务API创建新的资源或进一步向任何网络实体发布服务API。

备选地或附加地，发送单元720可以被配置为当第一网络实体的标识符不包括在第一列表中时，向第三网络实体发送用于发布服务API的第二API发布请求，该第二API发布请求包含通过将第一网络实体的标识符添加到第一列表来获得的网络实体的标识符的第二列表。在这种情况下，可以响应于确定第三网络实体的标识符不包括在第一列表中来发送第二API发布请求。第一网络实体700还可以包括创建单元，该创建单元被配置为在第一网络实体处针对服务API创建新的资源，并且发送单元720还可以被配置为向第二网络实体发送API发布响应，该API发布响应指示服务API发布成功并包含所创建的新的资源的标识符。

在实施例中，第一网络实体、第二网络实体、第三网络实体以及已发布服务API的网络实体中的每一个都可以是CCF实体。

在实施例中，第一网络实体、第二网络实体、第三网络实体、以及已发布服务API的网络实体可以全部都在单个CAPIF提供商域中。

备选地，网络实体700可以操作用于执行如图5所示的方法500。如图7所示，网络实体700包括接收单元710，该接收单元710被配置为从功能实体接收用于发布服务API的第一API发布请求。网络实体700还包括发送单元720，该发送单元720被配置为向第二网络实体发送用于发布API的第二API发布请求，第二API发布请求包含第一网络实体的标识符。

在实施例中，第一网络实体和第二网络实体中的每一个都可以是CCF实体，并且功能实体可以是APF实体。

在实施例中，第一网络实体和第二网络实体两者都可以在单个CAPIF提供商域中。

单元710和单元720可以例如通过以下各项中的一项或多项实现为纯硬件解决方案或软件和硬件的组合：处理器或微处理器和适合的软件以及用于存储该软件的存储器、被配置为执行上述以及例如在图4或图5中示出的动作的可编程逻辑器件(PLD)或其他电子组件或处理电路。

图8是根据本公开的另一实施例的第一网络实体800的框图。

第一网络实体800包括通信接口810、处理器820和存储器830。存储器830可以包含可由处理器820执行的指令，从而第一网络实体800操作用于执行例如前面结合图4描述的过程的动作。如上面结合方法400所讨论的，在一实施方式中，第一网络实体800可以操作用于仅执行方法400中的框410和框420。在另一实施方式中，第一网络实体800可以操作用于仅执行方法400中的框410和框430。在又一实施方式中，第一网络实体800可以操作用于执行方法400中的框410、框420和框430。

具体地，存储器830包含可由处理器820执行的指令，从而第一网络实体800操作用于从第二网络实体接收用于发布服务API的第一API发布请求，该第一API发布请求包含已发布服务API的网络实体的标识符的第一列表。

存储器830还可以包含可由处理器820执行的指令，由此第一网络实体800操作用于当第一网络实体的标识符包括在第一列表中时，向第二网络实体发送指示服务API发布失败的API发布响应，而不在第一网络实体处针对服务API创建新的资源或进一步向任何网络实体发布服务API。

备选地或附加地，存储器830还可以包含可由处理器820执行的指令，从而第一网络实体800操作用于当第一网络实体的标识符不包括在第一列表中时，向第三网络实体发送用于发布服务API的第二API发布请求，该第二API发布请求包含通过将第一网络实体的标识符添加到第一列表来获得的网络实体的标识符的第二列表。在实施例中，可以响应于确定第三网络实体的标识符不包括在第一列表中来发送第二API发布请求。在实施例中，存储器830还可以包含可由处理器820执行的指令，由此当第一网络实体的标识符不包括在第一列表中时，第一网络实体800操作用于：在第一网络实体处针对服务API创建新的资源；以及向第二网络实体发送API发布响应，该API发布响应指示服务API发布成功并包含所创建的新的资源的标识符。

在实施例中，第一网络实体、第二网络实体、第三网络实体以及已发布服务API的网络实体中的每一个都可以是CCF实体。

在实施例中，第一网络实体、第二网络实体、第三网络实体、以及已发布服务API的网络实体可以全部都在单个CAPIF提供商域中。

备选地，存储器830可以包含可由处理器820执行的指令，从而第一网络实体800操作用于执行例如前面结合图5描述的过程的动作。具体地，存储器830包含由处理器820可执行的指令，从而第一网络实体800操作用于从功能实体接收用于发布服务API的第一API发布请求；以及向第二网络实体发送用于发布该API的第二API发布请求，该第二API发布请求包含第一网络实体的标识符。

在实施例中，第一网络实体和第二网络实体中的每一个都可以是CCF实体，并且功能实体可以是APF实体。

在实施例中，第一网络实体和第二网络实体两者都可以在单个CAPIF提供商域中。

本公开还提供了非易失性或易失性存储器(例如，非暂时性计算机可读存储介质、电可擦除可编程只读存储器(EEPROM)、闪存和硬盘驱动器)的形式的至少一个计算机程序产品。计算机程序产品包括计算机程序。计算机程序包括：代码/计算机可读指令，其在由处理器820执行时使网络实体800执行例如前面结合图4或图5描述的过程的动作。

计算机程序产品可以被配置为以计算机程序模块构造的计算机程序代码。计算机程序模块可以基本上执行图4或图5所示流程的动作。

处理器可以是单个CPU(中央处理单元)，但是还可以包括两个或更多个处理单元。例如，处理器可以包括通用微处理器；指令集处理器和/或相关芯片集和/或专用微处理器，例如专用集成电路(ASIC)。处理器还可以包括用于高速缓存目的的板载存储器。计算机程序可以由与处理器连接的计算机程序产品来承载。计算机程序产品可以包括存储计算机程序的非暂时性计算机可读存储介质。例如，计算机程序产品可以是闪存、随机存取存储器(RAM)、只读存储器(ROM)或EEPROM，并且上述计算机程序模块在备选实施例中可以分布在存储器形式的不同计算机程序产品上。

以上已经参考其实施例描述了本公开。应当理解，在不脱离本公开的精神和范围的情况下，本领域技术人员可以进行各种修改、替换和添加。因此，本公开的范围不限于上述特定实施例，而是仅由所附权利要求限定。