用于确定数据格式的控制设备和方法与流程

文档序号:21699572发布日期:2020-07-31 23:00阅读:296来源:国知局
用于确定数据格式的控制设备和方法与流程

本发明涉及一种用于确定数据格式的控制设备、一种用于发送数据的车辆、一种用于发送数据的设备、一种用于确定数据格式的系统、一种用于确定数据格式的方法和一种计算机程序。具体而言,本发明涉及在用户设备ue/车辆之间协调处理任务以实现大数据量的协同处理。



背景技术:

典型的车载通信使用案例要求车辆之间共享信息,以便进行适当的决策。然而,由于无线资源有限,车辆之间共享信息将导致时延增加。在没有协调的v2x(vehicle-to-everything,简称v2x)应用中,车辆在没有网络协调的情况下向其邻居传输,可能发生冲突,从而进一步增加时延。

处理待传输数据量增加的一个潜在方法是在车辆之间共享信息之前对信息进行处理。这可以在云服务器中发生,也可以在本地发生。第一种情况下,由于需要从ue/车辆向网络传输信息(反之亦然)以及到达云服务器需要传播时延,增加了时延。第二个选择是基于以下假设:ue/车辆具有在传输信息之前处理信息的处理能力。这对附近的所有车辆来说并非都是可能的。第一选择和第二选择的组合是基于车辆的实现(称为雾计算),其中,设备根据它们的能力和例如负载等网络条件分担处理负载。

已针对v2x应用对雾计算进行了若干研究。侯、李、陈等人在“aviewpointofvehiclesastheinfrastructures,ieeetransactionsonvehiculartechnology,2016,65(6):3860-3873”中通过识别车辆的通信能力、连接性和机动性之间的关系,描述了雾计算在车载通信中的优势,但没有说明系统如何考虑每辆车的计算能力。

在陈和王的“exploringfogcomputingbasedadaptivevehiculardataschedulingpoliciesthroughacompositionalformalmethod-pepa,ieeecommunicationsletters,2017,pp(99):1-1.”中,雾计算技术用于增强分层网络架构中的车载网络,其中,针对将处理任务动态调度到设备,考虑了网络拓扑,但未考虑网络负载,同时,也未说明设备配置的方式。

us2012/0105637a1公开了一种使车辆能够连接到云服务器的方法,该方法有助于车辆访问多媒体应用。该方法只关注多媒体业务,只关注方便车辆连接到云服务器共享信息。



技术实现要素:

针对上述问题和缺点,本发明旨在改善v2x通信中的数据传输。因此,本发明的目的是提供一种用于确定数据格式的控制设备和用于确定数据格式的方法,与本领域已知的相应方案相比,所述控制设备和所述方法具有更好的性能。

本发明的目的通过在所附独立权利要求中提供的方案来实现。本发明的有利实施方式在从属权利要求中进一步定义。

具体地,本发明提出基于v2x和雾计算的大数据量协同处理。本发明涉及协调附近车辆之间的处理任务。

本发明第一方面提供了一种控制设备,用于确定通过车辆与至少一个设备之间的v2x通信链路待发送的数据的数据格式。其中,所述控制设备用于接收关于所述车辆和/或所述至少一个设备的通信能力和计算能力的信息,所述控制设备用于基于所述通信能力和所述计算能力分析所述接收到的信息,所述控制设备用于基于所述分析,从所述v2x通信链路的数据格式集合中选择数据格式,其中,所述集合的数据格式根据待发送数据的数据量而不同,以及所述控制设备用于向所述车辆和/或所述至少一个设备发送待发送数据使用的数据格式的指示。

本发明引入了通信计算控制功能(communicationcomputingcontrolfunction,简称cccf),用于根据每个车辆/设备通信和计算能力决定其将使用哪种格式,并将该决策传送给该车辆/设备。该决策可以包括发送多个指示,例如,当车辆或其用户设备(userequipment,简称ue)应针对一种业务使用完成格式而针对另一种业务使用原始格式进行通信时。所有车辆都向cccf提供自己的车辆状态(车辆自描述参数)、计算能力、通信能力信息。可以按需提供、周期性提供、或者每次网络元素/拓扑/等发生重大变化时提供。

本发明提供了一种根据车辆能力自适应选择传输数据类型的方案,通过高效利用通信和计算能力提高终端性能。具有各种计算和通信能力的车辆之间形成合作,以支持各代车辆和/或具有各种计算能力的车辆的混合。

