CN113726865B - 基于边缘计算的数据传输与协同系统 - Google Patents

Abstract

本发明公开了一种基于边缘计算的数据传输与协同系统，包括边缘节点、安全检测引擎、传输监听引擎和核心云端，所述的边缘节点：边缘计算技术带来的部署节点，本身以服务器或是服务器集群组成，用于承载企业或是用户的相关业务，整体部署在网络边缘侧，目的用于将云上部分处理功能下沉；下方连接多个用户终端，以流量方式处理传输各个终端上的业务；本发明提供了一个监听引擎来检测发现，并及时报错；实现了各个引擎间的信息传递协同，保证每个安全检测引擎输出的数据格式统一，方便后续的数据打包上传及引擎间协同的互相请求。

Description

基于边缘计算的数据传输与协同系统

技术领域

本发明涉及的是一种基于边缘计算的数据传输与协同系统。

背景技术

随着5G的快速发现，边缘计算的应用也逐步推广。现阶段，各运营 商、企业都开始对于边缘节点的部署，期望将各类业务下沉到边缘进行 处理，以满足5G对于高带宽(eMBB)、低时延(URLLC)、广连接(mMTC)的 三大特性需求。伴随着边缘节点的部署，各类安全手段及解决方案也逐 渐推出，在现有方案中，有一种安全检测引擎能力填加类方案架构，该 方案整体结合安全能力边缘化的思想，采用安全微服务的方式，将各个 传统的网络安全能力剖析为一个个安全检测引擎，如入侵检测引擎、威 胁行为检测引擎、恶意文件检测引擎、资产漏洞检测引擎、日志采集分 析引擎等等，每个安全引擎包含一定的安全分析检测功能，但性能更针 对化，可以根据每个边缘节点的业务情况与需求进行不同的安全能力部 署。对于边缘节点来说，边缘节点就类似一台智能手机，而安全引擎类 似手机上装载的各个app。

在该安全检测引擎能力填加类方案架构下，每个引擎的工作状态缺 少监控手段，同时每个引擎输出的数据格式不统一，给云端的数据处理 及引擎间的协同传输都带来了难题，因此，亟需一种新的管控手段，来 实现引擎间的协同监测，保证整体安全检测引擎能力填加类方案架构的 正常运作。

发明内容

针对现有技术上存在的不足，本发明目的是在于提供一种基于边缘 计算的数据传输与协同系统，提供了一个监听引擎来检测发现，并及时 报错；实现了各个引擎间的信息传递协同，保证每个安全检测引擎输出 的数据格式统一，方便后续的数据打包上传及引擎间协同的互相请求。

为了实现上述目的，本发明是通过如下的技术方案来实现：基于边 缘计算的数据传输与协同系统，包括边缘节点、安全检测引擎、传输监 听引擎和核心云端，所述的边缘节点：边缘计算技术带来的部署节点， 本身以服务器或是服务器集群组成，用于承载企业或是用户的相关业务， 整体部署在网络边缘侧，目的用于将云上部分处理功能下沉；下方连接 多个用户终端，以流量方式处理传输各个终端上的业务；

所述的安全检测引擎：对威胁行为检测引擎、恶意文件检测引擎、 入侵检测引擎、资产漏洞检测引擎等网络安全能力产品的核心能力的统 称；所指的引擎为软件类中的程序，是一种经过高度抽象的业务执行逻 辑，具有一定的通用性，使开发者可以更专注自身业务的开发，而不需 要直接考虑业务需求的问题，以满足该需求领域内的大多数具体使用场 景，达到简化开发的目的，一般引擎都是加载于服务器中。

所述的安全检测引擎对边缘节点的流量/日志进行采集分析，依据每 个引擎自身的功能从流量/日志中剖析可能存在的网络威胁行为、恶意文 件、资产漏洞、网络攻击的网络安全问题，形成相应的问题分析结果报 告并进行上传；安全检测引擎的部署目的在于从被动防御与主动防御两 个角度实现对边缘节点的网络安全管控。

