CN109495929B - 一种业务处理方法、移动边缘计算设备及网络设备 - Google Patents

Abstract

本申请公开了一种业务处理方法、移动边缘计算设备及网络设备，用以解决现有技术中存在的MEC的资源利用率低的技术问题。该方法包括：第一移动边缘计算设备接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；所述第一移动边缘计算设备向第二移动边缘计算设备发送第二业务请求；其中，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容，以及所述第一移动边缘计算设备的标识信息；所述第一移动边缘计算设备从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据。

Description

一种业务处理方法、移动边缘计算设备及网络设备

技术领域

本申请涉及通信技术领域，尤其涉及一种业务处理方法、移动边缘计算设备及网络设备。

背景技术

随着业务类型的多样化以及业务数量的不断增长，为了降低通信网络对业务请求的响应时延，现有的移动通信技术网络中，例如第四代移动通信技术(4th Generation,4G)网络或者第五代移动通信技术(5th generation，5G)网络，采用一种利用移动边缘计算设备(Mobile Edge Computing，MEC)的能力开放架构进行业务处理，该能力开放架构如图1所示。

在图1所示的能力开放架构中，将部分数据处理与存储的功能前移至MEC。其中，每一个预设区域内设置一个MEC，通过该区域内的MEC对该区域内的终端设备的业务请求进行集中处理。

由于每个MEC的覆盖区域内的终端设备的业务量不同，因此，现有技术中的业务处理方法会造成MEC的资源利用率低。

发明内容

本申请实施例提供一种业务处理方法、移动边缘计算设备及网络设备，用以解决现有技术中存在的MEC的资源利用率低的技术问题。

第一方面，本申请实施例提供了一种业务处理方法，该方法可以应用于第一移动边缘计算设备中，该第一移动边缘计算设备可以是能力开放架构中的任一移动边缘计算设备，在该方法中，当第一移动边缘计算设备接收到包含业务类型和/或业务内容第一业务请求后，可以向第二移动边缘计算设备发送第二业务请求，该第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容，以及所述第一移动边缘计算设备的标识信息，最后从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据。

在上述技术方案中，当移动边缘计算设备接收到业务请求后，可以将业务请求中的一部分业务或者全部业务转发给其他移动边缘计算设备进行处理，这样，当某个移动边缘计算设备接收到大量的业务请求时，可以将业务请求转发至较空闲的移动边缘计算设备进行处理，从而使多个移动边缘计算设备可以协同处理业务请求，可以提高移动边缘计算设备的资源利用率。

在一种可能的实现方式中，在该第一移动边缘计算设备向第二移动边缘计算设备发送第二业务请求之前，该第一移动边缘计算设备根据该第一移动边缘计算设备部署的业务类型和/或业务内容，确定该第一移动边缘计算设备需要向该第二移动边缘计算设备发送该第二业务请求。

在上述技术方案中，移动边缘计算设备可以在接收到业务请求后，先根据本地部署的业务类型和/或业务内容，确定该移动边缘计算设备自身是否能够处理，如果处理不了，则确定需要转发给其他移动边缘计算设备进行处理，然后再将该业务请求转发至其他移动边缘计算设备，可以提高业务处理效率。

在一种可能的实现方式中，该第一移动边缘计算设备向第二移动边缘计算设备发送第二业务请求之前，该第一移动边缘计算设备根据移动边缘计算设备的信息列表，确定该第二移动边缘计算设备；其中，该移动边缘计算设备的信息列表中包含该第二移动边缘计算设备的信息。

在上述技术方案中，移动边缘计算设备可以在接收到业务请求后，先根据移动边缘计算设备的信息列表，确定能够处理该业务请求的第二移动边缘计算设备，然后再将该业务请求转发至确定的移动边缘计算设备，从而节省移动边缘计算设备之间的信令资源，可以提高业务处理效率。

在一种可能的实现方式中，移动边缘计算设备的信息列表包括至少一个移动边缘计算设备的标识信息；或者，该移动边缘计算设备的信息列表包括该至少一个移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

在上述技术方案中，该移动边缘计算设备的信息列表可以是只包含部分或者全部移动边缘计算设备的标识信息，例如第一移动边缘计算设备本地存储的移动边缘计算设备的信息列表可以只包含其邻居移动边缘计算设备的标识信息，可以节省移动边缘计算设备的存储空间；

该移动边缘设备的信息列表也可以包含部分或者全部移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容，这样，第一移动边缘计算设备可以根据该信息列表准确的确定出能够处理该业务请求的第二移动边缘计算设备，可以提高业务处理效率。

在一种可能的实现方式中，该移动边缘计算设备的信息列表部署在该第一移动边缘计算设备，该第一移动边缘计算设备查询该移动边缘计算设备的信息列表，确定能够用于处理该第二业务请求的至少一个移动边缘计算设备，然后，该第一移动边缘计算设备向该至少一个移动边缘计算设备发送第一询问消息，该第一询问消息包含该业务类型的至少部分业务类型和/或该业务内容的至少部分业务内容，并从该至少一个移动边缘计算设备接收应答消息，最后根据接收到的应答消息，从该至少一个移动边缘计算设备中确定该第二移动边缘计算设备。

在上述技术方案中，第一移动边缘计算设备可以根据本地部署的移动边缘计算设备的信息列表，采用发送询问消息的方式确定第二移动边缘计算设备，从而每个移动边缘计算设备可以根据当前处理业务的实际情况，确定是否能够处理该业务请求，并反馈应答消息，这样，第一移动边缘计算设备确定出的第二移动边缘计算设备可以是较佳的，例如，第二移动边缘计算设备的业务处理量较少，可以减少该业务请求的等待时长，提高业务处理效率。

在一种可能的实现方式中，该移动边缘计算设备的信息列表部署在管理设备，该第一移动边缘计算设备首先向该管理设备发送查询请求，该查询请求包含该业务类型的至少部分业务类型和/或该业务内容的至少部分业务内容，然后，从该管理设备接收与至少一个移动边缘计算设备对应的至少一个标识信息，该移动边缘计算设备的信息列表中包含该至少一个标识信息，最后，该第一移动边缘计算设备根据该至少一个标识信息，从该至少一个移动边缘计算设备确定该第二移动边缘计算设备。

在上述技术方案中，提供另外一种确定第二移动边缘计算设备的方法。第一移动边缘计算设备可以根据管理设备部署的移动边缘计算设备的信息列表，采用发送查询消息的方式确定第二移动边缘计算设备。

在一种可能的实现方式中，该第一移动边缘计算设备根据与该第二业务请求对应的业务数据，获得与该第一业务请求对应的业务数据，该第一移动边缘计算设备发送与该第一业务请求对应的业务数据。

在上述技术方案中，当第一移动边缘计算设备从第二移动边缘计算设备中接收到业务数据后，可以直接将该业务数据作为与第一业务请求对应的业务数据；也可以对该业务处理进行处理后，获得与第一业务请求对应的业务数据，例如，第二移动边缘计算设备是多个时，可以将多个第二移动边缘计算设备发送的业务数据进行聚合处理等，从而获得最终的业务数据，第一移动边缘计算设备可以根据实际情况灵活确定与第一业务请求对应的业务数据。

第二方面，本申请实施例提供一种业务处理方法，该方法应用于管理设备中，该管理设备首先从第一移动边缘计算设备接收第一业务请求，该第一业务请求包含业务类型和/或业务内容，然后，该管理设备向该第一移动边缘计算设备发送与该第一业务请求对应的业务数据。

在上述技术方案中，管理设备可以接收移动边缘计算设备发送的业务请求，并向该移动边缘计算设备发送与该业务请求对应的业务数据，这样，当某个移动边缘计算设备接收到大量的业务请求时，可以将业务请求转发至管理设备进行处理，从而移动边缘计算设备可以和管理设备协同处理业务请求，可以提高移动边缘计算设备及管理设备的资源利用率。

在一种可能的实现方式中，该管理设备可以向第二移动边缘计算设备发送第二业务请求，该第二业务请求包含该业务类型的至少部分业务类型和/或该业务内容的至少部分业务内容，然后从该第二移动边缘计算设备接收与该第二业务请求对应的业务数据。

在上述技术方案中，当管理设备接收到业务请求后，可以向其他移动边缘计算设备转发与该业务请求对应的第二业务请求，利用其它移动边缘计算设备对该第二业务请求进行处理，从而可以使多个移动边缘计算设备协同处理该业务请求，可以提高多个移动边缘计算设备的资源利用率。

在一种可能的实现方式中，在该管理设备向第二移动边缘计算设备发送该第二业务请求之前，该管理设备根据该管理设备部署的移动边缘计算设备的信息列表，确定该第二移动边缘计算设备，该移动边缘计算设备的信息列表中包含该第二移动边缘计算设备的信息。

在上述技术方案中，该管理设备可以在获取第二业务请求后，先根据移动边缘计算设备的信息列表，确定能够处理该第二业务请求的第二移动边缘计算设备，然后再将该第二业务请求转发至确定的移动边缘计算设备，从而节省管理设备与移动边缘计算设备之间的信令资源，可以提高业务处理效率。

在一种可能的实现方式中，移动边缘计算设备的信息列表包括移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

在上述技术方案中，该移动边缘设备的信息列表也可以包含部分或者全部移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容，这样，管理设备可以根据该信息列表准确的确定出能够处理该第二业务请求的第二移动边缘计算设备，可以提高业务处理效率。

在一种可能的实现方式中，该管理设备首先根据与该第二业务请求对应的业务数据，获得与该第一业务请求对应的业务数据，然后，向该第一移动边缘计算设备发送与该第一业务请求对应的业务数据。

在上述技术方案中，当管理设备从第二移动边缘计算设备中接收到业务数据后，可以直接将该业务数据作为与第一业务请求对应的业务数据；也可以对该业务处理进行处理后，获得与第一业务请求对应的业务数据，例如，第二移动边缘计算设备是多个时，可以将多个第二移动边缘计算设备发送的业务数据进行聚合处理等，从而获得最终的业务数据，管理设备可以根据实际情况灵活确定与第一业务请求对应的业务数据。