本发明提供了一种支持安全相关的v2x业务的方案,如环境感知、传感器数据共享和/或动态地图更新;实时提供交通信息和环境感知信息(传输前预处理);降低以牺牲车辆计算为代价对无线资源的需求;以及缩短由于在车辆、rsu和/或移动边缘计算(mobileedgecomputing,简称mec)之间分担计算负载导致的车辆感知反应时间。

本发明还提供了一种支持非安全v2x服务的方案,例如,车联网和信息娱乐,如网页浏览、社交媒体和应用下载;无缝覆盖广域的移动商务服务,如移动云办公、邮件服务和在线会议;以及增强现实(augmentedreality,简称ar)/虚拟现实(virtualreality,简称vr)。

本发明的优点是至少在网络边缘处分析时间敏感度最高的数据,靠近网络边缘处生成数据,而不是向云发送大量数据,例如物联网(internetofthings,简称iot)数据。因此,基于定义的策略,可以以毫秒级对iot数据进行操作,同时可以将选择的数据发送到云进行历史分析和更长期存储。

在第一方面的一种实现方式中,所述控制设备用于向所述车辆和/或所述至少一个设备发送包括所述数据格式的指示和数据发送之前要对数据执行的计算任务的分配的消息,或者包括所述数据格式的指示、计算任务的分配和接收器的消息。除了所述数据格式的指示之外,还可以发送数据发送之前要对数据执行的计算任务的分配。这(或这些)计算任务可将源数据或原始数据转换为其它格式的数据量较少的数据。此外,可以包括消息的一个或多个接收器,从而将数据格式和/或任务直接发送到相应的接收器。

在第一方面的另一种实现方式中,所述控制设备用于提供至少三种数据格式,包括用于发送未经计算的原始数据的原始数据格式、用于发送适度计算的粗略数据的粗略数据格式和用于发送广泛计算的完成数据的完成数据格式中的至少一个。可以提供三种以上数据格式,例如,五种数据格式。进一步地,可以提供不同级别的数据格式。例如,可以为经过少量或大量处理的数据提供多个粗略格式级别。完成格式可以是指不再进一步处理的数据。

在第一方面的一种实现方式中,所述关于通信能力的信息包括所述车辆和/或所述设备的通信能力以及所述v2x通信链路的通信能力。该实现方式考虑了实际状况和更精确的协作处理。

在第一方面的另一种实现方式中,所述关于计算能力的信息包括当前计算能力、实际计算任务和/或静态计算能力。该实现方式考虑了实际状况和更精确的协作处理。

在第一方面的一种实现方式中,所述控制设备用于接收和分析其它信息,例如静态车辆信息、动态车辆信息、静态设备信息、动态设备信息、源数据描述和/或与数据相关的使用案例。例如,在紧急制动等使用案例中,无论链路是否具有高能力,均可能需要处理数据。该信息可以改进分析和分析结果,即数据格式和/或计算任务的分配。

在第一方面的另一种实现方式中,所述控制设备用于从所述车辆和/或所述至少一个设备的代表处间接接收关于所述车辆和/或所述至少一个设备的通信能力和计算能力的信息。例如,车辆和/或至少一个设备的代表可以为排头。

在第一方面的一种实现方式中,所述控制设备用于在车辆、设备、提供v2x通信链路的v2x通信网络的元件和/或服务提供商中实现。例如,所述控制设备可以在基站或路侧单元(roadsideunit,简称rsu)中实现。所述控制设备或控制功能可以在任何单元或元件中实现,只要其能够直接或间接与所述车辆和/或所述至少一个设备进行通信。所述控制设备可以分布在多个实体上。所述控制设备可以在逻辑上集中的任一网元中实现。换言之,所述控制设备可以与基站、控制面网络功能如移动性服务器等共处一地。进一步地,还可以在云服务器应用、边缘计算服务器等中实现。还可以在车辆群/组的群/组长中实现。

本发明第二方面提供了一种用于根据接收到的数据格式,通过车辆和至少一个设备之间的v2x通信链路发送数据的车辆。其中,所述车辆用于发送关于所述车辆的通信能力和计算能力的信息,所述车辆用于接收待发送至所述至少一个设备的数据使用的数据格式的指示,以及所述车辆用于根据所述接收到的数据格式发送所述数据。与上述相同的优点和修改同样适用。