所述的传输监听引擎：实现两部分功能，第一部分功能是实现对于 各个安全检测引擎上报的分析结果的统一打包；该功能是为了解决各个 安全检测引擎上报数据格式杂乱，云端要额外分配资源进行数据分析的 问题；结合边缘计算理念，目的将绝大多数的分析任务下沉到边缘，故 通过传输监听引擎事先对所有上报的分析结果进行一个预处理，通过在 安全引擎所检测出的数据增加一层数据标识，包含对安全检测引擎名称、 传输监听引擎IP、传输监听引擎运行状态、上报时间和主要上报的详细 数据内容的识别；其中详细数据内容包含各个安全检测引擎的运行状态。 该标识可通过自定义协议传输，或通过json这种key-value的数据格式进 行传输；数据格式统一后，将数据通过AES256进行加密，保障云端与 传输监听引擎、传输监听引擎之间的数据传输间的安全；完成数据加密 处理后，定期打包上传给云端，云端只需根据传输监听引擎名称、传输 监听引擎IP、传输监听引擎运行状态、上报时间、信息主要内容进行相 关的数据存储与展示；第二部分功能是实现对于安全检测引擎的工作状 态的一个定期监听，目的在于发现安全检测引擎的工作故障或是其他导 致引擎工作异常的问题；传输监听引擎主要监听安全检测引擎的网络、 进程、日志三方面数据并进行采集分析，其中网络情况是通过实时监测 与计算安全监测引擎所在服务器的网络丢包率来反应当前的网络状况， 进程情况是通过判断安全检测引擎运行进程是否存在来反应安全检测引 擎的运行状态，日志情况是通过读取与解析系统日志与安全检测引擎日 志数据来分析安全检测引擎运行异常的具体情况，在传输监听引擎侧分 析出安全检测引擎可能存在的系统故障，定期上报给云端。

所述的边缘节点不少于2个。

本发明的有益效果：

1、针对现有的安全检测引擎(如威胁行为分析引擎、恶意文件检测 引擎、日志采集分析引擎、资产管理引擎等)在完成自身检测分析的功 能的同时，引擎本身是否正常工作的状态缺少检测的问题。即在工作过 程中，安全检测引擎可能因为某些问题，无法很好的行使自己的功能或 是完全宕机，那么这种引擎因故障下线的问题，本发明提供了一个监听 引擎来检测发现，并及时报错。

2、实现了各个引擎间的信息传递协同，保证每个安全检测引擎输出 的数据格式统一，方便后续的数据打包上传及引擎间协同的互相请求。 故需要一个传输引擎来对各个引擎输出的数据进行格式统一包装，保证 在上传到云端及传输引擎间的互相请求时，数据格式互通，减少传输时 因数据格式变化带来的冗余时间。

3、引擎间的协同监测问题，基于前面2个问题，在保证能够监听安 全检测引擎本身的安全的同时，也需要保证监听引擎自身的工作情况是 正常可靠的，那么需要其余的监听引擎来监控该监听引擎本身的工作情 况，总体上实现一个相互协同检测的架构，保证了整个网络环境中的各 个安全设备都有所监控，减少了云端用于监控边缘侧工作情况的监控资 源。

附图说明

下面结合附图和具体实施方式来详细说明本发明；

图1为本发明的功能架构图；

图2为本发明的协同体系架构图。

具体实施方式

为使本发明实现的技术手段、创作特征、达成目的与功效易于明白 了解，下面结合具体实施方式，进一步阐述本发明。

参照图1，本具体实施方式采用以下技术方案：基于边缘计算的数据 传输与协同系统，包括边缘节点(服务器)、安全检测引擎、传输监听引 擎和核心云端，所述的边缘节点(业务服务器)：边缘计算技术带来的部 署节点，本身以服务器或是服务器集群组成，主要用于承载企业或是用 户的相关业务，整体部署在网络边缘侧，目的用于将云上部分处理功能 下沉。下方连接多个用户终端，以流量等方式处理传输各个终端上的业 务。

所述的安全检测引擎：对威胁行为检测引擎、恶意文件检测引擎、 入侵检测引擎、资产漏洞检测引擎等网络安全能力产品的核心能力的统 称。所指的引擎为软件类中的程序，是一种经过高度抽象的业务执行逻 辑，具有一定的通用性，使开发者可以更专注自身业务的开发，而不需 要直接考虑业务需求的问题，以满足该需求领域内的大多数具体使用场 景，达到简化开发的目的，一般引擎都是加载于服务器中。这些安全检 测引擎对边缘节点(业务服务器)的流量/日志进行采集分析，依据每个 引擎自身的功能从流量/日志中剖析可能存在的网络威胁行为、恶意文件、 资产漏洞、网络攻击等网络安全问题，形成相应的问题分析结果报告并 进行上传。安全检测引擎的部署目的在于从被动防御与主动防御两个角 度实现对边缘节点(业务服务器)的网络安全管控。

