近年来开发了许多新的面向网络的业务，它们有望在多接入边缘计算(MEC)环境中虚拟化，随着第五代(5g)的标准化，许多新的面向网络的业务已经开发出来，以满足各种用户需求，面向服务的开发，其中业务功能的划分和组合，有望促进灵活的低成本业务的开发。核心/外围结构是生物系统中的一种信息处理系统，它由紧密连接并提供高效处理的核心单元和能够容纳各种输入和输出的外围单元组成。在本文中，我们将核心/外围结构引入到服务设计中，因为基于该结构的服务只需修改外围功能即可适应各种输入和输出。我们期望通过基于核心/外围结构设计服务来降低开发成本，因为整个服务不会根据环境变化进行修改。此外，我们还考虑了惩罚和减少开发成本之间的平衡，因为划分功能并将它们放置在不同的设备中会产生额外的通信路径并降低服务响应性。我们为购物服务设计并实现了两个服务场景，使用基于核心/外围结构的远程机器人。通过实现的服务，我们证明了使用核心/外围结构的设计在远程机器人之间信息共享的实现成本和开销方面是有效的。此外，我们通过在实际设备上的实验来测量惩罚，并表明它是可以容忍的。
近年来，出现了许多新的面向网络的服务，信息网络日新月异。例如，目前正在开发的远程存在[25]服务允许人类用户通过操作远程机器人并使用虚拟现实(VR)或混合现实(MR)技术来体验在远程地方的虚拟存在感，就好像它是自己的身体一样。它们使用来自发送到云端的摄像头和传感器的真实信息，或者进行高负载处理，如图像识别、语音和声音识别。一些尚未被设想的不同服务预计将在未来出现。这些服务将需要在多接入边缘计算(MEC)[4,10,29]环境中进行虚拟化，该环境目前正在与第五代(5g)技术一起标准化。
服务设计应适应用户需求和环境变化，以便以低成本容纳大量服务。当设计决策在短期内是权宜之计时，在未来维护和调整该系统的成本会增加，这被称为技术债务[12]。为了降低成本，基于模块的设计被广泛引入。在基于模块的设计中，模块之间通过接口相互连接，并且可以解耦[5]，并且可以在多个产品中重用。
模块化设计的缺点是开发过程复杂，产品维护困难。Albers等[2]指出，不同产品中使用的模块之间的相互依赖性增加，因为模块的变化会影响到其他产品。因此，模块的开发变得复杂，模块和产品的维护变得困难。尽管Albers等人[2]解释了车辆开发，但基于模块的服务设计也使开发变得复杂。模块之间平等连接，相互依赖。更重要的是，模块(在我们的例子中是服务功能)有时是由几个不同的开发人员开发的。因此，开发人员在修改模块时很难观察到影响范围。这将导致服务和/或模块的维护和修改困难。
我们研究了一个核心/外围结构[6,15]，它允许服务组件有效地适应每个用户请求和环境变化。核心/外围结构是生物系统中灵活高效的信息处理机制模型;核心/外围结构中的信息处理单元分为核心单元和外围单元。核心/外围结构的优势在于，通过将服务功能区分为核心功能和外围功能，有助于降低维护或更改服务的成本。与基于模块的设计不同，基于核心/外围结构的服务设计可以适应环境变化，只修改外围功能，重用核心功能，如图1所示。
使用核心/外围结构进行服务设计的有效性。考虑将输入2和输出2添加到具有输入1和输出1的服务中。当提供核心功能时，支持各种输入和输出所需的附加功能更少
我们在之前的工作中[30]对以功能链为代表的容纳信息服务的核心/外围结构的优势进行了数值研究。从生物学的角度来看，核心/外围结构有望实现对环境变化的有效和适应性行为。图1表明，基于核心/外围结构的服务设计可以通过更少的附加实现来支持输入和输出的变化。然而，从服务设计的角度来看，划分功能并将它们放置在不同的设备中会创建额外的通信路径，并可能降低服务响应性，这是不容忽视的。因此，当我们将核心/外围结构应用于服务设计时，我们要考虑惩罚和减少开发成本之间的平衡。
在[27,28]中，我们使用混合现实(MR)和机器人作为实现基于[30]的服务场景的用例实现了购物体验服务，并使用实际设备实现了该服务，并证明了当用户端和远程端设备类型数量增加时，使用核心/外围结构的服务设计对于机器人操作是有效的。
在本文中，我们在以下两个方面进行了评估，比以往的工作更务实。第一个方面是在我们的实验中使用的服务场景。在我们之前的工作[30]和[27,28]中，我们考虑了一个仅包括信息处理的服务场景;然而，今天常用的应用程序不仅处理从设备获得的信息，而且还在这些设备之间共享信息。因此，本文的研究重点是信息共享。我们考虑一个服务场景，其中包括远程机器人和用户之间的信息处理和信息共享，我们根据源代码的复杂性和信息共享的开销来评估我们的服务设计。我们实现了一项服务，并通过在实际设备上的实验来衡量惩罚，以调查共享信息的惩罚程度。第二个方面是表示实现成本的度量。在我们之前的工作[30]和[27,28]中，我们使用用户端应用程序的源代码行数作为实现成本。线路数可用于评估使服务适应环境所需的努力;然而，它不能帮助评估应用程序逻辑简化的程度，因为源代码的数量只代表了努力的实现结果。因此，我们将程序的复杂性作为适应环境成本的一个因素引入，因为当多人开发服务时，即在现代软件开发中，复杂性尤为重要。我们使用圈复杂度[13]，它表示从程序开始到结束的独立路径的数量，作为评估实现成本的指标。
本文的其余部分组织如下。第2节介绍了相关工作。第3节描述了本文所针对的服务以及服务场景。第4节描述了基于核心/外围结构和服务实现的服务设计。第5部分描述了对服务设计的评估。最后，第六节提供了一些结束语和未来的研究领域。
我们提出了面向网络的服务和体系结构作为相关工作。
现有的传统核磁共振服务，如ANA Avatar[3]，并不是为支持各种输入和输出而设计的，因为它是由单一供应商提供的;然而，相信服务的模块化划分已经到位。
当多个供应商创建的功能组合成一个服务时，这些功能分布在不同的设备上。这种分布通过多访问边缘计算(MEC)加速[10,22]。ETSI行业规范组建议视频内容交付、视频流分析和增强现实(AR)作为MEC的关键用例，它还为软件开发人员提出了指导方针。用于开发VR业务的虚拟现实外围网络(virtual-reality peripheral network, VRPN)[11]类似于核心/外围结构的概念，可以吸收VR设备之间的差异。在创建支持多种输入输出的业务时，可以使用VRPN作为核心功能。在本文中，我们使用消息队列遥测传输(MQTT) [16]， MQTT是一种能够吸收设备之间差异作为核心功能的消息传递协议。
近年来，微服务[26]、面向服务的架构(service-oriented architecture, SOA)[20]等服务功能划分和组合的概念被提出。在这些架构中，每个功能都是松散连接的，可以适应不断变化的需求;然而，支持各种输入/输出的开发成本更高，因为功能被精细划分。在本文中，这些架构被称为“无核心”，因为它们被认为是仅具有外围功能的服务结构。
我们的基本服务是使用远程机器人的购物体验。远程机器人捕捉商店或商店林立的街道的图像，并使用目标检测功能向用户提供处理后的视频。用户一边操作机器人，一边观看视频和远程发送的信息。
我们考虑增加以下服务场景，通过适应真实环境来改进此基础服务:
根据机器人行走的位置调整移动方向，避免在拥挤或狭小区域发生碰撞的服务场景
一种基于用户关注程度获取信息的服务。
我们的服务和功能如图2所示。这些服务场景需要功能进行目标检测，并利用目标检测结果存储和共享信息，调整机器人的移动方式。在实现此类服务时，将这些功能组合在一起。
我们的服务有附加功能
在没有核心/外围结构的设计中，每个服务功能的规范都是特定于特定环境的，例如，特定机器人的API。在实施没有用于机器人操作的核心/外围结构的设计时，直接从用户设备访问机器人;为了适应环境，程序被改变了。在信息共享中，由于存储信息的方法不统一，每个设备存储信息的格式不同，因此难以存储从各种机器人收集的信息并向用户提供信息。
我们在以下三种设计场景下使用核心/外围结构评估了服务设计的有效性。
无核心:所有功能都是外设，并且特定于每个设备。
核心机器人:将常用功能作为核心功能实现在机器人上。
核心边缘服务器:常用功能作为核心功能在边缘服务器上实现。
正如我们在第2节中所描述的，我们将微服务[26]和面向服务的体系结构(SOA)[20]等结构称为“无核心”，因为它们被认为是只有外围功能的服务结构。
其中所有功能紧密耦合的整体结构是设计场景的另一个候选方案。因此，我们将单片设计解释为仅由核心功能组成的设计。与微服务设计相比，单片设计更难以维护和扩展，因为单片服务比微服务更大、更复杂[26]。本文不与单片设计进行比较，因为单片设计的开发成本比仅由外围功能组成的结构要高。
在3.2节中，我们基于核心/外围结构设计了我们的业务场景。在没有核心/外围结构的服务设计中，所有功能都作为外围功能实现，并针对每个业务场景或实际环境进行具体实现;这使得添加更多函数或更改函数组合变得困难。在核心/外围结构的服务设计中，我们实现了用户到机器人的消息传递、视频的对象检测、对象检测结果的存储等常见功能作为核心功能，并将其他功能外围连接到核心功能上。因此，当环境发生变化时，只需要在短时间内改变外围功能。
图3和图4显示了基于我们的服务设计的核心/外围结构。图中圆点表示业务功能，箭头表示业务功能连接。服务功能按照从输入端(分别为图3和图4中的摄像头和用户)到输出端(分别为图3和图4中的用户和机器人)的连接顺序使用。图3中绿色矩形为视频输入输出接口。图3显示了业务功能的核心/外围结构及其连接，用于处理摄像头捕获的视频，存储信息，并向用户提供处理后的视频和定制信息。对于视频处理和信息存储，我们的业务场景中常用到的是目标检测功能，因此它和紧密相连的信息存储功能都是核心组件;外围函数提供了如何使用这些信息，如4.3.3和4.3.4所述。图4显示了基于我们的机器人操作服务设计的核心/外围结构。对于机器人操作来说，向机器人发送用户命令的功能是一个常见的功能。因此，它被认为是一个核心功能;外围功能根据每个API调整机器人的速度并处理消息。
用于视频处理和信息存储的核心/外围结构
机器人操作的核心/外围结构
来自摄像机的视频输入被传输到机器人端边缘服务器，然后使用OpenCV进行捕获[18];随后，使用YOLO v3的PyTorch实现应用对象检测[21]。处理后的视频通过UDP以FFmpeg[9]传输到用户佩戴的HoloLens[14]上并显示。HoloLens是一款由微软开发的独立头戴式电脑，它可以显示全息图，并识别用户的目光和手势，从而提供MR体验。从目标检测功能得到的结果来看，店内所售产品的种类、坐标、拍摄时间等都是远程信息，作为机器人之间的共享信息存储。
控制器信息通过MQTT传输[16]，MQTT是为物联网设备之间频繁的消息交换而开发的发布/订阅型协议。MQTT代理通过HoloLens接收控制器命令，并将其发送给运行在Pepper机器人上的程序[24]。
用户使用可以连接到HoloLens的Xbox控制器。我们使用开源消息代理[7]和事件驱动应用程序编程工具Node-RED[19]在用户端边缘服务器上开发了MQTT消息传递系统。
基本服务提供了一个以恒定速度移动的功能。我们增加了一个功能来调整机器人的速度，以改变机器人根据周围环境的移动方式;我们利用物体检测功能获得的周围环境信息，确保机器人不会撞到人或障碍物。物体检测的结果从边缘服务器返回给机器人，机器人使用这些信息来调整其移动速度(例如，在拥挤的区域减速)。核心功能是对机器人发送的图像进行对象检测并返回结果;周边功能包括在该区域有很多人时降低速度。外围功能用于处理结果，因此，机器人可以根据其位置选择避开除了人以外的障碍物。边缘服务器存储对象及其大小的列表，机器人只引用要避免的对象的信息。
基本服务使用带有学习模型的对象检测来显示有关对象的信息。我们添加了一个检测凝视和显示信息的功能，使用产品数据库根据用户的注意力显示周围物体的详细信息。将每个商店的产品列表整合到一个数据库中，并对感兴趣的区域(即用户在视频中注视的对象)进行裁剪和放大。此外，还会对用户尚未看到的同一类型的产品进行推荐。外围功能通过从存储在核心功能中的信息中选择必要的信息，或通过删除用户已经凝视过的对象，为每个用户定制信息。
我们通过使用4.1中描述的三个设计场景，从实现成本和信息共享开销方面评估了使用核心/外围结构的服务设计的有效性。
我们评估了增加设备类型数量的实现成本。在我们的服务中，用户端连接了n种远程机器人和m种设备。
在[27,28]中，我们根据源代码的数量衡量了核心和外围功能的实现成本。然而，源代码的数量并不能完全捕获适应环境所需的工作量，因为它只代表了工作的实现结果。因此，我们将项目的复杂性作为适应环境成本的一个因素;当多人开发服务时，复杂性尤其重要，例如在现代软件开发中。
根据直接连接HoloLens MR头显与Pepper机器人的程序的实现，我们假设No Core场景下的所有实现都是在用户端设备的程序中编写的。因此，在修改控制其他机器人的程序时，需要修改每个机器人的API程序。当用户具有设备类型时，提供用于该设备的n种机器人的流程。另外，当机器人种类增加1时，对m种用户设备的每个程序中第th个机器人的进程进行相加。我们向程序中添加的代码越多，程序就会变得越复杂，并且需要更长的时间来读写添加源代码。因此，实现成本不仅基于必须编写的新源代码的数量，还基于我们在修改程序时必须阅读的程序的复杂性。因此，我们将读取程序的成本定义为实现成本，并使用圈复杂度[13]来评估实现成本。圈复杂度表示从程序开始到结束的独立路径的数量。分支数越高，该值越高，也就越难读取。图5显示了机器人数量n增加时应用程序源代码的圈复杂度。横轴表示机器人种类的数量，纵轴表示周期复杂度。
机器人数量n增加时应用程序源代码的圈复杂度
我们将展示用于与机器人建立连接的源代码摘录。源代码1显示了无核心场景下HoloLens应用程序的一部分源代码。此示例表示和的情况。所有机器人api的所有进程都在一个程序中编写，以便直接从HoloLens应用程序访问每个机器人。第二行和第九行表示基于环境(在本例中是设备类型)的分支，随着n和m的增加，它们变得更加复杂。
源代码2显示了HoloLens应用程序的一部分源代码，源代码3显示了具有核心/外围结构的Pepper应用程序的一部分源代码。MQTT的消息传递功能作为核心功能提供，因此，只需要从每个设备连接到MQTT代理的过程。
在无核心场景下，访问机器人的整个源代码被写入HoloLens程序中，因此，使用的机器人越多，添加到程序中的分支数量就越多。因此，整个服务的圈复杂度变为。在机器人/边缘服务器上的核心场景下，该值不会改变并保持为1，因为程序没有分支。因此，随着机器人类型数量的增加，No Core和Core on Robot/Edge Server设计方案之间的圈复杂度差异变得更加显著。
我们在三种设计场景中测量信息共享发送的消息数量，假设我们保持信息共享功能存储的信息是最新的，并且机器人，，…，彼此分享信息。此外，我们还展示了当系统作为核心功能实现并部署在边缘服务器上时，消息的数量是最低的。
图6显示了我们实验室的实验环境配置。我们使用OpenStack版本3.8.1构建MEC环境[17]。用户端边缘服务器为OpenStack虚拟机(192.168.10.73)，机器人端边缘服务器为物理机(192.168.10.39)。我们使用蚊子版本1.4.15在边缘服务器上构建MQTT代理，这是一个MQTT版本3.1.1/3.1代理[7]。从用户发送到机器人的消息，例如控制器操作或注视操作，是通过用户端的MQTT代理发送的。机器人端的MQTT服务器用于将信息从边缘服务器发送到机器人，并从机器人发送到边缘服务器。机器人Pepper(192.168.10.51)已连接到MEC环境。Pepper内置了320 - 240分辨率的摄像头，但它的分辨率太低，无法享受HoloLens的视频流。因此，在本实验中，我们在Pepper的头部附加了一个外部摄像头，该摄像头通过SDI电缆连接到Aja HELO[1]，对视频流进行H.264编码。来自附加摄像机的视频以60 fps, 1920 1280的速度输入到HELO，并以30 fps, 1080 720的速度输出。通过HELO编码的视频以mpegts格式使用UDP发送到机器人侧边缘服务器。处理完成后，将视频作为原始数据输出到标准输出，然后使用FFmpeg将其编码为mpeg，并发送到用户佩戴的HoloLens上。
用于测量消息以执行信息共享的实验环境。这些数字对应于每个阶段
我们实验中的信息就是从捕获的视频中得到的目标检测结果。因此，我们使用一定长度的视频测量消息的数量，并计算每帧的平均开销。然后，我们将从获得新信息到将其反映给用户的过程分为以下三个阶段;随后，我们测量了每个阶段的消息数量。
执行目标检测功能，每个机器人获取新的目标信息。此信息是应用程序中使用的相机所看到的对象列表。该阶段不应用于No core和core on Robot场景下，因为机器人直接执行目标识别功能。边缘服务器执行对象检测功能，并通过MQTT将列表发送给机器人，以便与边缘服务器上的核心场景下机器人持有的信息集成。
信息从机器人发送到信息共享功能。机器人Pepper将机器人获得的坐标和时间信息添加到对象信息中。在“无核心”和“有核心”两种情况下，机器人向所有其他机器人发送信息。在边缘服务器上的核心场景下，机器人通过MQTT向边缘服务器发送信息。
当用户注视特定对象时，信息共享功能向用户提供信息。在No Core和Core on robot场景下，机器人向用户发送信息;在“边缘服务器上的核心”场景下，边缘服务器向用户发送信息。
根据应用的机器人类型，在No Core场景下以特定的方式实现信息共享功能。当机器人所持有的周围信息有更新时，各机器人通过泛洪方式共享信息，以确保所有机器人信息共享功能中存储的信息都是最新的。因为每个机器人，，，…，向除自身以外的机器人发送信息，发送信息是为了信息共享。信息共享功能作为外围功能实现，各机器人信息存储方法不统一;因此，有必要对每一类信息进行分解和传输，例如物体的名称和坐标。因此，发送消息，其中k表示信息类型的数量。
在核心上机器人场景下，由于信息共享功能统一为核心功能，因此可以在一次洪水中共享多种类型的信息。我们假设在所有机器人的信息共享函数中存储的信息需要和在No Core场景下一样是最新的，因此我们假设有消息发送，因为每n个机器人都向自己以外的机器人发送信息。
图7显示了当机器人数量n增加时，用于信息共享的消息数量的变化。我们测量了每帧的消息数量，并计算了每帧的消息数量，这就是系数。对于阶段1，开销只发生在核心边缘服务器场景中。由于将信息共享功能作为核心功能实现，实现了信息存储和共享的方法统一;从一帧中获得的所有信息可以并发地发送给机器人。因此，每帧应用一条消息。对于阶段2(边缘服务器上的核心场景)，我们使用29.97 fps捕获的视频26.36 s长视频(790帧)来测量消息数量，我们发现边缘服务器发送了854条消息。因此，每次更新信息时发送1.08条消息。E，每一帧)。在第三阶段，与第二阶段的实验相比，同一视频中出现了11次凝视。因为每次凝视都会发送一次推荐，所以每帧的速率约为0.014次。这些结果表明，核心边缘服务器场景中的消息数量是每帧的次数。
当机器人数量n增加时，信息共享的消息数
当外推图7所示的实验结果时，在无核心场景下，消息以每帧的速率出现(其中k表示信息类型的数量，在本实现中为三种)，而在核心机器人场景下，消息以每帧的速率出现。对于单个机器人，核心边缘服务器场景下的消息数量是最大的。但是，随着n的增加，无核心和机器人上的核心场景下的消息数量也会增加，并且开销被认为比边缘服务器上的核心场景下的消息数量要大。
划分功能并将它们放置在不同的设备中会产生额外的通信路径和服务响应性的损失。我们进行了另一个实验来调查这种惩罚;在本实验中，计算了机器人共享信息时通过边缘服务器进行通信的损失。
在本实验中，我们使用机器人之间信息共享的服务场景来评估应用级延迟。图8显示了我们的实验环境;机器人NAO(192.168.10.44)[23]作为附加机器人连接。该服务中的应用级延迟是机器人获取新对象的信息，将信息存储在边缘服务器中，并根据用户的注意力提供信息之间的延迟。在这些延迟中，使用边缘服务器向用户提供信息的代价与[27]中测量的结果大致相同，因为边缘服务器核心场景中的额外路径位于机器人端交换机和机器人端边缘服务器之间。因此，我们将时间测量为应用级延迟，该延迟表示核心边缘服务器场景下，目标检测功能获得的信息在信息共享功能中得到反映所需的时间;这在图6中用橙色箭头表示。此外，我们将服务流程划分为五个阶段，以便更清楚地理解应用程序级延迟。图9显示了五个阶段，从在边缘服务器上获取新信息的时间开始，到信息存储在边缘服务器中的时间结束。五个阶段如下:
从对象检测函数完成执行到它在边缘服务器上的核心场景下完成向MQTT代理发布的时间。在其他设计场景下，由于机器人执行目标检测功能，因此不应用此阶段。
直到Pepper/NAO接收到目标检测功能获得的信息。该信息是应用程序中使用的相机所看到的对象列表。在其他设计场景下，由于机器人执行目标检测功能，因此不应用此阶段。在Core on Edge Server场景下，边缘服务器执行对象检测功能，然后通过MQTT将列表发送给机器人，与机器人持有的坐标和时间信息进行集成。
直到Pepper/NAO将机器人获得的坐标和时间信息添加到物体信息中。这是所有设计场景的通用流程。
直到机器人添加的对象信息被信息共享功能接收。在无核心和有核心的机器人场景下，机器人向所有其他机器人发送信息。在边缘服务器上的核心场景下，机器人通过MQTT向边缘服务器发送信息。
直到Pepper/NAO发送的信息被存储。这是所有设计场景的通用流程。
五个阶段所花费的时间总和表示在边缘服务器核心场景中所花费的延迟。我们测量边缘服务器中的对象检测功能完成向同一边缘服务器中的MQTT代理发布对象列表所需的时间。与其他设计方案相比，阶段1、2和4需要额外的处理。因此，在边缘服务器上的核心场景中，这些阶段所花费的时间被认为是一种损失。阶段2代表Pepper/NAO的MQTT订阅过程。由于边缘服务器和机器人之间的系统时钟不同，因此很难准确测量阶段2的时间。因此，我们计算阶段1到阶段5所花费的总时间与阶段1、2、3和5所花费的时间之差，并测量阶段2所花费的时间。对于阶段4，我们测量Pepper/NAO完成向边缘服务器上的MQTT代理发布每个信息(包括对象、坐标和时间)所花费的时间。我们通过记录边缘服务器执行目标检测功能的时间和边缘服务器接收到消息的时间，以及NAO为每个视频帧添加的坐标和时间信息，来测量所有阶段的总时间。在我们的实验中，我们使用存储在边缘服务器中的70帧视频;在本视频中，共检测到1024个对象。
实验环境下的惩罚归因于额外的通信路径。这些数字对应于每个阶段
每个相位用于测量延迟
我们用机器人NAO展示了我们的实验结果。表1给出了总时间的平均值、最大值和最小值、每个阶段的时间以及在边缘服务器核心场景下产生的时间惩罚。测量的总时间平均为104 ms，是机器人之间信息共享的应用级延迟。在边缘服务器上的核心场景下，平均损失为99毫秒，最高可达536毫秒。用户操作机器人时的应用级延迟惩罚平均为31 ms[27]。在[27]中，额外的路径位于边缘服务器和用户端的交换机之间，因为这是对用户-机器人通信的惩罚。在本实验中，额外的通信路径是在机器人和机器人端边缘服务器之间;它是跳数的三倍，并且有更大的惩罚。阶段1和阶段5所用的时间为0 ms，因为在这些阶段中执行的功能与同一边缘服务器上的MQTT代理进行通信，没有通信延迟。阶段3的延迟变化很大，因为机器人没有一个好的CPU，除了对机器人头部和手臂的基本控制外，还需要处理我们的信息处理。此外，机器人依次添加和发送对象列表中每个项目的信息;一个帧中的对象越多，或者发送其他对象所需的时间越长，最大值就越大。这是因为发送列表末尾的对象所需的等待时间变大了。因此，我们评估了阶段2和阶段4的额外通信路径所带来的损失，而阶段3的平均时间为4毫秒。
图10显示了边缘服务器核心方案下阶段2、3和4的时间与阶段3的平均时间的对比。平均通信延迟为99 ms，约占应用级延迟的95%，比阶段3的延迟长约25倍。Wi-Fi通信在阶段2和阶段4中使用，因此，延迟会因拥塞、障碍物和与接入点的距离而变化。这个结果表明惩罚是可以容忍的，因为交互延迟容忍是100 ms[8]。无线通信的延迟预计将随着5g提供的超低延迟而改善。
核心边缘服务器场景的最小和平均时间
在本文讨论的实现中，仅在外围和核心功能之间进行通信;但在实际业务中，可能需要在边缘服务器上的核心功能之间实现通信。例如，边缘服务器上的核心功能可以聚合相邻机器人所持有的信息，这些机器人可以相互通信，在广泛的区域内共享信息。在这种情况下，我们可以将每个边缘服务器的信息收集功能视为外围功能，将边缘服务器之间的信息共享功能视为核心功能。因此，我们可以在存在多个边缘服务器的大规模服务配置中找到分层的核心/外围结构。考虑到图7所示的相同场景，在聚合四个或更多边缘服务器的信息时，将核心功能放置在更高层次的边缘服务器中是有效的。然而，这个图假设每帧都交换信息。在实际服务中，边缘服务器之间的信息共享并不频繁，只有当信息在数量极大的边缘服务器之间共享时，才会使用更高层次核心功能的边缘服务器。
发表评论
暂时没有评论，来抢沙发吧~