在第二方面的一种实现方式中,所述车辆用于在发送所述数据之前计算所述数据。这可以通过压缩技术和过滤操作等实现。

本发明第三方面提供了一种用于根据接收到的数据格式,通过设备和至少一个车辆之间的v2x通信链路发送数据的设备。其中,所述设备用于发送关于所述设备的通信能力和计算能力的信息,所述设备用于接收待发送至所述至少一个车辆的数据使用的数据格式的指示,以及所述设备用于根据所述接收到的数据格式发送所述数据。与上述相同的优点和修改同样适用。

在第三方面的一种实现方式中,所述设备用于在发送所述数据之前计算所述数据。通过计算数据,可以减少待发送的数据量。这可以通过压缩技术和过滤操作等实现。

本发明第四方面提供了一种系统,用于确定通过车辆和至少一个设备之间的v2x通信链路待发送的数据的数据格式。其中,所述系统包括如上所述的控制设备、至少一个如上所述的车辆和/或至少一个如上所述的设备。与上述相同的优点和修改同样适用。

本发明第五方面提供了一种方法,用于确定通过车辆和至少一个设备之间的v2x通信链路待发送的数据的数据格式,包括:

接收关于所述车辆和/或所述至少一个设备的通信能力和计算能力的信息;

基于所述通信能力和所述计算能力分析所述接收到的信息;

基于所述分析,从所述v2x通信链路的数据格式集合中选择数据格式,其中,所述集合的数据格式根据数据量而不同;以及

向所述车辆和/或所述至少一个设备发送待发送数据使用的数据格式的指示。与上述相同的优点和修改同样适用。

本发明第六方面提供了一种具有程序代码的计算机程序,用于:当计算机程序在计算机或如上所述的控制设备上运行时,执行如上所述的方法。与上述相同的优点和修改同样适用。

需要注意的是,本申请所描述的所有设备、元件、单元和方式均可在软件或硬件元件或它们的任意组合中实现。本申请中描述的各种实体执行的所有步骤和所描述的将由各种实体执行的功能旨在表明各个实体适于或用于执行各自的步骤和功能。虽然在以下具体实施例的描述中,由外部实体执行的特定功能或步骤没有在执行特定步骤或功能的该实体的具体元件的描述中反映,但是技术人员应该清楚的是这些方法和功能可以在各自的硬件或软件元件或其任意组合中实现。

附图说明

结合所附附图,下面具体实施例的描述将阐述上述本发明的各方面及其实现形式,其中:

图1示出了用于确定通过v2x通信链路发送的数据的数据格式的控制设备的示例;

图2示出了v2x通信架构的示例;

图3为用于确定待发送数据的数据格式的控制算法的示例性实现方式的流程图;

图4为用于确定待发送数据的数据格式的控制算法的另一种示例性实现方式的流程图;

图5为示出了用于车载ue的控制和数据传输顺序的时序图;

图6为示出了车载ue和rsu的控制和数据传输顺序的时序图。

具体实施方式

图1示出了一种控制设备100,用于确定通过车辆120和至少一个设备130之间的v2x通信链路110待发送的数据的数据格式。所述控制设备100接收关于所述车辆120和/或所述至少一个设备130的通信能力和计算能力的信息。所述控制设备100基于所述通信能力和所述计算能力分析所述接收到的信息。所述控制设备100基于所述分析,从所述v2x通信链路110的数据格式集合中选择数据格式,其中,所述集合的数据格式根据待发送数据的数据量而不同。所述控制设备100向所述车辆120和/或所述至少一个设备130发送待发送数据使用的数据格式的指示。所述设备130可以是车辆、rsu或任何其它类似类型的设备。

图1具体示出了闭环控制流。具体地,cccf或控制设备100可以采集车辆描述参数,包括但不限于速度、位置、制动、加速度等。信息还可以包含待传输的信息的类型,即传感器信息、摄像头输入等,以及进一步的源数据描述,例如源类型、待发送的信息以及每辆车120的计算和通信能力。此外,cccf100可以从附近的其它网元,例如路侧单元(roadsideunit,简称rsu),收集类似的信息,这些网元可以提供处理可用数据的计算能力。

在基于雾计算的v2x通信中交互的信息还可以包括控制信息,例如传输数据格式和计算任务。控制设备100可以向其它元件或订户发送该控制信息。关于车辆120和设备130之间的通信,应注意的是,这些元件中的每一个元件包括用于通信的用户设备ue等。控制设备100还可以包括ue。可选地,控制设备100可以通过can总线等另一链路或协议与其主机的ue进行通信。

