CN117857548A - 一种通信方法及装置 - Google Patents

一种通信方法及装置 Download PDF

Info

Publication number
CN117857548A
CN117857548A CN202211215653.2A CN202211215653A CN117857548A CN 117857548 A CN117857548 A CN 117857548A CN 202211215653 A CN202211215653 A CN 202211215653A CN 117857548 A CN117857548 A CN 117857548A
Authority
CN
China
Prior art keywords
api
entity
ccf
request
providing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211215653.2A
Other languages
English (en)
Inventor
张健
杨艳梅
葛翠丽
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202211215653.2A priority Critical patent/CN117857548A/zh
Priority to PCT/CN2023/120184 priority patent/WO2024067313A1/zh
Publication of CN117857548A publication Critical patent/CN117857548A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例公开了一种通信方法和装置,该方法包括:CCF实体接收API调用实体发送的第一请求,所述第一请求包括所述API调用实体请求的第一API;所述CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则所述CCF实体确定请求对所述第一API对应的API提供实体进行实例化。采用本申请实施例,实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。

Description

一种通信方法及装置
技术领域
本申请涉及通信技术领域,尤其涉及一种通信方法及装置。
背景技术
移动边缘计算(mobile edge computing,MEC)又称为多接入边缘计算(multi-access edge computing),可利用无线接入网络就近提供电信用户IT所需服务和云端计算功能,而创造出一个具备高性能、低延迟与高带宽的电信服务环境,加速网络中各项内容、服务及应用的快速下载,让消费者享有不间断的高质量网络体验。
在当前应用服务器的部署架构中,存在将传统的单应用服务器划分为多应用服务器的趋势,从而为提供高安全和大容量的应用服务。当前应用服务器呈虚拟化或云化形式部署,边缘应用服务器(edge application server,EAS)可以作为一个虚拟服务器的实例进行部署,为有效利用边缘网络的计算资源,EAS可以动态的按需部署或实例化。但是,现有技术方案无法充分利用应用编程接口(application program interface,API)提供实体(例如EAS)的资源,导致API提供实体资源的浪费。
发明内容
本申请实施例提供一种通信方法及装置,实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
第一方面,本申请实施例提供了一种通信方法,该方法包括:
通用应用编程接口框架核心功能CCF实体接收应用编程接口API调用实体发送的第一请求,所述第一请求包括所述API调用实体请求的第一API;所述CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则所述CCF实体确定请求对所述第一API对应的API提供实体进行实例化。
CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求网管系统对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
在一种可能的设计中,所述CCF实体向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;所述CCF实体接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述CCF实体向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。以便API调用实体通过第一API的接口信息调用第一API进行服务。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述CCF实体从所述多个API提供实体中选取目标API提供实体;其中,所述第二请求包括所述目标API提供实体的标识,所述第二请求用于请求对所述目标API提供实体进行实例化。
在另一种可能的设计中,所述CCF实体接收网管系统发送的第二API信息,所述第二API信息包括可实例化的API提供实体的API和/或可实例化的API提供实体的API的可用性。
第二方面,本申请实施例提供了一种通信方法,该方法包括:
网管系统接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
所述网管系统对所述第一API对应的API提供实体进行实例化;
所述网管系统向所述CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求网管系统对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述网管系统向所述CCF实体发送第二API信息,所述第二API信息包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述网管系统从所述多个API提供实体中选取目标API提供实体;所述网管系统对所述目标API提供实体进行实例化。避免网管实体对多个API提供实体进行实例化,造成资源浪费。
第三方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体向通用应用编程接口框架核心功能CCF实体发送第一请求,所述第一请求包括所述API调用实体请求的第一API;
所述API调用实体接收所述CCF实体发送的第二响应,所述第二响应包括实例化所述第一API对应的API提供实体后获得的所述第一API的接口信息。
CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求网管系统对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
第四方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体接收通用应用编程接口框架核心功能CCF实体发送的第一响应,所述第一响应包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性;所述API调用实体根据所述可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性,确定所述API调用实体请求的第一API是否可用;若所述第一API不可用,则所述API调用实体确定请求对所述第一API对应的API提供实体进行实例化。
API调用实体接收可实例化的API提供实体的API和/或可实例化的API提供实体的API的可用性之后,确定是否请求对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
在一种可能的设计中,所述API调用实体向所述CCF实体发送第一请求,所述第一请求用于指示在对所述第一API对应的API提供实体进行实例化后可用的所述第一API;所述API调用实体接收所述CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
第五方面,本申请实施例提供了一种通信方法,该方法包括:
通用应用编程接口框架核心功能CCF实体向应用编程接口API调用实体发送第一响应,所述第一响应包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性;所述CCF实体接收所述API调用实体发送的第一请求,所述第一请求用于指示在对所述第一API对应的API提供实体进行实例化后可用的所述第一API。
API调用实体接收可实例化的API提供实体的API和/或可实例化的API提供实体的API的可用性之后,确定是否请求对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
在一种可能的设计中,所述CCF实体向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;所述CCF实体接收所述网管系统的第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述CCF实体从所述多个API提供实体中选取目标API提供实体;其中,所述第二请求包括所述目标API提供实体的标识,所述第二请求用于请求对所述目标API提供实体进行实例化。
在另一种可能的设计中,所述CCF实体向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述CCF实体接收网管系统发送的第一API信息,所述第一API信息包括所述可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
第六方面,本申请实施例提供了一种通信方法,该方法包括:
网管系统接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;所述网管系统对所述第一API对应的API提供实体进行实例化;所述网管系统向所述CCF实体发送第三响应,所述第三响应包括所述第一API的接口信息。
API调用实体接收可实例化的API提供实体的API和/或可实例化的API提供实体的API的可用性之后,确定是否请求对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述网管系统向所述CCF实体发送第一API信息,所述第一API信息包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述网管系统从所述多个API提供实体中选取目标API提供实体;所述网管系统对所述目标API提供实体进行实例化。
第七方面,本申请实施例提供了一种通信方法,该方法包括:
第一通用应用编程接口框架核心功能CCF实体接收第二CCF实体发送的第一请求,所述第一请求包括API调用实体请求的第一API;所述第一CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则所述第一CCF确定请求对所述第一API对应的API提供实体进行实例化。
第二CCF实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
在另一种可能的设计中,所述第一CCF实体向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;所述第一CCF实体接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第一CCF实体向所述第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述第一CCF实体从所述多个API提供实体中选取目标API提供实体;其中,所述第二请求包括所述目标API提供实体的标识,所述第二请求用于请求对所述目标API提供实体进行实例化。
在另一种可能的设计中,所述第一CCF实体接收网管系统发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述第一CCF实体向所述第二CCF实体发送第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
第八方面,本申请实施例提供了一种通信方法,该方法包括:
第二通用应用编程接口框架核心功能CCF实体接收API调用实体发送的第四请求,所述第四请求包括所述API调用实体请求的第一API;
所述第二CCF实体从预先保存的第三API信息中查询所述第一API是否可用,所述第三API信息包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;
若所述第一API不可用,则所述第二CCF实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
第二CCF实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
在另一种可能的设计中,所述第二CCF实体向所述第一CCF实体发送第一请求,所述第一请求包括API调用实体请求的第一API;所述第二CCF实体接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第二CCF实体接收所述第一CCF实体发送的第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述第二CCF实体向所述API调用实体发送第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第二CCF实体接收网管系统发送的第四API信息,所述第四API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
第九方面,本申请实施例提供了一种通信方法,该方法包括:
网管系统接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
所述网管系统对所述第一API对应的API提供实体进行实例化;
所述网管系统向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
第二CCF实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
在另一种可能的设计中,所述网管系统向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述网管系统向所述第二CCF实体发送第四API信息,所述第四API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述网管系统从所述多个API提供实体中选取目标API提供实体;所述网管系统对所述目标API提供实体进行实例化。
第十方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体向第二通用应用编程接口框架核心功能CCF实体发送第四请求,所述第四请求包括所述API调用实体请求的第一API;
所述API调用实体接收所述第二CCF实体发送的第三响应,所述第三响应包括实例化所述第一API对应的API提供实体后获得的所述第一API的接口信息,所述第一API的接口信息用于所述API调用实体调用所述第一API进行服务。
第二CCF实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
第十一方面,本申请实施例提供了一种通信方法,该方法包括:
第一通用应用编程接口框架核心功能CCF实体接收第二CCF实体发送的第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API;所述第一CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则所述第一CCF确定请求对所述第一API对应的API提供实体进行实例化。
API调用实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
在另一种可能的设计中,所述第一CCF实体向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;所述第一CCF实体接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述第一CCF实体从所述多个API提供实体中选取目标API提供实体;其中,所述第二请求包括所述目标API提供实体的标识,所述第二请求用于请求对所述目标API提供实体进行实例化。
在另一种可能的设计中,所述第一CCF实体向第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第一CCF实体接收网管系统发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述第一CCF实体接收所述第二CCF实体发送的第三请求;
所述第一CCF实体向所述第二CCF实体发送第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
第十二方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体接收第二通用应用编程接口框架核心功能CCF实体发送的第四响应,所述第四响应包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;所述API调用实体根据所述多个CCF实体控制范围内的API提供实体的API的可用性,确定所述API调用实体请求的第一API是否可用;若所述第一API不可用,则所述API调用实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
API调用实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
在另一种可能的设计中,所述API调用实体向所述第二CCF实体发送第四请求,所述第四请求包括所述第一CCF实体的标识和所述第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API对应的API提供实体进行实例化;所述API调用实体接收所述第二CCF实体发送的第五响应,所述第五响应包括所述第一API的接口信息。
第十三方面,本申请实施例提供了一种通信方法,该方法包括:
第二通用应用编程接口框架核心功CCF实体接收API调用实体发送的第四请求,所述第四请求包括所述第一CCF实体的标识和应用编程接口API调用实体请求的第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API对应的API提供实体进行实例化;所述第二CCF实体向所述第一CCF实体发送第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API。
API调用实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
在另一种可能的设计中,所述第二CCF实体接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息;所述第二CCF实体向所述API调用实体发送第五响应,所述第五响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第二CCF实体接收网管系统发送的第三API信息,所述第三API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述第二CCF实体向所述第一CCF实体发送第三请求;所述第二CCF实体接收所述第一CCF实体发送的第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述第二CCF实体向所述API调用实体发送第四响应,所述第四响应包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。
第十四方面,本申请实施例提供了一种通信方法,该方法包括:
网管系统接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;所述网管系统对所述第一API对应的API提供实体进行实例化;所述网管系统向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
API调用实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,支持多EAS场景的功能需求,实现充分利用移动边缘网络的计算资源。
在另一种可能的设计中,所述网管系统向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述网管系统向所述第二CCF实体发送第三API信息,所述第三API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,当所述第一API对应的API提供实体包括多个API提供实体时,所述网管系统从所述多个API提供实体中选取目标API提供实体;所述网管系统对所述目标API提供实体进行实例化。
第十五方面,本申请实施例提供了一种通信方法,该方法包括:
通用应用编程接口框架核心功能CCF实体接收应用编程接口API调用实体发送的第一请求,所述第一请求包括所述API调用实体请求的第一API;所述CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则所述CCF实体确定请求对所述第一API进行上线或激活。
CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求第二API提供实体对第一API进行上线或激活。通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述CCF实体向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;所述CCF实体接收所述第二API提供实体发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述CCF实体向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述CCF实体接收第二API提供实体发送的第二API信息,所述第二API信息包括可上线或可激活的API、和/或可上线或可激活的API的可用性。
第十六方面,本申请实施例提供了一种通信方法,该方法包括:
第二API提供实体接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;所述第二API提供实体对所述第一API进行上线或激活;所述第二API提供实体向所述CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第二API提供实体向所述CCF实体发送第二API信息,所述第二API信息包括可上线或可激活的API、和/或可上线或可激活的API的可用性。
CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求第二API提供实体对第一API进行上线或激活。通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
第十七方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体向通用应用编程接口框架核心功能CCF实体发送第一请求,所述第一请求包括所述API调用实体请求的第一API;所述API调用实体接收所述CCF实体发送的第二响应,所述第二响应包括对所述第一API进行上线或激活后获得的所述第一API的接口信息。
CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求第二API提供实体对第一API进行上线或激活。通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
第十八方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体接收通用应用编程接口框架核心功能CCF实体发送的第一响应,所述第一响应包括可上线或可激活的API、和/或可上线或可激活的API的可用性;
所述API调用实体根据所述可上线或可激活的API、和/或所述可上线或可激活的API的可用性,确定所述API调用实体请求的第一API是否可用;
若所述第一API不可用,则所述API调用实体确定请求对所述第一API进行上线或激活。
API调用实体接收可上线或可激活的API、和/或可上线或可激活的API的可用性之后,确定是否请求对第一API进行上线或激活。通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述API调用实体向所述CCF实体发送第一请求,所述第一请求用于指示在对所述第一API进行上线或激活后可用的所述第一API;所述API调用实体接收所述CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
第十九方面,本申请实施例提供了一种通信方法,该方法包括:
通用应用编程接口框架核心功能CCF实体向应用编程接口API调用实体发送第一响应,所述第一响应包括可上线或可激活的API、和/或可上线或可激活的API的可用性;所述CCF实体接收所述API调用实体发送的第一请求,所述第一请求用于指示在对所述第一API进行上线或激活后可用的所述第一API。
API调用实体接收可上线或可激活的API、和/或可上线或可激活的API的可用性之后,确定是否请求对第一API进行上线或激活。通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述CCF实体向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;所述CCF实体接收所述第二API提供实体的第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,所述CCF实体向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述CCF实体接收第二API提供实体发送的第一API信息,所述第一API信息包括所述可上线或可激活的API、和/或所述可上线或可激活的API的可用性。
第二十方面,本申请实施例提供了一种通信方法,该方法包括:
第二API提供实体接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;所述第二API提供实体对所述第一API进行上线或激活;所述第二API提供实体向所述CCF实体发送第三响应,所述第三响应包括所述第一API的接口信息。
API调用实体接收可上线或可激活的API、和/或可上线或可激活的API的可用性之后,确定是否请求对第一API进行上线或激活。通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述第二API提供实体向所述CCF实体发送第一API信息,所述第一API信息包括可上线或可激活的API、和/或可上线或可激活的API的可用性。
第二十一方面,本申请实施例提供了一种通信方法,该方法包括:
第一通用应用编程接口框架核心功能CCF实体接收第二CCF实体发送的第一请求,所述第一请求包括API调用实体请求的第一API;所述第一CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则所述第一CCF确定请求对所述第一API进行上线或激活。
第二CCF实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述第一CCF实体向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;
所述第一CCF实体接收所述第二API提供实体发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第一CCF实体向所述第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第一CCF实体接收第二API提供实体发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,所述第一CCF实体向所述第二CCF实体发送第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
第二十二方面,本申请实施例提供了一种通信方法,该方法包括:
第二通用应用编程接口框架核心功能CCF实体接收API调用实体发送的第四请求,所述第四请求包括所述API调用实体请求的第一API;所述第二CCF实体从预先保存的第三API信息中查询所述第一API是否可用,所述第三API信息包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;若所述第一API不可用,则所述第二CCF实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
第二CCF实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述第二CCF实体向所述第一CCF实体发送第一请求,所述第一请求包括API调用实体请求的第一API;所述第二CCF实体接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第二CCF实体接收所述第一CCF实体发送的第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,所述第二CCF实体向所述API调用实体发送第三响应,所述第三响应包括所述第一API的接口信息。
第二十三方面,本申请实施例提供了一种通信方法,该方法包括:
第二API提供实体接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;所述第二API提供实体对所述第一API进行上线或激活;所述第二API提供实体向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
第二CCF实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述第二API提供实体向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
第二十四方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体向第二通用应用编程接口框架核心功能CCF实体发送第四请求,所述第四请求包括所述API调用实体请求的第一API;
所述API调用实体接收所述第二CCF实体发送的第三响应,所述第三响应包括对所述第一API进行上线或激活后获得的所述第一API的接口信息,所述第一API的接口信息用于所述API调用实体调用所述第一API进行服务。
第二CCF实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
第二十五方面,本申请实施例提供了一种通信方法,该方法包括:
第一通用应用编程接口框架核心功能CCF实体接收第二CCF实体发送的第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API;所述第一CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则所述第一CCF确定请求对所述第一API进行上线或激活。
API调用实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所所述第一CCF实体向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;所述第一CCF实体接收所述第二API提供实体发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所所述第一CCF实体向第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第一CCF实体接收第二API提供实体发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,所述第一CCF实体接收所述第二CCF实体发送的第三请求;所述第一CCF实体向所述第二CCF实体发送第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
第二十六方面,本申请实施例提供了一种通信方法,该方法包括:
应用编程接口API调用实体接收第二通用应用编程接口框架核心功能CCF实体发送的第四响应,所述第四响应包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;所述API调用实体根据所述多个CCF实体控制范围内的API提供实体的API的可用性,确定所述API调用实体请求的第一API是否可用;若所述第一API不可用,则所述API调用实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
API调用实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述API调用实体向所述第二CCF实体发送第四请求,所述第四请求包括所述第一CCF实体的标识和所述第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API进行上线或激活;所述API调用实体接收所述第二CCF实体发送的第五响应,所述第五响应包括所述第一API的接口信息。
第二十七方面,本申请实施例提供了一种通信方法,该方法包括:
第二通用应用编程接口框架核心功CCF实体接收API调用实体发送的第四请求,所述第四请求包括所述第一CCF实体的标识和应用编程接口API调用实体请求的第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API进行上线或激活;所述第二CCF实体向所述第一CCF实体发送第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API。
API调用实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述第二CCF实体接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息;所述第二CCF实体向所述API调用实体发送第五响应,所述第五响应包括所述第一API的接口信息。
在另一种可能的设计中,所述第二CCF实体向所述第一CCF实体发送第三请求;所述第二CCF实体接收所述第一CCF实体发送的第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,所述第二CCF实体向所述API调用实体发送第四响应,所述第四响应包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。
第二十八方面,本申请实施例提供了一种通信方法,该方法包括:
第二API提供实体接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一AP进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;所述第二API提供实体对所述第一API进行上线或激活;所述第二API提供实体向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
API调用实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
在另一种可能的设计中,所述第二API提供实体向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
第二十九方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收应用编程接口API调用实体发送的第一请求,所述第一请求包括所述API调用实体请求的第一API;
处理模块,用于从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则确定请求对所述第一API对应的API提供实体进行实例化。
在另一种可能的设计中,发送模块,用于向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;
所述接收模块,还用于接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收网管系统发送的第二API信息,所述第二API信息包括可实例化的API提供实体的API和/或可实例化的API提供实体的API的可用性。
第三十方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API对应的API提供实体进行实例化;
发送模块,用于向所述CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述CCF实体发送第二API信息,所述第二API信息包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述处理模块,还用于当所述第一API对应的API提供实体包括多个API提供实体时,从所述多个API提供实体中选取目标API提供实体;对所述目标API提供实体进行实例化。
第三十一方面,本申请实施例提供了一种通信装置,所述装置包括:
发送模块,用于向通用应用编程接口框架核心功能CCF实体发送第一请求,所述第一请求包括所述API调用实体请求的第一API;
接收模块,用于接收所述CCF实体发送的第二响应,所述第二响应包括实例化所述第一API对应的API提供实体后获得的所述第一API的接口信息。
第三十二方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收通用应用编程接口框架核心功能CCF实体发送的第一响应,所述第一响应包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性;
处理模块,用于根据所述可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性,确定所述API调用实体请求的第一API是否可用;若所述第一API不可用,则确定请求对所述第一API对应的API提供实体进行实例化。
在另一种可能的设计中,发送模块,用于向所述CCF实体发送第一请求,所述第一请求用于指示在对所述第一API对应的API提供实体进行实例化后可用的所述第一API;
所述接收模块,还用于接收所述CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
第三十三方面,本申请实施例提供了一种通信装置,所述装置包括:
发送模块,用于向应用编程接口API调用实体发送第一响应,所述第一响应包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性;
接收模块,用于接收所述API调用实体发送的第一请求,所述第一请求用于指示在对所述第一API对应的API提供实体进行实例化后可用的所述第一API。
在另一种可能的设计中,发送模块,用于向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;
所述接收模块,还用于接收所述网管系统的第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收网管系统发送的第一API信息,所述第一API信息包括所述可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
第三十四方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API对应的API提供实体进行实例化;
发送模块,用于向所述CCF实体发送第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述CCF实体发送第一API信息,所述第一API信息包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述处理模块,还用于当所述第一API对应的API提供实体包括多个API提供实体时,从所述多个API提供实体中选取目标API提供实体;对所述目标API提供实体进行实例化。
第三十五方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第二CCF实体发送的第一请求,所述第一请求包括API调用实体请求的第一API;
处理模块,用于从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则确定请求对所述第一API对应的API提供实体进行实例化。
在另一种可能的设计中,发送模块,用于向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;
所述接收模块,还用于接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收网管系统发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,发送模块,用于向所述第二CCF实体发送第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
第三十六方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收API调用实体发送的第四请求,所述第四请求包括所述API调用实体请求的第一API;
处理模块,用于从预先保存的第三API信息中查询所述第一API是否可用,所述第三API信息包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;若所述第一API不可用,则从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
在另一种可能的设计中,发送模块,用于向所述第一CCF实体发送第一请求,所述第一请求包括API调用实体请求的第一API;
所述接收模块,还用于接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收所述第一CCF实体发送的第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,发送模块,用于向所述API调用实体发送第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收网管系统发送的第四API信息,所述第四API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
第三十七方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API对应的API提供实体进行实例化;
发送模块,用于向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述发送模块,还用于向所述第二CCF实体发送第四API信息,所述第四API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述处理模块,还用于当所述第一API对应的API提供实体包括多个API提供实体时,从所述多个API提供实体中选取目标API提供实体;对所述目标API提供实体进行实例化。
第三十八方面,本申请实施例提供了一种通信装置,所述装置包括:
发送模块,用于向第二通用应用编程接口框架核心功能CCF实体发送第四请求,所述第四请求包括所述API调用实体请求的第一API;
接收模块,用于接收所述第二CCF实体发送的第三响应,所述第三响应包括实例化所述第一API对应的API提供实体后获得的所述第一API的接口信息,所述第一API的接口信息用于所述API调用实体调用所述第一API进行服务。
第三十九方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第二CCF实体发送的第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API;
处理模块,用于从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则确定请求对所述第一API对应的API提供实体进行实例化。
在另一种可能的设计中,发送模块,用于向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;
所述接收模块,还用于接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收网管系统发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述接收模块,还用于接收所述第二CCF实体发送的第三请求;
发送模块,用于向所述第二CCF实体发送第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
第四十方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第二通用应用编程接口框架核心功能CCF实体发送的第四响应,所述第四响应包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;
处理模块,用于根据所述多个CCF实体控制范围内的API提供实体的API的可用性,确定所述API调用实体请求的第一API是否可用;若所述第一API不可用,则从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
在另一种可能的设计中,发送模块,用于向所述第二CCF实体发送第四请求,所述第四请求包括所述第一CCF实体的标识和所述第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API对应的API提供实体进行实例化;
所述接收模块,还用于接收所述第二CCF实体发送的第五响应,所述第五响应包括所述第一API的接口信息。
第四十一方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收API调用实体发送的第四请求,所述第四请求包括所述第一CCF实体的标识和应用编程接口API调用实体请求的第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API对应的API提供实体进行实例化;
发送模块,用于向所述第一CCF实体发送第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API。
在另一种可能的设计中,接收模块,用于接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息;
发送模块,用于向所述API调用实体发送第五响应,所述第五响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收网管系统发送的第三API信息,所述第三API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述发送模块,还用于向所述第一CCF实体发送第三请求;
所述接收模块,还用于接收所述第一CCF实体发送的第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述发送模块,还用于向所述API调用实体发送第四响应,所述第四响应包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。
第四十二方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API对应的API提供实体进行实例化;
发送模块,用于向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述发送模块,还用于向所述第二CCF实体发送第三API信息,所述第三API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
在另一种可能的设计中,所述处理模块,还用于当所述第一API对应的API提供实体包括多个API提供实体时,从所述多个API提供实体中选取目标API提供实体;对所述目标API提供实体进行实例化。
第四十三方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收应用编程接口API调用实体发送的第一请求,所述第一请求包括所述API调用实体请求的第一API;
处理模块,用于从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则确定请求对所述第一API进行上线或激活。
在另一种可能的设计中,发送模块,用于向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;
所述接收模块,还用于接收所述第二API提供实体发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收第二API提供实体发送的第二API信息,所述第二API信息包括可上线或可激活的API、和/或可上线或可激活的API的可用性。
第四十四方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API进行上线或激活;
发送模块,用于向所述CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述CCF实体发送第二API信息,所述第二API信息包括可上线或可激活的API、和/或可上线或可激活的API的可用性。
第四十五方面,本申请实施例提供了一种通信装置,所述装置包括:
发送模块,用于向通用应用编程接口框架核心功能CCF实体发送第一请求,所述第一请求包括所述API调用实体请求的第一API;
接收模块,用于接收所述CCF实体发送的第二响应,所述第二响应包括对所述第一API进行上线或激活后获得的所述第一API的接口信息。
第四十六方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收通用应用编程接口框架核心功能CCF实体发送的第一响应,所述第一响应包括可上线或可激活的API、和/或可上线或可激活的API的可用性;
处理模块,用于根据所述可上线或可激活的API、和/或所述可上线或可激活的API的可用性,确定所述API调用实体请求的第一API是否可用;若所述第一API不可用,则确定请求对所述第一API进行上线或激活。
在另一种可能的设计中,发送模块,用于向所述CCF实体发送第一请求,所述第一请求用于指示在对所述第一API进行上线或激活后可用的所述第一API;
所述接收模块,还用于接收所述CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
第四十七方面,本申请实施例提供了一种通信装置,所述装置包括:
发送模块,用于向应用编程接口API调用实体发送第一响应,所述第一响应包括可上线或可激活的API、和/或可上线或可激活的API的可用性;
接收模块,用于接收所述API调用实体发送的第一请求,所述第一请求用于指示在对所述第一API进行上线或激活后可用的所述第一API。
在另一种可能的设计中,发送模块,用于向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;
接收模块,用于接收所述第二API提供实体的第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收第二API提供实体发送的第一API信息,所述第一API信息包括所述可上线或可激活的API、和/或所述可上线或可激活的API的可用性。
第四十八方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API进行上线或激活;
发送模块,用于向所述CCF实体发送第三响应,所述第三响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述CCF实体发送第一API信息,所述第一API信息包括可上线或可激活的API、和/或可上线或可激活的API的可用性。
第四十九方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第二CCF实体发送的第一请求,所述第一请求包括API调用实体请求的第一API;
处理模块,用于从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则确定请求对所述第一API进行上线或激活。
在另一种可能的设计中,发送模块,用于向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;
所述接收模块,还用于接收所述第二API提供实体发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收第二API提供实体发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,发送模块,用于向所述第二CCF实体发送第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
第五十方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收API调用实体发送的第四请求,所述第四请求包括所述API调用实体请求的第一API;
处理模块,用于从预先保存的第三API信息中查询所述第一API是否可用,所述第三API信息包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;若所述第一API不可用,则从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
在另一种可能的设计中,发送模块,用于向所述第一CCF实体发送第一请求,所述第一请求包括API调用实体请求的第一API;
所述接收模块,还用于接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收所述第一CCF实体发送的第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,发送模块,用于向所述API调用实体发送第三响应,所述第三响应包括所述第一API的接口信息。
第五十一方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一API进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API进行上线或激活;
发送模块,用于向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
第五十二方面,本申请实施例提供了一种通信装置,所述装置包括:
发送模块,用于向第二通用应用编程接口框架核心功能CCF实体发送第四请求,所述第四请求包括所述API调用实体请求的第一API;
接收模块,用于接收所述第二CCF实体发送的第三响应,所述第三响应包括对所述第一API进行上线或激活后获得的所述第一API的接口信息,所述第一API的接口信息用于所述API调用实体调用所述第一API进行服务。
第五十三方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第二CCF实体发送的第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API;
处理模块,用于从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;若所述第一API不可用,则确定请求对所述第一API进行上线或激活。
在另一种可能的设计中,发送模块,用于向第二API提供实体发送第二请求,所述第二请求用于请求对所述第一API进行上线或激活;
所述接收模块,还用于接收所述第二API提供实体发送的第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
在另一种可能的设计中,所述接收模块,还用于接收第二API提供实体发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,所述接收模块,还用于接收所述第二CCF实体发送的第三请求;
发送模块,用于向所述第二CCF实体发送第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
第五十四方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第二通用应用编程接口框架核心功能CCF实体发送的第四响应,所述第四响应包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;
处理模块,用于根据所述多个CCF实体控制范围内的API提供实体的API的可用性,确定所述API调用实体请求的第一API是否可用;若所述第一API不可用,则从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
在另一种可能的设计中,发送模块,用于向所述第二CCF实体发送第四请求,所述第四请求包括所述第一CCF实体的标识和所述第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API进行上线或激活;
所述接收模块,还用于接收所述第二CCF实体发送的第五响应,所述第五响应包括所述第一API的接口信息。
第五十五方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收API调用实体发送的第四请求,所述第四请求包括所述第一CCF实体的标识和应用编程接口API调用实体请求的第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API进行上线或激活;
发送模块,用于向所述第一CCF实体发送第一请求,所述第一请求包括应用编程接口API调用实体请求的第一API。
在另一种可能的设计中,接收模块,用于接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息;
发送模块,用于向所述API调用实体发送第五响应,所述第五响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述第一CCF实体发送第三请求;
所述接收模块,还用于接收所述第一CCF实体发送的第三响应,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
在另一种可能的设计中,所述发送模块,还用于向所述API调用实体发送第四响应,所述第四响应包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。
第五十六方面,本申请实施例提供了一种通信装置,所述装置包括:
接收模块,用于接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一AP进行上线或激活,所述第一API为应用编程接口API调用实体请求的API;
处理模块,用于对所述第一API进行上线或激活;
发送模块,用于向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
在另一种可能的设计中,所述发送模块,还用于向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
上述通信装置执行的操作及有益效果可以参见上述第一方面至第二十八方面的方法以及有益效果,重复之处不再赘述。
第五十七方面,本申请提供了一种API调用实体,API调用实体包括处理器和存储器,存储器用于存储计算机执行指令;处理器用于执行存储器所存储的计算机执行指令,以使API调用实体执行如第三方面、第四方面、第十方面、第十二方面、第十七方面、第十八方面、第二十四方面,第二十六方面中任意一项的方法。
第五十八方面,本申请提供了一种API提供实体,API提供实体包括处理器和存储器,存储器用于存储计算机执行指令;处理器用于执行存储器所存储的计算机执行指令,以使API提供实体执行如第二方面、第十六方面、第二十方面、第二十三方面和第二十八方面中任意一项的方法。
第五十九方面,本申请提供了一种CCF实体,CCF实体包括处理器和存储器,存储器用于存储计算机执行指令;处理器用于执行存储器所存储的计算机执行指令,以使CCF实体执行如第一方面、第五方面、第七方面、第八方面、第十一方面、第十三方面、第十五方面、第十九方面、第二十一方面、第二十二方面、第二十五方面、第二十七方面中任意一项的方法。
第六十方面,本申请提供了一种网管系统,网管系统包括处理器和存储器,存储器用于存储计算机执行指令;处理器用于执行存储器所存储的计算机执行指令,以使网管系统执行如第二方面、第六方面、第九方面、第十四方面中任意一项的方法。
第六十一方面,本申请提供了一种计算机可读存储介质,计算机可读存储介质用于存储计算机程序,当计算机程序被执行时,使得如第一方面至第二十八方面中任意一项的方法被实现。
第六十二方面,本申请提供一种包括计算机程序的计算机程序产品,当计算机程序被执行时,使得如第一方面至第二十八方面中任意一项的方法被实现。
第六十三方面,本申请提供一种通信系统,通信系统包括API调用实体、API提供实体、网管系统和CCF实体,API调用实体用于执行如第三方面、第四方面、第十方面、第十二方面、第十七方面、第十八方面、第二十四方面,第二十六方面中任意一项的方法,API提供实体用于执行如第二方面、第十六方面、第二十方面、第二十三方面和第二十八方面中任意一项的方法,CCF实体用于执行如第一方面、第五方面、第七方面、第八方面、第十一方面、第十三方面、第十五方面、第十九方面、第二十一方面、第二十二方面、第二十五方面、第二十七方面中任意一项的方法,网管系统用于执行如第二方面、第六方面、第九方面、第十四方面中任意一项的方法。
第六十四方面,本申请提供一种通信系统,通信系统包括CCF实体、API调用实体、API提供实体和网管系统,CCF实体为边缘使能服务器EES,API调用实体为第一边缘应用服务器EAS,API提供实体为除第一EAS之外的其他EAS,网管系统为EAS实例化管理系统。
附图说明
为了更清楚地说明本申请实施例或背景技术中的技术方案,下面将对本申请实施例或背景技术中所需要使用的附图进行说明。
图1是一种SA6 MEC架构;
图2是一种SA6通用API框架;
图3是一种多EAS场景的示意图;
图4是一种EAS实例化的流程示意图;
图5是另一种EAS实例化的流程示意图;
图6是一种API发布的流程示意图;
图7是一种API发现的流程示意图;
图8是本申请实施例提供的一种通信方法的流程示意图;
图9是本申请实施例提供的另一种通信方法的流程示意图;
图10是本申请实施例提供的又一种通信方法的流程示意图;
图11是本申请实施例提供的又一种通信方法的流程示意图;
图12是本申请实施例提供的又一种通信方法的流程示意图;
图13是本申请实施例提供的又一种通信方法的流程示意图;
图14是本申请实施例提供的又一种通信方法的流程示意图;
图15是本申请实施例提供的又一种通信方法的流程示意图;
图16是本申请实施例提供的一种通信装置的结构示意图;
图17是本申请实施例提供的另一种通信装置的结构示意图;
图18是本申请实施例提供的又一种通信装置的结构示意图;
图19是本申请实施例提供的又一种通信装置的结构示意图;
图20是本申请实施例提供的一种CCF实体的结构示意图;
图21是本申请实施例提供的一种网管系统的结构示意图;
图22是本申请实施例提供的一种API调用实体的结构示意图;
图23是本申请实施例提供的一种API提供实体的结构示意图。
具体实施方式
下面结合本申请实施例中的附图对本申请实施例进行描述。
如图1所示,图1是一种SA6 MEC架构。SA6 MEC架构包括用户设备(userequipment,UE)、第三代合作伙伴计划(3rd generation partnership project,3GPP)核心网和边缘数据网络(edge data network,END)。其中,UE包括应用客户端(applicationclient,AC)和边缘使能客户端(edge enabler client,EEC),边缘数据网络包括边缘应用服务器(edge application server,EAS)、边缘使能服务器(edge enabler server,EES)和边缘配置服务器(edge configuration server,ECS)。其中:
END:一种通用理解,边缘数据网络对应一个数据网络,是一个特别的本地数据网络(local DN),包含边缘使能功能,可以使用数据网络接入标识(data network sccessidentifier,DNAI)和数据网络名称(data network name,DNN)标识,是网络逻辑概念。另一种理解,边缘数据网络是中心云的对等概念,可以理解为是一个本地的数据中心(地理位置概念),可以使用数据网络接入标识(data network access identifier,DNAI)来标识,可以包含多个本地数据网络。
EAS:部署在边缘数据网络中的应用称为应用实例。具体是指一个服务器应用程序(例如,社交媒体软件、增强现实(augmented reality,AR)、虚拟现实(virtual reality,VR))部署运行在EDN的实例(instance)。一个应用可在一个或多个EDN中部署一个或多个EAS,部署运行在不同的EDN中的EAS可以认为是一个应用的不同的EAS,它们可以共享一个域名,可以使用一个IP地址,也可以使用不同的IP地址。EAS也可以称为边缘应用(服务器)、应用实例、边缘应用实例、MEC应用(服务器)、EAS功能等。
AC:边缘应用在UE侧的对等实体。应用客户端用于应用用户(User)从应用服务器获取应用业务。应用客户端是应用在终端侧的客户端程序,应用客户端可以连接到云上的应用服务器获取应用业务,也可以连接到部署并运行在一个或多个EDN中的EAS以获取应用业务。
EES:可以为部署在EDN中的应用实例提供一些使能能力,可以支持应用在MEC的部署情况。可以支持边缘应用的注册、对UE的认证和鉴权,为UE提供应用实例的IP地址信息等。还可以进一步支持获取应用实例的标识和IP地址信息,并进一步向应用实例的标识和IP地址信息发送给边缘数据网络配置服务器。EES部署在EDN中。一般情况下,EAS注册到一个EES上,或者,通过管理系统将一个EAS的信息配置在一个EES上,该EES称为该EAS关联的EES,EES控制/管理注册/配置在该EES上的EAS。
EEC:是EES在UE侧的对等实体。EEC用于向EES注册EEC的信息及应用客户端的信息、执行安全认证和鉴权、从EES获取EAS的IP地址信息、向应用客户端提供边缘计算使能能力,如EAS发现服务将EAS的IP地址返回给应用客户端。
ECS:负责EDN的配置。如向UE提供EES的信息。还可以直接向UE提供应用实例的信息,以及和应用的DNS交互获取应用实例的信息。进一步从其他功能实体获取并保存应用实例和IP地址的信息。
其中,应用用户与应用的提供商签订服务协议,从而为应用用户提供服务,而应用用户通过登录用户终端上的应用客户端AC,通过应用客户端AC与边缘应用EAS的连接进行通信。边缘使能客户端EEC为中间件层,一般位于操作系统中,或者位于应用客户端与操作系统中间。应用客户端AC可以以应用编程接口(application program interface,API)的方式从边缘使能客户端EEC获取边缘使能服务。
如图2所示,图2是一种SA6通用API框架(common API framework,CAPIF)架构。该SA6 CAPIF架构包括API调用(API invoker)实体、CAPIF核心功能(CAPIF core function,CCF)实体和API提供(API provider)实体。其中,API提供实体可以包括API开放功能实体(API exposing function,AEF)、API发布功能实体(API publishing function,APF)和API管理功能实体(API management function,AMF)。其中:
API调用实体:也称为API调用者,一般为与公共陆地移动网络(public landmobile network,PLMN)运营商签订了服务协议的第三方应用,如物联网(Internet ofThings,IoT)应用,车联网(vehicle to everything,V2X)应用等,这些应用可以运行在终端设备中,也可以运行在网络设备中。此外,API调用实体也可以为运营商PLMN网络中的设备,如4G系统中的移动管理(mobility management entity,MME)实体,策略和计费规则功能(policy and charging rule function,PCRF)实体等,也可以为5G网络中的会话管理功能(session management function,SMF),策略控制功能(policy control function,PCF)实体等。API调用实体可以与运营商PLMN网络处于同一个信任域(trust domain)中。API调用实体支持如下功能:触发API调用实体的上线或下线;通过提供API调用实体的标识及其他信息,支持API调用实体的认证;支持和CAPIF的互相鉴权;在接入/访问API之间获取授权;发现API信息;调用API。
CCF具有如下功能:基于API调用实体的标识及其他信息,进行API调用实体的认证;支持API调用实体间互相鉴权;在API调用实体接入/访问API前,提供API调用实体的授权;支持API的发布、存储和发现功能;基于运营商PLMN配置的策略,执行API接入或访问的控制;存储API调用的日志信息,并可以将API调用日志提供给其他授权实体;基于API调用的日志信息,进行计费;监控API调用情况;执行API调用实体的上线或下线功能;存储CAPIF或API相关的配置策略信息;支持接入或访问API日志,以实现审计功能;支持与另一个CCF互连,实现API的发布与发现功能。
AEF:为API的提供方,同时也是API调用实体进行API调用的入口点,AEF具有如下功能:基于API调用实体的标识和其他信息,执行API调用实体的认证;确认CCF提供的授权;将API调用日志同步至CCF。
APF:为API提供者(API povider)发布API信息,从而支持API调用实体发现API信息,APF具有如下功能:发布API提供实体的API信息至CCF。
AMF:为API提供者(API provider)进行API管理,AMF具有如下功能:支持对从CCF接收的API调用日志信息进行审计;监控CCF报告的相关事件;配置API提供者的策略信息至CCF;监控API的状态;支持API调用实体的上线或下线;支持API提供者域功能(APIprovider domain function)注册以及注册维护信息。
如图3所示,图3是一种多EAS场景的示意图。在当前应用服务器的部署架构中,存在将传统的单应用服务器划分为多应用服务器的趋势,从而为提供高安全和大容量的应用服务。在SA6 MEC架构下,多应用服务器场景可以称为多EAS场景,也可以称为联邦EAS场景。例如为向用户或客户端AC提供游戏应用,可以将游戏应用服务器划分为多个EAS。其中,每个EAS可以提供多种API服务。
例如,EAS1为与游戏客户端AC保持连接的EAS,又可称为主EAS,EAS2和EAS3为多EAS中除主EAS外的其他EAS,其中EAS2和EAS3可以提供多种API,如EAS2可以提供游戏渲染API1,内容存储API2等,EAS3可以提供游戏加速API3,内容分析API4等。在游戏运行时,AC可以连接至EAS1,通过EAS1调用来自EAS2的游戏渲染API1和来自EAS3的游戏加速API3,能够为用户或游戏客户端提供游戏体验。
另外,当前应用服务器呈虚拟化或云化形式部署,EAS可以作为一个虚拟服务器的实例进行部署,为有效利用边缘网络的计算资源,EAS可以动态的按需部署或实例化。其中,实例化指创建虚拟服务器实例或EAS实例的过程。以下提供EAS实例化触发的两种情况:
如图4所示,图4是一种EAS实例化的流程示意图。主要步骤包括:
S401,EEC向EES发送EAS发现请求。其中,AS发现请求可以包括UE位置和EAS发现过滤器信息(EAS discovery filter),EAS发现过滤器信息包括AC配置文件信息(ACprofile)等。EAS发现过滤器信息如表1所示,AC配置文件信息如表2所示。状态O表示可选,状态M表示必选。
S402,EES确定EES是否对应当前UE位置,或是否存在AC应用所需的EAS可以使用,若确定EES没有对应当前UE位置,或者没有AC应用所需的EAS可以使用,则向EAS管理系统发送EAS实例化请求。
S403,EAS管理系统接收到EAS实例化请求之后,对EAS进行实例化。
S404,EAS管理系统向EES发送实例化结果。其中,实例化结果包括实例化成功或实例化失败。若实例化结果为实例化成功,实例化结果可以进一步包括实例化后的EAS的信息。
S405,EES向EEC发送EAS发现响应,EAS发现响应包括实例化的EAS信息。
如图5所示,图5是另一种EAS实例化的流程示意图。主要步骤包括:
S501,源EES向目标EES发送EAS发现请求。其中,AS发现请求可以包括UE位置和EAS发现过滤器信息,EAS发现过滤器信息进一步包括AC配置文件信息等。EAS发现过滤器信息如表1所示,AC配置文件信息如表2所示。状态O表示可选,状态M表示必选。
S502,目标EES确定目标EES是否对应当前UE位置,或是否存在AC应用所需的目标EAS可以使用,若确定目标EES没有对应当前UE位置,或者没有AC应用所需的目标EAS可以使用,则向EAS管理系统发送EAS实例化请求。
S503,EAS管理系统接收到EAS实例化请求之后,对目标EAS进行实例化。
S504,EAS管理系统向目标EES发送实例化结果。其中,实例化结果包括实例化成功或实例化失败。若实例化结果为实例化成功,实例化结果可以进一步包括实例化的目标EAS信息。
S505,目标EES向源EES发送EAS发现响应。其中,EAS发现响应包括实例化的目标EAS信息。
表1
/>
表2
在以上EAS实例化触发过程中,EES或目标EES判断是否向EAS网管系统执行EAS实例化请求依据为:基于EAS发现过滤器(AC配置文件或EAS特性)进行判断。没有考虑EAS所需的服务API是否可用,因此不支持多EAS场景中EAS实例化。
如图6所示,图6是一种API发布的流程示意图。主要步骤包括:
S601,APF实体向CCF实体发送API发布请求。API发布请求中包括API内容(如API名称、API类型、服务区域和接口信息(如IP地址,端口号,URI等)),若向其他CCF实体共享API,则API发布请求中包括可共享信息。
S602,CCF实体接收API发布请求后,CCF实体对APF实体进行检查与授权。若授权成功,则CCF实体将存储APF实体提供的API信息。
S603,CCF实体向APF实体发送API发布响应,API发布响应用于指示API发布结果,所述API发布结果包括API发布成功或API发布失败。
如图7所示,图7是一种API发现的流程示意图。主要步骤包括:
S701,API调用实体向CCF实体发送API发现请求,API发现请求中包括API调用实体的标识、以及查询信息(即API发现的准则,如API类型,API名称等)。
S702,在CCF实体接收API发现请求后,CCF实体对API调用标识进行验证与授权,CCF实体根据查询信息,从存储的API中获取API信息。此外,CCF实体也可以根据API发现策略进行API的过滤与发现。
S703,CCF实体向API调用实体发送API发现响应,API发现响应包括发现的API列表信息,API列表信息可以包括API的名称、类型、服务区域或接口信息等。
在以上API发布或API发现流程中,均已假设所需的API对应的EAS已实例化,未考虑多EAS场景中存在EAS请求的API不可用的情况,即不支持基于API可用性的EAS实例化,以及不支持API的上线或激活。
为了解决上述技术问题,本申请实施例提供了如下解决方案。
本申请实施例中的网元可以包括API调用实体、API提供实体、CCF实体和管理系统。本申请实施例可以应用于CAPIF场景、MEC场景或其他应用场景。在MEC的多EAS场景,API调用实体可以为主EAS,CCF实体可以为EES,API提供实体可以为除主EAS之外的其他EAS,网管系统可以为EAS实例化管理系统或服务管理系统等。
本申请实施例中的多EAS场景可以由API调用实体和多个API提供实体(例如第一API提供实体和第二API提供实体)组成,其中,API调用实体、第一API提供实体和第二API提供实体可以均为EAS,API调用实体为主EAS,第一API提供实体为已实例化的EAS,第二API提供实体为可实例化但还未实例化的EAS。或者,第一API提供实体为已实例化的EAS,提供已上线或已激活的API,第二API提供实体为已实例化的EAS,但提供可上线或可激活的API。CCF实体支持多EAS场景中的API发现以及EAS实例化触发。
如图8所示,图8是本申请实施例提供的一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S801,网管系统向CCF实体发送第二API信息,所述第二API信息包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
其中,第二API信息还可以包括可实例化的API提供实体的API的名称、类型和服务区域等信息,但不包括可实例化的API提供实体的API的接口信息(例如IP地址、端口号、URI等),因此API调用实体无法调用可实例化的API提供实体的API。
在本申请实施例中,可实例化的API提供实体可以为第二API提供实体。
可选的,所述第二API信息还可以包括指示信息,所述指示信息用于指示API提供实体的API在对API提供实体进行实例化后可用。
S802,CCF实体向网管系统返回第三响应。
具体的,当CCF实体接收到第二API信息时,所述第三响应可以为确认响应,当CCF实体未接收到第二API信息时,所述第三响应可以为否定确认响应。
S803,第一API提供实体向CCF实体发送第三请求。
其中,第三请求用于请求将第一API提供实体注册至CCF实体,以支持第一API提供实体成为使用CAPIF功能的授权实体。第三请求可以为API注册请求。
S804,CCF实体向第一API提供实体发送第四响应。
具体的,若第一API提供实体注册至CCF实体成功,则第四响应为确认响应,若第一API提供实体注册至CCF实体失败,则第四响应为否定确认响应。
S805,第一API提供实体向CCF实体发送第四请求。
其中,第四请求用于请求CCF实体对第一API提供实体进行检查与授权后存储第一API提供实体提供的API信息。第四请求可以为API发布请求。
其中,第四请求中可以包括第一API提供实体提供的API信息,API信息包括API的名称、API类型、服务区域和接口信息(如IP地址,端口号,URI等)。
可选的,第四请求中还可以包括可共享信息。可共享信息用于指示其他CCF实体可以共享第一API提供实体提供的API信息。
需要说明的是,第一API提供实体为已实例化的API提供实体,将已实例化的API提供实体发布至CCF实体,第一API提供实体提供的API信息包括API的接口信息。
S806,CCF实体向第一API提供实体发送第五响应。
具体的,CCF实体接收第四请求之后,对第一API提供实体进行检查与授权,若授权成功,则第五响应为确认响应,CCF实体存储第一API提供实体提供的API信息,若授权失败,则第五响应为否定确认响应。
S807,API调用实体向CCF实体发送第五请求。
其中,第五请求用于请求将API调用实体注册至CCF实体,以支持API调用实体成为使用CAPIF功能的授权实体。第五请求可以为API注册请求。
S808,CCF实体向API调用实体发送第六响应。
具体的,若API调用实体注册至CCF实体成功,则第六响应为确认响应,若API调用实体注册至CCF实体失败,则第六响应为否定确认响应。
S809,API调用实体向CCF实体发送第一请求。
其中,第一请求用于请求从CCF实体预先保存的第一API信息中查询API调用实体请求的第一API。所述第一请求可以包括API调用实体请求的第一API。第一请求可以为API发现请求。
S810,CCF实体从预先保存的第一API信息中查询所述第一API是否可用。
其中,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API。如表3所示,表3是CCF实体预先存储的第一API信息的统计表。统计表包括API的名称、接口信息和可用信息。API#1和API#2为已实例化的第一API提供实体S803-S806发布至CCF实体,API#3和API#4为可实例化的第二API提供实体通过S801-S802提供或配置至CCF实体。已实例化的第一API提供实体对应的第一API信息中包括API的接口信息,因此第一API提供实体的API可用。可实例化的第二API提供实体对应的第一API信息中不包括API的接口信息,因此第二API提供实体的API不可用,需要对第二API提供实体进行实例化后可用。
表3
具体的,若CCF实体从预先保存的第一API信息中查询到所述第一API可用,则向API调用实体发送第一API的接口信息,以便API调用实体通过第一API的接口信息调用第一API进行服务。若CCF实体从预先保存的第一API信息中查询到所述第一API不可用,则确定请求对第一API对应的API提供实体进行实例化。
例如,API调用实体请求的第一API为API#1和API#4,从表3可知,API#1为已实例化的第一API提供实体的API,具有接口信息,API#1是可用的API。API#4为可实例化的第二API提供实体的API,不具有接口信息,API#4是不可用的API。因此CCF实体确定请求对第二API提供实体进行实例化。
可选的,第一API信息还可以包括每个API对应的API提供实体的标识。若CCF实体从预先保存的第一API信息中查询到第一API不可用,且第一API对应的API提供实体包括多个API提供实体,CCF实体可以从多个API提供实体中选取目标API提供实体。
S811,CCF实体向网管系统发送第二请求。
其中,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化,第二请求可以为实例化请求。
其中,第二请求可以包括第一API的名称、类型和服务区域中的一项或多项。
可选的,第二请求可以包括目标API提供实体的标识,所述第二请求用于请求对目标API提供实体进行实例化。
S812,网管系统对所述第一API对应的API提供实体进行实例化。
在本申请实施例中,第一API对应的API提供实体为第二API提供实体,通过对第二API提供实体进行实例化可以获取第一API的接口信息。
可选的,当所述第一API对应的API提供实体包括多个API提供实体时,网管系统从所述多个API提供实体中选取目标API提供实体;对目标API提供实体进行实例化。
例如,CCF实体发送的第二请求中包括API#4,如果网管系统确定第二API提供实体能够提供API#4,因此对第二API提供实体进行实例化。如果网管系统确定API#4对应的API提供实体包括多个API提供实体,如第二API提供实体和第三API提供实体,则网管系统从第二API提供实体和第三API提供实体中选择其中一个API提供实体进行实例化。
S813,网管系统向所述CCF实体发送第一响应。
具体的,若网管系统对第一API对应的API提供实体进行实例化成功,则第一响应可以为确认响应,第一响应包括所述第一API的接口信息,接口信息包括第一API的IP地址、端口号和URI等。可选的,第一响应还可以包括第一API的名称、类型和服务区域中的一项或多项。若网管系统对第一API对应的API提供实体进行实例化失败,则第一响应可以为否定确认响应。
其中,第一响应可以为实例化响应。
S814,CCF实体向API调用实体发送第二响应。
其中,第二响应可以包括第一API的接口信息。可选的,第二响应还可以包括第一API的名称、类型和服务区域中的一项或多项。第二响应可以为API发现响应。
S815,API调用实体接收到第二响应之后,获取第一API的接口信息,通过第一API的接口信息调用第一API进行服务。
S816,第二API提供实体将第二API提供实体提供的API信息发布至CCF实体,以支持后续API调用实体可以对实例化后的API进行发现和调用。
具体实现过程与S803-S806类似,此处不再赘述。
在本申请实施例中,CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求网管系统对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
以上实施例是由CCF实体判断是否触发请求执行实例化过程。下一个实施例是由API调用实体判断是否触发请求执行实例化过程。
如图9所示,图9是本申请实施例提供的另一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S901-S908与上一实施例中S801-S808相同,具体实现方式可以参考S801-S808,此处不再赘述。
S909,API调用实体向CCF实体发送第六请求。
其中,第六请求用于请求从CCF实体保存的第一API信息中查询API调用实体请求的第一API。第一请求可以包括API调用实体请求的第一API,第一请求可以为API发现请求。
S910,CCF实体向API调用实体发送第一响应。
其中,第一响应包括CCF实体反馈给API调用实体的API信息,该API信息可以包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。该API信息还可以包括已实例化的API提供实体的API和/或已实例化的API提供实体的API的可用性。第一响应可以为API发现响应。
如表4所示,表4是CCF实体反馈给API调用实体的API信息的统计表。例如,API调用实体请求的第一API为API#1和API#4,因此CCF实体反馈API#1和API#4的API信息。其中,API#1为已实例化的第一API提供实体通过S903-S906发布至CCF实体,API#4为可实例化的第二API提供实体通过S901-S902提供或配置至CCF实体。已实例化的第一API提供实体对应的第一API信息中包括API的接口信息,因此第一API提供实体的API可用。可实例化的第二API提供实体对应的第一API信息中不包括API的接口信息,因此第二API提供实体的API不可用,需要对第二API提供实体进行实例化后可用。
表4
可选的,所述第一响应还可以包括指示信息,所述指示信息用于指示可实例化的API提供实体的API在对API提供实体进行实例化后可用。
S911,API调用实体根据所述可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性,确定所述API调用实体请求的第一API是否可用。
具体的,若API调用实体确定API调用实体请求的第一API可用,则API调用实体可以通过第一API的接口信息调用第一API接口进行服务。若API调用实体确定第一API不可用,则API调用实体确定请求对第一API对应的API提供实体进行实例化。
例如,API调用实体请求的第一API为API#1和API#4,从表4可知,API#1为已实例化的第一API提供实体的API,具有接口信息,API#1是可用的API。API#4为可实例化的第二API提供实体的API,不具有接口信息,API#4是不可用的API。因此CCF实体确定请求对API#4对应的第二API提供实体进行实例化。
S912,API调用实体向CCF实体发送第一请求。
其中,所述第一请求用于指示在对所述第一API对应的API提供实体进行实例化后可用的所述第一API。第一请求可以为API调用通知请求消息。
其中,第一请求可以包括第一API的名称、类型和服务区域中的一项或多项。
S913,CCF实体向网管系统发送第二请求。
其中,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化,第二请求可以为实例化请求。
可选的,CCF实体预先存储第一API对应的API提供实体的标识。当第一API对应的API提供实体包括多个API提供实体时,CCF实体可以从多个API提供实体中选取目标API提供实体。第二请求可以包括目标API提供实体的标识,所述第二请求用于请求对目标API提供实体进行实例化。
其中,第二请求可以包括第一API的名称、类型和服务区域中的一项或多项。
S914,网管系统对所述第一API对应的API提供实体进行实例化。
在本申请实施例中,第一API对应的API提供实体为第二API提供实体,通过对第二API提供实体进行实例化可以获取第一API的接口信息。
可选的,当所述第一API对应的API提供实体包括多个API提供实体时,网管系统从所述多个API提供实体中选取目标API提供实体;对目标API提供实体进行实例化。
例如,CCF实体发送的第二请求中包括API#4,如果网管系统确定第二API提供实体能够提供API#4,因此对第二API提供实体进行实例化。如果网管系统确定API#4对应的API提供实体包括多个API提供实体,如第二API提供实体和第三API提供实体,则网管系统从第二API提供实体和第三API提供实体中选择其中一个API提供实体进行实例化。
S915,网管系统向CCF实体发送第三响应。
具体的,若网管系统对第一API对应的API提供实体进行实例化成功,则第三响应可以为确认响应,第三响应包括所述第一API的接口信息,接口信息包括第一API的IP地址、端口号和URI等。可选的,第三响应还可以包括第一API的名称、类型和服务区域中的一项或多项。若网管系统对第一API对应的API提供实体进行实例化失败,则第三响应可以为否定确认响应。
其中,第三响应可以为实例化响应。
S916,CCF实体向API调用实体发送第二响应。
其中,第二响应可以包括第一API的接口信息。可选的,第二响应还可以包括第一API的名称、类型和服务区域中的一项或多项。第二响应可以为API发现响应。
S917,API调用实体接收到第二响应之后,获取第一API的接口信息,通过第一API的接口信息调用第一API进行服务。
S918,第二API提供实体将第二API提供实体提供的API信息发布至CCF实体,以支持后续API调用实体可以对实例化后的API进行发现和调用。
在本申请实施例中,API调用实体接收可实例化的API提供实体的API和/或可实例化的API提供实体的API的可用性之后,确定是否请求对第一API对应的API提供实体进行实例化。通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
以上实施例是针对API调用实体和API提供实体由单个CCF实体控制的API提供实体实例化流程,下一个实施例是针对API调用实体和API提供实体由多个CCF实体控制的API提供实体实例化流程,并且由CCF实体判断是否触发请求执行实例化过程。
如图10所示,图10是本申请实施例提供的又一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S1001,网管系统向第二CCF实体发送第四API信息。所述第四API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
其中,第四API信息还可以包括第二CCF实体控制范围内的可实例化的API提供实体的API的名称、类型和服务区域等信息,但不包括可实例化的API提供实体的API的接口信息(例如IP地址、端口号、URI等),因此API调用实体无法调用可实例化的API提供实体的API。
可选的,所述第四API信息还可以包括指示信息,所述指示信息用于指示第二CCF实体控制范围内API提供实体的API在对API提供实体进行实例化后可用。
S1002,第二CCF实体向网管系统返回第四响应。
具体的,当第二CCF实体接收到第四API信息时,所述第四响应可以为确认响应,当第二CCF实体未接收到第四API信息时,所述第四响应可以为否定确认响应。
S1003,网管系统向第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
其中,第二API信息还可以包括第一CCF实体控制范围内的可实例化的API提供实体的API的名称、类型和服务区域等信息,但不包括可实例化的API提供实体的API的接口信息(例如IP地址、端口号、URI等),因此API调用实体无法调用可实例化的API提供实体的API。
可选的,所述第二API信息还可以包括指示信息,所述指示信息用于指示第一CCF实体控制范围内API提供实体的API在对API提供实体进行实例化后可用。
S1004,第一CCF实体向网管系统返回第五响应。
具体的,当第一CCF实体接收到第二API信息时,所述第五响应可以为确认响应,当第一CCF实体未接收到第二API信息时,所述第五响应可以为否定确认响应。
S1005-S1008与S803-S806相同,具体实现方式可以参考S803-S806,此处不再赘述。
S1009,第一CCF实体向第二CCF实体发送第三请求。所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
可选的,第三请求还可以包括指示信息,该指示信息用于指示第一CCF实体控制范围内API提供实体的API在对API提供实体进行实例化后可用。
其中,第三请求可以为API发布请求。
S1010,第二CCF实体向第一CCF实体发送第八响应。
具体的,第二CCF实体接收到第三请求之后,对第一CCF实体进行检查和授权,如果授权成功,则存储第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性,向第一CCF实体返回的第八响应为确认响应。如果授权成功,向第一CCF实体返回的第八响应为否定确认响应。
S1011-S1012与S807-S808相同,具体实现方式可以参考S807-S808,此处不再赘述。
S1013,API调用实体向第二CCF实体发送第四请求,所述第四请求包括所述API调用实体请求的第一API。
其中,第四请求可以API发现请求。
S1014,第二CCF实体从预先保存的第三API信息中查询所述第一API是否可用。其中,所述第三API信息包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。
需要说明的是,经过上述S1001-S1004以及S1009-S1010之后,第二CCF实体上存储的第三API信息包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。第三API信息还可以包括第二CCF实体的标识、第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。第三API信息还可以包括第二CCF实体的标识、第二CCF实体控制范围内已实例化的API提供实体的API和/或第二CCF实体控制范围内已实例化的API提供实体的API的可用性。
例如,如表5所示,表5是第二CCF实体上存储的第三API信息的统计表。第二CCF实体上存储的第三API信息包括CCF#1控制范围内的API#1和API#2的名称、接口信息和可用性,CCF#2控制范围内的API#3和API#4的名称、接口信息和可用性。CCF#3控制范围内的API#4和API#5的名称、接口信息和可用性。其中,CCF#2控制范围内的API#3和API#4不具有接口信息,因此CCF#2控制范围内的API#3和API#4不可用,需要对CCF#2控制范围内API提供实体进行实例化。CCF#3控制范围内的API#4和API#5不具有接口信息,因此CCF#3控制范围内的API#4和API#5不可用,需要对CCF#3控制范围内API提供实体进行实例化。
表5
具体的,若所述第一API不可用,则第二CCF实体从多个CCF实体中选取所述第一API对应的第一CCF实体。若所述第一API可用,则第二CCF实体向API调用实体返回第一API的接口信息,以便API调用实体通过第一API的接口信息调用第一API接口进行服务。
例如,API调用实体请求的第一API为API#1和API#4。从表5可知,API#1可以由CCF#1控制范围内的API提供实体提供,具有接口信息,API#1是可用的。API#4可以由CCF#2控制范围内的API提供实体和CCF#3控制范围内的API提供实体,不具有接口信息,API#4是不可用的,需要从CCF#2和CCF#3上选择一个CCF实体,避免实例化多个CCF实体控制范围内的API提供实体,造成资源浪费。
S1015,第二CCF实体向第一CCF实体发送第一请求。
其中,所述第一请求包括API调用实体请求的第一API。第一请求还可以包括第一CCF实体的标识。第一请求可以为API发现请求。
S1016-S1019与图8所示的实施例中S810-S813相同,具体实现方式可以参考S810-S813,此处不再赘述。
S1020,第一CCF实体向第二CCF实体发送第二响应。
其中,第二响应可以包括第一API的接口信息。第二响应还可以包括第一API的名称、类型和服务区域中一项或多项。第二响应可以为API发现响应。
S1021,第二CCF实体向API调用实体发送第三响应。
其中,第三响应可以包括第一API的接口信息。第二响应还可以包括第一API的名称、类型和服务区域中一项或多项。第三响应可以为API发现响应。
S1022-S1023与图8所示的实施例中S815-S816相同,具体实现方式可以参考S815-S816,此处不再赘述。
在本申请实施例中,第二CCF实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
上一个实施例是由CCF实体判断是否触发请求执行实例化过程,下一个实施例是由API调用实体判断是否触发请求执行实例化过程,并且是针对API调用实体和API提供实体由多个CCF实体控制的API提供实体实例化流程。
如图11所示,图11是本申请实施例提供的又一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S1101-S1112与图10所示的实施例中S1001-S1012相同,具体实现方式可以参考S1001-S1012,此处不再赘述。
S1113,API调用实体向第二CCF实体发送第九请求。
其中,第九请求用于请求查询API调用实体请求的第一API。第九请求可以包括API调用实体请求的第一API,第九请求可以为API发现请求。
S1114,第二CCF实体向第一CCF实体发送第三请求。
其中,第三请求用于请求查询API调用实体请求的第一API。所述第三请求包括API调用实体请求的第一API,第三请求还可以包括第一CCF实体的标识。第三请求可以为API发现请求。
S1115,第一CCF实体向第二CCF实体发送第三响应。
其中,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。第三响应可以为API发现响应。
可选的,第三响应还可以包括指示信息,该指示信息用于指示在对第一CCF实体控制范围内的可实例化的API提供实体进行实例化后API可用。
S1116,第二CCF实体向API调用实体发送第四响应。
其中,所述第四响应包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。进一步的。所述第四响应可以包括多个CCF实体控制范围内的可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。所述第四响应还可以包括多个CCF实体控制范围内的已实例化的API提供实体的API和/或已实例化的API提供实体的API的可用性。第四响应可以为API发现响应。
可选的,第四响应还可以包括指示信息,该指示信息用于指示在对多个CCF实体控制范围内内的可实例化的API提供实体进行实例化后API可用。
如表6所示,表6是第二CCF实体反馈给API调用实体的API信息的统计表。例如,API调用实体请求的第一API为API#1和API#4,因此第二CCF实体反馈API#1和API#4的API信息。其中,API#1由CCF#1控制范围内的已实例化的API提供实体提供,API#4由CCF#2和CCF#3控制范围的可实例化的API提供实体提供。CCF#1控制范围内的已实例化的API提供实体的API具有接口信息,API#1是可用的。CCF#2和CCF#3控制范围的可实例化的API提供实体的API不具有接口信息,API#4是不可用的,需要对CCF#2和CCF#3控制范围内的可实例化的API提供实体进行实例化。
表6
S1117,API调用实体根据多个CCF实体控制范围内的API提供实体的API的可用性,确定API调用实体请求的第一API是否可用。
具体的,若所述第一API可用,则API调用实体可以通过第一API的接口信息调用第一API进行服务。若所述第一API不可用,则API调用实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
例如,API调用实体请求的第一API为API#1和API#4,从表6可知,API#1为CCF#1控制范围内的已实例化的API提供实体的API,具有接口信息,API#1是可用的API。API#4为CCF#2和CCF#3控制范围的可实例化的API提供实体的API,不具有接口信息,API#4是不可用的API。因此CCF实体从CCF#2和CCF#3中选取一个CCF#2,请求对CCF#2控制范围内的API#4对应的API提供实体进行实例化。
S1118,API调用实体向第二CCF实体发送第四请求。
其中,所述第四请求包括所述第一CCF实体的标识和所述第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API对应的API提供实体进行实例化。第四请求可以为API调用通知请求。
可选的,第四请求包括第一API的名称、类型和服务区域中的一项或多项。
在本申请实施例中,第一CCF实体控制范围内的所述第一API对应的API提供实体为第二API提供实体。
具体的,第二CCF实体接收到第四请求之后,可以根据第一CCF实体的标识,确定第一API是由第一CCF实体控制范围内的API提供实体提供的,因此确定请求对第一CCF实体控制范围内的第一API对应的API提供实体进行实例化。
S1119,第二CCF实体向第一CCF实体发送第一请求。
其中,所述第一请求用于请求对第一CCF实体控制范围内的第一API对应的API提供实体进行实例化。所述第一请求包括API调用实体请求的第一API。
可选的,第一请求可以包括第一API的名称、类型和服务区域中的一项或多项。第一请求可以为API调用通知请求。
S1120-S1127与图10所示的实施例中S1016-S1023相同,具体实现方式可以参考S1016-S1023,此处不再赘述。
在本申请实施例中,API调用实体根据多个CCF实体控制范围内的API提供实体的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API对应的API提供实体进行实例化,通过网管系统对第一API对应的API提供实体进行实例化,使得API调用实体获得第一API的接口信息,实现按照需求实例化相应的API提供实体,避免API提供实体的资源浪费,提高资源的利用率。
在以上实施例中,如果API调用实体请求的第一API为可实例化的API提供实体的API,可由网管系统对可实例化的API提供实体进行实例化后,通过实例化后的API提供实体提供可用的接口信息。在以下实施例中,如果API调用实体请求的第一API为已实例化的API提供实体的可上线或可激活API,可由已实例化的API提供实体对第一API进行上线或激活后提供可用的接口信息。
如图12所示,图12是本申请实施例提供的又一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S1201,第二API提供实体向CCF实体发送第二API信息,所述第二API信息包括可上线或可激活的API、和/或可上线或可激活的API的可用性。
其中,第二API信息还可以包括可上线或可激活的API的名称、类型和服务区域等信息,但不包括可上线或可激活的API的接口信息(例如IP地址、端口号、URI等),因此API调用实体无法调用可上线或可激活的API。
可选的,所述第二API信息还可以包括指示信息,所述指示信息用于指示在对可上线或可激活的API进行上线或激活后可用。
其中,第二API实体可以为已实例化的API提供实体。
S1202,CCF实体向第二API提供实体返回第三响应。
具体的,当CCF实体接收到第二API信息时,所述第三响应可以为确认响应,当CCF实体未接收到第二API信息时,所述第三响应可以为否定确认响应。
S1203,第一API提供实体向CCF实体发送第三请求。
其中,第三请求用于请求将第一API提供实体注册至CCF实体,以支持第一API提供实体成为使用CAPIF功能的授权实体。第三请求可以为API注册请求。
其中,第一API提供实体可以为已实例化的API提供实体。
S1204,CCF实体向第一API提供实体发送第四响应。
具体的,若第一API提供实体注册至CCF实体成功,则第四响应为确认响应,若第一API提供实体注册至CCF实体失败,则第四响应为否定确认响应。
S1205,第一API提供实体向CCF实体发送第四请求。
其中,第四请求用于请求CCF实体对第一API提供实体进行检查与授权后存储第一API提供实体提供的API信息。第四请求可以为API发布请求。
其中,第四请求中可以包括第一API提供实体提供的API信息,API信息包括API的名称、API类型、服务区域和接口信息(如IP地址,端口号,URI等)。
可选的,第四请求中还可以包括可共享信息。可共享信息用于指示其他CCF实体可以共享第一API提供实体提供的API信息。
S1206,CCF实体向第一API提供实体发送第五响应。
具体的,CCF实体接收第四请求之后,对第一API提供实体进行检查与授权,若授权成功,则第五响应为确认响应,CCF实体存储第一API提供实体提供的API信息,若授权失败,则第五响应为否定确认响应。
S1207,API调用实体向CCF实体发送第五请求。
其中,第五请求用于请求将API调用实体注册至CCF实体,以支持API调用实体成为使用CAPIF功能的授权实体。第五请求可以为API注册请求。
S1208,CCF实体向API调用实体发送第六响应。
具体的,若API调用实体注册至CCF实体成功,则第六响应为确认响应,若API调用实体注册至CCF实体失败,则第六响应为否定确认响应。
S1209,API调用实体向CCF实体发送第一请求。
其中,第一请求用于请求从CCF实体预先保存的第一API信息中查询API调用实体请求的第一API。所述第一请求可以包括API调用实体请求的第一API。第一请求可以为API发现请求。
S1210,CCF实体从预先保存的第一API信息中查询所述第一API是否可用。
其中,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API。如表7所示,表7是CCF实体预先存储的第一API信息的统计表。统计表包括API的名称、接口信息和可用信息。API#1和API#2为第一API提供实体通过S1203-S1206发布至CCF实体,API#3和API#4为第二API提供实体通过S1201-S1202提供或配置至CCF实体。第一API提供实体对应的第一API信息中包括API的接口信息,因此第一API提供实体的API可用。第二API提供实体对应的第一API信息中不包括API的接口信息,因此第二API提供实体的API不可用,需要对API#3和API#4上线或激活后可用。
表7
具体的,若CCF实体从预先保存的第一API信息中查询到所述第一API可用,则向API调用实体发送第一API的接口信息,以便API调用实体通过第一API的接口信息调用第一API进行服务。若CCF实体从预先保存的第一API信息中查询到所述第一API不可用,则确定请求对第一API进行上线或激活。
例如,API调用实体请求的第一API为API#1和API#4,从表7可知,API#1为第一API提供实体的API,具有接口信息,API#1是可用的API。API#4为第二API提供实体的API,不具有接口信息,API#4是不可用的API。因此CCF实体确定请求对API#4进行上线或激活。
S1211,CCF实体向第二API提供实体发送第二请求。
其中,所述第二请求用于请求对所述第一API进行上线或激活,第二请求可以为上线或激活请求。
其中,第二请求可以包括第一API的名称、类型和服务区域中的一项或多项。
S1212,第二API提供实体对所述第一API进行上线或激活。通过对第一API进行上线或激活可以获取第一API的接口信息。
S1213,第二API提供实体向所述CCF实体发送第一响应。
具体的,若第二API提供实体对第一API进行上线或激活成功,则第一响应可以为确认响应,第一响应包括所述第一API的接口信息,接口信息包括第一API的IP地址、端口号和URI等。可选的,第一响应还可以包括第一API的名称、类型和服务区域中的一项或多项。若第二API提供实体对第一API进行上线或激活失败,则第一响应可以为否定确认响应。
其中,第一响应可以为上线或激活响应。
S1214,CCF实体向API调用实体发送第二响应。
其中,第二响应可以包括第一API的接口信息。可选的,第二响应还可以包括第一API的名称、类型和服务区域中的一项或多项。第二响应可以为API发现响应。
S1215,API调用实体接收到第二响应之后,获取第一API的接口信息,通过第一API的接口信息调用第一API进行服务。
S1216,第二API提供实体将第二API提供实体提供的API信息发布至CCF实体,以支持后续API调用实体可以对上线或激活后的API进行发现和调用。
具体实现过程与S1203-S1206类似,此处不再赘述。
在本申请实施例中,CCF实体接收API调用实体请求的第一API之后,根据第一API的可用性确定是否请求第二API提供实体对第一API进行上线或激活。通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
以上实施例是由CCF实体判断是否触发请求执行上线或激活过程。下一个实施例是由API调用实体判断是否触发请求执行上线或激活过程。
如图13所示,图13是本申请实施例提供的又一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S1301-S1308与上一实施例中S1201-S1208相同,具体实现方式可以参考S1201-S1208,此处不再赘述。
S1309,API调用实体向CCF实体发送第六请求。
其中,第六请求用于请求从CCF实体保存的第一API信息中查询API调用实体请求的第一API。第一请求可以包括API调用实体请求的第一API,第一请求可以为API发现请求。
S1310,CCF实体向API调用实体发送第一响应。
其中,第一响应包括CCF实体反馈给API调用实体的API信息,该API信息可以包括可上线或可激活的API、和/或可上线或可激活的API的可用性。该API信息还可以包括已上线或已激活的API和/或已上线或已激活的API的可用性。第一响应可以为API发现响应。
如表8所示,表8是CCF实体反馈给API调用实体的API信息的统计表。例如,API调用实体请求的第一API为API#1和API#4,因此CCF实体反馈API#1和API#4的API信息。其中,API#1为第一API提供实体通过S1303-S1306发布至CCF实体的已上线或已激活的API,API#4为第二API提供实体通过S1301-S1302提供或配置至CCF实体的可上线或可激活的API。第一API提供实体对应的API信息中包括API的接口信息,因此API#1是可用的。第二API提供实体对应的API信息中不包括API的接口信息,因此API#4是不可用的,需要对API#4进行上线或激活。
表8
可选的,所述第一响应还可以包括指示信息,所述指示信息用于指示对可上线或可激活的API进行上线或激活后可用。
S1311,API调用实体根据所述可上线或可激活的API、和/或所述可上线或可激活的可用性,确定所述API调用实体请求的第一API是否可用。
具体的,若API调用实体确定API调用实体请求的第一API可用,则API调用实体可以通过第一API的接口信息调用第一API接口进行服务。若API调用实体确定第一API不可用,则API调用实体确定请求对第一API进行上线或激活。
例如,API调用实体请求的第一API为API#1和API#4,从表8可知,API#1为第一API提供实体的API,具有接口信息,API#1是可用的API。API#4为第二API提供实体的API,不具有接口信息,API#4是不可用的API。因此CCF实体确定请求对API#4进行上线或激活。
S1312,API调用实体向CCF实体发送第一请求。
其中,所述第一请求用于指示在对所述第一API进行上线或激活后可用的第一API。第一请求可以为API调用通知请求消息。
其中,第一请求可以包括第一API的名称、类型和服务区域中的一项或多项。
S1313,CCF实体向第二API提供实体发送第二请求。
其中,所述第二请求用于请求对所述第一API进行上线或激活,第二请求可以为上线或激活请求。
其中,第二请求可以包括第一API的名称、类型和服务区域中的一项或多项。
S1314,第二API提供实体对所述第一API进行上线或激活。通过对第一API进行上线或激活可以获取第一API的接口信息。
S1315,第二API提供实体向CCF实体发送第三响应。
具体的,若第二API提供实体对第一API进行上线或激活成功,则第三响应可以为确认响应,第三响应包括所述第一API的接口信息,接口信息包括第一API的IP地址、端口号和URI等。可选的,第三响应还可以包括第一API的名称、类型和服务区域中的一项或多项。若第二API提供实体对第一API进行上线或激活失败,则第三响应可以为否定确认响应。
其中,第三响应可以为上线或激活响应。
S1316,CCF实体向API调用实体发送第二响应。
其中,第二响应可以包括第一API的接口信息。可选的,第二响应还可以包括第一API的名称、类型和服务区域中的一项或多项。第二响应可以为API发现响应。
S1317,API调用实体接收到第二响应之后,获取第一API的接口信息,通过第一API的接口信息调用第一API进行服务。
S1318,第二API提供实体将第二API提供实体提供的API信息发布至CCF实体,以支持后续API调用实体可以对上线或激活后的API进行发现和调用。
在本申请实施例中,API调用实体接收可上线或可激活的API、和/或可上线或可激活的API的可用性之后,确定是否请求对第一API进行上线或激活。通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,通过第一API的接口信息调用第一API进行服务。实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
以上实施例是针对API调用实体和API提供实体由单个CCF实体控制,对API进行上线或激活流程,下一个实施例是针对API调用实体和API提供实体由多个CCF实体控制,对API进行上线或激活流程,并且由CCF实体判断是否触发请求执行上线或激活过程。
如图14所示,图14是本申请实施例提供的又一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S1401,第二API提供实体向第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活API的可用性。
其中,第二API信息还可以包括第一CCF实体控制范围内的可上线或可激活的API的名称、类型和服务区域等信息,但不包括可上线或可激活的API的接口信息(例如IP地址、端口号、URI等),因此API调用实体无法调用可上线或可激活的API。
可选的,所述第二API信息还可以包括指示信息,所述指示信息用于指示第一CCF实体控制范围内的可上线或可激活的API在上线或激活后可用。
S1402,第一CCF实体向第二API提供实体返回第四响应。
具体的,当第一CCF实体接收到第二API信息时,所述第四响应可以为确认响应,当第一CCF实体未接收到第二API信息时,所述第四响应可以为否定确认响应。
S1403-S1406与S1203-S1206相同,具体实现方式可以参考S1203-S1206,此处不再赘述。
S1407,第一CCF实体向第二CCF实体发送第三请求。所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。
可选的,第三请求还可以包括指示信息,该指示信息用于指示第一CCF实体控制范围内可上线或可激活的API进行上线或激活后可用。
其中,第三请求可以为API发布请求。
S1408,第二CCF实体向第一CCF实体发送第七响应。
具体的,第二CCF实体接收到第三请求之后,对第一CCF实体进行检查和授权,如果授权成功,则存储第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性,向第一CCF实体返回的第七响应为确认响应。如果授权成功,向第一CCF实体返回的第七响应为否定确认响应。
S1409-S1410与S1207-S1208相同,具体实现方式可以参考S1207-S1208,此处不再赘述。
S1411,API调用实体向第二CCF实体发送第四请求,所述第四请求包括所述API调用实体请求的第一API。
其中,第四请求可以API发现请求。
S1412,第二CCF实体从预先保存的第三API信息中查询所述第一API是否可用。其中,所述第三API信息包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。
需要说明的是,经过上述S1401-S1402以及S1407-S1408之后,第二CCF实体上存储的第三API信息包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。第三API信息还可以包括第二CCF实体的标识、第二CCF实体控制范围内的可上线或可激活的API和/或所述第二CCF实体控制范围内的可上线或可激活的API的可用性。第三API信息还可以包括第二CCF实体的标识、第二CCF实体控制范围内已上线或已激活的API和/或第二CCF实体控制范围内已上线或已激活的API的可用性。
例如,如表9所示,表9是第二CCF实体上存储的第三API信息的统计表。第二CCF实体上存储的第三API信息包括CCF#1控制范围内的API#1和API#2的名称、接口信息和可用性,CCF#2控制范围内的API#3和API#4的名称、接口信息和可用性。CCF#3控制范围内的API#4和API#5的名称、接口信息和可用性。其中,CCF#2控制范围内的API#3和API#4不具有接口信息,因此CCF#2控制范围内的API#3和API#4不可用,需要对CCF#2控制范围内的API进行上线或激活。CCF#3控制范围内的API#4和API#5不具有接口信息,因此CCF#3控制范围内的API#4和API#5不可用,需要对CCF#3控制范围内的API进行上线或激活。
表9
具体的,若所述第一API不可用,则第二CCF实体从多个CCF实体中选取所述第一API对应的第一CCF实体。若所述第一API可用,则第二CCF实体向API调用实体返回第一API的接口信息,以便API调用实体通过第一API的接口信息调用第一API接口进行服务。
例如,API调用实体请求的第一API为API#1和API#4。从表9可知,API#1可以由CCF#1控制范围内的API提供实体提供,具有接口信息,API#1是可用的。API#4可以由CCF#2控制范围内的API提供实体和CCF#3控制范围内的API提供实体,不具有接口信息,API#4是不可用的,需要从CCF#2和CCF#3上选择一个CCF实体,避免对多个CCF实体控制范围内的API进行上线或激活,造成资源浪费。
S1413,第二CCF实体向第一CCF实体发送第一请求。
其中,所述第一请求包括API调用实体请求的第一API。第一请求还可以包括第一CCF实体的标识。第一请求可以为API发现请求。
S1414-S1417与图12所示的实施例中S1210-S1213相同,具体实现方式可以参考S1214-S1213,此处不再赘述。
S1418,第一CCF实体向第二CCF实体发送第二响应。
其中,第二响应可以包括第一API的接口信息。第二响应还可以包括第一API的名称、类型和服务区域中一项或多项。第二响应可以为API发现响应。
S1419,第二CCF实体向API调用实体发送第三响应。
其中,第三响应可以包括第一API的接口信息。第二响应还可以包括第一API的名称、类型和服务区域中一项或多项。第三响应可以为API发现响应。
S1420-S1421与图12所示的实施例中S1215-S1216相同,具体实现方式可以参考S1215-S1216,此处不再赘述。
在本申请实施例中,第二CCF实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
上一个实施例是由CCF实体判断是否触发请求执行上线或激活过程,下一个实施例是由API调用实体判断是否触发请求执行上线或激活过程,并且是针对API调用实体和API提供实体由多个CCF实体控制,对API进行上线或激活流程。
如图15所示,图15是本申请实施例提供的又一种通信方法的流程示意图。该通信方法主要包括如下步骤:
S1501-S1510与图14所示的实施例中S1401-S1410相同,具体实现方式可以参考S1401-S1410,此处不再赘述。
S1511,API调用实体向第二CCF实体发送第九请求。
其中,第九请求用于请求查询API调用实体请求的第一API。第九请求可以包括API调用实体请求的第一API,第九请求可以为API发现请求。
S1512,第二CCF实体向第一CCF实体发送第三请求。
其中,第三请求用于请求查询API调用实体请求的第一API。所述第三请求包括API调用实体请求的第一API,第三请求还可以包括第一CCF实体的标识。第三请求可以为API发现请求。
S1513,第一CCF实体向第二CCF实体发送第三响应。
其中,所述第三响应包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可上线或可激活的API、和/或所述第一CCF实体控制范围内的可上线或可激活的API的可用性。第三响应可以为API发现响应。
可选的,第三响应还可以包括指示信息,该指示信息用于指示在对第一CCF实体控制范围内的可上线或可激活的API进行上线或激活后可用。
S1514,第二CCF实体向API调用实体发送第四响应。
其中,所述第四响应包括多个CCF实体控制范围内的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体。进一步的。所述第四响应可以包括多个CCF实体控制范围内的可上线或可激活的API和/或所述可上线或可激活的API的可用性。所述第四响应还可以包括多个CCF实体控制范围内的已上线或已激活的API和/或已上线或已激活的API的可用性。第四响应可以为API发现响应。
可选的,第四响应还可以包括指示信息,该指示信息用于指示在对多个CCF实体控制范围内内的可上线或可激活的API进行上线或激活后可用。
如表10所示,表10是第二CCF实体反馈给API调用实体的API信息的统计表。例如,API调用实体请求的第一API为API#1和API#4,因此第二CCF实体反馈API#1和API#4的API信息。其中,API#1是CCF#1控制范围内的已上线或已激活的API,API#4是CCF#2和CCF#3控制范围的可上线或可激活的API。CCF#1控制范围内的已上线或已激活的API具有接口信息,API#1是可用的。CCF#2和CCF#3控制范围的可上线或可激活的API不具有接口信息,API#4是不可用的,需要对CCF#2和CCF#3控制范围内的API进行上线或激活。
表10
S1515,API调用实体根据多个CCF实体控制范围内的API的可用性,确定API调用实体请求的第一API是否可用。
具体的,若所述第一API可用,则API调用实体可以通过第一API的接口信息调用第一API进行服务。若所述第一API不可用,则API调用实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
例如,API调用实体请求的第一API为API#1和API#4,从表10可知,API#1为CCF#1控制范围内的API,具有接口信息,API#1是可用的API。API#4为CCF#2和CCF#3控制范围的API,不具有接口信息,API#4是不可用的API。因此CCF实体从CCF#2和CCF#3中选取一个CCF#2,请求对CCF#2控制范围内的API进行上线或激活。
S1516,API调用实体向第二CCF实体发送第四请求。
其中,所述第四请求包括所述第一CCF实体的标识和所述第一API,所述第一CCF实体的标识和所述第一API用于请求对所述第一CCF实体控制范围内的所述第一API进行上线或激活。第四请求可以为API调用通知请求。
可选的,第四请求包括第一API的名称、类型和服务区域中的一项或多项。
在本申请实施例中,第一CCF实体控制范围内的所述第一API为第二API提供实体的API。
具体的,第二CCF实体接收到第四请求之后,可以根据第一CCF实体的标识,确定第一API是由第一CCF实体控制范围内的API提供实体提供的,因此确定请求对第一CCF实体控制范围内的第一API进行上线或激活。
S1517,第二CCF实体向第一CCF实体发送第一请求。
其中,所述第一请求用于请求对第一CCF实体控制范围内的第一API进行上线或激活。所述第一请求包括API调用实体请求的第一API。
可选的,第一请求可以包括第一API的名称、类型和服务区域中的一项或多项。第一请求可以为API调用通知请求。
S1518-S1525与图14所示的实施例中S1414-S1421相同,具体实现方式可以参考S1414-S142,此处不再赘述。
在本申请实施例中,API调用实体根据多个CCF实体控制范围内的API的可用性,进行CCF实体选择。在跨CCF实体执行API发现流程时,第一CCF实体基于自身控制范围内的多个API的可用性,确定是否请求对第一API进行上线或激活,通过第二API提供实体对第一API对应的API提供实体进行上线或激活,使得API调用实体获得第一API的接口信息,实现按照需求上线或激活相应的API,避免API提供实体的资源浪费,提高资源的利用率。
需要说明的是,以上各个实施例中的各个步骤的执行先后顺序并不限定,各个步骤可以合并也可以拆分。
本申请实施例可以根据上述方法示例对API提供实体、API调用实体、CCF实体和网管系统进行功能模块的划分,例如,可以对应各个功能划分各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以使用硬件的形式实现,也可以使用软件功能模块的形式实现。需要说明的是,本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。下面以使用对应各个功能划分各个功能模块为例进行说明。
如图16所示,图16是本申请实施例提供的一种通信装置的示意图。该通信装置可以包括接收模块1601、处理模块1602和发送模块1603。接收模块1601和发送模块1603可以与外部进行通信,接收模块1601和发送模块1603还可以称为通信接口、收发单元或收发模块,处理模块1602可以执行处理相关动作。该接收模块1601、处理模块1602和发送模块1603可以用于执行上文方法实施例中CCF实体所执行的动作。
在一种可能的设计中,该固件升级装置可实现对应于上文方法实施例中的CCF实体执行的步骤或者流程,例如,可以为CCF实体,或者配置于CCF实体中的芯片或电路。
需要说明的是,各个模块的实现还可以对应参照图8-图15所示的方法实施例的相应描述,执行上述实施例中CCF实体所执行的方法和功能。
如图17所示,图17是本申请实施例提供的另一种通信装置的示意图。该通信装置可以包括接收模块1701、处理模块1702和发送模块1703。接收模块1701和发送模块1703可以与外部进行通信,接收模块1701和发送模块1703还可以称为通信接口、收发单元或收发模块,处理模块1702可以执行处理相关动作。该接收模块1701、处理模块1702和发送模块1703可以用于执行上文方法实施例中网管系统所执行的动作。
在一种可能的设计中,该通信装置可实现对应于上文方法实施例中的网管系统执行的步骤或者流程,例如,可以为网管系统,或者配置于网管系统中的芯片或电路。
需要说明的是,各个模块的实现还可以对应参照图8-图15所示的方法实施例的相应描述,执行上述实施例中网管系统所执行的方法和功能。
如图18所示,图18是本申请实施例提供的又一种通信装置的示意图。该通信装置可以包括接收模块1801、处理模块1802和发送模块1803。接收模块1801和发送模块1803可以与外部进行通信,接收模块1801和发送模块1803还可以称为通信接口、收发单元或收发模块,处理模块1802可以执行处理相关动作。该接收模块1801、处理模块1802和发送模块1803可以用于执行上文方法实施例中API调用实体所执行的动作。
在一种可能的设计中,该通信装置可实现对应于上文方法实施例中的API调用实体执行的步骤或者流程,例如,可以为API调用实体,或者配置于API调用实体中的芯片或电路。
需要说明的是,各个模块的实现还可以对应参照图8-图15所示的方法实施例的相应描述,执行上述实施例中API调用实体所执行的方法和功能。
如图19所示,图19是本申请实施例提供的又一种通信装置的示意图。该通信装置可以包括接收模块1901、处理模块1902和发送模块1903。接收模块1901和发送模块1903可以与外部进行通信,接收模块1901和发送模块1903还可以称为通信接口、收发单元或收发模块,处理模块1902可以执行处理相关动作。该接收模块1901、处理模块1902和发送模块1903可以用于执行上文方法实施例中API提供实体所执行的动作。
在一种可能的设计中,该通信装置可实现对应于上文方法实施例中的API提供实体执行的步骤或者流程,例如,可以为API提供实体,或者配置于API提供实体中的芯片或电路。
需要说明的是,各个模块的实现还可以对应参照图8-图15所示的方法实施例的相应描述,执行上述实施例中API提供实体所执行的方法和功能。
图20是本申请实施例提供的一种CCF实体的结构示意图。该CCF实体可应用于如图1-图3所示的系统中,执行上述方法实施例中CCF实体的功能,或者实现上述方法实施例中CCF实体执行的步骤或者流程。
如图20所示,该CCF实体包括处理器2001和收发器2002。可选地,该CCF实体还包括存储器2003。其中,处理器2001、收发器2002和存储器2003之间可以通过内部连接通路互相通信,传递控制和/或数据信号,该存储器2003用于存储计算机程序,该处理器2001用于从该存储器2003中调用并运行该计算机程序,以控制该收发器2002收发信号。可选地,CCF实体还可以包括天线,用于将收发器2002输出的上行数据或上行控制信令通过无线信号发送出去。
上述处理器2001可以与图16中的接收模块和发送模块对应,上述处理器2001可以和存储器2003可以合成一个处理装置,处理器2001用于执行存储器2003中存储的程序代码来实现上述功能。具体实现时,该存储器2003也可以集成在处理器2001中,或者独立于处理器2001。
上述收发器2002可以与图16中的接收模块和发送模块对应,也可以称为收发单元或收发模块。收发器2002可以包括接收器(或称接收机、接收电路)和发射器(或称发射机、发射电路)。其中,接收器用于接收信号,发射器用于发射信号。
应理解,图20所示的CCF实体能够实现图8-图15所所示方法实施例中涉及CCF实体的各个过程。CCF实体中的各个模块的操作和/或功能,分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述,为避免重复,此处适当省略详述描述。
上述处理器2001可以用于执行前面方法实施例中描述的由CCF实体内部实现的动作,而收发器2002可以用于执行前面方法实施例中描述的CCF实体发送或接收的动作。具体请见前面方法实施例中的描述,此处不再赘述。
其中,处理器2001可以是中央处理器单元,通用处理器,数字信号处理器,专用集成电路,现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器2001也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,数字信号处理器和微处理器的组合等等。通信总线2004可以是外设部件互连标准PCI总线或扩展工业标准结构EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图20中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。通信总线2004用于实现这些组件之间的连接通信。其中,本申请实施例中收发器2002用于与其他节点设备进行信令或数据的通信。存储器2003可以包括易失性存储器,例如非挥发性动态随机存取内存(nonvolatile random access memory,NVRAM)、相变化随机存取内存(phasechange RAM,PRAM)、磁阻式随机存取内存(magetoresistive RAM,MRAM)等,还可以包括非易失性存储器,例如至少一个磁盘存储器件、电子可擦除可编程只读存储器(electricallyerasable programmable read-only memory,EEPROM)、闪存器件,例如反或闪存(NORflash memory)或是反及闪存(NAND flash memory)、半导体器件,例如固态硬盘(solidstate disk,SSD)等。存储器2003可选的还可以是至少一个位于远离前述处理器2001的存储装置。存储器2003中可选的还可以存储一组计算机程序代码或配置信息。可选的,处理器2001还可以执行存储器2003中所存储的程序。处理器可以与存储器和收发器相配合,执行上述申请实施例中CCF实体的任意一种方法和功能。
图21是本申请实施例提供的一种网管系统的结构示意图。该网管系统可应用于如图1-图3所示的系统中,执行上述方法实施例中网管系统的功能,或者实现上述方法实施例中网管系统执行的步骤或者流程。
如图21所示,该网管系统包括处理器2101和收发器2102。可选地,该网管系统还包括存储器2103。其中,处理器2101、收发器2102和存储器2103之间可以通过内部连接通路互相通信,传递控制和/或数据信号,该存储器2103用于存储计算机程序,该处理器2101用于从该存储器2103中调用并运行该计算机程序,以控制该收发器2102收发信号。可选地,网管系统还可以包括天线,用于将收发器2102输出的上行数据或上行控制信令通过无线信号发送出去。
上述处理器2101可以与图17中的处理模块对应,上述处理器2101可以和存储器2103可以合成一个处理装置,处理器2101用于执行存储器2103中存储的程序代码来实现上述功能。具体实现时,该存储器2103也可以集成在处理器2101中,或者独立于处理器2101。
上述收发器2102可以与图17中的发送模块和接收模块对应,也可以称为收发单元或收发模块。收发器2102可以包括接收器(或称接收机、接收电路)和发射器(或称发射机、发射电路)。其中,接收器用于接收信号,发射器用于发射信号。
应理解,图21所示的网管系统能够实现图8-图16所示方法实施例中涉及网管系统的各个过程。网管系统中的各个模块的操作和/或功能,分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述,为避免重复,此处适当省略详述描述。
上述处理器2101可以用于执行前面方法实施例中描述的由网管系统内部实现的动作,而收发器2102可以用于执行前面方法实施例中描述的网管系统发送或接收的动作。具体请见前面方法实施例中的描述,此处不再赘述。
其中,处理器2101可以是前文提及的各种类型的处理器。通信总线2104可以是外设部件互连标准PCI总线或扩展工业标准结构EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图21中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。通信总线2104用于实现这些组件之间的连接通信。其中,本申请实施例中设备的收发器2102用于与其他设备进行信令或数据的通信。存储器2103可以是前文提及的各种类型的存储器。存储器2103可选的还可以是至少一个位于远离前述处理器2101的存储装置。存储器2103中存储一组计算机程序代码或配置信息,且处理器2101执行存储器2103中程序。处理器可以与存储器和收发器相配合,执行上述申请实施例中网管系统的任意一种方法和功能。
图22是本申请实施例提供的一种API调用实体的结构示意图。该API调用实体可应用于如图1-图3所示的系统中,执行上述方法实施例中API调用实体的功能,或者实现上述方法实施例中API调用实体执行的步骤或者流程。
如图22所示,该API调用实体包括处理器2201和收发器2202。可选地,该API调用实体还包括存储器2203。其中,处理器2201、收发器2202和存储器2203之间可以通过内部连接通路互相通信,传递控制和/或数据信号,该存储器2203用于存储计算机程序,该处理器2201用于从该存储器2203中调用并运行该计算机程序,以控制该收发器2202收发信号。可选地,API调用实体还可以包括天线,用于将收发器2202输出的上行数据或上行控制信令通过无线信号发送出去。
上述处理器2201可以与图18中的处理模块对应,上述处理器2201可以和存储器2203可以合成一个处理装置,处理器2201用于执行存储器2203中存储的程序代码来实现上述功能。具体实现时,该存储器2203也可以集成在处理器2201中,或者独立于处理器2201。
上述收发器2202可以与图18中的发送模块和接收模块对应,也可以称为收发单元或收发模块。收发器2202可以包括接收器(或称接收机、接收电路)和发射器(或称发射机、发射电路)。其中,接收器用于接收信号,发射器用于发射信号。
应理解,图22所示的API调用实体能够实现图8-图16所示方法实施例中涉及API调用实体的各个过程。API调用实体中的各个模块的操作和/或功能,分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述,为避免重复,此处适当省略详述描述。
上述处理器2201可以用于执行前面方法实施例中描述的由API调用实体内部实现的动作,而收发器2202可以用于执行前面方法实施例中描述的API调用实体发送或接收的动作。具体请见前面方法实施例中的描述,此处不再赘述。
其中,处理器2201可以是前文提及的各种类型的处理器。通信总线2204可以是外设部件互连标准PCI总线或扩展工业标准结构EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图22中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。通信总线2204用于实现这些组件之间的连接通信。其中,本申请实施例中设备的收发器2202用于与其他设备进行信令或数据的通信。存储器2203可以是前文提及的各种类型的存储器。存储器2203可选的还可以是至少一个位于远离前述处理器2201的存储装置。存储器2203中存储一组计算机程序代码或配置信息,且处理器2201执行存储器2203中程序。处理器可以与存储器和收发器相配合,执行上述申请实施例中API调用实体的任意一种方法和功能。
图23是本申请实施例提供的一种API提供实体的结构示意图。该API提供实体可应用于如图1-图3所示的系统中,执行上述方法实施例中API提供实体的功能,或者实现上述方法实施例中API提供实体执行的步骤或者流程。
如图23所示,该API提供实体包括处理器2301和收发器2302。可选地,该API提供实体还包括存储器2303。其中,处理器2301、收发器2302和存储器2303之间可以通过内部连接通路互相通信,传递控制和/或数据信号,该存储器2303用于存储计算机程序,该处理器2301用于从该存储器2303中调用并运行该计算机程序,以控制该收发器2302收发信号。可选地,API提供实体还可以包括天线,用于将收发器2302输出的上行数据或上行控制信令通过无线信号发送出去。
上述处理器2301可以与图19中的处理模块对应,上述处理器2301可以和存储器2303可以合成一个处理装置,处理器2301用于执行存储器2303中存储的程序代码来实现上述功能。具体实现时,该存储器2303也可以集成在处理器2301中,或者独立于处理器2301。
上述收发器2302可以与图19中的发送模块和接收模块对应,也可以称为收发单元或收发模块。收发器2302可以包括接收器(或称接收机、接收电路)和发射器(或称发射机、发射电路)。其中,接收器用于接收信号,发射器用于发射信号。
应理解,图23所示的API提供实体能够实现图8-图16所示方法实施例中涉及API提供实体的各个过程。API提供实体中的各个模块的操作和/或功能,分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述,为避免重复,此处适当省略详述描述。
上述处理器2301可以用于执行前面方法实施例中描述的由API提供实体内部实现的动作,而收发器2302可以用于执行前面方法实施例中描述的API提供实体发送或接收的动作。具体请见前面方法实施例中的描述,此处不再赘述。
其中,处理器2301可以是前文提及的各种类型的处理器。通信总线2304可以是外设部件互连标准PCI总线或扩展工业标准结构EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图23中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。通信总线2304用于实现这些组件之间的连接通信。其中,本申请实施例中设备的收发器2302用于与其他设备进行信令或数据的通信。存储器2303可以是前文提及的各种类型的存储器。存储器2303可选的还可以是至少一个位于远离前述处理器2301的存储装置。存储器2303中存储一组计算机程序代码或配置信息,且处理器2301执行存储器2303中程序。处理器可以与存储器和收发器相配合,执行上述申请实施例中API提供实体的任意一种方法和功能。
本申请实施例还提供了一种芯片系统,该芯片系统包括处理器,用于支持CCF实体、管理网管、API调用实体和API提供实体以实现上述任一实施例中所涉及的功能,例如生成或处理上述方法中所涉及的实例化过程、或上线或激活过程。在一种可能的设计中,所述芯片系统还可以包括存储器,所述存储器,用于CCF实体、管理网管、API调用实体和API提供实体必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他分立器件。其中,芯片系统的输入和输出,分别对应方法实施例CCF实体、管理网管、API调用实体和API提供实体的接收与发送操作。
根据本申请实施例提供的方法,本申请还提供一种计算机程序产品,该计算机程序产品包括:计算机程序,当该计算机程序在计算机上运行时,使得该计算机执行图8-图15所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法,本申请还提供一种计算机可读介质,该计算机可读介质存储有计算机程序,当该计算机程序在计算机上运行时,使得该计算机执行图8-图15所示实施例中任意一个实施例的方法。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,高密度数字视频光盘(digital video disc,DVD))、或者半导体介质(例如,固态硬盘(solid state disc,SSD))等。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。