第三方面，本申请实施例提供了一种移动边缘计算设备，该移动边缘计算设备具有实现上述第一方面方法中第一移动边缘计算设备行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

在一个可能的设计中，移动边缘计算设备的结构中包括处理器和发送器，所述处理器被配置为支持移动边缘计算设备执行上述第一方面方法中相应的功能。所述发送器用于支持移动边缘计算设备和其他设备之间的通信，向其他设备发送上述第一方面方法中所涉及的信息或者指令。所述移动边缘计算设备还可以包括存储器，所述存储器用于与处理器耦合，其保存必要的程序指令和数据。

第四方面，本申请实施例提供了一种网络设备，该网络设备具有实现上述第二方面方法中管理设备行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

在一个可能的设计中，网络设备的结构中包括处理器和发送器，所述处理器被配置为支持网络设备执行上述第二方面方法中相应的功能。所述发送器用于支持网络设备和其他设备之间的通信，向其他设备发送上述第一方面方法中所涉及的信息或者指令。所述网络设备还可以包括存储器，所述存储器用于与处理器耦合，其保存必要的程序指令和数据。

第五方面，本申请实施例提供了一种能力开放架构，该架构包括上述第一方面以及第三方面所述的移动边缘计算设备和/或第二方面以及第四方面所述的网络设备。

第六方面，本申请实施例提供了一种计算机存储介质，用于存储用于执行上述第一方面、第一方面的任意一种设计以及上述第二方面的功能所用的计算机软件指令，并包含用于执行上述第一方面、第一方面的任意一种设计以及上述第二方面的方法所设计的程序。

第七方面，本申请实施例提供了一种计算机程序产品，该计算机程序产品包含有指令，当该指令在计算机上运行时，使得所述计算机执行执行上述第一方面、第一方面的任意一种设计以及上述第二方面的方法。

第八方面，本申请实施例还提供了一种芯片系统，该芯片系统包括处理器，用于支持移动边缘计算设备实现上述第一方面所述的方法或用于支持网络设备实现上述第二方面的方法，例如，生成或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，该芯片系统还包括存储器，该存储器，用于保存移动边缘计算设备或网络设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其它分立器件。

在本申请实施例中，当移动边缘计算设备接收到业务请求后，可以将业务请求中的一部分业务或者全部业务转发给其他移动边缘计算设备或者管理设备进行处理，这样，当某个移动边缘计算设备接收到大量的业务请求时，可以将业务请求转发至管理设备或者较空闲的移动边缘计算设备进行处理，从而使多个移动边缘计算设备以及管理设备可以协同处理业务请求，可以提高移动边缘计算设备的资源利用率。

附图说明

图1为现有技术中的能力开放架构的示意图；

图2为现有技术中的业务处理方法的流程图；

图3为本申请实施例提供的一种能力开放架构的示意图；

图4为本申请实施例中提供的能力开放架构中的管理设备和MEC的功能模块示意图；

图5A-图5B为本申请实施例中提供的一种业务处理方法的流程图；

图6A-图6B为本申请实施例采用图5A所示的业务处理方法时步骤503的第四种发送方式的具体实现过程的流程图；

图7为本申请实施例采用图5A所示的业务处理方法时通过邻居节点信息表确定第二MEC的流程图；

图8为本申请实施例采用图5A所示的业务处理方法时通过NEF中的节点信息表确定第二MEC的流程图；

图9为本申请实施例采用图5B所示的业务处理方法时通过邻居节点信息表确定第二MEC的流程图；

图10为本申请实施例采用图5B所示的业务处理方法时通过NEF中的节点信息表确定第二MEC的流程图；

图11为本申请另一实施例中提供的一种业务处理方法的流程图；

图12A-图12B为本申请另一实施例中步骤1102的第三种发送方式的具体实现方式的流程图；

图13为本申请实施例中移动边缘计算设备的一种结构示意图；

图14为本申请实施例中网络设备的一种结构示意图；

图15为本申请实施例中移动边缘计算设备的另一种结构示意图；

图16为本申请实施例中网络设备的另一种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请实施例提供一种业务处理方法，该方法可以应用于通信系统中，例如4G网络或者5G网络，当然，也可以是其他的通信系统，例如，新无线(New Radio，NR)系统、无线保真(wifi)、全球微波互联接入(Worldwide Interoperability for Microwave Access，WiMAX)、全球移动通讯(Global System of Mobile communication，GSM)系统、码分多址(Code Division Multiple Access，CDMA)系统、宽带码分多址(Wideband Code DivisionMultiple Access，WCDMA)系统、通用分组无线业务(General Packet Radio Service，GPRS)、长期演进(Long Term Evolution，LTE)系统、先进的长期演进(Advanced long termevolution，LTE-A)系统、通用移动通信系统(Universal Mobile TelecommunicationSystem，UMTS)、以及第三代合作伙伴计划(The 3rd Generation Partnership Project，3GPP)相关的蜂窝系统等，该异系统可以为上述通信系统中的任意两种。

此外，该方法还可以适用于面向未来的通信技术，本申请实施例描述的系统是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

以下，对本申请实施例中的部分用语进行解释说明，以便于本领域技术人员理解。

(1)基站(Evolved Node B，eNB)，也可以称为网络设备，可以是指接入网中在空中接口上通过一个或多个小区与无线终端设备通信的设备。基站可用于将收到的空中帧与IP分组进行相互转换，作为终端设备与接入网的其余部分之间的路由器，其中接入网的其余部分可包括IP网络。基站还可协调对空中接口的属性管理。例如，基站可以包括长期演进(Long Term Evolution，LTE)系统或演进的LTE系统(LTE-Advanced，LTE-A)中的演进型基站(NodeB或eNB或e-NodeB，evolutional Node B)，或者也可以包括5G系统中的下一代节点B(next generation node B，gNB)，本申请实施例并不限定。

(2)终端设备，包括向用户提供语音和/或数据连通性的设备，例如可以包括具有无线连接功能的手持式设备、或连接到无线调制解调器的处理设备。该终端设备可以经无线接入网(Radio Access Network，RAN)与核心网进行通信，与RAN交换语音和/或数据。该终端设备可以包括用户设备(User Equipment，UE)、无线终端设备、移动终端设备、订户单元(Subscriber Unit)、订户站(Subscriber Station)，移动站(Mobile Station)、移动台(Mobile)、远程站(Remote Station)、接入点(Access Point，AP)、远程终端设备(RemoteTerminal)、接入终端设备(Access Terminal)、用户终端设备(User Terminal)、用户代理(User Agent)、或用户装备(User Device)等。例如，可以包括移动电话(或称为“蜂窝”电话)，具有移动终端设备的计算机，便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，智能穿戴式设备等。例如，个人通信业务(Personal Communication Service，PCS)电话、无绳电话、会话发起协议(SIP)话机、无线本地环路(Wireless Local Loop，WLL)站、个人数字助理(Personal Digital Assistant，PDA)、智能手表、智能头盔、智能眼镜、智能手环、等设备。还包括受限设备，例如功耗较低的设备，或存储能力有限的设备，或计算能力有限的设备等。例如包括条码、射频识别(RFID)、传感器、全球定位系统(GPS)、激光扫描器等信息传感设备。

(3)移动边缘计算设备(Mobile Edge Computing，MEC)：是靠近基站的设备，能够获取UE的数据报文，并对数据报文进行处理，然后将处理结果进行路由，从而对终端设备提供所需的服务。同时，也可以提供第三方应用集成，那么，MEC设备能够将终端设备的数据报文路由到相应的第三方应用服务器，并本地处理，如，在MEC上获取接入网侧的负载信息、无线链路质量信息，并反馈给内容优化处理单元，进行动态调整(主要用于视频码率调整)，从而可以提高用户的体验，减少时延和卡顿次数。

(4)服务网关(Serving Gateway，SGW)：主要负责终端设备的数据传输、转发以及路由切换等，并作为终端设备在基站之间切换时的本地移动性锚定点。