控制设备100具体用作控制单元,用于确定协作模式和释放控制信息。它进一步用作存储单元,用于存储静态信息,例如车辆信息。

当cccf或控制设备100接收到上述信息元素时,将分析该信息元素以提取合适的计算工作量分布。该计算工作量分布包括数据格式以及待发送数据的数据量。

车载网络传输的数据种类分为数据格式。该例中,提供了三种数据格式。可能有数据格式的子格式或附加格式类型。

原始数据格式包含原来的未处理信息,例如未压缩的原始图像或视频。

粗略数据格式包含经过轻度处理的数据,例如,从捕获的图像或具有粗略大小和位置的模糊物体中提取出相关部分信息。

完成数据格式包含经过高度处理的数据,包括从原始数据中提取的一些准确信息,如对象大小、速度和位置、警告信息等。

rsu/车辆的数据分为原始格式、粗略格式和完成格式或数据。cccf或控制设备100可以根据每个车辆的计算能力以及通信能力和/或考虑的使用案例为其选择待传输数据的类型。

粗略数据具有较大的灵活性,可由车辆本身先进行压缩,再传输给其它车辆。完成格式数据需要车辆先对数据进行完全计算或压缩,然后再传输给其它车辆。因此,完成数据的特点包括数据量小,适用于交通安全相关的重要内容。

根据车辆的处理能力和通信能力以及链路能力,控制设备100可以决定网元应使用所提出的示例性数据格式中的一种向其相邻车辆发送。当然,控制设备100可以决定一个网元使用所提出的示例性数据格式中的一种来传输给第一邻居,以及使用另一种数据格式来传输给另一邻居。

在控制设备100中运行的算法可以遵循需要的原则。原始格式数据可以直接发送给附近的车辆。计算能力差的车辆将采用这种数据格式。计算能力适中的车辆将采用粗略格式。至于完成格式,车辆可以在传输前处理所有的数据。它将用于计算能力强的车辆。这一过程将减轻车载网络的负担。可以考虑使用移动边缘计算(mobileedgecomputing,简称mec)或rsu中的额外计算能力来分担处理任务。

图1示出了控制设备100的第一实施例。反映图1中示出的第一实施例的更详细和可选实现方式的进一步实施例在以下附图中示出。

图2示出了v2x通信架构的示例以及用于确定待通过v2x通信链路发送的数据的数据格式的系统200的示例。

汽车、卡车、摩托车、公共汽车等在道路220上行驶的车辆210以及例如路侧单元(roadsideunit,简称rsu)230等设备是所述系统的一部分。此外,所述系统200包括至少一个通信计算控制功能(communicationcomputingcontrolfunction,简称cccf)240。

所述系统200与云250连接,以便车辆210或设备230能够利用云资源,例如计算能力。系统200还可包括和/或连接到v2x通信网络和/或例如移动通信网络等无线网络。

所有车辆210和/或rsu230向cccf240提供其车辆状态,例如车辆自描述参数、计算能力和通信能力信息。cccf240基于车辆210和/或rsu230的聚合信息规划资源使用,并将任务分配发送到这些车辆210和/或rsu230。待处理的原始数据是否能够由车辆本身处理、rsu230与其它车辆是否协同工作是根据任务分配的。

cccf240至少基于相应的通信能力和计算能力分析车辆210和/或rsu230。该通信能力或空间效率是车辆或设备通信能力的一项指标。它可以通过带宽或吞吐量参数来测量。计算能力是衡量车辆或设备计算能力的一项指标。它可以通过例如处理核的数量和速度等计算参数来测量。通信能力和计算能力为动态值,其可以根据例如车辆的位置、无线网络的负载、车载计算机的负载等而变化。

在图2的示例中,存在四组不同的车辆210。第一车辆210a具有高通信能力和高计算能力。第二车辆210b具有低通信能力和低计算能力。第三车辆210c具有高通信能力和低计算能力。最后,第四车辆210d具有低通信能力和高计算能力。

根据这些不同的通信能力和计算能力,cccf240向车辆210和/或至少一个设备230提供待发送至例如车辆210和设备230等其它订户的数据的数据格式的不同指示。此外,cccf240可以在将数据发送到车辆210和设备230之前,发送需对数据执行的计算任务的分配。

在下文中,给出了车辆210之间的通信的一些示例。例如,具有高通信能力和低计算能力的车辆210c由于车辆210a的高通信能力和高计算能力而将原始数据格式的数据发送给车辆210a。另一车辆210c与另一车辆210a协作,并将粗略数据格式的数据发送给具有低通信能力和高计算能力的车辆210d。具有低通信能力和低计算能力的车辆210b将数据发送到云250和/或rsu230进行处理。计算或处理的数据以完成数据格式从rsu230发送到相邻车辆210b和210d。

图3为用于确定待发送数据的数据格式的控制算法的示例性实现方式的流程图。

算法开始于步骤300,可以包括设置通信元件或传感器等。在步骤310中,接收关于通信能力和计算能力的信息。该信息可以从至少一个车辆和/或至少一个设备处接收或请求。其它信息可以来自无线网络、v2x网络等,且可以包括关于无线环境和网络负载的信息。更多其它信息可包括关于数据或需要数据和/或创建数据的使用案例的信息。

在步骤320中,识别v2x通信链路是否具有高通信能力。此处,可以使用静态信息来指示v2x通信链路的理论带宽。然而,指示v2x通信链路的实际带宽的动态信息可以提供更准确的信息。

对于通信能力不高的v2x通信链路,算法转到步骤330。在步骤330中,识别车辆是否具有高计算能力。该表述“车辆”是指待发送数据的车辆。

在车辆具有高计算能力的情况下,算法转到步骤340。在步骤340中,选择完成数据格式用于车辆发送数据。在车辆不具有高计算能力的情况下,算法转到步骤350。在步骤350中,选择粗略数据格式用于车辆发送数据。

在步骤360中,将控制信息或待使用数据格式的指示输出到车辆或车辆的ue。

如果在步骤320中确定v2x通信链路具有高通信能力,则算法转到步骤370。在步骤370中,选择原始数据格式用于车辆发送数据。在运行步骤370之后,执行步骤360,如上所述。在步骤380中,控制算法结束,并且可以再次启动,以便向另一车辆和/或设备进行下一次数据传输或下一次相同数据通信。

该算法也可以考虑输入,例如使用案例。甚至在高链路能力的情况下,也不需要发送原始数据,这取决于使用案例。

图4为用于确定待发送数据的数据格式的控制算法的另一示例性实现方式的流程图。图4所示的控制算法与图3所示的控制算法类似,但考虑了相邻车辆的计算能力。

算法开始于步骤400,可以包括设置通信元件或传感器等。在步骤410中,接收关于通信能力和计算能力的信息。该信息可以从至少一个车辆和/或至少一个设备处接收或请求。其它信息可以来自无线网络、v2x网络等,且可以包括关于无线环境和网络负载的信息。更多其它信息可包括关于数据或需要数据和/或创建数据的使用案例的信息。

在步骤420中,识别v2x通信链路是否具有高通信能力。此处,可以使用静态信息来指示v2x通信链路的理论带宽。然而,指示v2x通信链路的实际带宽的动态信息可以提供更准确的信息。

对于通信能力不高的v2x通信链路,算法转到步骤430。在步骤430中,识别车辆是否具有高计算能力。该表述“车辆”是指待发送数据的车辆。

在车辆具有高计算能力的情况下,算法转到步骤440。在步骤440中,选择完成数据格式用于车辆发送数据。在车辆不具有高计算能力的情况下,算法转到步骤450。在步骤450中,选择粗略数据格式用于车辆发送数据。

在步骤460中,将控制信息或待使用数据格式的指示输出到车辆或车辆的ue。

如果在步骤420中确定v2x通信链路具有高通信能力,则算法转到步骤470。在步骤470中,识别一个或多个相邻车辆是否具有高计算能力。

如果在步骤420中确定相邻车辆不具有高计算能力,则算法转到步骤430。如上所述,在步骤430中,识别车辆是否具有高计算能力。

如果在步骤420中确定相邻车辆具有高计算能力,则算法转到步骤480。在步骤480中,选择原始数据格式用于车辆发送数据。在运行步骤480之后,执行步骤460,如上所述。在步骤480中,控制算法结束,并且可以再次启动,以便向另一车辆和/或设备进行下一次数据传输或下一次相同数据通信。

控制算法的其它替代实现方式还可以考虑所考虑使用案例的时延要求。例如,如果需要低时延,则可以优先较少地处理数据。

图5为示出了用于车载ue的控制和数据传输顺序的时序图。控制设备或通信计算控制功能(communicationcomputingcontrolfunction,简称cccf)500与第一ue1510和第二ue2520进行通信。用户设备(userequipment,简称ue)510和520集成在其它车辆中。

在530中,可选地,在cccf500处接收来自ue1510和ue2520的静态车辆信息。例如,该静态信息包括车辆的单板计算能力,且可以从车辆应用服务器获取。

在540中,在cccf500处接收来自ue1510和ue2520的其它信息。例如,该其它信息包括通信能力,例如链路质量等无线链路信息,且可以从通信网络,例如,基站,中获取。进一步地,可以传输例如当前计算能力或车载计算机的负载等计算能力信息。例如当前速度、位置等动态车辆信息以及例如数据类型和数据量等车辆的源数据描述还可以从ue510和520中的一个或两个传输到cccf500。

在550中,cccf500运行如上所述的决策或控制算法。在560中,cccf将处理任务和数据传输类型分配给车载ue510和520。计算分配或数据传输类型可固有地根据其它信息从ue510或520推断出。例如,密集计算或处理任务可能与完成数据格式的指示有关。此处,将预处理数据的分配以及向ue2520发送粗略数据的分配发送至ue1510。ue2接收从ue1处接收的后处理数据的分配。

在570中,相应地,ue1510对源数据执行数据预处理。在580中,向ue2520发送粗略数据,即,粗略格式的数据。

在590中,ue2520对数据进行后处理。因此,组员ue1510和ue2520根据cccf决策使用雾资源完成其传输任务。

图6为示出了车载ue和rsu的控制和数据传输顺序的时序图。控制设备或通信计算控制功能communicationcomputingcontrolfunction,简称cccf)600与第一ue1610、第二ue2620和第三ue3630进行通信。用户设备(userequipment,简称ue)610和620集成在其它车辆中,而第三ue3630集成在rsu中。

在640中,可选地,在cccf500处接收来自ue1610和ue2620的静态车辆信息。从rsu处接收其它静态信息。例如,该静态信息包括车辆/rsu的计算能力,且可以从车辆应用服务器或rsu获取。

在650中,在cccf600处接收来自ue1610和ue2620的其它信息。例如,该其它信息包括通信能力,例如链路质量等无线链路信息,且可以从通信网络,例如,基站,中获取。进一步地,可以传输例如当前计算能力或车载计算机的负载等计算能力信息。例如,当前速度、位置等动态车辆信息以及例如数据类型和数据量等车辆的源数据描述还可以从ue610、620和630中的一个或多个传输到cccf600。

在660中,cccf600运行如上所述的决策或控制算法。在670中,cccf600将处理任务和数据传输类型分配给车载ue610和620以及rsuue630。计算分配或数据传输类型可固有地根据其它信息从ue610、620或630推断出。例如,密集计算或处理任务可能与完成数据格式的指示有关。

此处,将预处理数据的分配以及向ue3630发送粗略数据的分配发送至ue1610。ue2620接收从ue3630接收的后处理粗略数据的分配以及向ue2620发送粗略数据的分配。应注意的是,在该示例中,ue1和rsu发送粗略数据,ue3仍然要处理该数据。这意味着存在若干级别的粗略数据格式。

在680中,相应地,ue1610对源数据执行数据预处理。在690中,向ue3630发送粗略数据,即,粗略格式的数据。

在700中,ue3630处理数据。在710中,向ue2620发送粗略数据,即,粗略格式的数据。

在720中,ue2620后处理数据并完成由cccf600划分的任务。

在该示例中,排头,例如ue1610的车辆,可以执行cccf算法660来做出决策。决策结果中,将计算/传输任务分配给每个组员和rsu,以指导合作。因此,组员ue1610、ue2620和rsuue3630使用雾资源或自己的资源按照排头的命令完成其计算/传输任务。

已经结合作为实例的不同实施例以及实施方案描述了本发明。但本领域技术人员通过实践所请发明,研究附图、本公开以及独立权项,能够理解并获得其它变体。在权利要求以及描述中,术语包括并不排除其它元件或步骤,且一个并并不排除复数可能。单个元件或其它单元可满足权利要求书中所叙述的若干实体或项目的功能。在仅凭某些措施被记载在相互不同的从属权利要求书中这个单纯的事实并不意味着这些措施的结合不能在有利的实现方式中使用。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1