Claims (29)

1.一种通信方法,其特征在于,所述方法包括:
通用应用编程接口框架核心功能CCF实体接收应用编程接口API调用实体发送的第一请求,所述第一请求包括所述API调用实体请求的第一API;
所述CCF实体从预先保存的第一API信息中查询所述第一API是否可用,所述第一API信息包括多个API的可用性,所述多个API包括所述第一API;
若所述第一API不可用,则所述CCF实体确定请求对所述第一API对应的API提供实体进行实例化。
2.如权利要求1所述的方法,其特征在于,所述方法还包括:
所述CCF实体向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;
所述CCF实体接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
3.如权利要求2所述的方法,其特征在于,所述方法还包括:
所述CCF实体向所述API调用实体发送第二响应,所述第二响应包括所述第一API的接口信息。
4.如权利要求2或3所述的方法,其特征在于,所述方法还包括:
当所述第一API对应的API提供实体包括多个API提供实体时,所述CCF实体从所述多个API提供实体中选取目标API提供实体;
其中,所述第二请求包括所述目标API提供实体的标识,所述第二请求用于请求对所述目标API提供实体进行实例化。
5.如权利要求1-4任一项所述的方法,其特征在于,所述CCF实体接收API调用实体发送的第一请求之前,还包括:
所述CCF实体接收网管系统发送的第二API信息,所述第二API信息包括可实例化的API提供实体的API和/或可实例化的API提供实体的API的可用性。
6.一种通信方法,其特征在于,所述方法包括:
网管系统接收通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一应用编程接口API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
所述网管系统对所述第一API对应的API提供实体进行实例化;
所述网管系统向所述CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
7.如权利要求6所述的方法,其特征在于,所述方法还包括:
所述网管系统向所述CCF实体发送第二API信息,所述第二API信息包括可实例化的API提供实体的API和/或所述可实例化的API提供实体的API的可用性。
8.如权利要求6或7所述的方法,其特征在于,所述网管系统对所述第一API对应的API提供实体进行实例化包括:
当所述第一API对应的API提供实体包括多个API提供实体时,所述网管系统从所述多个API提供实体中选取目标API提供实体;
所述网管系统对所述目标API提供实体进行实例化。
9.一种通信方法,其特征在于,所述方法包括:
应用编程接口API调用实体向通用应用编程接口框架核心功能CCF实体发送第一请求,所述第一请求包括所述API调用实体请求的第一API;
所述API调用实体接收所述CCF实体发送的第二响应,所述第二响应包括实例化所述第一API对应的API提供实体后获得的所述第一API的接口信息。
10.一种通信方法,其特征在于,所述方法包括:
第一通用应用编程接口框架核心功能CCF实体接收第二CCF实体发送的第一请求,所述第一请求包括API调用实体请求的第一API;
所述第一CCF实体从预先保存的第一应用编程接口API信息中查询所述第一API是否可用,所述第一API信息包括所述第一CCF实体控制范围内的多个API的可用性,所述多个API包括所述第一API;
若所述第一API不可用,则所述第一CCF确定请求对所述第一API对应的API提供实体进行实例化。
11.如权利要求10所述的方法,其特征在于,所述方法还包括:
所述第一CCF实体向网管系统发送第二请求,所述第二请求用于请求对所述第一API对应的API提供实体进行实例化;
所述第一CCF实体接收所述网管系统发送的第一响应,所述第一响应包括所述第一API的接口信息。
12.如权利要求11所述的方法,其特征在于,所述方法还包括:
所述第一CCF实体向所述第二CCF实体发送第二响应,所述第二响应包括所述第一API的接口信息。
13.如权利要求11或12所述的方法,其特征在于,所述方法还包括:
当所述第一API对应的API提供实体包括多个API提供实体时,所述第一CCF实体从所述多个API提供实体中选取目标API提供实体;
其中,所述第二请求包括所述目标API提供实体的标识,所述第二请求用于请求对所述目标API提供实体进行实例化。
14.如权利要求10-13任一项所述的方法,其特征在于,所述第一CCF实体接收第二CCF实体发送的第一请求之前,还包括:
所述第一CCF实体接收网管系统发送的第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
15.如权利要求10-14任一项所述的方法,其特征在于,所述第一CCF实体接收第二CCF实体发送的第一请求之前,还包括:
所述第一CCF实体向所述第二CCF实体发送第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
16.一种通信方法,其特征在于,所述方法包括:
第二通用应用编程接口框架核心功能CCF实体接收应用编程接口API调用实体发送的第四请求,所述第四请求包括所述API调用实体请求的第一API;
所述第二CCF实体从预先保存的第三API信息中查询所述第一API是否可用,所述第三API信息包括多个CCF实体控制范围内的API提供实体的API的可用性,所述多个CCF实体包括所述第一CCF实体和第二CCF实体;
若所述第一API不可用,则所述第二CCF实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体。
17.如权利要求16所述的方法,其特征在于,所述第二CCF实体从所述多个CCF实体中选取所述第一API对应的第一CCF实体之后,还包括:
所述第二CCF实体向所述第一CCF实体发送第一请求,所述第一请求包括API调用实体请求的第一API;
所述第二CCF实体接收所述第一CCF实体发送的第二响应,所述第二响应包括所述第一API的接口信息。
18.如权利要求16或17所述的方法,其特征在于,所述第二CCF实体接收API调用实体发送的第四请求之前,还包括:
所述第二CCF实体接收所述第一CCF实体发送的第三请求,所述第三请求包括所述第一CCF的标识、以及所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
19.如权利要求16-18任一项所述的方法,其特征在于,所述方法还包括:
所述第二CCF实体向所述API调用实体发送第三响应,所述第三响应包括所述第一API的接口信息。
20.如权利要求16-19任一项所述的方法,其特征在于,所述第二CCF实体接收API调用实体发送的第四请求之前,还包括:
所述第二CCF实体接收网管系统发送的第四API信息,所述第四API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
21.一种通信方法,其特征在于,所述方法包括:
网管系统接收第一通用应用编程接口框架核心功能CCF实体发送的第二请求,所述第二请求用于请求对第一应用编程接口API对应的API提供实体进行实例化,所述第一API为应用编程接口API调用实体请求的API;
所述网管系统对所述第一API对应的API提供实体进行实例化;
所述网管系统向所述第一CCF实体发送第一响应,所述第一响应包括所述第一API的接口信息。
22.如权利要求21所述的方法,其特征在于,所述方法还包括:
所述网管系统向所述第一CCF实体发送第二API信息,所述第二API信息包括所述第一CCF实体控制范围内的可实例化的API提供实体的API和/或所述第一CCF实体控制范围内的可实例化的API提供实体的API的可用性。
23.如权利要求21所述的方法,其特征在于,所述方法还包括:
所述网管系统向所述第二CCF实体发送第四API信息,所述第四API信息包括所述第二CCF实体控制范围内的可实例化的API提供实体的API和/或所述第二CCF实体控制范围内的可实例化的API提供实体的API的可用性。
24.如权利要求21-23任一项所述的方法,其特征在于,所述网管系统对所述第一API对应的API提供实体进行实例化包括:
当所述第一API对应的API提供实体包括多个API提供实体时,所述网管系统从所述多个API提供实体中选取目标API提供实体;
所述网管系统对所述目标API提供实体进行实例化。
25.一种通信方法,其特征在于,所述方法包括:
应用编程接口API调用实体向第二通用应用编程接口框架核心功能CCF实体发送第四请求,所述第四请求包括所述API调用实体请求的第一API;
所述API调用实体接收所述第二CCF实体发送的第三响应,所述第三响应包括实例化所述第一API对应的API提供实体后获得的所述第一API的接口信息,所述第一API的接口信息用于所述API调用实体调用所述第一API进行服务。
26.一种通信装置,其特征在于,包括处理器和存储器,所述存储器用于存储计算机程序,所述处理器运行所述计算机程序以使得所述装置执行权利要求1-5中任一项、权利要求6-8中任一项、权利要求9、权利要求10-15中任一项、权利要求16-20中任一项、权利要求21-24中任一项或权利要求25所述的方法。
27.一种计算机可读存储介质,其特征在于,用于存储计算机程序,当所述计算机程序在计算机上运行时,使所述计算机执行权利要求1-25中任一项所述的方法。
28.一种通信系统,其特征在于,所述通信系统包括通用应用编程接口框架核心功能CCF实体、应用编程接口API调用实体和网管系统,其中,所述CCF实体用于执行如权利要求1-5中任一项或权利要求10-20中任意一项所述的方法,所述网管系统用于执行如权利要求6-8中任一项或权利要求21-24中任意一项所述的方法,所述API调用实体用于执行如权利要求9或25所述的方法。
29.如权利要求28所述的通信系统,其特征在于,所述通信系统还包括API提供实体,所述CCF实体为边缘使能服务器EES,所述API调用实体为第一边缘应用服务器EAS,所述API提供实体为除所述第一EAS之外的其他EAS,所述网管系统为EAS实例化管理系统。
CN202211215653.2A 2022-09-30 2022-09-30 一种通信方法及装置 Pending CN117857548A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202211215653.2A CN117857548A (zh) 2022-09-30 2022-09-30 一种通信方法及装置
PCT/CN2023/120184 WO2024067313A1 (zh) 2022-09-30 2023-09-20 一种通信方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211215653.2A CN117857548A (zh) 2022-09-30 2022-09-30 一种通信方法及装置