(5)分组数据网网关((Packet Data Network GateWay，PGW)：是外部网络发送给终端设备的数据的入口，负责终端设备的IP地址分配，终端设备的数据报文过滤、速率控制、生成计费信息等。终端设备可以通过连接到PGW创建分组数据网络(Packet DataNetwork，PDN)连接来访问外部PDN网络，这些PDN网络可以是Internet、虚拟私有网络(Virtual Private Network，VPN)、IP多媒体业务(IP Multi-media Service，IMS)网络，或者由运营商提供的无线应用协议(Wireless Application Protocol，WAP)网络等。

(6)本申请实施例中的术语“系统”和“网络”可被互换使用。“多个”是指两个或两个以上，鉴于此，本申请实施例中也可以将“多个”理解为“至少两个”。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，字符“/”，如无特殊说明，一般表示前后关联对象是一种“或”的关系。

目前，通信系统中的能力开放架构主要如图1所示，在这种场景下，通信系统的业务处理过程如图2所示。

步骤201：终端设备向基站发送业务请求。

步骤202：基站在接收该业务请求后，则将该业务请求转发至与该终端设备所在的区域对应的MEC。

步骤203：MEC判断是否能处理该业务请求，若MEC能处理该业务请求，则将该业务请求加入该MEC的请求队列中，等待处理，当处理完成后，则执行步骤206-步骤207。若MEC不能处理该业务请求，则执行步骤204-步骤207。

步骤204：MEC判断不能处理该业务请求，则MEC经由SGW以及PGW，将业务请求发送至云端进行处理。

步骤205：MEC从云端接收与该业务请求对应的业务数据。

步骤206：MEC将与该业务请求对应的业务数据反馈至基站。

步骤207：基站将与该业务请求对应的业务数据发送至终端设备，完成对该业务请求的处理。

在上述技术方案中，由于每个MEC的覆盖区域内的终端设备的数量不同，每个终端设备的业务量也不同，从而导致各个MEC需要处理的业务请求的数量也不相同，例如，在某一时刻，MEC1需要处理的业务请求的数量很多，而MEC2需要处理的业务请求的数量几乎为零，可见，现有技术中的业务处理方法会导致MEC的资源利用率低。

鉴于此，本申请实施例基于图3所示的能力开放架构提出了一种业务处理方法，用以提高MEC的资源利用率。

如图3所示，本申请实施例提供了一种能力开放架构。该能力开放架构中包括至少一个管理设备和多个MEC。其中，多个MEC中的每个MEC用于对终端设备的业务请求进行分析、匹配、分发、重构、处理以及缓存与业务请求对应的业务数据，管理设备主要用于对多个MEC进行识别以及管理，包括管理每个MEC的节点状态以及部署的业务类型等。该管理设备可以为网络能力开放(Network Exposure Function，NEF)设备，也可以是其他能够管理该多个MEC的设备或者控制节点等，在此不作限制。在本申请实施例中，以该管理设备为NEF设备为例进行说明。

如图3所示，该能力开放架构中还可以包含有多个基站，多个基站与多个MEC之间可以是预设的对应关系。例如，多个基站和多个MEC是一一对应的关系，即每个MEC管理一个基站发送的业务请求；当然，每个基站可能包括多个服务小区，因此，多个基站与多个MEC之间预设的对应关系也可以是多个基站的各个服务小区与MEC的对应关系。例如，基站包括有3个服务小区，分别为服务小区1-服务小区3，可以设置服务小区1和服务小区2与图3所示的MEC1对应，服务小区3与图3所示的MEC2对应，这样，来自服务小区1和服务小区2的各个终端设备发送的业务请求由MEC1处理，来自服务小区3的各个终端设备发送的业务请求由MEC2处理。当然，多个基站与多个MEC之间还可以设置其他的对应关系，在此不作限制。

例如，请参考图4，每个MEC中可以设置应用解析模块，用于分析终端设备的业务请求，确定该业务请求的业务类型与特征，提取该业务请求的关键数据等等，同时，为了加速业务处理过程，每个MEC中还可以设置有多个信息表，例如，业务类型表、节点信息表、数据资源表、功能模块表以及原请求队列，其中，业务类型表中存放已部署的应用服务；节点信息表中存放该MEC的邻居设备的状态信息、资源使用情况、已有的业务类型等；数据资源表用于存放数据资源，包括来自终端设备的感知数据、已获得的业务数据、云端传输的资源；原请求队列用于存放未解析的业务请求；功能模块表用于存放该MEC当前部署的功能模块。NEF中可以设置业务类型表用于存放NEF部署的业务类型；节点信息表用于存放其管理的多个MEC的每个MEC的节点信息，包括每个MEC的资源使用情况以及已部署的业务类型。请参考表1，为每个MEC及NEF中存储的信息表的标识符号及对应的描述。例如，M_ID为MEC的编号，取值为1、2、3…N中的任意整数，N为该NEF管理的多个MEC的总数量；M_State为MEC当前的工作状态，取值可以为1或0，当M_State＝1时，表征该MEC当前处于工作状态；当M_State＝0时，表征该MEC当前处于非工作状态。当标识符号为其他符号时，其对应的描述可参考表1所示，在此不再一一例举。

表1

如图4所示，NEF可以向每个MEC进行交互，例如，MEC可以向NEF发送查询请求，从而NEF根据该查询请求，查询其他MEC的节点状态信息、部署的业务类型以及当前的负载情况等，并将查询结果反馈至MEC。且，各个MEC之间也可以进行交互，例如，每个MEC设置有至少一个邻居设备以及至少一个非邻居设备，该邻居设备和非邻居设备具体可以是人工配置的，也可以是每个MEC根据预设规则自动确定的，例如根据距离值小于阈值的规则确定，在此不作限制。例如图4中MEC2-MEC5为MEC1的邻居设备，MEC6-MEC9为MEC2的非邻居设备，则MEC1可以直接与MEC2-MEC5中的任意MEC进行交互，例如MEC1将接收到的业务请求封装成新的业务请求发送给MEC2，MEC2在对新的业务请求进行处理后，将业务数据反馈至MEC1。当MEC1需要与MEC6-MEC9中的任一设备进行交互，例如MEC1与MEC6进行交互，则可以首先向NEF发送查询请求，然后NEF向MEC1反馈MEC6的节点信息，则MEC1根据NEF反馈的节点信息与MEC6进行交互。当然，各个MEC以及NEF之间还可以进行其他信息交互，具体请参考表2所示，在此不再一一例举。

表2

需要说明的是，图3所示的能力开放架构中所包含的NEF以及MEC的数量仅仅是一种例举，本申请实施例也并不限制于此。例如，还可以包含更多的NEF或者包含更多的MEC，为简明描述，不在附图中一一描述。此外，在图3所示的能力开放架构中，尽管示出了终端设备、基站、NEF、MEC1-MEC9、SGW、PGW以及云端，但所述能力开放架构中可以并不限于包括所述终端设备、基站、NEF、MEC1-MEC9、SGW、PGW以及云端，例如，还可以包括核心网设备或用于承载虚拟化网络功能的设备等，这些对于本领域普通技术人员而言是显而易见的，在此不再一一例举。

进一步，图4所示的MEC和NEF中设置的功能模块的内容以及数量、表1中所示的多种信息表的内容以及数量、表2中交互信息的内容以及数量也仅仅是一种例举，本领域普通技术人员还可以设置其他内容或数量的功能模块、信息表以及交互信息，在本申请实施例也并不限制于此。

由于现有技术中的业务处理方法会导致MEC的资源利用率低，在本申请实施例基于图3所示的能力开放架构提出的业务处理方法中，当第一移动边缘计算设备接收到包含业务类型和/或业务内容第一业务请求后，可以向第二移动边缘计算设备发送第二业务请求，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容，以及所述第一移动边缘计算设备的标识信息，最后从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据。

在上述技术方案中，当移动边缘计算设备接收到业务请求后，可以将业务请求中的一部分业务或者全部业务转发给其他移动边缘计算设备进行处理，这样，当某个移动边缘计算设备接收到大量的业务请求时，可以将业务请求转发至较空闲的移动边缘计算设备进行处理，从而使多个移动边缘计算设备可以协同处理业务请求，可以提高移动边缘计算设备的资源利用率。

下面结合附图介绍本申请实施例提供的技术方案，在下面的介绍过程中，以将本申请提供的技术方案应用在图3所示的能力开放架构中，且以管理设备为NEF，终端设备为UE，第一MEC为图3所示的多个MEC中的用于处理该UE对应的业务请求的MEC，例如MEC1，能力开放架构中的各个设备之间的交互信息为表1及表2中所示的信息为例。

请参考图5A及图5B，为本申请一实施例提供的一种业务处理方法，该方法的流程描述如下：

步骤501：UE向基站发送第一业务请求。

在本申请实施例中，第一业务请求可以是纯计算型请求，例如在线翻译的请求，可以是纯存储型请求，例如进行网络存储的请求，也可以是计算与存储综合型请求，例如进行导航的请求或者进行在线游戏的请求等，在此不作限制。在下面的描述中，以第一业务请求为业务请求Req_Service为例进行说明。

步骤502：基站接收该第一业务请求，并将该第一业务请求发送至MEC1。

在本申请实施例中，在基站的存储单元中，可以预先存储该基站的各个服务小区与MEC的对应关系。例如，基站由3个服务小区，分别为服务小区1、服务小区2以及服务小区3，其中服务小区1和服务小区2对应的MEC为图3中的MEC1，服务小区3对应的MEC为图3中的MEC2。基站在接收到UE发送的业务请求Req_Service后，则首先判断该UE所在的服务小区，例如，该UE所在的服务小区为服务小区2，则确定与该UE对应的MEC为MEC1，从而将该业务请求Req_Service发送至MEC1。

当然，基站的存储单元中也可以直接存储与自身对应的MEC的标识信息，例如，基站中存储的MEC的标识信息为MEC1，则该基站所有的服务小区中的UE均与MEC1对应，只要该基站接收到UE的业务请求，则直接将该业务请求发送至MEC1。当然，基站还可以通过其他方式确定发送至MEC1，例如，基站可以直接将该业务请求发送至距离基站最近的MEC，在此不作限制。

需要说明的是，步骤501和步骤502不是必须的，即，步骤501和步骤502可以不执行。例如，当该业务请求是第三方应用发送的，而不是由UE发送的，此时，便不执行步骤501和步骤502。

步骤503：MEC1向第二MEC发送第二业务请求。

在本申请实施例中，第二业务请求包含该第一业务请求的业务类型的至少部分业务类型和/或该第一业务请求的业务内容的至少部分业务内容，以及该第一移动边缘计算设备的标识信息。

在具体实现过程中，步骤503具体可以选择如下四种发送方式中的任意一种发送该第二MEC。

第一种发送方式：MEC1中预先存储有第二MEC的标识信息，例如，存储第二MEC的编号M_3，从而当MEC1在接收到该业务请求Req_Service后，则直接向MEC3发送与该业务请求Req_Service对应的第二业务请求。

第二种发送方式：MEC1首先根据移动边缘计算设备的信息列表，确定第二MEC，然后再向第二MEC发送第二业务请求。

在这种发送方式中，该移动边缘计算设备的信息列表中包含至少一个移动边缘计算设备的标识信息，例如，该第二MEC的编号；或者，该移动边缘计算设备的信息列表包括至少一个移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容，例如，MEC1中可以包含MEC2-MEC5的每个MEC的编号以及每个MEC部署的业务类型和/或每个MEC的资源数据表中的业务内容。该移动边缘计算设备的信息列表可以设置在MEC1中，例如，可以为表1中的MEC的邻居节点信息表M_NeigNodeTable；也可以设置在NEF中，例如，可以是表1中的NEF的节点信息表N_MECTable。当然，该移动边缘计算设备的信息列表也可以是其他类型的列表，该移动边缘计算设备的信息列表可以包含上述列表中的一个或者多个，在此不作限制。例如可以在下面的描述中，以该移动边缘计算设备的信息列表分别为MEC的邻居节点信息表M_NeigNodeTable以及NEF的节点信息表N_MECTable为例进行说明。

当该移动边缘计算设备的信息列表为MEC的邻居节点信息表M_NeigNodeTable时，MEC1可以通过查询自身的邻居节点信息表M_NeigNodeTable来确定第二MEC；当该移动边缘计算设备的信息列表为NEF的节点信息表N_MECTable时，则MEC1向NEF发送查询请求，然后由NEF查询节点信息表N_MECTable确定第二MEC后，将第二MEC的节点信息反馈至MEC1，从而MEC1便根据NEF反馈的节点信息确定第二MEC。

第三种发送方式：当MEC1在接收到该业务请求Req_Service后，首先根据MEC1部署的业务类型和/或业务内容，确定需要向第二MEC发送第二业务请求，然后则根据MEC1中预先存储的第二MEC的标识信息，例如，存储第二MEC的编号M_3，向MEC3发送与该业务请求Req_Service对应的第二业务请求。

例如，MEC1接收到该业务请求Req_Service后，可以对该业务请求进行解析，确定该业务请求Req_Service的业务类型Req_Type以及请求内容Req_KeyContent，然后确定是否需要向第二MEC发送第二业务请求，例如，可以判断MEC1自身部署的业务类型包括该业务类型Req_Type和/或MEC1自身的资源数据表中是否有与请求内容Req_KeyContent相同的业务数据，若判断结果为否，确定需要向第二MEC发送第二业务请求，则MEC1向MEC3发送与该业务请求Req_Service对应的第二业务请求。

第四种发送方式：当MEC1在接收到该业务请求Req_Service后，首先根据MEC1部署的业务类型和/或业务内容，确定需要向第二MEC发送第二业务请求，然后MEC1根据移动边缘计算设备的信息列表，确定第二MEC，最后向第二MEC发送第二业务请求。

在该发送方式中，MEC1根据MEC1部署的业务类型和/或业务内容，确定需要向第二MEC发送第二业务请求的方法与第三种方式中的确定方法相同，MEC1根据移动边缘计算设备的信息列表确定第二MEC的方法与第二种方式中的确定方法相同，在此不再赘述。

需要说明的是，第二MEC的数量可以是一个，也可以是多个，在本申请实施例中不作限制。

在上述四种发送方式中，第一种发送方式的实现过程比较简单，在下面的描述中不再赘述。由于第四种发送方式中包含了第二种发送方式和第三种发送方式中的主要步骤，因此，下面仅对第四种发送方式的实现过程进行详细描述，第二种发送方式和第三种发送方式中的实现过程可参考对第四种发送方式中相应步骤的描述即可，在本申请实施例中不再赘述。

请参考图6A-6B，为第四种发送方式的具体实现过程的流程图，具体步骤如下：

步骤601：MEC1接收该业务请求Req_Service并解析，确定需要向第二MEC发送第二业务请求。

在具体实现过程中，MEC1接收业务请求Req_Service后，首先对该业务请求Req_Service进行解析，确定该业务请求Req_Service的业务类型Req_Type，提取请求内容Req_KeyContent，同时将业务请求Req_Service存放至原请求队列M_ReqServiceTable中。然后，则根据该业务请求Req_Service的业务类型Req_Type、请求内容Req_KeyContent以及当前的负载情况M_Workload中的一个或多个因素，确定需要向第二MEC发送第二业务请求。例如，可以判断MEC1自身部署的业务类型包括该业务类型Req_Type，若不包括，则确定需要向第二MEC发送第二业务请求；或者，MEC1根据当前的负载情况M_Workload，确定MEC1处理的业务量已达到最大值，则确定需要向第二MEC发送第二业务请求。当然，还可以有其他的确定方式，在此不作限制。

在具体实现过程中，不同的业务请求可能需要不同的处理过程，在本申请实施例中，当MEC1解析接收的业务请求Req_Service后，可以确定该业务请求Req_Service所需的处理过程，然后根据业务请求所需的处理过程，确定是否需要向第二MEC发送第二业务请求。根据业务请求所需的处理过程确定是否需要向第二MEC发送第二业务请求，可以分为如下三种情况：

第一种情况：业务请求可以由一个MEC单独处理。

例如，MEC1解析该业务请求Req_Service后，根据该业务请求Req_Service的业务类型确定该业务请求Req_Service为纯计算型的在线翻译的请求，则MEC1可以通过查询业务类型表M_AppTypeTable或者数据资源表M_ResourceTable，以及当前负载情况M_Workload，综合决定需要向第二MEC发送第二业务请求。例如，判断该业务类型表M_AppTypeTable中是否部署有与该业务类型Req_Type相匹配的业务类型，若有，则确定不需要向第二MEC发送第二业务请求，否则确定需要向第二MEC发送第二业务请求；或者，MEC1判断该数据资源表M_ResourceTable中是否存储有与该请求内容Req_KeyContent相同的数据，若有，则确定不需要向第二MEC发送第二业务请求，否则确定需要向第二MEC发送第二业务请求；或者，MEC1也可以判断MEC1当前的负载量是否已经达到了预设上限值，如果当前的负载量未达到预设上限值，则确定不需要向第二MEC发送第二业务请求，否则确定确定需要向第二MEC发送第二业务请求。当然，也可以将结合前述三种因素一起进行判断。

需要说明的是，在这种情况下，第二业务请求包括该业务请求Req_Service的全部业务类型和/或该业务请求Req_Service的全部业务内容，以及MEC1的编号。

第二种情况：业务请求需要多个MEC协同处理。其中，协同处理的多个MEC中的每个MEC提供的业务类型相同。

例如，该业务请求Req_Service为道路拥堵情况查询，MEC1解析该业务请求Req_Service后，根据该业务请求Req_Service的业务内容确定单独一个MEC无法完成，所查询的路线上包括多个MEC，因此，需要所查路线上的所有MEC协同配合，方可得到整条道路的拥堵情况。此时，MEC1确定需要向第二MEC发送第二业务请求。

需要说明的是，MEC1可以进一步判断自身是否在该业务请求Req_Service所查询的路线上，从而确定第二业务请求包含的内容。例如，MEC1在所查询的路线上，则MEC1确定第二业务请求包括该业务请求Req_Service的部分业务类型和/或该业务请求Req_Service的部分业务内容，以及MEC1的编号；若MEC1不在所查询的路线上，MEC1确定第二业务请求包括该业务请求Req_Service的全部业务类型和/或该业务请求Req_Service的全部业务内容，以及MEC1的编号。

需要说明的是，在这种情况下，第二业务请求可以是多个子业务请求，每一个子业务请求由MEC进行处理，每个子业务请求中包括该子业务请求的业务类型和/或业务内容，以及MEC1的编号。

第三种情况：该业务请求的请求内容需要被拆分成多个独立的业务请求进行处理。

例如，该业务请求Req_Service为一个景点导游的业务请求，而景点导游信息本身可以包括景点路线、景点购物以及景点的停车位，因此，MEC1解析该业务请求Req_Service后，根据该业务请求Req_Service的业务类型以及业务内容，确定该业务请求Req_Service可以拆分为：景点路线的查询请求、景点购物的查询请求、景点的停车位查询请求，这样，将该业务请求Req_Service拆分成多个子业务请求，对于不同的子业务请求，可以请求不同的MEC处理，从而可以加速能力开放架构对业务请求的处理速度，降低服务延迟。此时，MEC1可以分别对这三个子业务请求进行判断，确定是否需要向第二MEC发送第二业务请求。若MEC1可以处理这三个子业务请求，则确定不需要向第二MEC发送第二业务请求；若MEC1只能处理这三个子业务请求中的其中一个或两个，则确定需要向第二MEC发送第二业务请求，此时，第二业务请求包括该业务请求Req_Service的部分业务类型和/或该业务请求Req_Service的部分业务内容，以及MEC1的编号。具体如何对每个子业务请求进行判断，可以参考第一种情况中MEC1判断第一种情况中对业务请求Req_Service的判断方法，在此不再赘述。

需要说明的是，在这种情况下，第二业务请求可以是多个子业务请求，每一个子业务请求由MEC进行处理，每个子业务请求中包括该子业务请求的业务类型和/或业务内容，以及MEC1的编号。

下面针对上述三种情况进行分别描述。

针对第一种情况，请参考图6A，第四种发送方式的具体实现过程如下，在执行步骤601后，执行步骤602-603。

步骤602：MEC1从其他MEC中确定第二MEC。

在本申请实施例中，步骤602的具体实现方式有如下两种。

第一种确定方式，通过邻居节点信息表M_NeigNodeTable确定第二MEC。请参考图7，方式A包括：

步骤701：MEC1查询邻居节点信息表M_NeigNodeTable，确定能够处理该业务请求的邻居设备。

在具体实现过程中，MEC1通过在邻居节点信息表M_NeigNodeTable，查询关键字，该关键字至少包括该业务请求Req_Service的业务类型Req_Type和/或请求内容Req_KeyContent，寻找与关键字相匹配的邻居MEC的节点信息。具体来讲，可以是查询邻居节点信息表M_NeigNodeTable中部署了该业务类型Req_Type和/或存储有该请求内容Req_KeyContent的邻居MEC。

例如，以关键字为该业务类型Req_Type为例，MEC1确定MEC2和MEC3部署了该业务类型Req_Type，则确定MEC2和MEC3为能够处理该业务请求的邻居设备。

步骤702：MEC1向能够处理该业务请求的邻居设备发送询问消息。

在本申请实施例中，该询问消息包含该业务请求的业务类型和/或该业务请求的请求内容。

当MEC1确定MEC2和MEC3为能够处理该业务请求Req_Service的邻居设备，则向MEC2和MEC3发送携带有该业务类型Req_Type和/或请求内容Req_KeyContent的询问信息。需要说明的是，在本申请实施例中，对询问信息的命名不作限制。

步骤703：能够处理该业务请求的邻居设备向MEC1反馈应答消息。

当MEC2和MEC3接收到MEC1发送的询问消息后，则MEC2和MEC3分别查询各自部署的业务类型以及当前的负载情况，确定是否能够处理该业务请求Req_Service，该确定过程可以参考步骤601，在此不再赘述。例如，MEC2确定能够处理该业务请求Req_Service，则向MEC1发送确认消息；MEC3确定不能处理该业务请求Req_Service，则向MEC1发送拒绝消息。在此，对确认消息和拒绝消息的具体形式及内容不作限制。

步骤704：MEC1基于应答消息确定第二MEC。

MEC1在接收到的应答消息中，确定反馈确认消息的邻居MEC为第二MEC，例如，MEC1确定MEC2为第二MEC。当然，若有多个邻居MEC均反馈确认消息，则MEC1可以按照预设选择规则选择其中一个作为第二MEC，该预设规则可以是选择距离最近的等，在此不作限制。

第二种确定方式，通过NEF中的节点信息表N_MECTable确定第二MEC。请参考图8，方式B包括：

步骤801：MEC1向NEF发送查询信息。

在本申请实施例中，该查询信息中至少包括该业务请求Req_Service的业务类型Req_Type和/或请求内容Req_KeyContent。

步骤802：NEF根据查询信息确定能够处理该业务请求的非邻居设备。其中，该非邻居设备为MEC1的非邻居MEC。

在具体实现过程中，NEF接收到查询消息后，则通过在节点信息表N_MECTable中查询关键字，该关键字至少包括该业务请求Req_Service的业务类型Req_Type和/或请求内容Req_KeyContent，寻找与关键字相匹配的非邻居MEC的节点信息。具体来讲，可以是查询节点信息表N_MECTable中部署了该业务类型Req_Type和/或存储有该请求内容Req_KeyContent的非邻居MEC。

例如，以关键字为该业务类型Req_Type为例，NEF确定MEC6和MEC7部署了该业务类型Req_Type，则确定MEC6和MEC7为能够处理该业务请求的非邻居设备。

步骤803：NEF向MEC1发送能够处理该业务请求的非邻居设备的节点信息。

在具体实施过程中，NEF可以将能够处理该业务请求的非邻居设备的编号发送至MEC1。例如，向MEC1发送M_6和M_7。

步骤804：MEC1接收该节点信息，并向该节点信息对应的MEC发送询问消息。

在本申请实施例中，该询问消息包含该业务请求的业务类型和/或该业务请求的请求内容。

MEC1接收由NEF发送的M_6和M_7后，则向MEC6和MEC7发送携带有该业务类型Req_Type和/或请求内容Req_KeyContent的询问信息。需要说明的是，在本申请实施例中，对询问信息的命名不作限制。

步骤805：能够处理该业务请求的非邻居设备向MEC1反馈应答消息。

当MEC6和MEC7接收到MEC1发送的询问消息后，则MEC6和MEC7分别查询各自部署的业务类型以及当前的负载情况，确定是否能够处理该业务请求Req_Service，并向MEC1反馈应答信息。该步骤与步骤703相同，在此不再赘述。

步骤806：MEC1基于应答消息确定第二MEC。

MEC1在接收到的应答消息中，确定反馈确认消息的非邻居MEC为第二MEC。该步骤与步骤704相同，在此不再赘述。

在具体实现过程中，MEC1可以通过上述两种方式中的任意一种方式确定第二MEC。当然，可以将上述两种方式进行结合，从而确定第二MEC。即，先通过方式A从邻居MEC中确定第二MEC，若邻居MEC无法处理该业务请求，则通过方式B从非邻居MEC中确定第二MEC。

在通过执行步骤602后，MEC1确定第二MEC，则执行步骤603。

步骤603：MEC1向第二MEC发送第二业务请求。

当MEC1确定第二MEC后，则将根据该业务请求Req_Service的业务类型Req_Type和/或请求内容Req_KeyContent，以及MEC1的标识信息生成第二业务请求，然后将该第二业务请求发送至第二MEC。

通过将业务请求重封装的方式，可以区别多个业务请求的来源，又可避免其他MEC对业务请求的二次解析，可以加快MEC处理与响应速度。

通过上述步骤，MEC1完成步骤503，请参考图5A，MEC1在执行完成步骤503后，执行步骤504-506。

步骤504：第二MEC对该第二业务请求进行处理，并向MEC1发送与第二业务请求对应的业务数据。

第二MEC在接收到该第二业务请求后，则对该第二业务请求进行处理，获取业务结果Req_Result，并将该业务结果Req_Result发送至MEC1。该业务结果Req_Result即为与第二业务请求对应的业务数据。

步骤505：MEC1接收与第二业务请求对应的业务数据，并将该业务数据反馈至基站。

步骤506：基站将该业务数据反馈至UE。

当然，若业务请求是由第三方应用发起的，则不执行步骤505-506，MEC1直接将该业务数据反馈至第三方应用。即，步骤505-506不是必须的。

需要说明的是，若MEC1确定不需要向第二MEC发送第二业务请求，则MEC1直接对该业务请求Req_Service进行处理，获得业务结果Req_Result，该业务结果Req_Result即为与该业务请求Req_Service对应的业务数据，然后将业务结果Req_Result反馈至UE或者第三方应用，在此不再赘述。

针对第二种情况和第三种情况，请参考图6B，第四种发送方式的具体实现过程如下，在执行步骤601后，执行步骤604-606。

步骤604：MEC1确定只能处理该业务请求的部分业务，则将无法处理的剩余部分业务重新封装为多个子业务请求。

在本申请实施例中，子业务请求Req_SubService以MEC1的编号M_ID、各个子请求的业务类型Req_Type作为业务标识。

例如，该业务请求Req_Service要查询的路线可以分为3个路段，其中，MEC1只覆盖路段1，因此，MEC1则将路段2的道路拥堵情况查询封装为子业务请求1，将路段3的道路拥堵情况查询封装为子业务请求2。当然，也可以将路段2的道路拥堵情况查询和路段3的道路拥堵情况查询封装成一个子业务请求，在此不作限制。

在下面的描述中将以MEC1将路段2的道路拥堵情况查询封装为子业务请求1，将路段3的道路拥堵情况查询封装为子业务请求2为例进行说明。

步骤605：从其他MEC中确定用于处理该多个子业务请求的第二MEC。

在本申请实施例中，该第二MEC为多个。步骤605的具体实现方式可以有如下两种。

方式A，通过邻居节点信息表M_NeigNodeTable确定第二MEC。请参考图9，方式A包括：

步骤901：MEC1查询邻居节点信息表M_NeigNodeTable，确定能够处理该多个子业务请求的邻居设备集合。

步骤901的具体实现步骤与步骤701相同，在此不再赘述。

例如，MEC1通过步骤901确定能够处理该多个子业务请求的邻居设备集合为MEC2-MEC5。

步骤902：MEC1向能够处理该多个子业务请求的邻居设备集合广播协同请求消息。

在本申请实施例中，该协同请求消息包含每个子业务请求的业务类型和/或每个子业务请求的请求内容。

需要说明的是，在本申请实施例中，对协同请求消息的命名不作限制。

步骤903：能够处理该多个子业务请求的邻居设备集合中的每个邻居设备向MEC1反馈应答消息。

当MEC2-MEC5接收到协同请求消息后，则分别查询各自部署的业务类型以及当前的负载情况，确定是否能够处理子业务请求1和/或子业务请求2。该确定过程可以参考步骤503中的第一种情况，在此不再赘述。例如，MEC2确定能够处理子业务请求1，则向MEC1发送与子业务请求1对应的确认消息；MEC3确定能够处理子业务请求2，则向MEC1发送与子业务请求2对应的确认消息；MEC4以及MEC5无法处理任何子业务请求，则分别向MEC1发送拒绝消息。在此，对确认消息和拒绝消息的具体形式及内容不作限制。

当然，一个MEC也可以能够处理多个子业务请求，例如，MEC3能够处理子业务请求1和子业务请求2，则可以向MEC1发送两个确认消息，或者在一个确认消息中携带两个子业务请求的标识信息，在此不作限制。

步骤904：MEC1基于应答消息确定目标MEC。

步骤904的具体实现步骤与步骤704相同，在此不再赘述。

方式B，通过NEF中的节点信息表N_MECTable确定目标MEC。请参考图10，方式B包括：

步骤1001：MEC1向NEF发送查询信息。

在本申请实施例中，该查询信息中至少包括多个子业务请求的业务类型和/或请求内容。

步骤1002：NEF根据查询信息确定能够处理该多个子业务请求的非邻居设备。

步骤1003：NEF向MEC1发送能够处理该业务请求的非邻居设备的节点信息集合。

步骤1002-1003的具体实现步骤可以参考步骤802-803，在此不再赘述。

例如，NEF通过步骤1002-1003确定能够处理该多个子业务请求的非邻居设备集合为MEC6-MEC9。

步骤1004：MEC1接收该节点信息集合，并向与该节点信息集合对应的多个MEC广播协同请求消息。

在本申请实施例中，该协同请求消息包含每个子业务请求的业务类型和/或每个子业务请求的请求内容。

需要说明的是，在本申请实施例中，对协同请求消息的命名不作限制。

步骤1005：非邻居设备集合中的非邻居设备向MEC1反馈应答消息。

当MEC6-MEC9接收到协同请求消息后，则分别查询各自部署的业务类型以及当前的负载情况，确定是否能够处理子业务请求1和/或子业务请求2，并向MEC1反馈应答消息。应答消息的形式及内容与步骤803相同，在此不再赘述。

步骤1006：MEC1基于应答消息确定第二MEC。

步骤1006的具体实现步骤与步骤704相同，在此不再赘述。

在具体实现过程中，MEC1可以通过上述两种方式中的任意一种方式确定第二MEC。当然，可以将上述两种方式进行结合，从而确定第二MEC。即，先通过方式A从邻居MEC确定第二MEC，若邻居MEC无法处理该多个子业务请求，则通过方式B从非邻居MEC确定第二MEC。

在通过执行步骤605后，MEC1确定第二MEC，则执行步骤606。

步骤606：MEC1向第二MEC发送子业务请求。

当MEC1确定第二MEC后，则向第二MEC发送该第二MEC能够处理的子业务请求Req_SubService。

例如，MEC1确定第二MEC为MEC6和MEC7，且MEC6用于处理子业务请求1，MEC7用于处理子业务请求2，则MEC1将子业务请求1发送至MEC6，将子业务请求2发送至MEC7。

通过上述步骤，MEC1完成步骤503，需要说明的是，在该实现方式中，第二业务请求即为多个子业务请求，请参考图5B，MEC1在执行完成步骤503后，执行步骤507-506。

步骤507：第二MEC对该子业务请求进行处理，并向MEC1发送与子业务请求对应的业务数据。

第二MEC在接收到该子业务请求Req_SubService后，则对该子业务请求Req_SubService进行处理，获取与子业务请求Req_SubService对应的业务结果Req_SubResult，并将该子业务结果Req_SubResult发送至MEC1。该子业务结果Req_SubResult即为与子业务请求对应的业务数据。

例如，MEC6对子业务请求1进行处理，获得业务结果1，并将业务结果1发送至MEC1；MEC7对子业务请求2进行处理，获得业务结果2，并将业务结果2发送至MEC1。

步骤508：MEC1根据接收的与子业务请求对应的业务数据，获取与第一业务请求对应的业务数据。

当MEC1接收到目标MEC发送的子业务请求对应的业务结果，例如，接收多个目标MEC发送的多个业务结果，则可以对多个业务结果进行聚合，获取与第一业务请求对应的业务数据。

步骤509：将该业务数据反馈至基站。

步骤510：基站将该业务数据反馈至终端设备。

当然，若业务请求是由第三方应用发起的，则不执行步骤509-510，MEC1直接将该业务数据反馈至第三方应用。即，步骤509-510不是必须的。

需要说明的是，针对第三种情况，若MEC1确定不需要向第二MEC发送第二业务请求，则MEC1直接对该业务请求Req_Service拆分成多个子业务请求，分别对每个子业务请求进行处理，将多个子业务请求的业务结果进行聚合，获得与业务请求Req_Service对应的业务结果Req_Result，最后将业务结果Req_Result反馈至UE或者第三方应用，在此不再赘述。

需要说明的是，当MEC1通过执行上述步骤获得与业务请求对应的业务数据后，还可以对该业务数据进行缓存处理，方便后续用户的访问，可以避免业务请求的二次解析与处理，节省网络通讯带宽和通讯成本。具体来讲，MEC1可以判断自身存储容量是否能缓存业务结果Req_Result，若能，则将业务结果Req_Result加入到数据资源表M_ResourceTable；若不能，查询邻居节点信息表M_NeigNodeTable，寻找能存储业务结果Req_Result的邻居MEC，若寻找到符合要求的邻居MEC，则将业务结果Req_Result发送至该MEC进行存储；若邻居MEC都不能缓存业务结果Req_Result，则MEC1可以将业务结果Req_Result发送至NEF进行存储。

在上述技术方案中，当MEC1无法处理该业务请求时，可以请求其他MEC进行处理，或者，多个MEC可以对同一个业务请求进行处理，实现了多个MEC之间的协同配合处理的效果，可以提高MEC的资源利用率。且由于多个MEC可以协同处理同一个业务请求，这样，可以缩短对业务请求的处理时长，提高用户的访问体验。

由于如图3所示的能力开放架构中还设置有管理设备，该管理设备也部署有业务类型表，即管理设备自身也可以对业务请求进行处理，鉴于此，本申请另一实施例提供一种业务处理方法，请参考图11，该方法的流程描述如下：

步骤1101：MEC1向NEF发送第一业务请求。

在具体实现过程中，MEC1可以参考步骤501-503的实现方式来接收第一业务请求，在此不再赘述。

在本申请实施例中，第一业务请求可以是MEC1接收到的原始业务请求，也可以是在MEC1对原始业务请求进行处理后的业务请求，具体过程可以为：MEC1接收原始业务请求后，对原始业务请求进行解析，获取原始业务请求的业务类型以及请求的业务内容，然后根据原始业务请求的业务类型、请求的业务内容以及MEC1的标识信息中的任意一个或多个因素进行重新封装，将封装后的业务请求作为第一业务请求，在此不作限制。

在获取第一业务请求后，MEC1可以采用如下两种方式中的任意一种，向NEF发送该第一业务请求，具体过程如下：

第一种发送方式：

MEC1直接将该第一业务请求发送至NEF。

第二种发送方式：

MEC1在获取第一业务请求之后，可以采用图7和/或图8所述的方法，先判断该第一业务请求是否可以由邻居MEC进行处理或者该第一业务请求是否可以由非邻居MEC进行处理，若邻居MEC及非邻居MEC均无法处理该第一业务请求，则MEC1将该第一业务请求发送至NEF。

步骤1102：NEF接收第一业务请求，获取与第一业务请求对应的业务数据。

在本申请实施例中，步骤1102具体可以包含如下三种实现方式，在具体实现过程中，可以选择其中的一种执行：

第一种实现方式：NEF在接收到第一业务请求后，则直接对第一业务请求进行处理，从而获取与第一业务请求对应的业务数据。

第二种实现方式：NEF中可以预先存储有第二MEC的标识信息，例如，存储第二MEC的编号M_3，从而当NEF在接收到该第一业务请求后，则直接向MEC3发送第二业务请求，然后由第二MEC对第二业务请求进行处理，并将与第二业务请求对应的业务数据反馈至NEF，NEF根据与第二业务请求对应的业务数据，获取与第一业务请求对应的业务数据。在本申请实施例中，第二业务请求包含该第一业务请求的业务类型的至少部分业务类型和/或该第一业务请求的业务内容的至少部分业务内容，也可以包含MEC1的标识信息。

第三种实现方式：NEF首先根据NEF部署的移动边缘计算设备的信息列表，确定第二MEC，然后再向第二MEC发送第二业务请求，然后由第二MEC对第二业务请求进行处理，并将与第二业务请求对应的业务数据反馈至NEF，NEF根据与第二业务请求对应的业务数据，获取与第一业务请求对应的业务数据。在本申请实施例中，第二业务请求包含该第一业务请求的业务类型的至少部分业务类型和/或该第一业务请求的业务内容的至少部分业务内容，也可以包含MEC1的标识信息。该移动边缘计算设备的信息列表中包括第二MEC的信息，例如，该移动边缘计算设备的信息列表中包括第二MEC的编号或所有的MEC的编号，当然，该移动边缘计算设备的信息列表中也可以包括移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容，在此不作限制。

需要说明的是，第二MEC的数量可以是一个，也可以是多个，在本申请实施例中不作限制。

在上述三种发送方式中，第一种发送方式的实现过程比较简单，在下面的描述中不再赘述。由于第三种发送方式中包含了第二种发送方式的主要步骤，因此，下面仅对第三种发送方式的实现过程进行详细描述，第二种发送方式的实现过程可参考对第三种发送方式中相应步骤的描述即可，在本申请实施例中不再赘述。

在本申请实施例中，由步骤601可知，不同的业务请求可能需要不同的处理过程，根据所需的处理过程的不同，业务请求主要分为三种情况：第一种情况：业务请求可以由一个MEC单独处理；第二种情况：业务请求需要多个MEC协同处理，其中，协同处理的多个MEC中的每个MEC提供的业务类型相同；第三种情况：该业务请求的请求内容需要被拆分成多个独立的业务请求进行处理。针对上述三种情况，步骤1102的第三种发送方式可以有如下两种实现方式，在具体实现过程中，可以选择其中任意一个进行执行，具体实现方式如下：

针对第一种情况，请参考图12A，为步骤1102的第三种发送方式的第一种实现方式的流程图，具体步骤如下：

步骤1201：NEF确定用于处理该第二业务请求的第二MEC。

当NEF接收到第一业务请求后，则通过在节点信息表N_MECTable中查询关键字，该关键字至少包括该新的业务请求Req_Service的业务类型Req_Type和/或请求内容Req_KeyContent，寻找与关键字相匹配的MEC的节点信息。具体来讲，可以是查询节点信息表N_MECTable中部署了该业务类型Req_Type和/或存储有该请求内容Req_KeyContent的MEC。

例如，以关键字为该业务类型Req_Type为例，NEF确定MEC6部署了该业务类型Req_Type，则确定MEC6为目标MEC。

步骤1202：NEF向第二MEC发送第二业务请求。

在这种实现方式中，第二业务请求与第一业务请求可以完全相同，即第二业务请求即为第一业务请求，第二业务请求包含该第一业务请求的业务类型的全部业务类型和/或该第一业务请求的业务内容的全部业务内容。当NEF确定第二MEC后，则直接将第一业务请求转发至第二MEC。当然，NEF在确定第二MEC后，也可以将第一业务请求的业务类型的全部业务类型和/或该第一业务请求的业务内容与MEC1的标识信息进行封装，获得实质内容相同，但封装不同的第二业务请求，然后将第二业务请求发送至第二MEC，在此不作限制。

步骤1203：第二MEC接收并处理该第二业务请求，并向NEF发送与该第二业务请求对应的业务数据。

在具体实施过程中，当第二MEC接收NEF发送的第二业务请求后，可以直接对第二业务请求进行处理；也可以先根据该第二业务请求的业务类型Req_Type、请求内容Req_KeyContent以及当前的负载情况M_Workload中的一个或多个因素，确定是否能处理该第二业务请求，若能够处理，则对第二业务请求进行处理，然后向NEF发送与第二业务请求对应的业务数据。

步骤1204：NEF接收与该第二业务请求对应的业务数据。

在这种实现方式中，由于第二业务请求包含该第一业务请求的业务类型的全部业务类型和/或该第一业务请求的业务内容的全部业务内容，因此，第二MEC发送的与第二业务请求对应的业务数据，即与第一业务请求对应的业务数据，从而NEF获取了与第一业务请求对应的业务数据。

需要说明的是，若第二MEC通过步骤1203中的方法确定无法处理第二业务请求时，可以向NEF发送拒绝消息，当NEF接收第二MEC发送的拒绝消息，则由NEF对该第二业务请求进行处理，获得与该第二业务请求对应的业务数据。该拒绝消息的具体形式及内容可以参考步骤703，在此不再赘述。

针对第二种情况及第三种情况，请参考图12B，为步骤1102的第三种发送方式的第二种实现方式的流程图，具体步骤如下：

步骤1205：NEF将第一业务请求拆分为多个子业务请求，该多个子业务请求即为第二业务请求。

当NEF接收第一业务请求后，可以第一业务请求的业务类型和/或业务内容确定该第一业务请求以拆分成多个独立的业务请求，则NEF将第一业务请求重新封装成多个子业务请求，其中，每个子业务请求Req_SubService包括该子业务请求的业务类型Req_Type和/或该子业务请求的请求内容Req_KeyContent，当然，每个子业务请求Req_SubService也可以包含MEC1的标识信息。

在下面的描述中，以该多个子业务请求表征第二业务请求。

步骤1206：NEF确定用于处理该多个子业务请求的第二MEC。

在具体实现过程中，NEF在将第一业务请求拆分为多个子业务请求后，则通过在节点信息表N_MECTable中查询关键字，该关键字至少包括该多个子业务请求的业务类型Req_Type和/或请求内容Req_KeyContent，寻找与关键字相匹配的MEC的节点信息。从而从所有的MEC中确定能够用于处理该多个子业务请求的MEC集合。然后，NEF向能够用于处理该多个子业务请求的MEC集合对应的每个MEC广播协同请求消息，并根据每个MEC的应答消息确定第二MEC。

步骤1206的具体实现方式可以参考步骤1002-1006，在此不再赘述。

需要说明的是，在这种实现方式中，第二MEC可以为多个MEC，例如每个子业务请求需要一个MEC处理。

步骤1207：NEF向第二MEC发送对应的子业务请求。

步骤1208：第二MEC接收对应的子业务请求，对该子业务请求进行处理，并向NEF发送与该子业务请求对应的业务数据。

步骤1209：NEF根据第二MEC发送的业务数据，获取与该业务请求对应的业务数据。

具体来讲，当第二MEC为多个时，NEF可以将每个MEC发送的业务数据进行聚合，从而获得与该业务请求对应的业务数据。

当NEF通过上述步骤获取与第一业务第一业务请求对应的业务数据后，则执行步骤1103。

步骤1103：NEF向MEC1发送与该第一业务请求对应的业务数据。

需要说明的是，当MEC1通过执行上述步骤获得与该业务请求对应的业务数据后，还可以对该业务数据进行缓存处理。具体实现方式与前述实施例相同，在此不再赘述。

在上述技术方案中，MEC1在接收到业务请求后，首先对业务请求进行预处理，包括提取业务特征、业务类型、关键数据等，重新封装成新的业务请求，然后发送至NEF。NEF对新的业务请求进行集中调度，根据各个MEC部署业务类型、功能模块、工作负载，进行服务匹配，选择合适的最优MEC节点，可以提高MEC的资源利用率。

基于以上实施例，本申请实施例还提供了一种移动边缘计算设备，该移动边缘计算设备可以实现如图5A-图12B所示的实施例中的由MEC1执行的对应步骤。请参考图13，该移动边缘计算设备包括接收器、处理器以及发送器。

其中，处理器1302可以是中央处理器(CPU)或特定应用集成电路(ApplicationSpecific Integrated Circuit，ASIC)，可以是一个或多个用于控制程序执行的集成电路，可以是基带芯片，等等。

接收器1301以及发送器1303可以通过总线结构或者星型结构或者其它结构与处理器1302相连接，或者也可以通过专门的连接线分别与处理器1302连接。

所述网络装置还可以包括存储器，存储器可以通过总线结构或者星型结构或者其它结构与处理器1302连接。存储器的数量可以是一个或多个，存储器可以是只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)或磁盘存储器，等等。存储器可以用于存储处理器1302执行任务所需的程序代码，还可以用于存储数据。

接收器1301用于接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

发送器1303用于向第二移动边缘计算设备发送由处理器1302生成的第二业务请求；其中，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容，以及所述第一移动边缘计算设备的标识信息；

接收器1301还用于从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据。

在一种可能的实现方式中，处理器1302用于：

在所述发送器向所述第二移动边缘计算设备发送所述第二业务请求之前，根据所述移动边缘计算设备部署的业务类型和/或业务内容，确定所述移动边缘计算设备需要向所述第二移动边缘计算设备发送所述第二业务请求。

在一种可能的实现方式中，处理器1302用于：

在发送器1303向第二移动边缘计算设备发送所述第二业务请求之前，根据移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

在一种可能的实现方式中，移动边缘计算设备的信息列表包括至少一个移动边缘计算设备的标识信息；或者，

所述移动边缘计算设备的信息列表包括所述至少一个移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

在一种可能的实现方式中，处理器1302用于：

查询所述移动边缘计算设备的信息列表，确定能够用于处理所述第二业务请求的至少一个移动边缘计算设备；

控制发送器1303向所述至少一个移动边缘计算设备发送第一询问消息；其中，所述第一询问消息包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

控制接收器1301从所述至少一个移动边缘计算设备接收应答消息；

根据所述应答消息，从所述至少一个移动边缘计算设备中确定所述第二移动边缘计算设备。

在一种可能的实现方式中，处理器1302用于：

控制发送器1303向所述管理设备发送查询请求；所述查询请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

控制接收器1301从所述管理设备接收与至少一个移动边缘计算设备对应的至少一个标识信息；其中，所述移动边缘计算设备的信息列表中包含所述至少一个标识信息；

根据所述至少一个标识信息，从所述至少一个移动边缘计算设备确定所述第二移动边缘计算设备。

在一种可能的实现方式中，处理器1302用于：

根据与所述第二业务请求对应的业务数据，获得与所述第一业务请求对应的业务数据；

控制发送器1303发送与所述第一业务请求对应的业务数据。

通过对接收器1301、处理器1302以及发送器1303进行设计编程，将前述的业务处理方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行前述的业务处理方法，如何对接收器1301、处理器1302以及发送器1303进行设计编程为本领域技术人员所公知的技术，这里不再赘述。

基于以上实施例，本申请实施例还提供了一种网络设备，该网络设备可以实现如图5A-图12B所示的实施例中的由NEF执行的对应步骤。请参考图14，该网络设备包括接收器1401、处理器1402以及发送器1403。

其中，接收器1401、处理器1402以及发送器1403的硬件结构、连接关系以及数量等可以参考图13所示的移动边缘计算设备中接收器、处理器以及发送器，在此不再赘述。

接收器1401用于从第一移动边缘计算设备接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

发送器1403用于根据处理器1402的控制，向所述第一移动边缘计算设备发送与所述第一业务请求对应的业务数据。

在一种可能的实现方式中，发送器1403用于：

根据处理器1402的控制，向第二移动边缘计算设备发送第二业务请求；其中，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

接收器1401用于：

从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据。

在一种可能的实现方式中，处理器1402用于：

在发送器1403向第二移动边缘计算设备发送所述第二业务请求之前，根据所述网络设备部署的移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

在一种可能的实现方式中，移动边缘计算设备的信息列表包括移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

在一种可能的实现方式中，处理器1402用于：

根据所述与所述第二业务请求对应的业务数据，获得与所述第一业务请求对应的业务数据

控制发送器1403向所述第一移动边缘计算设备发送与所述第一业务请求对应的业务数据。

通过对接收器1401、处理器1402以及发送器1403进行设计编程，将前述的业务处理方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行前述的业务处理方法，如何对接收器1401、处理器1402以及发送器1403进行设计编程为本领域技术人员所公知的技术，这里不再赘述。

基于以上实施例，本申请实施例还提供了一种移动边缘计算设备的简化功能框图，该网络设备可以实现如图5A-图12B所示的实施例中的由MEC1执行的对应步骤。请参考图15，该移动边缘计算设备包括接收单元1501、处理单元1502以及发送单元1503。

在实际应用中，接收单元1501对应的网元设备可以是图13中的接收器1301，发送单元1503对应的网元设备可以是图13中的发送器1303，处理单元1502对应的网元设备可以是图13中的处理器1302。

其中，接收单元1501用于接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

发送单元1503用于向第二移动边缘计算设备发送由处理单元1502生成的第二业务请求；其中，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容，以及所述第一移动边缘计算设备的标识信息；

接收单元1501还用于从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据。

在一种可能的实现方式中，处理单元1502用于：

在发送单元1503向所述第二移动边缘计算设备发送所述第二业务请求之前，根据所述移动边缘计算设备部署的业务类型和/或业务内容，确定所述移动边缘计算设备需要向所述第二移动边缘计算设备发送所述第二业务请求。

在一种可能的实现方式中，处理单元1502用于：

在发送单元1503向第二移动边缘计算设备发送所述第二业务请求之前，根据移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

在一种可能的实现方式中，移动边缘计算设备的信息列表包括至少一个移动边缘计算设备的标识信息；或者，

所述移动边缘计算设备的信息列表包括所述至少一个移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

在一种可能的实现方式中，处理单元1502用于：

查询所述移动边缘计算设备的信息列表，确定能够用于处理所述第二业务请求的至少一个移动边缘计算设备；

控制发送单元1503向所述至少一个移动边缘计算设备发送第一询问消息；其中，所述第一询问消息包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

控制接收单元1501从所述至少一个移动边缘计算设备接收应答消息；

根据所述应答消息，从所述至少一个移动边缘计算设备中确定所述第二移动边缘计算设备。

在一种可能的实现方式中，处理单元1502用于：

控制发送单元1503向所述管理设备发送查询请求；所述查询请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

控制接收单元1501从所述管理设备接收与至少一个移动边缘计算设备对应的至少一个标识信息；其中，所述移动边缘计算设备的信息列表中包含所述至少一个标识信息；

根据所述至少一个标识信息，从所述至少一个移动边缘计算设备确定所述第二移动边缘计算设备。

在一种可能的实现方式中，处理单元1502用于：

根据与所述第二业务请求对应的业务数据，获得与所述第一业务请求对应的业务数据；

控制发送单元1503发送与所述第一业务请求对应的业务数据。

基于以上实施例，本申请实施例还提供了一种网络设备的简化功能框图，该网络设备可以实现如图5A-图12B所示的实施例中的由NEF执行的对应步骤。请参考图16，该网络设备包括接收单元1601、处理单元1602以及发送单元1603。

在实际应用中，接收单元1601对应的网元设备可以是图14中的接收器1401，发送单元1603对应的网元设备可以是图14中的发送器1403，处理单元1602对应的网元设备可以是图14中的处理器1402。

其中，接收单元1601用于从第一移动边缘计算设备接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

发送单元1603用于根据处理单元1602的控制，向所述第一移动边缘计算设备发送与所述第一业务请求对应的业务数据。

在一种可能的实现方式中，发送单元1603用于：

根据处理单元1602的控制，向第二移动边缘计算设备发送第二业务请求；其中，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

接收单元1601用于：

从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据。

在一种可能的实现方式中，处理单元1602用于：

在发送单元1603向第二移动边缘计算设备发送所述第二业务请求之前，根据所述网络设备部署的移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

在一种可能的实现方式中，移动边缘计算设备的信息列表包括移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

在一种可能的实现方式中，处理单元1602用于：

根据所述与所述第二业务请求对应的业务数据，获得与所述第一业务请求对应的业务数据

控制发送单元1603向所述第一移动边缘计算设备发送与所述第一业务请求对应的业务数据。

本申请所提供的移动边缘计算设备以及网络设备可以是一种芯片系统，所述芯片系统中可以包含至少一个芯片，也可以包含其他分立器件。所述芯片系统可以置于移动边缘计算设备或者网络设备中，支持所述移动边缘计算设备或所述网络设备完成本申请实施例中所提供的业务处理的方法。

本申请实施例提供一种计算机存储介质，所述计算机存储介质中存储有指令，当所述指令在计算机上运行时，使得所述计算机执行前述业务处理的方法。

本申请实施例提供一种计算机程序产品，所述计算机程序产品包含有指令，当所述指令在计算机上运行时，使得所述计算机执行前述业务处理的方法。

在上述技术方案中，当移动边缘计算设备接收到业务请求后，可以将业务请求中的一部分业务或者全部业务转发给其他移动边缘计算设备进行处理，这样，当某个移动边缘计算设备接收到大量的业务请求时，可以将业务请求转发至较空闲的移动边缘计算设备进行处理，从而使多个移动边缘计算设备可以协同处理业务请求，可以提高移动边缘计算设备的资源利用率。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘SolidState Disk(SSD))等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (19)

1.一种业务处理方法，其特征在于，包括：

第一移动边缘计算设备接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

所述第一移动边缘计算设备向第二移动边缘计算设备发送第二业务请求；其中，所述第二业务请求包含所述业务类型的部分业务类型和/或所述业务内容的部分业务内容，以及所述第一移动边缘计算设备的标识信息；

所述第一移动边缘计算设备从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据；

所述第一移动边缘计算设备对与所述第二业务请求对应的业务数据、以及所述业务类型中除了所述部分业务类型之外的业务类型和/或所述业务内容中除了所述部分业务内容之外的业务内容对应的业务数据进行聚合，获得与所述第一业务请求对应的业务数据；

所述第一移动边缘计算设备发送与所述第一业务请求对应的业务数据。

2.根据权利要求1所述的方法，其特征在于，在所述第一移动边缘计算设备向第二移动边缘计算设备发送第二业务请求之前，所述方法还包括：

所述第一移动边缘计算设备根据所述第一移动边缘计算设备部署的业务类型和/或业务内容，确定所述第一移动边缘计算设备需要向所述第二移动边缘计算设备发送所述第二业务请求。

3.根据权利要求1或2所述的方法，其特征在于，所述第一移动边缘计算设备向第二移动边缘计算设备发送第二业务请求之前，所述方法还包括；

所述第一移动边缘计算设备根据移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

4.根据权利要求3所述的方法，其特征在于，移动边缘计算设备的信息列表包括至少一个移动边缘计算设备的标识信息；或者，

所述移动边缘计算设备的信息列表包括所述至少一个移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

5.根据权利要求4所述的方法，其特征在于，所述移动边缘计算设备的信息列表部署在所述第一移动边缘计算设备，所述第一移动边缘计算根据移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备，包括：

所述第一移动边缘计算设备查询所述移动边缘计算设备的信息列表，确定能够用于处理所述第二业务请求的至少一个移动边缘计算设备；

所述第一移动边缘计算设备向所述至少一个移动边缘计算设备发送第一询问消息；其中，所述第一询问消息包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

所述第一移动边缘计算设备从所述至少一个移动边缘计算设备接收应答消息；

所述第一移动边缘计算设备根据所述应答消息，从所述至少一个移动边缘计算设备中确定所述第二移动边缘计算设备。

6.根据权利要求4所述的方法，其特征在于，所述移动边缘计算设备的信息列表部署在管理设备，所述第一移动边缘计算根据移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备，包括：

所述第一移动边缘计算设备向所述管理设备发送查询请求；所述查询请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

所述第一移动边缘计算设备从所述管理设备接收与至少一个移动边缘计算设备对应的至少一个标识信息；其中，所述移动边缘计算设备的信息列表中包含所述至少一个标识信息；

所述第一移动边缘计算设备根据所述至少一个标识信息，从所述至少一个移动边缘计算设备确定所述第二移动边缘计算设备。

7.一种业务处理方法，其特征在于，包括：

管理设备从第一移动边缘计算设备接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

所述管理设备向第二移动边缘计算设备发送第二业务请求，其中，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

所述管理设备从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据；

所述管理设备根据与所述第二业务请求对应的业务数据，获得与所述第一业务请求对应的业务数据；

所述管理设备向所述第一移动边缘计算设备发送与所述第一业务请求对应的业务数据。

8.根据权利要求7所述的方法，其特征在于，在所述管理设备向第二移动边缘计算设备发送所述第二业务请求之前，所述方法还包括：

所述管理设备根据所述管理设备部署的移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

9.根据权利要求8所述的方法，其特征在于，移动边缘计算设备的信息列表包括移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

10.一种移动边缘计算设备，其特征在于，包括接收器、处理器以及发送器，其中：

所述接收器用于接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

所述发送器用于向第二移动边缘计算设备发送由所述处理器生成的第二业务请求；其中，所述第二业务请求包含所述业务类型的部分业务类型和/或所述业务内容的部分业务内容，以及所述移动边缘计算设备的标识信息；

所述接收器还用于从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据；

所述处理器用于：

对与所述第二业务请求对应的业务数据、以及所述业务类型中除了所述部分业务类型之外的业务类型和/或所述业务内容中除了所述部分业务内容之外的业务内容对应的业务数据进行聚合，获得与所述第一业务请求对应的业务数据；

控制所述发送器发送与所述第一业务请求对应的业务数据。

11.根据权利要求10所述的设备，其特征在于，所述处理器用于：

在所述发送器向所述第二移动边缘计算设备发送所述第二业务请求之前，根据所述移动边缘计算设备部署的业务类型和/或业务内容，确定所述移动边缘计算设备需要向所述第二移动边缘计算设备发送所述第二业务请求。

12.根据权利要求10或11所述的设备，其特征在于，所述处理器用于：

在所述发送器向第二移动边缘计算设备发送所述第二业务请求之前，根据移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

13.根据权利要求12所述的设备，其特征在于，移动边缘计算设备的信息列表包括至少一个移动边缘计算设备的标识信息；或者，

所述移动边缘计算设备的信息列表包括所述至少一个移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

14.根据权利要求13所述的设备，其特征在于，所述处理器用于：

查询所述移动边缘计算设备的信息列表，确定能够用于处理所述第二业务请求的至少一个移动边缘计算设备；

控制所述发送器向所述至少一个移动边缘计算设备发送第一询问消息；其中，所述第一询问消息包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

控制所述接收器从所述至少一个移动边缘计算设备接收应答消息；

根据所述应答消息，从所述至少一个移动边缘计算设备中确定所述第二移动边缘计算设备。

15.根据权利要求14所述的设备，其特征在于，所述处理器用于：

控制所述发送器向管理设备发送查询请求；所述查询请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

控制所述接收器从所述管理设备接收与至少一个移动边缘计算设备对应的至少一个标识信息；其中，所述移动边缘计算设备的信息列表中包含所述至少一个标识信息；

根据所述至少一个标识信息，从所述至少一个移动边缘计算设备确定所述第二移动边缘计算设备。

16.一种网络设备，其特征在于，包括接收器、处理器以及发送器，其中：

所述接收器用于从第一移动边缘计算设备接收第一业务请求；其中，所述第一业务请求包含业务类型和/或业务内容；

所述发送器用于向第二移动边缘计算设备发送第二业务请求，所述第二业务请求包含所述业务类型的至少部分业务类型和/或所述业务内容的至少部分业务内容；

所述接收器用于从所述第二移动边缘计算设备接收与所述第二业务请求对应的业务数据；

所述处理器用于根据与所述第二业务请求对应的业务数据，获得与所述第一业务请求对应的业务数据；

所述发送器用于根据所述处理器的控制，向所述第一移动边缘计算设备发送与所述第一业务请求对应的业务数据。

17.根据权利要求16所述的设备，其特征在于，所述处理器用于：

在所述发送器向第二移动边缘计算设备发送所述第二业务请求之前，根据所述网络设备部署的移动边缘计算设备的信息列表，确定所述第二移动边缘计算设备；其中，所述移动边缘计算设备的信息列表中包含所述第二移动边缘计算设备的信息。

18.根据权利要求17所述的设备，其特征在于，移动边缘计算设备的信息列表包括移动边缘计算设备的标识信息以及对应的移动边缘计算设备部署的业务类型和/或业务内容。

19.一种计算机可读存储介质，其特征在于，所述介质上存储有指令，当其在计算机上运行时，使得计算机实现如权利要求1-6或7-9任一项所述的方法。

Images