所述的传输监听引擎：本发明方案的创新点，主要实现两部分功能。 第一部分功能是实现对于各个安全检测引擎上报的分析结果的统一打 包。该功能是为了解决各个安全检测引擎上报数据格式杂乱，云端要额 外分配资源进行数据分析的问题。结合边缘计算理念，目的将绝大多数 的分析任务下沉到边缘，故通过传输监听引擎事先对所有上报的分析结 果进行一个预处理，通过在安全引擎所检测出的数据增加一层数据标识， 主要包含对安全检测引擎名称、传输监听引擎IP、传输监听引擎运行状 态、上报时间和主要上报的详细数据内容的识别；其中详细数据内容包 含各个安全检测引擎的运行状态。该标识可通过自定义协议传输，也可 通过json这种key-value的数据格式进行传输。数据格式统一后，将数据 通过AES256进行加密，保障云端与传输监听引擎、传输监听引擎之间 的数据传输间的安全。完成数据加密处理后，定期打包上传给云端，云 端只需根据传输监听引擎名称、传输监听引擎IP、传输监听引擎运行状 态、上报时间、信息主要内容进行相关的数据存储与展示。第二部分功 能是实现对于安全检测引擎的工作状态的一个定期监听，目的在于发现 安全检测引擎的工作故障或是其他导致引擎工作异常的问题。传输监听 引擎主要监听安全检测引擎的网络、进程、日志三方面数据并进行采集 分析，其中网络情况是通过实时监测与计算安全监测引擎所在服务器的 网络丢包率来反应当前的网络状况，进程情况是通过判断安全检测引擎 运行进程是否存在来反应安全检测引擎的运行状态，日志情况是通过读 取与解析系统日志与安全检测引擎日志数据来分析安全检测引擎运行异 常的具体情况，在传输监听引擎侧分析出安全检测引擎可能存在的系统 故障，定期上报给云端。

实施例1：整体的技术方案体系架构如图2所示。借助功能架构中设 计的传输监听引擎，形成边缘节点间的协同监测体系。该体系中不局限 于边缘节点A、边缘节点B和边缘节点C，节点数量可以更多但不少于2 个。

图2中，边缘节点A或B对应图1的功能架构图，该协同体系架构 图主要体现节点间的协同功能。协同点在于每个边缘节点对应的传输监 听引擎会对处于协同状态的传输监听引擎定期发送数据协同请求，收到 请求的传输监听引擎，如果正常工作则进行反馈，如果工作异常则无法 进行反馈，发出请求的传输监听引擎根据反馈情况判断相邻节点的工作 情况是否正常。

当只有2个节点A和B的时候，即如图2所示。节点A和节点B启 动后会经过一个初始化过程，首先会先向云端发送节点注册请求，请求 内容包含了边缘节点A的IP和传输监听引擎A使用的端口，云端接收到 信息后，会将边缘节点A信息存储到数据库中，并返回除了边缘节点A 之外且已在云端注册的节点信息给节点A，即会返回边缘节点B，边缘 节点A会对边缘节点B做一次探活请求，若该节点接收请求，则将该节 点作为自身的协同对象进行数据协同；若返回的节点信息都没有可用的 则无法执行协同功能；初始化完成后，传输监听引擎A每隔一定时间(该 时间可以依据需求制定，假设为1小时)向传输监听引擎B发送一个数 据协同请求，其中数据包含了边缘节点A中的各个安全检测引擎的检测 数据、运行日志、运行状态、网络状况等数据，传输监听引擎B在接受 到该数据包后，如果在正常工作，则发送一个反馈包给传输监听引擎A， 传输监听引擎A在收到反馈包后判断传输监听引擎B工作正常，则一个 数据协同过程完成。如果传输监听引擎B未正常工作(如断线、故障等)， 则无法发送反馈包，此时传输监听引擎A未收到反馈包，记录1次未收 到，1小时(一个周期)后再次发送数据协同请求给传输监听引擎B，此 时传输监听引擎B收到数据包后如果正常工作则发送反馈包给传输监听 引擎A，传输监听引擎A收到后判断传输监听引擎B正常，抹除上一次 的未收到记录，完成本次的请求反馈环节，如果此时传输监听引擎B仍 为正常工作，仍无法发送反馈包给传输监听引擎A，则传输监听引擎A 再次记录1次未收到并上传传输监听引擎B工作异常的告警数据给云端， 提示相关人员进行检查修复。同理，传输监听引擎B也可以向传输监听 引擎A做同样的请求反馈行为，以整体完成一个协同监测的流程。其中， 传输监听引擎触发告警上报机制的未收到记录次数可以根据实际需求进 行设定，本实施例假定是2次未收到即触发告警上报机制。

传输监听引擎间互相获取检测分析数据的目的在于，防止出现由于 传输监听引擎与云端的网络连接出现问题而导致的数据无法上报的情 况。如果传输监听引擎B与云端的网络连接断开了，则可以由传输监听 引擎A请求获取传输监听引擎B的分析数据，再上报给云端，保证数据 的完整性。即某刻传输监听引擎A向传输监听引擎B发送请求，传输监 听引擎B在接收到请求数据包后，若在正常工作，则发送存活反馈与自 身此时所存储的检测分析数据给传输监听引擎A，传输监听引擎A在接 收到存活反馈与B发送的检测分析数据后，结合自身的检测分析数据一 并打包上传给云端，若此时传输监听引擎B与云端的连接正常，则B也 正常上传自身的检测分析数据给云端，云端在收到传输监听引擎A和B 上报的数据后，依据云端自有的去重算法策略，判别其中重复上报的数 据(即由传输监听引擎A上报的传输监听引擎B的检测分析数据)并进 行删除，保留存储真实有效的数据；若此时传输监听引擎B与云端的连 接断开，则云端也可以通过传输监听引擎A上报的传输监听引擎B的检 测分析数据发现边缘节点B上的网络安全问题，解决短时间内传输监听 引擎与云端连接断开造成的上报数据失败问题。如果长时间云端未接收 到某个传输监听引擎上报的数据，则云端自动判断自身与该传输监听引 擎间的网络连接已断开并进行告警反馈。

实施例2：本实施例有3个边缘节点A、B、C的情况，传输监听引 擎A在刚开始启动运行时，首先会先向云端发送节点注册请求，请求内 容包含了边缘节点A的IP和传输监听引擎A使用的端口，云端接收到信 息后，会将边缘节点A信息存储到数据库中，并返回除了边缘节点A之 外且已在云端注册的节点信息给节点A，即会返回边缘节点B和边缘节 点C，边缘节点A会对边缘节点B和边缘节点C分别做一次探活请求， 并根据边缘节点B和边缘节点C的响应时间从低到高进行最优排序，形 成最优的网络节点排序列表，并选择响应时间最少的节点发送协同请求； 若该节点接收请求，则将该节点作为自身的协同对象进行数据协同；若 返回的节点信息都没有可用的则无法执行协同功能；

若存在可作为协同对象的节点且确定协同节点后，边缘节点A将周 期性的将自身节点数据发送给节点协同对象进行数据协同，其中数据包 含了边缘节点A中的各个安全检测引擎的检测数据、运行日志、运行状 态、网络状况等数据；假设边缘节点A选择的边缘节点B为协同对象， 当节点协同对象B发生了故障无法进行数据协同时，则边缘节点A会按 照之前网络最优的节点排序列表；从第二个节点开始发送协同请求，即 向边缘节点C发送请求；若边缘节点C能够接收数据协同请求，则边缘 节点A本次将与边缘节点C进行数据协同，并上报边缘节点B的故障至 云端；当边缘节点A三个周期都无法与协同对象边缘节点B进行数据协 同，则在第三个周期无法进行数据协同后，丢弃边缘节点B的节点信息， 并将边缘节点C作为新的数据协同对象。

当节点数量增加(3个或以上)，那么传输监听引擎间可以实现两两、 或是多方请求探活及反馈的功能，理想情况，每个传输监听引擎可以跟 自身以外的同一个网络环境(或域)内的所有传输监听引擎进行数据互 通，搭建探活请求及反馈的沟通桥梁，这个互相连接的数量可根据网络 情况及流量情况可以调整与适配。互联数越多，协同监测结果的可靠性 也越高，只有出现该网络环境(域)下所有的传输监听引擎同时出现故 障了，该体系才会失去它的监测作用，这种情况只有通过云端进行分析 判断，但可能性较小。

同时，为了解决传输监听引擎侧接收的安全检测引擎上报的流量分 析数据与对于安全检测引擎的日志等分析数据产生频率不同的问题，在 传输监听引擎侧设立一个小型数据库，该小型数据库用于暂存传输监听 引擎对于安全检测引擎的日志等数据的采集分析结果(因为该类数据相 对安全检测引擎上报的流量分析数据生成频率较大)，当传输监听引擎收 到安全检测引擎上报的流量分析数据时，再将已存储于小型数据库中的 分析结果取出并和流量分析数据一起打包上传给云端。若超过12小时(该 时间可以依据实际需求调整)未接收到安全检测引擎上报的流量分析数 据(可能就是没有检测到网络安全问题)，则传输监听引擎会自动调取小 型数据库中的数据上报给云端，该步骤目的是防止出现长时间安全检测 引擎未检测到网络安全问题或是传输监听引擎与安全检测引擎间连接断 开而导致传输监听引擎停止上报数据的问题。

以上显示和描述了本发明的基本原理和主要特征和本发明的优点。 本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施 例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范 围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要 求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其 等效物界定。

Claims (5)

1.基于边缘计算的数据传输与协同系统，其特征在于，包括边缘节点、安全检测引擎、传输监听引擎和核心云端，所述的边缘节点：边缘计算技术带来的部署节点，本身以服务器或是服务器集群组成，用于承载企业或是用户的相关业务，整体部署在网络边缘侧，目的用于将云上部分处理功能下沉；下方连接多个用户终端，以流量方式处理传输各个终端上的业务；

所述的安全检测引擎：对威胁行为检测引擎、恶意文件检测引擎、入侵检测引擎、资产漏洞检测引擎的网络安全能力产品的核心能力的统称；所指的引擎为软件类中的程序，是一种经过高度抽象的业务执行逻辑，具有一定的通用性，使开发者可以更专注自身业务的开发，而不需要直接考虑业务需求的问题，以满足该需求领域内的大多数具体使用场景，达到简化开发的目的，安全检测引擎都是加载于服务器中；

所述的传输监听引擎：实现两部分功能，第一部分功能是实现对于各个安全检测引擎上报的分析结果的统一打包；该功能是为了解决各个安全检测引擎上报数据格式杂乱，云端要额外分配资源进行数据分析的问题；结合边缘计算理念，目的将绝大多数的分析任务下沉到边缘，故通过传输监听引擎事先对所有上报的分析结果进行一个预处理，通过在安全引擎所检测出的数据增加一层数据标识，包含对安全检测引擎名称、传输监听引擎IP、传输监听引擎运行状态、上报时间和主要上报的详细数据内容的识别；其中详细数据内容包含各个安全检测引擎的运行状态；该标识通过自定义协议传输，或通过json这种key-value的数据格式进行传输；数据格式统一后，将数据通过AES256进行加密，保障云端与传输监听引擎、传输监听引擎之间的数据传输间的安全；完成数据加密处理后，定期打包上传给云端，云端只需根据传输监听引擎名称、传输监听引擎IP、传输监听引擎运行状态、上报时间、信息主要内容进行相关的数据存储与展示；第二部分功能是实现对于安全检测引擎的工作状态的一个定期监听，目的在于发现安全检测引擎的工作故障或是其他导致引擎工作异常的问题；传输监听引擎主要监听安全检测引擎的网络、进程、日志三方面数据并进行采集分析，其中网络情况是通过实时监测与计算安全监测引擎所在服务器的网络丢包率来反应当前的网络状况，进程情况是通过判断安全检测引擎运行进程是否存在来反应安全检测引擎的运行状态，日志情况是通过读取与解析系统日志与安全检测引擎日志数据来分析安全检测引擎运行异常的具体情况，在传输监听引擎侧分析出安全检测引擎可能存在的系统故障，定期上报给云端。

2.根据权利要求1所述的基于边缘计算的数据传输与协同系统，其特征在于，所述的安全检测引擎对边缘节点的流量/日志进行采集分析，依据每个引擎自身的功能从流量/日志中剖析可能存在的网络威胁行为、恶意文件、资产漏洞、网络攻击的网络安全问题，形成相应的问题分析结果报告并进行上传；安全检测引擎的部署目的在于从被动防御与主动防御两个角度实现对边缘节点的网络安全管控。

3.根据权利要求1所述的基于边缘计算的数据传输与协同系统，其特征在于，所述的边缘节点不少于2个。

4.根据权利要求1所述的基于边缘计算的数据传输与协同系统，其特征在于，所述的边缘节点为边缘节点A和边缘节点B两个节点时，其协同流程如下：节点A和节点B启动后经过一个初始化过程，首先先向云端发送节点注册请求，请求内容包含了边缘节点A的IP和传输监听引擎A使用的端口，云端接收到信息后，将边缘节点A信息存储到数据库中，并返回除了边缘节点A之外且已在云端注册的节点信息给节点A，即返回边缘节点B，边缘节点A对边缘节点B做一次探活请求，若该节点接收请求，则将该节点作为自身的协同对象进行数据协同；若返回的节点信息都没有可用的则无法执行协同功能；初始化完成后，传输监听引擎A每隔一定时间向传输监听引擎B发送一个数据协同请求，其中数据包含了边缘节点A中的各个安全检测引擎的检测数据、运行日志、运行状态、网络状况数据，传输监听引擎B在接受到该数据包后，如果在正常工作，则发送一个反馈包给传输监听引擎A，传输监听引擎A在收到反馈包后判断传输监听引擎B工作正常，则一个数据协同过程完成；如果传输监听引擎B未正常工作，则无法发送反馈包，此时传输监听引擎A未收到反馈包，记录1次未收到，一个周期后再次发送数据协同请求给传输监听引擎B，此时传输监听引擎B收到数据包后如果正常工作则发送反馈包给传输监听引擎A，传输监听引擎A收到后判断传输监听引擎B正常，抹除上一次的未收到记录，完成本次的请求反馈环节，如果此时传输监听引擎B仍为正常工作，仍无法发送反馈包给传输监听引擎A，则传输监听引擎A再次记录1次未收到并上传传输监听引擎B工作异常的告警数据给云端，提示相关人员进行检查修复；同理，传输监听引擎B也可以向传输监听引擎A做同样的请求反馈行为，以整体完成一个协同监测的流程。

5.根据权利要求1所述的基于边缘计算的数据传输与协同系统，其特征在于，所述的边缘节点为边缘节点A、边缘节点B和边缘节点C三个节点时，其协同流程如下：传输监听引擎A在刚开始启动运行时，首先先向云端发送节点注册请求，请求内容包含了边缘节点A的IP和传输监听引擎A使用的端口，云端接收到信息后，将边缘节点A信息存储到数据库中，并返回除了边缘节点A之外且已在云端注册的节点信息给节点A，即返回边缘节点B和边缘节点C，边缘节点A对边缘节点B和边缘节点C分别做一次探活请求，并根据边缘节点B和边缘节点C的响应时间从低到高进行最优排序，形成最优的网络节点排序列表，并选择响应时间最少的节点发送协同请求；若该节点接收请求，则将该节点作为自身的协同对象进行数据协同；若返回的节点信息都没有可用的则无法执行协同功能；

若存在可作为协同对象的节点且确定协同节点后，边缘节点A将周期性的将自身节点数据发送给节点协同对象进行数据协同，其中数据包含了边缘节点A中的各个安全检测引擎的检测数据、运行日志、运行状态、网络状况数据；假设边缘节点A选择的边缘节点B为协同对象，当节点协同对象B发生了故障无法进行数据协同时，则边缘节点A按照之前网络最优的节点排序列表；从第二个节点开始发送协同请求，即向边缘节点C发送请求；若边缘节点C能够接收数据协同请求，则边缘节点A本次将与边缘节点C进行数据协同，并上报边缘节点B的故障至云端；当边缘节点A三个周期都无法与协同对象边缘节点B进行数据协同，则在第三个周期无法进行数据协同后，丢弃边缘节点B的节点信息，并将边缘节点C作为新的数据协同对象。