Publications (1)

Publication Number Publication Date
CN117857548A true CN117857548A (zh) 2024-04-09

Family

ID=90476253

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211215653.2A Pending CN117857548A (zh) 2022-09-30 2022-09-30 一种通信方法及装置

Country Status (2)

Country Link
CN (1) CN117857548A (zh)
WO (1) WO2024067313A1 (zh)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111279319A (zh) * 2017-09-30 2020-06-12 甲骨文国际公司 容器组的动态迁移
CN111164573A (zh) * 2017-10-06 2020-05-15 康维达无线有限责任公司 启用雾服务层并应用于智能运输系统
CN110661638B (zh) * 2018-06-30 2021-04-20 华为技术有限公司 一种通信方法及装置
CN110730499B (zh) * 2018-07-16 2021-06-15 华为技术有限公司 一种mec信息获取方法及装置
CN111435924B (zh) * 2019-01-14 2021-08-31 华为技术有限公司 调用应用程序接口的方法和装置
WO2022067736A1 (zh) * 2020-09-30 2022-04-07 华为技术有限公司 一种通信方法及装置

Also Published As

Publication number Publication date
WO2024067313A1 (zh) 2024-04-04

Similar Documents

Publication Publication Date Title
CN111279316B (zh) 网络中的应用功能及其控制
CN109391592B (zh) 网络功能服务的发现方法及设备
CN111865598A (zh) 网络功能服务的身份校验方法及相关装置
US10389848B2 (en) Message transmission method and core network interface device
US9065832B2 (en) Method and apparatus for automated network connectivity for managed application components within a cloud
JP2022084690A (ja) エイリアスベースのアドレス指定発呼方法および装置
CN113630266B (zh) 一种实例化边缘应用服务器的方法和装置
US10951718B2 (en) Protocol for anycast based discovery of local resources
CN112740642A (zh) 通信方法及多接入边缘计算服务器
CN113037761B (zh) 登录请求的验证方法及装置、存储介质、电子设备
CN112995247A (zh) 数据发送或处理的方法、装置和系统
KR20190108371A (ko) 네트워크 슬라이스/서비스를 선택하는 통신 방법 및 이를 수행하는 통신 장치
JP7437853B2 (ja) サービス要求の処理
CN113079207B (zh) 一种实现端口或网络高可用的方法、系统、终端及介质
CN112492592A (zh) 一种多个nrf场景下的授权方法
CN114727361A (zh) 一种用于网络功能选择的处理方法、装置和网络设备
CN111917810B (zh) 一种云通信方法及装置、用户设备、网络设备
CN117857548A (zh) 一种通信方法及装置
Tangudu et al. Common framework for 5G northbound APIs
CN112910796B (zh) 流量管理方法、装置、设备、存储介质以及程序产品
CN116711265A (zh) 用于间接通信的访问令牌处理
US11863520B2 (en) Data access methods and systems
CN116155890B (zh) 分布式文件系统的实现方法及装置
EP3965394A1 (en) Method for controlling an internet-based communication
WO2023246681A1 (zh) 一种通信方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination