CN112236979B - 用于启用基于雾的数据处理的数据样本模板(dst)管理 - Google Patents
用于启用基于雾的数据处理的数据样本模板(dst)管理 Download PDFInfo
- Publication number
- CN112236979B CN112236979B CN201980037993.0A CN201980037993A CN112236979B CN 112236979 B CN112236979 B CN 112236979B CN 201980037993 A CN201980037993 A CN 201980037993A CN 112236979 B CN112236979 B CN 112236979B
- Authority
- CN
- China
- Prior art keywords
- data
- dst
- agent
- data sample
- dscs
- 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.)
- Active
Links
- 238000012545 processing Methods 0.000 title claims description 204
- 238000000034 method Methods 0.000 claims abstract description 191
- 239000003795 chemical substances by application Substances 0.000 claims description 84
- 238000004519 manufacturing process Methods 0.000 claims description 61
- 239000003595 mist Substances 0.000 claims description 33
- 230000015654 memory Effects 0.000 claims description 27
- 238000003860 storage Methods 0.000 claims description 21
- 230000008569 process Effects 0.000 abstract description 122
- 230000006870 function Effects 0.000 abstract description 27
- 230000004913 activation Effects 0.000 abstract description 10
- 238000012217 deletion Methods 0.000 abstract description 9
- 230000037430 deletion Effects 0.000 abstract description 9
- 230000009849 deactivation Effects 0.000 abstract description 4
- 239000010410 layer Substances 0.000 description 76
- 102100022339 Integrin alpha-L Human genes 0.000 description 52
- 108010064548 Lymphocyte Function-Associated Antigen-1 Proteins 0.000 description 52
- 230000000875 corresponding effect Effects 0.000 description 51
- 238000004891 communication Methods 0.000 description 46
- 238000013480 data collection Methods 0.000 description 37
- 238000004458 analytical method Methods 0.000 description 30
- 102100025237 T-cell surface antigen CD2 Human genes 0.000 description 25
- 101710165202 T-cell surface antigen CD2 Proteins 0.000 description 25
- 238000007726 management method Methods 0.000 description 19
- 230000008520 organization Effects 0.000 description 16
- 101001016186 Homo sapiens Dystonin Proteins 0.000 description 13
- 101000832669 Rattus norvegicus Probable alcohol sulfotransferase Proteins 0.000 description 13
- 238000010586 diagram Methods 0.000 description 13
- 230000009471 action Effects 0.000 description 11
- 238000004325 capillary sieving electrophoresis Methods 0.000 description 10
- 238000007405 data analysis Methods 0.000 description 9
- 230000002093 peripheral effect Effects 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 7
- 230000001413 cellular effect Effects 0.000 description 7
- 230000000694 effects Effects 0.000 description 7
- 238000000224 chemical solution deposition Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 6
- 230000010354 integration Effects 0.000 description 6
- 238000011144 upstream manufacturing Methods 0.000 description 6
- 108010084313 CD58 Antigens Proteins 0.000 description 5
- 230000002776 aggregation Effects 0.000 description 5
- 238000004220 aggregation Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 5
- 239000003999 initiator Substances 0.000 description 5
- 230000000977 initiatory effect Effects 0.000 description 5
- 108010045283 Cystathionine gamma-lyase Proteins 0.000 description 4
- 238000013459 approach Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 238000012384 transportation and delivery Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 101710204136 Acyl carrier protein 1 Proteins 0.000 description 2
- 238000012935 Averaging Methods 0.000 description 2
- 101710113788 Candidapepsin-1 Proteins 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 238000003912 environmental pollution Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 229910001416 lithium ion Inorganic materials 0.000 description 2
- 238000010801 machine learning Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- UPBAOYRENQEPJO-UHFFFAOYSA-N n-[5-[[5-[(3-amino-3-iminopropyl)carbamoyl]-1-methylpyrrol-3-yl]carbamoyl]-1-methylpyrrol-3-yl]-4-formamido-1-methylpyrrole-2-carboxamide Chemical compound CN1C=C(NC=O)C=C1C(=O)NC1=CN(C)C(C(=O)NC2=CN(C)C(C(=O)NCCC(N)=N)=C2)=C1 UPBAOYRENQEPJO-UHFFFAOYSA-N 0.000 description 2
- QELJHCBNGDEXLD-UHFFFAOYSA-N nickel zinc Chemical compound [Ni].[Zn] QELJHCBNGDEXLD-UHFFFAOYSA-N 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- HBBGRARXTFLTSG-UHFFFAOYSA-N Lithium ion Chemical compound [Li+] HBBGRARXTFLTSG-UHFFFAOYSA-N 0.000 description 1
- 241000700159 Rattus Species 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 238000010420 art technique Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- OJIJEKBXJYRIBZ-UHFFFAOYSA-N cadmium nickel Chemical compound [Ni].[Cd] OJIJEKBXJYRIBZ-UHFFFAOYSA-N 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 108091000099 cysteine desulfurase Proteins 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000002360 explosive Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 238000005286 illumination Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 239000002346 layers by function Substances 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229910052987 metal hydride Inorganic materials 0.000 description 1
- 229910052759 nickel Inorganic materials 0.000 description 1
- PXHVJJICTQNCMI-UHFFFAOYSA-N nickel Substances [Ni] PXHVJJICTQNCMI-UHFFFAOYSA-N 0.000 description 1
- -1 nickel metal hydride Chemical class 0.000 description 1
- 239000007858 starting material Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/02—Capturing of monitoring data
- H04L43/022—Capturing of monitoring data by sampling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/04—Processing captured monitoring data, e.g. for logfile generation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling 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/62—Establishing a time schedule for servicing the requests
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
- Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Automation & Control Theory (AREA)
- Data Mining & Analysis (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
一种数据样本收集服务(DSCS)，可以被配置为从用户接收各种数据样本收集请求，并代表用户处理一个或多个请求。为了正确地描述用户需要哪种即用型的数据样本(RDS)，DSCS可以采用数据样本模板(DST)。通过使用DST，用户可以清楚地描绘其想要的数据样本的样子，以及有关数据样本的各种质量要求。DSCS可以进一步向用户提供DST管理功能。通常，DST管理涉及DST创建、DST更新、DST删除和DST激活/去激活的过程。例如，用户可以基于其数据样本收集需求来创建DST。之后，还可以基于用户需求的动态改变来更新和/或删除创建的DST。
Description
背景技术
近年来，我们世界中的数据量在各个领域中呈***式增长。例如，网络搜索引擎可以处理数百拍字节(Petabyte，PB)的搜索数据，而社交网络应用可以每月生成超过10PB的日志数据。由于***性的全球数据，造就了“大数据”一词来描述庞大的数据集。与传统数据集相比，大数据通常包括海量的非结构化数据，需要对其进行分析以便从此数据中获得深入的见解，例如如何从客户的购物历史记录中发现潜在的购买。
发明内容
公开了用于实现数据样本收集服务(DSCS)的方法和***。DSCS可以被配置为从用户接收各种数据样本收集请求，并代表用户处理一个或多个请求。为了正确地描述用户需要哪种即用型(ready-to-use)的数据样本(RDS)，DSCS可以采用数据样本模板(DST)。通过使用DST，用户可以清楚地描绘其需要的数据样本的样子，以及有关数据样本的各种质量要求。
DSCS可以进一步向用户提供DST管理功能。通常，DST管理涉及DST创建、DST更新、DST删除和DST激活/去激活的过程。例如，用户可以基于其数据样本收集需求来创建DST。之后，还可以基于用户需求的动态改变来更新和/或删除创建的DST。对DST进行的改变也可以导致对相应DST的相应数据样本的改变。
还公开了用于基于雾的服务层(SL)的用于合作数据源(DS)识别和即用型数据样本(RDS)制作的方法和***。在合作式DS识别过程期间，对于对应于数据样本收集请求(DSCR)的RDS中的每个数据元素(DE)，需要在本地雾区域(LFA)中发现和/或评估数千个潜在DS以确定它们是否是服务于此DSCR的期望DS。LFA中可用作数据源发现者(DSD)的不同本地雾节点(LFN)可以具有不同的DS识别和发现能力。因此，提供了方法和***以允许一个或多个LFA中的多个LFN(作为DSD)合作地共同工作以识别给定DSCR的期望DS。
给定的LFN可以具有DS识别能力，但可以不具有数据收集能力(例如，从期望的/已识别的DS收集数据)或特定的数据处理能力(例如，处理用于制作RDS的原始数据)。因此，本文公开的DS识别处理不仅是指根据给定DSCR的要求为RDS中的每个DE识别期望的DS，而且还指找到可以用作原始数据收集者(RDC)的合适的LFN以收集来自那些已识别的DS的原始数据，以及找到可以用作原始数据处理者(RDP)的适当LFN以处理用于制作RDS的原始数据。本文公开的用于合作式DS识别的方法和***包括但不限于具有RDC发现、DS识别结果整合和RDC/RDP作业分配的DS识别。
在RDS的制作过程期间，从DS收集的原始数据可以非常大量，并且可能还需要合作地完成对大量原始数据的数据处理。对于给定的DSCR，其数据处理可以跨越多个RDP，因为不同的LFN可能具有制作此DSCR的RDS所要求的各种数据处理能力。本文公开的用于合作RDS制作的主要方案包括但不限于触发针对给定DSCR的RDS制作、针对给定DE的RDS制作以及针对给定DSCR的RDS组装。
提供本发明内容是为了以简化形式介绍一些概念，这些概念将在下面的详细描述中进一步描述。本发明内容既不旨在确认所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，要求保护的主题不限于解决在本公开的任何部分中指出的任何或所有缺点的限制。
附图说明
为了促进对本申请的更稳健的理解，现在参考附图，其中相同的元件用相同的附图标记表示。这些附图不应被解释为限制本申请，而仅是示例性的。
图1示出了示例雾计算体系架构的框图；
图2示出了示例oneM2M体系架构的框图；
图3示出了示例oneM2M公共服务功能(CSF)的框图；
图4示出了示例智慧城市分析用例的流程图；
图5示出了使用数据样本模板(DST)的数据样本收集服务(DSCS)的示例高级体系架构的流程图；
图6示出了在LFA中利用反应式DS识别来创建DST的示例过程的流程图；
图7示出了在LFA中利用主动式DS识别来创建DST的示例过程的流程图；
图8示出了通过重用来创建DST的示例过程的流程图；
图9示出了使用R-DST拆分来创建DST的示例过程的流程图；
图10示出了用于RDS制作的第一示例配置；
图11示出了用于RDS制作的第二示例配置；
图12示出了用于DST更新的示例过程的流程图，该DST更新用于将一个或多个新数据元素(DE)添加到现有DST中；
图13示出了用于DST更新或删除一个或多个DST或删除整个DST的示例过程的流程图；
图14示出了DST状态的示例状态机模型的框图；
图15示出了用于oneM2M服务层的示例新DSCS CSF的框图；
图16示出了新oneM2M资源<dscs>的示例；
图17示出了示例用户界面；
图18示出了示例数据样本收集服务的体系架构图；
图19示出了用于向本地雾节点引领者注册本地雾节点能力的示例方法的流程图；
图20示出了利用原始数据收集者发现来进行数据样本识别的示例方法的流程图；
图21示出了用于数据源识别结果整合的示例方法的流程图；
图22示出了用于在本地雾区域中发起即用型数据样本制作过程的示例方法的流程图；
图23示出了用于为给定数据元素制作即用型数据样本的示例方法的流程图；
图24示出了用于为给定的数据样本收集请求制作即用型数据样本的示例方法的流程图；
图25示出了示例用户界面；
图26A示出了在其中能实现一个或多个所公开的实施例的示例机器对机器(M2M)或物联网(IoT)通信***的示例***图；
图26B示出了可以在图26A所示的M2M/IoT通信***内使用的示例体系架构的示例***图；
图26C示出了可以在图26A所示的通信***内使用的示例M2M/IoT终端或网关装置的示例***图；和
图26D示出了可以体现图26A的通信***的各个方面的示例计算***的示例框图。
具体实施方式
与传统数据集相比，大数据通常包括海量的非结构化数据，需要对其进行分析以便从该数据中获得深入的见解，例如如何从客户的购物历史记录中发现潜在的购买。通常，大数据有一种流行的定义，涉及如下几个“V”：
量(Volume)：随着大量数据的产生和收集，数据规模变得越来越大(例如，互联网公司每天产生的数据可以很容易地达到每天数十PB)。
种类(Variety)：指示各种类型的数据，包括半结构化和非结构化数据，例如音频、视频、网页和文本，以及传统的定义完善的结构化数据，例如数据库表。
速度(Velocity)：必须及时处理大数据的时效性(例如，数据收集和分析)，以使大数据的商业价值最大化。
价值(Value)：数据中隐藏着有用的知识和见解，但这些知识和见解的密度可能非常低。
值得注意的是，机器对机器(M2M)和物联网(IoT)通信的出现，通常指的是例如嵌入在物理世界中并通过网络与计算资源连接的传感器和装置，是推动大数据增长的主要趋势。例如，预计全球部署的已连接IoT节点数量将以每年超过30％的速度增长。预计那些庞大的IoT节点会产生大量数据，这要求经济高效的IoT数据处理方案。
边缘计算允许对IoT装置制作的数据的处理处更靠近创建位置，而不是通过长途将其发送到数据中心或云。
在多种情况下，边缘计算部署可以是理想的。一个示例场景是当IoT装置的连接性较差并且将IoT装置持续连接到中央云时效率不高。其他场景可以与对延迟敏感的信息处理有关。边缘计算可减少延迟，因为数据不必跨越网络到数据中心或云以进行处理。
雾计算是指边缘装置与云之间的网络连接。另一方面，边缘计算更具体地是指靠近边缘装置进行的计算处理。因此，雾计算可以包括边缘计算，但是雾计算也可以包含将处理后的数据送达其最终目的地所需的网络。形式上，雾计算(或简称为雾)是一种***级体系架构，其可使得从云到物的整个连续统一体中的资源和服务(例如计算、存储、控制和联网)更靠近最终用户。示例的启用雾的连续统一体在图1中示出。
通常，“数据分析”是一个广义术语。因此，市场上有许多类型的数据分析产品(例如谷歌分析(Google Analytics)，IBM沃森(IBM Watson)，用于分布式数据处理的开源Apache Hadoop生态***等)。
微软Azure IoT Edge是将云分析和定制业务逻辑移动到边缘处的装置的示例产品。通常，Azure IoT Edge由三个组件组成：
IoT Edge模块：运行Azure服务、第三方服务或开发人员自己的代码的容器。该模块可以被部署到IoT Edge装置，并在这些装置上本地执行。IoT Edge模块是执行单元，当前实现为Docker兼容容器，其在边缘处运行用户的业务逻辑。可以将多个模块配置为彼此通信，从而创建数据处理流水线(pipeline)；
IoT Edge运行时(runtime)：在每个IoT Edge装置上运行，并管理部署到每个装置的模块；和
基于云的界面：使用户能够远程监视和管理IoT Edge装置。
AWS Greengrass是使用户能够为已连接的装置运行本地计算、消息传递和数据缓存功能的软件。使用AWS Greengrass，已连接的装置可以运行AWS Lambda函数(事件处理服务)，使装置数据保持同步，并且即使未连接到因特网也可以安全地与其他装置通信。
AWS Greengrass允许用户构建IoT方案，以将不同类型的装置与云连接、以及将不同类型的装置相互连接。运行AWS Greengrass核心的装置用作枢纽(hub)，其可以与运行亚马逊FreeRTOS或安装了AWS IoT装置SDK的其他装置通信。
可以将AWS Greengrass核心装置、AWS IoT装置启用SDK的装置和亚马逊FreeRTOS装置配置为在边缘处的Greengrass组中相互通信。如果Greengrass核心装置失去与云的连接性，则Greengrass组中的装置可以继续通过本地网络相互通信。Greengrass组可以代表例如建筑的一层、一辆卡车或整个采矿场所。
正在发展的oneM2M标准定义了称为“公共服务实体(CSE)”的服务层(参见oneM2M-TS-0001oneM2M功能体系架构-V3.8.0)。该服务层的目的是提供可被不同的“垂直”M2M***和应用利用的“水平”服务。如图2所示，CSE支持四个参考点。Mca参考点与应用实体(AE)接口。Mcc参考点与同一服务提供者域中的另一个CSE接口，而Mcc'参考点与不同服务提供者域中的另一个CSE接口。Mcn参考点与底层网络服务实体(NSE)接口。NSE向CSE提供底层网络服务，例如装置管理、位置服务和装置触发。
CSE包含称为“公共服务功能(CSF)”的多个逻辑功能，例如“发现”和“数据管理和贮存库”。图3示出了由oneM2M定义的一些CSF。
oneM2M体系架构启用以下示例类型的节点：
应用服务节点(ASN)：ASN是包含一个CSE并包含至少一个应用实体(AE)的节点。物理映射的示例：ASN可以驻留在M2M装置中。
应用专用节点(ADN)：ADN是包含至少一个AE且不包含CSE的节点。oneM2M***的场域中可以有零个或多个ADN。物理映射的示例：应用专用节点可以驻留在受约束的M2M装置中。
中间节点(MN)：MN是包含一个CSE并且包含零个或多个AE的节点。oneM2M***的场域中可以有零个或多个MN。物理映射的示例：MN可以驻留在M2M网关中。
基础设施节点(IN)：IN是包含一个CSE并且包含零个或多个AE的节点。每个oneM2M服务提供者的基础设施域中仅存在一个IN。IN中的CSE可以包含不适用于其他节点类型的CSE功能。物理映射的示例：IN可以驻留在M2M服务基础设施中。
非oneM2M节点(NoDN)：非oneM2M节点是不包含oneM2M实体(既不包含AE也不包含CSE)的节点。此类节点代表出于互通目的(包括管理)而附接到oneM2M***的装置。
图4示出了示例智慧城市分析用例。为了建设智慧城市，市政府采用了基于标准的服务层(SL)平台(例如oneM2M)，并在城市公共基础设施上(如在道路和街道上、公共建筑内、公共汽车和地铁上等)部署了许多IoT传感器和装置。同时，由于预算有限，市政府还呼吁私人组织和个人参与这项智慧城市倡议。因此，那些安装在私有财产(例如私家车，手机等)上的IoT装置也被整合到***中，从而该***可以生成大量反映城市实时运行状况的综合IoT数据。
城市可以具有许多地理区域，例如中央商务区(CBD)、郊区住宅区等，其可以被称为本地雾区域(LFA)。可以在那些LFA中部署大量的IoT装置，并且可从这些LFA中生成大量的IoT数据。从通信网络的角度来看，不同的城市区域构成了多个LFA(例如，CBD对应于LFA-1，郊区住宅区对应于LFA-2，如图4所示)。
在云中部署了智慧城市控制台，其允许用户根据自己的需求提出各种数据分析请求。例如，来自组织A的用户可以有一个请求(表示为请求-1)，该请求旨在评估给定区域(例如，如图4所示的LFA-X，其为大规模修路和建筑施工的区域)的当前天气和环境污染状况。实际中，数据分析结果通常通过各种图表(例如线形图或条形图)表示。除了用户打算查看哪种类型的分析图外，用户还可以指定作为用于绘制图表的输入的数据样本应该是什么。为了准备这些数据样本以绘制图表，需要从LFA中的各种IoT装置(例如温度传感器、湿度传感器、污染传感器，噪声传感器等)收集相关的原始数据。特别是，这些传感器或装置可以由除组织A(用户所属的组织)以外的其他组织安装。在处理不同组织之间的互操作时，通过考虑各种约束(例如，不同组织之间的互操作的复杂性)和大量IoT数据的潜在通信和处理成本而以有效的方式做到这一点是个重大挑战。
在示例中，假设在请求-1中，用户打算查看LFA-X的线形图，该线形图要求每3分钟一个数据样本。特别地，每个数据样本可以由以下两个数据元素构成，并且每个数据元素都可以与质量要求相关联：
数据元素(DE)-1：最近3分钟内LFA-X的平均温度。
DE-1的质量要求：需要从LFA-X中部署的至少100个不同的温度传感器收集温度读数以确保准确性。
DE-2：最近3分钟内LFA-X的平均噪声水平。
DE-2的质量要求：需要从部署在LFA-X中的30个主要交通路口的噪声传感器收集噪声读数。
为了在部署在云中的智慧城市控制台上绘制线形图，每3分钟需要一个格式为(DE-1，DE-2，时间戳)的数据样本。
可以结合以上用例来确定以下技术挑战：
问题1：用于实现智慧城市分析用例的直接方案是从LFA收集所有所需的IoT数据，并在云中进行集中式数据处理。例如，考虑早期示例中的DE-1，将每3分钟从LFA收集100个温度读数，然后将其传输到云中进行数据处理(例如，计算这100个读数的平均值)。可以看出，由于从LFA到云的大量数据移动，集中式数据处理导致相当大的通信开销。
问题2：用户可以不了解LFA中可用的IoT数据源。例如，在智慧城市用例中，已部署的SL平台还整合来自不同组织和个人的许多IoT装置。因此，来自云端的用户可以不是部署那些IoT装置的同一方。结果，用户必须自己探索LFA以便识别可用作其期待数据样本的数据源的期待IoT装置。这样的要求给用户带来了额外的负担，尤其是在他们不具备在LFA中进行适当发现的能力时。
问题3：由于用户可以没有“边缘到云”的配置能力，因此现有的IoT Edge产品可能没有用。例如，大多数现有产品(例如微软的Azure IoT Edge或亚马逊的Greengrass)都配置为支持相对简单的情况，其中用户通常具有对在LFA中的装置/节点(例如，边缘处的传感器、网关等)的知识和配置能力。换句话说，当用户想要构建供自己使用的边缘分析应用时，他们可以知道应该连接什么边缘装置，并且还可以具有配置那些节点(例如网关)的能力以便运行用于直接在边缘侧进行数据处理的分析处理代码/单元。但是，在用户不是LFA中许多IoT装置的所有者或者没有任何能力配置LFA中可能由其他不同方或组织拥有的任何节点的情况下，情况并非如此。结果，现有的IoT边缘产品无法在这种异构场景中工作。
总体而言，从服务层的角度来看，基于SL的平台通常被认为是一个水平平台，其可跨不同域发起应用。换句话说，这种水平平台应该擅长整合来自不同方和/或组织的资源，这是异构应用场景的期待特征。为此，基于SL的平台(例如oneM2M)通常提供多种类型的公共服务，这可以使用户执行不同类型的操作(例如发现、装置管理等)，而无需允许或要求用户参与到细节中。但是，现有的基于SL的平台方案当前不提供公共服务或能力来通过利用雾计算范式支持有效的数据样本收集和处理。
本文公开了用于基于雾的服务层(SL)的数据样本收集服务(DSCS)。DSCS是SL处的基于雾计算范式的服务。借助DSCS，DSCS的用户可以指定他们打算接收哪种类型的RDS的需求，并且DSCS可以被配置为处理LFA中的所有内容并生成期望的RDS。
还公开了一种数据样本模板(DST)。DST描述了有关用户打算接收哪种类型的RDS的所有细节，这将成为DSCS在LFA中进行IoT原始数据收集和原始数据处理的指南。
还公开了用于“DST管理”的方法和***，其可以涉及以下一个或多个方面：
本文公开了用于“DST创建处理”的许多示例方案，其可以在不同的应用场景中使用，包括但不限于：
场景1：在LFA中利用反应式(Reactive)DS识别的DST创建；
场景2：在LFA中利用主动式(Proactive)DS识别的DST创建；
场景3：通过DE重用(re-use)的DST创建；和
场景4：利用DST拆分的DST创建。
公开了用于“DST更新/删除处理”的多种方案，包括但不限于：
用于向现有DST添加新的DE或简单地更新现有DST中的某些信息的DST更新过程；和
用于删除现有DST上的一个或多个DE或删除整个DST的DST更新过程。
公开了用于“DST激活处理”的多种方案，包括但不限于：
可以基于DST中的“RDS_Production_Schedule”参数中指示的参数来激活给定的DST；
可以基于来自用户本身的信号来激活给定的DST；和
可以基于LFA中发生的事件来激活给定的DST。
以下描述了贯穿本公开使用的一些术语的示例定义：
云节点(CN)：具有云能力的节点，该节点管理在部署层次结构中较低的其他雾节点的操作。注意，术语“云”可以用于指代云节点。此外，云监视和管理不同雾节点之间的交互，这些雾节点共同为应用启用雾服务层。
本地雾区域(LFA)：可以根据不同的应用场景将地理区域(例如，城市)划分为多个LFA。例如，在智慧城市场景中，特定的住宅区可以是LFA，或者市中心的CBD可以是LFA。
本地雾节点(LFN)：LFN可以是LFA中具有计算、存储和通信能力的节点。LFN可以与在其对应的LFA中的LFNL通信并进行交互。例如，LFN可以是人的手机、移动中的公共汽车、房屋的家庭网关等。LFN是网络的最低层处的一种FN。LFN可以与LFA中的其他LFN进行交互和合作，并且可以执行从DS中发现、获取和处理数据。
数据源(DS)：如果节点是IoT数据源，则该节点可以是DS。例如，DS可以是传感器、摄像头、交通信号灯或制造数据的任何IoT装置。路侧单元也可以是DS，因为它会生成与路面有关的感测数据。同时，路侧单元也可以是LFN，因为它可以进行某些数据处理和/或与LFNL通信。LFA中不仅具有感测而且还具有计算、存储和通信能力的节点可以是LFN以及DS。
LFN引领者(leader)(LFNL)：给定的LFA在雾区域可具有LFN引领者。LFNL管理该LFA中的所有LFN，并且还连接到更高级别的FN。例如，在智慧城市示例中，LFNL可以是特定住宅区的主网关。
雾节点(FN)：具有任何雾资源(例如计算、存储、通信、分析等)的节点。雾节点可以具有这些资源中的至少一个，并且还可以具有正在雾节点上运行的其他软件或服务。假设FN的部署级别比LFN高一个级别。FN部署可具有多个级别，而CN处于最高级别。例如，在智慧城市用例中，FN可以是网络中更高级别的路由器。
值得注意的是，尽管使用雾相关术语描述了本公开中提出的想法，但是本公开中提出的想法也可以应用于边缘场景。例如，LFA也可以解释为在边缘处的特定区域，LFN可以是边缘侧的节点，LFNL可以是边缘处的网关或边缘处的路侧单元，等等。
本文公开的是用于服务层的新的公共服务，其可以被称为数据样本收集服务(DSCS)。DSCS的高级体系架构如图5所示。公开的DSCS可具有以下一项或多项能力：
DSCS可以接收来自用户的各种数据样本收集请求，并代表其用户处理所有细节；
为了适当地描述用户需要哪种即用型的数据样本(RDS)(例如，用于在控制台上绘制线形图)，DSCS采用了一种称为数据样本模板(DST)的新概念。通过使用DST，用户可以清楚地描绘其所期望数据样本的样子，以及有关数据样本的各种质量要求；
DSCS可以向用户提供DST管理功能。通常，DST管理涉及DST创建、DST更新、DST删除和DST激活/去激活的过程。例如，用户可以根据其数据样本收集需求来创建DST。之后，还可以基于对需求的动态改变来更新和/或删除创建的DST。在DST上进行的改变也可导致对该DST的相应数据样本的改变；和
DSCS可以向用户提供用于激活或去激活所创建的DST的接口。请注意，在一个示例中，直到该DST处于激活状态，才可以开始DST的实际RDS制作。
示例方法可以包括将数据样本收集服务的第一代理配置为执行以下操作：接收创建数据样本模板的请求，所述创建数据样本模板的请求包括与一个或多个数据元素相关联的信息；根据与一个或多个数据元素相关联的信息，创建数据样本模板；向数据样本收集服务的第二代理发送请求以识别与一个或多个数据元素相关联的一个或多个数据源，其中，数据样本收集服务的第二代理位于本地雾节点上；从数据样本收集服务的第二代理接收与一个或多个数据源相关联的信息；并基于与一个或多个数据源相关联的信息配置该数据样本模板。
创建数据样本模板的请求可以包括对要创建的数据样本的类型的指示。创建数据样本模板的请求可以进一步包括对一个或多个参数的指示，该一个或多个参数包括：与数据样本相关联的目标区域；与数据样本相关联的频率；与数据样本相关联的制作计划表；以及与数据样本相关联的上下文。该方法可以进一步包括基于一个或多个参数确定将多个本地雾节点中的哪个作为目标。与一个或多个数据元素相关联的信息可包括以下一项或多项：数据元素的原始数据类型；数据元素的单位；数据元素的数据处理操作；数据元素的一个或多个定制处理细节；以及数据元素的一项或多项质量要求。该方法可以进一步包括将配置的数据样本模板发送到数据样本收集服务的第二代理。数据样本收集服务的第二代理可以被配置为基于所配置的数据样本模板来生成即用型的数据样本。
示例方法可以包括将数据样本收集服务的第一代理配置为执行以下操作：基于第一数据样本模板，生成第二数据样本模板和第三数据样本模板，其中第二数据样本模板与第一数据元素集相关联，第三数据样本模板与第二数据元素集相关联；向数据样本收集服务的第二代理发送请求以识别与第一数据元素集相关联的第一数据源集，其中数据样本收集服务的第二代理位于第一本地雾节点；向数据样本收集服务的第三代理发送请求，以识别与第二数据元素集相关联的第二数据源集，其中，数据样本收集服务的第三代理位于第二本地雾节点；从数据样本收集服务的第二代理接收与第一数据源集相关联的信息；从数据样本收集服务的第三代理接收与第二数据源集相关联的信息；基于与第一数据源集相关联的信息和与第二数据源集相关联的信息中的一个或多个，配置第二数据样本模板和第三数据样本模板中的至少一个。
该方法可以进一步包括接收创建数据样本模板的请求，该创建数据样本模板的请求包括与一个或多个数据元素相关联的信息；基于与一个或多个接收的数据元素相关联的信息，创建第二数据样本模板和第三数据样本模板。与一个或多个接收的数据元素相关联的信息可以包括与第一数据元素集相关联的信息和与第二数据元素集相关联的信息。该方法可以进一步包括基于与一个或多个接收的数据元素相关联的信息，确定将多个本地雾节点中的一个或多个作为目标。第二数据样本模板和第三数据样本模板中的每一个可以包括以下参数中的一个或多个：与相应的数据样本集相关联的目标区域；与相应的数据样本集相关联的频率；与相应的数据样本集相关联的制作计划表；以及与相应的数据样本集相关联的上下文。该方法可以进一步包括：将配置的第二数据样本模板发送到数据样本收集服务的第二代理；以及将配置的第三数据样本模板发送给数据样本收集服务的第三代理。数据样本收集服务的第二代理可以被配置为基于配置的第二数据样本模板来生成第一即用型数据样本。数据样本收集服务的第三代理可以被配置为基于配置的第三数据样本模板来生成第二即用型数据样本。
示例方法可以包括将数据样本收集服务的第一代理配置为执行以下操作：接收向现有数据样本模板添加新数据元素的请求，该现有数据样本模板与包括多个数据元素的即用型数据样本相关联；基于新数据元素，更新现有样本模板；向数据样本收集服务的第二代理发送请求以识别与新数据元素相关联的一个或多个数据源，其中，数据样本收集服务的第二代理位于本地雾节点上；从数据样本收集服务的第二代理接收与一个或多个数据源相关联的信息；根据与一个或多个数据源相关联的信息，配置更新后的数据样本模板。
添加新数据元素的请求可以包括现有数据样本模板的标识符和新数据元素的目标区域中的一个或多个。与新数据元素相关联的信息包括以下一项或多项：数据元素的原始数据类型；数据元素的单位；数据元素的数据处理操作；数据元素的一个或多个定制处理细节；以及数据元素的一项或多项质量要求。添加新数据元素的请求可以包括更新现有数据元素的请求。更新数据元素的请求可以包括以下一项或多项：现有数据样本模板的标识符和要更新的数据元素的一个或多个参数。该方法可以进一步包括在更新数据样本模板之前去激活该数据样本模板。
为了实现如上所述的DSCS的能力，描述了以下细节：
通常，如果服务层节点(例如在LFN、FN或CN上实现的节点)打算提供与数据样本收集相关的服务，则该服务层节点可以具有DSCS代理。SL节点上的DSCS代理是一款软件，该软件不仅可以与DSCS用户交互，而且可以与其他DSCS代理合作以执行用户提出的各种数据样本收集任务。
关于DSCS代理和DSCS用户之间的交互，DSCS代理可以向DSCS用户提供接口，以便支持在DST创建、DST更新和DST删除方面的DST管理。例如，如图5所示，在CN中部署了DSCS代理(例如DSCS代理-1)，该DSCS代理可以接受来自CN中不同用户的分析请求。
DSCS代理之间也可存在交互和合作。例如，可能还需要在LFA的LFNL(其可以处理该LFA中的所有原始数据收集和处理)中部署DSCS代理。通常，CN中的DSCS代理-1可以根据用户需求创建DST，并确定该DST应该部署到哪个或哪些LFA。例如，如果用户仅想从特定的LFA收集数据样本，则DST可以被部署到该LFA中的DSCS代理(例如DSCS代理-2)。在部署期间，可以在DSCS代理-2上设置某些工作线程(例如，代码段)。特别地，DSCS代理-2可负责在此LFA中识别期望的DS、进行所要求的数据处理操作、制作RDS并仅将RDS发送回CN中的用户。总体上，那些DSCS代理可以一起工作以便服务于各种数据样本收集请求；和
作为SL中的一项公共服务，即使***整合了来自不同方或组织的资源(就装置、节点等而言)，DSCS仍可以实现雾计算范式。更重要的是，DSCS可以帮助用户收集LFA中的原始数据，并直接在LFA中部署的DSCS代理上分析/处理原始数据。换句话说，在整个处理中，用户可以不必参与有关如何在LFA中识别合格DS以及如何在这些LFA中配置LFN以进行原始数据处理的任何细节。结果，用户可只需要通过创建DST来指定他们对期望RDS的需求。所有其余的处理可以由所公开的DSCS来处理。
当DSCS用户需要从LFA收集数据样本时，他们可以在数据样本收集请求中描述他们的需求，该请求可以被发送到DSCS代理。因此，可以创建DST，其中包括有关如何为此DST进行RDS制作的所有细节。如下所示，表1给出了DST的详细定义。
表1、数据样本模板(DST)的定义
/>
/>
/>
/>
/>
/>
/>
/>
/>
在本公开的第一方面，公开了用于DST创建处理的方法和***。
对于要创建的给定DST，在LFA中可以有大量(例如，数千个)潜在DS需要被发现和评估以确定它们是否是该DST的期望DS(该处理过程可以称为DS识别处理)。同时，从那些DS收集的原始数据也会是大量的，并且对用于制作RDS的海量原始数据的数据处理可以被称为RDS制作处理。与DST管理(作为控制面问题)相比，DS识别和RDS制作更像是用于实际RDS生成的“数据面”问题。
在第一示例中，讨论了在LFA中利用反应式DS识别进行DST创建处理。在该示例中，直到存在需要识别LFA中的期望DS的DST创建请求，才会进行DS识别。这可以适用于以下情景：LFA中的DSCS代理仅具有有限的能量或处理功能，或者LFA中的DS的可用性经常变化(例如，如果DS装备在移动车辆上，则从它们可以在不同的时间间隔内在不同的LFA中可用的意义而言，这些DS可行进跨越不同的LFA)。
图6示出了在LFA中利用反应式DS识别进行DST创建处理的示例过程：
在该示例***中，在步骤1，CN上有DSCS代理。用户-1有数据样本收集需求，并打算使用SL提供的DSCS。因此，用户-1决定联系CN上的DSCS代理-1。
在步骤2，用户-1将DST创建请求以及有关希望接收哪种类型的数据样本的信息发送到DSCS代理-1。特别地，该消息可以包括以下参数中的一个或多个(在表1中有进一步解释)：
Targeted_Region；
Data_Sample_Frequency；
RDS_Production_Schedule；和
RDS_Context。
对于要包括在期望RDS中的每个DE，该请求可以具有以下参数，这些参数描述了该DE的细节：
Raw_Data_Type；
Unit；
Data_Processing_Operation；
Customized_Processing_Details；和
Quality_Requirements。
在步骤3，DSCS代理-1基于来自用户-1的信息，创建DST-1。DSCS代理-1还需要在DST-1中配置用户-1未提供的其他信息，包括“DST_Users”(例如用户-1)，“DST_Initiator”(例如用户-1)和“Creating_DSCS_Agent_ID”(例如DSCS代理-1)。但是，由于到目前为止，尚未为DST-1识别DS，因此可以在“DST_Status”参数中将DST-1的状态设置为“不可执行”。因此，DSCS代理-1决定此DST-1涉及哪些LFA。例如，基于“Targeted_Region”参数中包含的细节，DSCS代理-1可以从通信网络的角度确定用户-1感兴趣的地理区域对应于哪些LFA。在该示例中，仅涉及一个LFA(例如，LFA-1)。另外，由于不会拆分DST-1，因此可以将Type_of_DST设置为R-DST的值。接下来，DSCS代理-1需要联系LFA-1中的LFNL上的DSCS代理(例如DSCS代理-2)，以便触发DST-1的DS识别处理。
在步骤4，根据来自用户-1的有关每个期望DE的信息，DSCS代理-1向DSCS代理-2发送请求和其他详细信息以触发DST-1的DS识别，其他详细信息例如将对原始数据执行哪种类型的数据处理操作和相关的质量要求。换句话说，在这种情况下，DSCS代理-2是DST-1的“现场管理者”。请注意，对于不会被拆分的给定DST(如场景1中所考虑的)，其现场管理者可以是中央控制者，用于在相应的LFA中进行DS识别和RDS制作。特别是，如果DST是R-DST(在这种情况下为DST-1)，则其现场管理者可以是该DST中相应DE的原始数据被处理(使用DST-1中每个DE的Data_Processing_Operation参数所指示的数据处理操作)的位置，从而导致为整个DST-1生成RDS。
在步骤5，在从DSCS代理-1接收到请求之后，LFA-1中的DSCS代理-2进行DS识别，以查看是否可以为DST-1中的所有DE识别期望的DS(例如，DSCS代理-2可以协调/管理LFA-1中的其他LFN以进行DS识别)。
在步骤6，DSCS代理-2将DS识别结果返回给DSCS代理-1。在此示例中，假定已为DST-1中的所有DE识别了期望的DS。在DS识别失败的情况下(例如，未能为DST-1中的所有DE识别期望的DS)，DST创建处理可以终止，并且DSCS代理-1可以向用户-1确认(例如，在步骤11中)DST创建未成功。
在步骤7，DSCS代理-1可能还需要在DST-1中配置其他信息，包括“In_Field_Manager_ID”(例如，本例中为DSCS代理-2)。DSCS还在“DST_Status”参数中将DST-1标记为“可执行”DST。
在步骤8，一旦DST-1已被完全配置，DSCS代理-1就将DST-1发送到DSCS代理-2进行现场部署。
在步骤9，DSCS代理-2进行某些设置或配置，以便为即将到来的RDS制作操作发起DST-1的工作线程。例如，如果用户-1提供了用于处理特定DE的原始数据的代码段，则可以将此类代码段安装在DSCS代理-2或LFA-1中由LFNL管理的其他LFN上。
在步骤10，DSCS代理-2确认DST-1的现场部署已完成。
作为备选，在步骤5，如果已经在步骤6期间为DST-1中的所有DE识别了期望的DS，则DSCS代理-1还可以指示是否可以直接设置DST-1的工作线程(如步骤9所示)。在这种情况下，可以不需要步骤8和步骤10。
在步骤11，DSCS代理-1向用户-1确认成功创建了DST-1，并且现在DST-1也为可执行，以及告知用户-1某些信息(例如DST_ID)。
在第二示例中，讨论了在LFA中利用主动式DS识别进行DST创建处理。在此示例中，即使没有DST创建请求，LFA中的DSCS代理也可以主动进行DS识别。该方案可以适用于以下场景：LFA中的DSCS代理具有足够的能量和强大的处理能力，或者DS的可用性不经常改变，因此可以提前识别DS。
图7示出了在LFA中利用主动式DS识别进行DST创建处理的示例过程：
作为前提，DSCS代理-2可以周期性地将LFA-1的实时DS目录发送到DSCS代理-1。
步骤1可以与图6的步骤1相同。
步骤2可以与图6的步骤2相同。
在步骤3，DSCS代理-1基于来自用户-1的信息创建DST-1。DSCS代理-1可能还需要在DST-1中配置一些其他信息，而这些信息不是由用户-1提供的，包括“DST_Users”(例如用户-1)，“DST_Initiator”(例如用户-1)，“Creating_DSCS_Agent_ID”。DSCS代理-1还可以决定DST-1中涉及哪些LFA(例如，本示例中的LFA-1)，然后DSCS代理-1可以检查从所涉及LFA的LFNL(例如此示例中为DSCS代理-2)发送的最新DS目录。基于此目录，如果可以为DST-1中的所有DE识别期望的DS，则DST-1可以被标记为“可执行”DST。完全配置了DST-1之后，可以将其发送到DSCS代理-2(在此示例中为DST-1的现场管理者)以进行现场部署。
步骤4可以与图6的步骤8相同。
步骤5可以与图6的步骤9相同。
步骤6可以与图6的步骤10相同。
步骤7可以与图6的步骤11相同。
在第三示例中，讨论了通过DE重用来创建DST。在此示例中，当已经在DSCS代理上创建了不同的DST时，其可以在DST贮存库中托管或存储这些DST。因此，为了待创建的新DST(例如，DST-100)，其可以具有存储在贮存库中的一个或多个现有DST中已经包括了的重叠DE。结果，这些DE可以重用于创建DST-100，这可以节省为DST-100中那些可被重用的DE进行DS识别处理的大量精力。
图8图示了通过DE重用来进行DST创建处理的示例过程：
作为前提条件，DSCS代理-1维护DST贮存库，该贮存库存储了已创建的所有现有DST。
步骤1可以与图6的步骤1相同。
步骤2可以与图6的步骤2相同。备选地，DSCS代理-1可以直接向DSCS用户提供访问界面，以供他们检查和查询存储在贮存库中的现有DST。在这种情况下，用户-1可以首先查询贮存库，并找出现有DST中的哪些DE可以重用。然后，在此步骤中，当描述用户-1想要接收什么样的期望RDS时，可以直接指示应重用现有DST中的哪些DE。
在步骤3，DSCS代理-1根据来自用户-1的信息创建DST-100。如果用户-1在步骤2中未指示应重用哪些DE，则DSCS代理-1进一步搜索贮存库，并筛选出可以将现有DST中的哪些DE用于DST-100中所需的DE。特别地，由于每个DE在DST中定义时都有许多特性和质量要求，因此在评估现有DST中的一个DE是否可以在另一个新创建的DST中进一步使用时，可以有必要评估该信息。例如，假设为用户-1创建的DST-100具有三个DE(例如，DST-1的RDS具有以下格式：(DE-1，DE-2，DE-3，RDS_Context))，则可以在DST贮存库中将现有DST-1中的DE-6重用为DST-100中的DE-2，而DST-3中的DE-27可以用作DST-100中的DE-3，因为它们的所有特性和质量要求都可以匹配。现有DST中这些重用DE的所有详细描述都可以克隆到DST-100。此外，可以为DST-100中的每个DE配置相应的参数。例如，DST-100的DE-2和DE-3的“Reused”参数可以设置为“真”，DST-100中的DE-2和DE-3的“Reused_Info”参数可以分别设置为“DST-1的DE-6”和“DST-3的DE-27”。
在步骤4，DSCS代理-1可以进一步仅对不能再使用现有DST中的可用DE的那些DE(例如DST-100中的DE-1)进行DS识别处理。该步骤包括图6的步骤4-6。同时，对于DST-100中的DE-1，应将“Reused”参数设置为“假”。注意，在图8所示的该示例中，仅涉及一个LFA，但是通常，通过使用以下描述的方案，DS识别处理也可以涉及多个LFA。
步骤5可以与图6的步骤7相同。
步骤6可以与图6的步骤8-10相同。特别是，可以利用他者创建的现有工作线程(这些工作线程负责为DST-100中那些重用的DE生成RDS数据)来构建DST-100的工作线程。
步骤7可以与图6的步骤11相同。
在第四示例中，讨论了通过R-DST创建DST。在前面的三个示例中，假定DST-1的原始数据来自单个LFA-1。在此示例中，考虑了高级的场景，其中DST-1的原始数据可以来自多个LFA。在这种情况下，DST-1可以是R-DST，可以将其拆分为多个S-DST。特别地，在创建DST-1之后(例如，在图6-8的步骤3中)，DSCS代理-1可以确认涉及哪些LFA，并且可以为每个涉及的LFA进一步创建S-DST。在每个S-DST中，仅当要从这些S-DST的相应LFA收集DE的原始数据时，才包括这些DE。
图9图示了利用R-DST拆分进行DST创建处理的示例过程：
在步骤1，DSCS代理-1从用户-1接收DST创建请求，并且创建了DST-1。该步骤对应于图6-8的步骤3。接下来，DSCS代理-1还决定该DST-1涉及哪些LFA(例如，在本示例中为LFA-1和LFA-2)。
在步骤2中，通过创建两个S-DST(例如，用于LFA-1的S-DST-1和用于LFA-2的S-DST-2)来进一步拆分DST-1。DSCS代理-1配置DST-1、S-DST-1和S-DST-2中的相关参数。例如，S-DST-1和S-DST-2的参数可以具有以下示例设置：
DST_Initiator：由于两个S-DST是基于其父R-DST(例如DST-1)创建的，其中发起者是用户-1，因此这两个S-DST的DST发起者也可以是用户-1。
DST_Users：出于相同的原因，在此示例中，这两个S-DST的DST用户也可以是用户-1。
Type_of_DST：S-DST
Targeted_Region：对于S-DST-1，其目标区域可以是LFA-1，而S-DST-2的目标区域可以是LFA-2。
Parent_DST_ID：S-DST-1和S-DST-2两者的父DST ID可以是DST-1。
Creating_DSCS_Agent_ID：在该示例中为DSCS代理-1。
Data_Sample_Frequency：与DST-1中的相应设置相同。
DST_Status：与DST-1中的相应设置相同。
RDS_Production_Schedule：与DST-1中的相应设置相同。
RDS_Production_Trigger：与DST-1中的相应设置相同。
RDS_Context：与DST-1中的相应设置相同。
在步骤3a和3b中，对于每个S-DST，可以在相应的LFA中进行DS识别处理(对于S-DST-1为步骤3a，对于S-DST-2为步骤3b)。对于该步骤，结合图6-8所公开的方法完全可以重复使用。例如，DSCS代理-1可以向LFA-1中的DSCS代理-2发送DS识别请求，或者DSCS代理-1可以重用存储在DST贮存库中的现有DST中的DE。一旦完成了DS识别处理，DSCS代理-1可以进一步配置DST-1、S-DST-1和S-DST-2中的相关参数(例如，将这些DST的状态标记为可执行)，并准备好将它们部署到现场。
以下步骤(例如，针对LFA-1的步骤4-6和针对LFA-2的步骤7-9)类似于先前图中的DST现场部署相关步骤(例如，图6的步骤8-10)加上一些其他配置。备选地，可以同时执行LFA-1的步骤4-6和LFA-2的步骤7-9，或者LFA-1的步骤4-6也可以在LFA-2的步骤7-9之后执行。
在步骤4，DSCS代理-1将S-DST-1发送到LFA-1中的DSCS代理-2以进行现场部署。
在步骤5，DSCS代理-2进行配置以设置S-DST-1的工作线程。基于步骤10中描述的细节，还完成了有关在何处处理数据的其他一些配置。
在步骤6，DSCS代理-2确认已设置S-DST-1的现场部署。
在步骤7，DSCS代理-1将S-DST-2发送到LFA-2中的DSCS代理-3以进行部署。
在步骤8，DSCS代理-3进行配置以设置S-DST-2的工作线程。基于步骤10中描述的细节，还执行了关于在何处处理数据的一些其他配置。
在步骤9，DSCS代理-3确认S-DST-2的现场部署已完成。
在步骤10，DSCS代理-1将DST-1发送到FN上的DSCS代理-4以进行部署。将DST-1拆分为多个S-DST时，可能需要决定在RDS制作期间应如何进行数据处理。
在一个示例中，DST-1可以是R-DST，其现场管理者可以是FN上的DSCS代理-4。特别是，由于DST-1已被拆分为两个S-DST并且可以对S-DST-1和S-DST-2进行DS识别，因此可不为DST-1发起DS识别处理。DSCS代理-4可仅参与某些数据处理操作，并且DST-1的最终RDS可以在DSCS代理-4上生成。
在另一个示例中，现场管理者可以分别是用于S-DST-1和S-DST-2的DSCS代理-2和DSCS代理-3。这些现场管理者可以分别负责相应LFA(例如LFA-1和LFA-2)中的S-DST-1和S-DST-2的DS识别处理。但是，对于S-DST中的特定DE，为DE-1进行RDS制作处理可以包括以下三种情况(例如Case_1，Case_2和Case_3)中的一种或多种：
在Case_1中，已经在S-DST中设置了DE的Data_Processing_Operation参数，并且该S-DST-1的现场管理者也可以在该DE的原始数据进行“完全处理”的位置。这意味着现场管理者可以生成仅包含此DE的不完整RDS。之后，此S-DST的现场管理者可以将这些不完整的RDS发送到其父R-DST的现场管理者，在后者处可以通过组装从不同LFA收集的那些不完整的RDS来生成R-DST的最终RDS。
图10示出了Case_1的示例实现。在此示例中，DST-1具有两个DE(例如DE-1和DE-2)。例如，DST-1的RDS具有(DE-1，DE-2，RDS_Context)的形式。特别是，DE-1和DE-2分别是最近3分钟内LFA-1和LFA-2的最高温度。因此，DST-1已经被拆分成两个S-DST(例如，S-DST-1和S-DST-2)。这两个S-DST已部署在LFA-1中的DSCS代理-2和LFA-2中的DSCS代理-3上。R-DST(例如DST-1本身)部署在更高级别FN的DSCS代理-4上。由于DE-1和DE-2可仅用于计算各个LFA中的最高温度，因此DSCS代理-2和DSCS代理-3分别可以完全处理从LFA-1和LFA-2收集的原始数据。换句话说，可以在DSCS代理-2或DSCS代理-3中直接计算各个LFA中的最高温度。然后，DSCS代理-2可将不完整的RDS(例如，DE-1部分的完全处理后的数据)发送给DSCS代理-4(与DSCS代理-3相同)。最后，基于RDS_context中的信息，DSCS代理-4可以通过组装来自DSCS代理-2的一条数据和来自DSCS代理-3的一条数据来制作DST-1的各单个RDS。
在Case_2中，已经在S-DST中设置了DE的Data_Processing_Operation参数，并且其现场管理者可以对原始数据进行一些数据处理。但是，原始数据只能被“部分处理”。此后，此S-DST的现场管理者可以将部分处理的数据发送到其父R-DST的现场管理者，从那里可以通过进一步处理从不同LFA收集到的部分处理的数据来制作最终的RDS。
图11示出了Case_2的示例实现。在此示例中，DST-1仅具有一个DE(例如DE-1)，而DST-1的RDS具有(DE-1)的形式。特别是DE-1是最近3分钟内整个市区(由LFA-1和LFA-2覆盖)的最高温度。在这种情况下，DST-1也已拆分为两个S-DST(例如S-DST-1和S-DST-2)。这两个S-DST已部署在LFA-1中的DSCS代理-2和LFA-2中的DSCS代理-3上。R-DST(例如DST-1本身)部署在更高级别FN的DSCS代理-4上。由于DE-1要计算覆盖LFA-1和LFA-2两者的整个区域的最高温度，因此DSCS代理-2和DSCS代理-3可以分别仅部分处理从LFA-1和LFA-2收集的原始数据。例如，DSCS代理-2可以处理从LFA-1收集的原始数据，可以只计算LFA-1的最高温度，这是部分处理的数据，因为这不是整个区域的最高温度(DSCS代理-3相同)。在DSCS代理-4中，需要基于收集的部分处理的数据进行进一步的数据处理。例如，给定在同一时间间隔期间从LFA-1和LFA-2收集的两个最高温度数据，这两个值中最大的一个可以是整个区域的最终最高温度，这可以是DE的完全处理数据-1。
在Case_3中，尚未在S-DST中设置DE的Data_Processing_Operation参数，并且其现场管理者可以简单地将此DE的所有原始数据转发到其父R-DST的现场管理者，其例如可以是更高级别雾节点上的DSCS代理。换句话说，所有原始数据都可以在R-DST的现场管理者中进行处理。
仍然对如图11所示的Case_2使用相同的示例。这次，DSCS代理-2和代理-3可能没有足够的数据处理能力。因此，可以不设置S-DST-1和S-DST-2中DE的Data_Processing_Operation参数。通过这样的配置，DSCS代理-2和代理-3可以不参与任何数据处理，而是可以将所有原始数据直接转发到DSCS代理-4。DSCS代理-4可以进行所有数据处理并为DST-1制作RDS。
通常，DSCS代理-4可以托管在雾层次结构中高于LFN的任何节点上。在一个示例中，DSCS代理-4甚至可以位于根CN节点上(在这种情况下，DSCS代理-4与DSCS代理-1相同)。总体而言，将DSCS代理-4尽可能多地部署到边缘的好处是可以进行本地/分布式数据处理，以节省潜在的处理和通信开销。
返回图9：
在步骤11，FN上的DSCS代理-4进行配置以设置DST-1的工作线程。
在步骤12，DSCS代理-4确认DST-1的现场部署已完成。此步骤之后，DSCS代理-1可以向DST-1的用户确认DST-1已成功创建并可执行。
注意，图9-11使用了一个示例场景，其中DSCS用户来自云侧，而IoT原始数据的收集和处理在LFA中完成。应该理解的是，可以使用附加或备选方案，其中用户可以直接与LFA交互，例如坐在移动车辆中的用户可以想查看一些实时的城市天气和污染分析/监测图表。在这种情况下，可以直接向路侧单元上托管的DSCS代理发送请求，以收集期望的RDS。用户可以将其RDS数据样本收集请求直接发送到FLA中的DSCS代理。
应当理解，无论采用哪种DST创建方法，DS识别(可以为DST识别期望的DS)都是重要的处理。仅当可以为该DST中的所有DE识别期望的DS时，DST才处于可执行状态。特别是，对于给定的可执行DST，考虑到现场DS可用性会发生动态变化，DSCS代理可能需要保持跟踪是否所有识别的DS仍然可用和/或满足所期望的质量要求。如果不是，则可执行的DST会变为不可执行的DST，并且会需要执行新的DS识别。
公开了用于DST更新和删除处理的许多方案。请注意，如果要更新/删除DST(及其相关的S-DST)，则此DST首先需要处于“可执行”状态，而不是“已激活”状态。换句话说，在对该DST进行任何DST更新/删除处理之前，需要先将已激活的DST去激活。
图12示出了用于DST更新处理以便向现有DST(例如，DST-1)添加一个或多个新的DE的示例过程。请注意，此示例还可以用于更新现有DST中的某些信息。
作为前提条件，DST-1已经由用户-1创建，并且DST-1的RDS具有两个DE(例如DE-1和DE-2)。DST-1已被拆分为两个S-DST(例如S-DST-1和S-DST-2)并分别被部署在LFA-1中的DSCS代理-2和LFA-2中的DSCS代理-3(在图12中未示出)中。特别地，S-DST-1负责制作与DE-1部分相关的RDS，而S-DST-2负责制作与DE-2部分相关的RDS。
在步骤1，由于新的需要，用户-1打算向现有DST-1添加一个或多个新DE。例如，除了现有的DE-1和DE-2，用户-1还希望将DE-3和DE-4添加到DST-1。换句话说，更新的DST-1的RDS可以具有(DE-1，DE-2，DE-3，DE-4，RDS_Context)的形式。
在步骤2，用户-1将DST更新请求与必要的信息一起发送给DSCS代理-1。特别地，该消息可以包括以下相关参数(例如表1中所示)：
DST_ID：该参数指示要更新哪个现有的DST；和
Targeted_Region：如果要添加的新DE导致目标区域的改变，则还需要更新此参数。例如，除了已经包含在DST-1中的该参数中的LFA-1和LFA-2之外，还可以涉及到新的LFA-3，因为要添加的新DE部分可以是从LFA-3收集的。
每个要添加的DE可以具有以下参数，这些参数定义了该DE的细节：
Raw_Data_Type；
Unit；
Data_Processing_Operation；
Customized_Processing_Details；和
Quality_Requirements。
代替添加新的DE，用户-1可以只想更新现有DST中的某些信息(例如，不添加新的DE)。在这种情况下，该消息可以包括以下相关参数：
DST_ID：该参数指示要更新哪个现有的DST；和
New_Parameter_Values：其包括要更新的参数及其新值。
在步骤3，DSCS代理-1首先检查DST-1(及其相关S-DST)是否处于“激活”状态。如果是这样，DSCS代理-1首先需要去激活DST-1(及其相关的S-DST)。然后，基于不同的应用场景，DSCS代理-1可以进一步进行适当的动作以添加这些新的DE。通常，可以有如下两种示例情况(Case_1和Case_2)：
在Case_1中，可以针对以下场景更新DST-1：
如上所述，在场景1下创建了DST-1，其中LFA中的DSCS代理仅在存在DST创建请求时才开始进行DS识别。在这种情况下，对于要添加的新DE，可以执行图6中所示的过程的用于DS识别的步骤3-6。
如上所述，在场景2下创建了DST-1，其中，即使没有DST创建请求，LFA中的DSCS代理也可以主动进行DS识别。在这种情况下，对要添加的新DE，可以执行图7所示的过程的用于DS识别的步骤3。
如上所述，在场景3下创建DST-1，其中存在DST贮存库，并且现有DST中的一个或多个DE可能被重用。在这种情况下，对要添加的新DE，可以执行图8所示的过程的用于DS识别的步骤3-5。
如上所述，在场景4下创建DST-1，其中DST可拆分为多个S-DST。在这种情况下，对于要添加的新DS，可以执行图9中所示的过程的用于DS识别的步骤3。注意，在图12中所示的步骤3之后的其余步骤主要基于此场景。作为示例，假设可以从LFA-2收集DE-3的原始数据。因此，可以通过合并新添加的DE-3来更新现有S-DST-2，并且还需要将更新后的S-DST-2部署到S-DST-2的现场管理者中。同时，由于可以从新的LFA-3收集DE-4的原始数据，因此可以创建新的S-DST-3。因此，可以将S-DST-3发送到LFA-3中的DSCS代理-5以进行现场部署。此外，DST-1本身也可能需要更新，因为当前DST-1已被分为三个S-DST并且更新后的DST-1也可能需要发送到DSCS代理-4进行现场部署。
在Case_2中，无法更新DST-1。值得注意的是，DST-1可以由于来自用户-1的DST更新请求而不更新。DST-1当前可以被多于一个用户使用(例如，不仅仅由用户-1使用)。因此，如果修改DST-1而未引起他人的注意，则用户-1以外的用户可能无法理解由更新的DST-1制作的RDS。在这种情况下，在执行Case_1中所示的任何动作之前，首先需要执行以下动作：
DSCS代理-1需要与如DST-1的DST_Users参数所指示的DST-1的所有用户进行检查，仅当所有用户都同意更新DST-1时才更新DST-1；和
如果不是DST-1的所有用户都同意更新DST-1，则此更新请求可能会被拒绝。或者，另一种高级方案是创建新的DST-2，它可以是DST-1的精确克隆，只是DST-2的DST_Users参数可以只包括用户-1(用户-1也可以从DST-1的用户列表中删除)。然后，新DE可以添加到DST-2。使用此新创建的DST-2，DSCS代理-1可以进一步将DST-2拆分为多个S-DST。因此，当部署DST-2的那些S-DST时，其相应的工作线程可以由相关LFA的现场管理者来设置。对于DST-2中的给定S-DST-X，根据特定的实现方式，DST-1中S-DST-X的工作线程可被完全重用，并且可以不需要新的工作线程(因为这两个S-DST完全相同)。然而，如果与DST-1中的S-DST-X相比，DST-2中的S-DST-X具有新DE，则可以基于DST-1中的S-DST-X的现有工作线程来建立新的工作线程。
代替添加新DE，用户-1可能只想更新现有DST中的某些信息(例如，不是添加一个或多个DE)。在这种情况下，上述方案也可以被重用。例如，如果用户-1打算更新DST-1的Data_Sample_Frequency参数或DST-1中的DE-1的Quality_Requirements，其还可以触发要执行的新DS识别处理以符合这些参数的新值。一旦那些参数得到更新，就可以重新部署更新的DST-1，以便DST-1的相应工作线程可以根据最新的/更新的DST-1开始工作。但是，如果由于DST-1当前由其他用户共享而无法进行这些参数的更新，则更新请求可被拒绝，或者可以创建包括上述那些参数的新值的新DST。
当添加与Case_1相关的一个或多个新DE时，步骤4-6说明了假设通过在步骤3中添加一个或多个DE来更新DST-1的步骤：
在步骤4，DSCS代理-1将更新的S-DST-2(包括一个或多个新添加的DE)部署到LFA-2中的DSCS代理-3。图9中的步骤7-9可以重用。
在步骤5，DSCS代理-1将新的S-DST-3部署到LFA-3中的DSCS代理-5。
在步骤6，DSCS代理-1将更新的DST-1(其中包括所有新添加的DE)部署到FN上的DSCS代理-4。类似地，图9中的步骤10-12可以重用。
对于Case_2，如果无法更新DST-1并在步骤3中创建了新的DST-2，则需要做的是将新创建的DST-2及其相关的S-DST部署到适当的LFA或FN。在这种情况下，DST更新处理将转换为DST创建处理。
在步骤7，DSCS代理-1确认DST-1已更新。或者，如果在步骤3中创建了新的DST-2，则DSCS代理-1可以通知用户-1已创建新的DST来服务于其新的需求。如果先前DST-1在步骤3之前处于“激活”状态，则DST-1可以被重新激活。
公开了一种DST更新处理，用于在现有DST处删除一个或多个DE或删除整个DST。注意，所公开的方案可以应用于DST创建处理中讨论的不同场景。
图13示出了用于DST删除处理以便在现有DST处删除一个或多个DE的示例过程(该过程也可以用于删除整个DST)，并且详细描述讨论如下：
作为前提，假设用户-1已创建DST-1，并且DST-1的RDS具有四个DE(例如DE-1，DE-2，DE-3和DE-4)。DST-1已被拆分为两个S-DST(S-DST-1和S-DST-2)并分别被部署在LFA-1中的DSCS代理-2和LFA-2中的DSCS代理-3上。特别是，S-DST-1负责为DE-1制作RDS，而S-DST-2负责为DE-2、DE-3和DE-4制作RDS(完整的RDS可以由FN上的DSCS代理-1组装)。在图13所示的示例中，DST-1和S-DST-2将是主要焦点。
在步骤1，由于新的需要，用户-1打算从现有DST-1删除一个或多个DE。例如，用户-1想要从DST-1删除DE-3和DE-4。
在步骤2，用户-1将DST删除请求与必要的信息一起发送给DSCS代理-1。特别地，该消息可以包括以下相关参数(例如表1中所示)：
DST_ID：此参数指示要更新哪个现有的DST；和
Deletion_List：其为要删除的DE的列表。如果要删除整个DST，则此参数可以被设置为“全部”。
在步骤3，DSCS代理-1首先检查DST-1(及其相关S-DST)是否处于“激活”状态。如果是这样，DSCS代理-1首先需要去激活DST-1(及其相关的S-DST)。根据不同的应用场景，DSCS代理-1可以进一步执行适当的动作以删除这些DE。通常，对于删除列表中的给定DE，可以具有以下三种情况(Case_1、Case_2和Case_3)：
对于Case_1，可以删除DST-1中的DE(例如DE-3)，并且需要在相应的LFA中采取相应的动作，这发生在以下可能的场景中：
1.用户-1是DST-1的唯一用户，同时DE-3从未在任何其他DST中重用；或者
2.用户-1是DST-1的唯一用户，并且该DE-3是最初在另一个DST中创建的重用DE。在这种情况下，有必要通过删除DE-3来更新DST-1和S-DST-2，并将更新后的S-DST-2部署到LFA-2中的DSCS代理-3。
对于Case_2，不能删除DST-1中的DE(例如DE-4)，并创建新的DST。这发生在DST-1当前可以被多于一个用户(例如，不仅仅是用户-1)使用的场景下。因此，如果修改DST-1而其他人不知道，则用户-1以外的用户将无法理解由更新的DST-1制作的RDS。在这种情况下，在执行如上所述的任何动作之前，首先需要执行以下动作：
DSCS代理-1需要与如DST-1的DST_Users参数所指示的DST-1的所有用户进行检查，仅当所有用户都同意更新DST-1时才能更新DST-1以删除这些DE。
如果不是DST-1的所有用户都同意从DST-1删除DE，则删除请求可以被拒绝。或者，另一种方案是创建新的DST-2，它可以是DST-1的精确克隆，除了DST-2的DST_Users参数可以仅包括用户-1(也可以从DST-1的用户列表中删除用户-1)。然后，可以从DST-2中删除相关的DE。使用此新创建的DST-2，DSCS代理-1可以进一步将DST-2拆分为多个S-DST并将它们发送以进行现场部署。
对于Case_3，不能删除DST-1中的DE，这发生在用户-1是DST-1的唯一用户但该DE已在其他DST中重用的场景下。在这种情况下，无需为此DE专门采取任何动作。
总体而言，DSCS代理-1可以检查要删除的每个DE。如果其中任何一个如上所述落入Case_2，则可以创建新的DST。否则，如果所有要删除的DE仅落入Case_1或Case_3，则可以通过对要删除的每个DE采取适当的动作来相应地修改原始S-DST-2。
对于用户-1想要删除整个DST-1(例如，删除所有DE)的情况，如果所有DE都落入Case_1，则可以真正删除整个DST(以及相应的工作线程)，否则可以遵循上述Case_2和Case_3中提到的方案。
步骤4-5说明了假设在步骤3中更新了DST-1(以及S-DST-2)的步骤。
在步骤4，DSCS代理-1将更新的S-DST-2发送到LFA-2中的DSCS代理-3以进行现场部署，并且还可以修改S-DST-2的现有工作线程，以便为S-DST-2制作的RDS数据可以不包括已删除的DE。
在步骤5，DSCS代理-1将更新的DST-1发送到FN上的DSCS代理-4以进行现场部署。
如果在步骤3中创建了新的DST-2，则需要将DST-2及其相关的S-DST部署到适当的LFA，并且可以重用DST创建处理的所有先前过程。换句话说，在这种情况下，DST删除处理在内部转换为DST创建处理。
在步骤6，DSCS代理-1确认DST-1中的一个或多个DE已被删除。或者，如果在步骤3中创建了新的DST-2，则DSCS代理-1可以通知用户-1根据其需要创建了新的DST。
值得注意的是，对于给定的DST-1，用户-1可能想添加一个或多个新DE，同时删除一个或多个现有DE。对于这种情况，图12和13中公开的过程可以整合在一起。例如，对于图12和图13的步骤2，用户-1可以直接表示不仅需要向DST-1添加一个或多个DE，而且还需要从DST-1删除一个或多个DE。在接收到这样的DST更新请求之后，DSCS代理-1可以组合要在图12和13中进行的动作来既添加DE又删除DE。以这种方式，用户-1可以只发出一个DST更新请求，而DSCS代理-1可以完成图12和13中介绍的所有所需动作。
对于创建的DST，在将其部署到其现场管理者之后，它仍可以不是激活的DST。特别是，直到激活该DST，才开始DST的RDS制作处理。图14示出了DST状态的状态机模型。例如，创建DST时，它可以处于“不可执行”状态。如果可以成功为此DST完成DS识别，则可以将其改变为“可执行”状态。类似地，对于可执行的DST，如果任何所期望的DS丢失或不再可用，则此DST可能会恢复为“不可执行”状态，并且需要进行进一步的DS识别。同时，通过DST激活操作，可执行的DST可以处于“激活”状态，这意味着真正的RDS制作开始了。
通常，有多种激活DST的方法，如下所列出的(并非详尽列表)：
(1)可以基于“RDS_Production_Schedule”参数中指示的参数来激活给定的DST。如图6所示的示例，一旦将DST-1部署到LFA-1中的DSCS代理-2，该代理就可以知道DST-1的RDS制作计划表，因此DSCS代理-2可以基于这个计划表激活DST-1的相应工作线程。同时，每次激活或去激活DST时，还需要更新Creating_DSCS_Agent(例如，如图6所示的CN中的DSCS代理-1)上托管的DST-1的DST_Status参数以反映其最新状态。
同时，如果给定的DST已被拆分，则也可以相应地执行上述处理。如图10所示的另一示例，DST-1已被拆分成两个S-DST(例如S-DST-1和S-DST-2)。因此，所有相应的工作线程(例如，FN上的DST-1、LFA-1中的LFNL上的S-DST-1和FLA-2中的LFNL上的S-DST-2的工作线程)也可以根据父R-DST(例如DST-1)中的“RDS_Production_Schedule”参数被激活或去激活。
在这种情况下，当用户创建DST时，可以在发送DST创建请求时直接提供其RDS发送地址(然后可以将其包括在“RDS_Sending_Address_List”参数中)。以后，如果另一个用户也想重用这整个DST，则该新用户可以通过将其ID添加到该DST的“DST_Users”中来向DSCS代理发送请求，并且还可以将自己的RDS发送地址添加到“RDS_Sending_Address_List”参数。
(2)可以基于来自用户的信号来激活给定的DST。如图6所示的示例，“RDS_Production_Schedule”参数可以未设置任何值。因此，用户-1可以向DSCS代理-1发送触发请求，DSCS代理-1可以将触发请求进一步转发到LFA-1中的DSCS代理-2以激活DST-1的工作线程。或者，DSCS代理-1本身可以根据RDS_Production_Trigger参数中指定的特定事件向DSCS代理-2发送触发请求。例如，一个触发可以是只要DST-1的任何用户登录到***中，DST-1就会被激活。可以以相反的方式完成去激活。
在由DST_Users参数中所示的多个用户共享DST的情况下，可以使用以下机制来激活或去激活DST：
对于当前未激活的给定DST-1(如表1中包括的“DST_Status”参数所指示的)，用户-1可以通过发送如上所述的触发来直接激活该DST-1。特别地，该用户可以将其RDS发送地址添加到如表1所示的“RDS_Sending_Address_List”参数中。
此后，如果DST-1的另一个用户-2也希望接收DST-1的RDS，则用户-2可以将其ID添加到该DST的“DST_Users”，并将其RDS发送地址添加到如表1所示的“RDS_Sending_Address_List”参数，因为DST-1已处于“激活”状态。
稍后，如果用户-1现在不希望接收DST-1的RDS，则可以通过查看“RDS_Sending_Address_List”参数来检查当前有多少用户正在接收DST-1的RDS。如果用户-1不是当前正在接收RDS的唯一一个用户，则用户-1可以从表1所示的“RDS_Sending_Address_List”参数中去除其RDS发送地址。如果用户-1再也不想接收DST-1的RDS，则用户-1可以进一步从“DST_Users”参数中去除其ID。
如果用户2暂时不希望接收DST-1的RDS，则可以通过查看“RDS_Sending_Address_List”参数来检查当前有多少用户正在接收DST-1的RDS。因为用户-2发现现在自己是唯一一个正在接收DST-1的RDS的用户，所以用户-2不仅可以从如表1所示的“RDS_Sending_Address_List”参数中去除其RDS发送地址，而且还可以实际上去激活此DST-1(换句话说，DST-1此时可以实际上被去激活)。如果用户2再也不想接收DST-1的RDS，则用户2可以进一步从“DST_Users”参数中去除其ID(特别是，如果去除用户2后“DST_Users”中没有了用户，则不仅可以去激活该DST-1，还可以删除该DST-1)。
(3)还可以基于LFA中发生的事件来激活给定的DST(如RDS_Production_Trigger参数中所指示的)。如图6所示的示例，在LFA-1中检测到交通阻塞时，如果要生成与LFA-1中的实时噪声水平监测相关的RDS，则DST-1可以由其现场管理者(例如，DSCS代理-2)激活。一旦激活了DST-1，DSCS代理-2可以通知CN中的DSCS代理-1，以便更新DST-1的DST_Status参数。
在这种情况下，当用户创建DST时，可以在发送DST创建请求时直接提供其RDS发送地址(然后可以将其包括在“RDS_Sending_Address_List”参数中)。此后，如果另一个用户也想重用这整个DST，则该新用户可以只通过将其ID添加到该DST的“DST_Users”中来向DSCS代理发送请求，并且还可以将自己的RDS发送地址添加到“RDS_Sending_Address_List”参数。
每次改变DST状态，其最新状态都可以反映在DST中的“DST_Status”参数中，并且现场管理者还需要执行特定动作(例如，根据DST的状态来挂起/恢复那些DST的相应工作线程)。
如下文所论述，可在oneM2M功能体系架构实施例中实施本文所揭示的方法和***。
如图15所示，所公开的DSCS方案可以被认为是one2M服务层中的新的CSF。应该理解，不同类型的M2M节点可以实现DSCS服务，例如IoT装置、M2M网关、M2M服务器、移动节点(例如车辆，手机等)等。特别地，取决于这些节点的各种/不同的硬件/软件容量，由那些节点实现的DSCS服务的容量也可以是变化的。
所定义的相关实体的oneM2M实施例如下：
数据源(DS)可以是oneM2M AE或CSE。因此，由AE或CSE生成的原始数据可以存储在<容器(container)>，<时间序列(timeSeries)>或<弹性容器(flexContainer)>资源中，这些资源可以在DS识别处理期间通过oneM2M资源发现来识别；
本地雾节点(LFN)可以是oneM2M CSE(例如ASN-CSE)；
LFN引领者(LFNL)和雾节点(FN)可以是oneM2M CSE(诸如MN-CSE)；
云节点(CN)可以是oneM2M CSE(例如IN-CSE)；和
DSCS用户可以是oneM2M AE(例如，IN-AE)。
在图16中揭示出了被称为<dscs>的新资源。<dscs>包括服务层资源的公共属性，其在图16中未示出。如果CSE具有DSCS能力(例如，正在此CSE上运行DSCS代理)，则其可以具有<dscs>子(child)资源。所有与DSCS相关的请求都可以发往此资源。例如，用户可以向CSE-1上托管的<dscs>资源发送DST创建请求。同样，当CSE-1打算部署创建的DST-1时，它也可以向边缘处的另一个CSE-2托管的<dscs>资源发送DST部署请求。
揭示DSCS的另一种方式或备选方式是使用为<CSE>资源定义的名为“dscs_capability”的新属性，该属性可以指示此CSE是否具有DSCS能力。因此，所有与DSCS相关的请求都可以发送到<CSEBase>资源。
公开了代表DST的新的<dst>资源，其中所有资源属性都与DST中定义的参数相对应(有关DST的详细定义，请参见表1)。
<dst>资源可以包含表2中指定的子资源。
表2、<dst>资源的子资源
上面的<dst>资源包含表3中指定的属性。
表3、<dst>资源的属性
/>
/>
/>
以下过程可以用于创建<dst>资源。
表4、<dst>创建
/>
以下过程可以用于取回<dst>资源的属性。
表5、<dst>取回
以下过程可以用于更新<dst>资源的属性。
表6、<dst>更新
以下过程可以用于删除<dst>资源。
表7、<dst>删除
/>
<dst触发(dstTriggering)>是虚拟资源，因为它没有表示形式。它是<dst>资源的子资源。此资源用于激活或去激活父<dst>资源。请注意，DST的最新状态应反映在<dst>资源的“DST_status”属性中。
<dst触发>资源应在创建父<DST>资源时创建。
取回操作可能不适用于<dst触发>。更新操作可用于激活或去激活父<dst>资源。
表8、<dst触发>更新
当托管CSE删除父<dst>资源时，应删除<dst触发>资源。该删除操作不适于经由Mca、Mcc或Mcc’进行。
在图17中公开了GUI界面，可以用于人类用户根据他/她的使用来创建DST。通常，这些参数可以传输到DSCS代理(可以是Creation_DSCS_Agent)，在该代理中可以相应地创建DST。换句话说，该用户界面上的参数可以是图6的步骤2中的请求消息中携带的参数。可以看出，用户可以为整个DST指定一些大体信息，例如目标区域、RDS生成频率、RDS上下文等。与此同时，用户还可以输入DST中每个DE的详细定义。如果用户希望在DST中具有多于一个DE，则他/她可以单击“添加更多DE”按钮，以便这些面板上可以为这些DE显示更多输入区域。
再次参考图4所示的智慧城市用例示例。为了建设智慧城市，市政府采用了基于标准的服务层(SL)平台(例如oneM2M)，并在城市公共基础设施上(如在道路/街道上、公共建筑内、公共汽车/地铁上等)部署了许多IoT传感器和装置。由于预算有限，市政府还呼吁私人组织和个人参与这项智慧城市倡议。因此，那些安装在私有财产(例如私家车，手机等)上的IoT装置也被整合到***中，从而该***可以生成大量反映城市实时运行状况的综合IoT数据。
城市可以具有许多地理区域，例如中央商务区(CBD)、郊区住宅区等，其可以被称为本地雾区域(LFA)。可以在那些LFA中部署大量的IoT装置，并且可以从这些LFA中生成大量的IoT数据。从通信网络的角度来看，不同的城市区域构成了多个LFA(例如，CBD对应于LFA-1，郊区住宅区对应于LFA-2，如图4所示)。
云中部署了智慧城市控制台，允许用户根据他们的需求提出各种数据分析请求。例如，来自组织A的用户有一个数据样本收集请求(表示为DSCR-1)，该请求旨在评估给定区域(例如，如图4所示的LFA-X，其为大规模修路和建筑施工的区域)的当前天气和环境污染状况。实际上，数据分析结果通常通过各种图表(例如线形图或条形图)表示。除了用户打算查看哪种类型的分析图(例如线形图)之外，用户还可以指定作为用于绘制图表等的输入的数据样本应该是什么。为了准备这些数据样本以绘制图表，相关原始数据需要从也称为数据源(DS)的各种IoT装置中收集。在智慧城市用例中，DS的示例包括温度传感器、湿度传感器、污染传感器、噪声传感器等。特别是，这些传感器或装置可以由除组织A(用户所属的组织)以外的其他组织安装。
可以假定，在DSCR-1中，用户打算查看LFA-X的线形图，该线形图要求每3分钟一个数据样本。特别地，每个数据样本可以由以下两个数据元素构成，每个数据元素都与质量要求相关联：
数据元素(DE)-1：每3分钟采样的LFA-X的平均温度。
DE-1的质量要求：需要从LFA-X中部署的至少100个不同的温度传感器收集温度读数以保证准确性。
DE-2：每3分钟采样的LFA-X的平均噪声水平。
DE-2的质量要求：需要从部署在LFA-X的30个主要交通路口的噪声传感器收集噪声读数。
为了在部署在云中的智慧城市控制台上绘制线形图，每3分钟需要一个格式为(DE-1，DE-2，时间戳)的数据样本。这样的数据样本可以称为DSCR-1的即用型数据样本(RDS)。
为了制作上述用例中说明的RDS，需要在LFA中收集并处理大量的IoT原始数据。雾计算范式非常适合支持此类应用，因为不必将大量原始数据移到云侧进行集中处理，而是可以在LFA中进行处理以制作RDS。
用户可以不了解LFA中可用的IoT DS。例如，在智慧城市用例中，已部署的SL平台还可以整合来自不同组织和个人的许多IoT DS。来自云侧的用户不是部署那些IoT DS的同一方。用户通常不是LFA中具有数据处理能力的许多LFN的所有者(例如网关、路侧单元等)，并且用户通常不具备为期望的数据处理操作配置LFA中的任何LFN的能力，因为那些LFN可由不同方或不同组织拥有。值得注意的是，某些现有的IoT边缘产品(例如微软IoT Edge或亚马逊Greengrass)在这种异构场景中无法有效工作。例如，这些产品支持相对简单的情况，即用户通常具有对在LFA中的处理节点的可用DS的完全知识和完全的配置能力两者。
为了支持这种异构场景，一般的方案是IoT***可以提供公共的数据样本收集服务，该服务可以从用户接收各种DSCR。给定的DSCR描述了有关用户打算接收哪种RDS的所有细节。但是，用户可以不参与在LFA中发生的服务于DSCR的任何活动。换句话说，用户可以只向IoT***提交DSCR，***将处理一切以将RDS交付给用户。
在为特定的DSCR服务时，需要考虑两个特定的技术问题：
DS识别处理：对于RDS中与给定DSCR对应的每个DE，需要在LFA中发现和/或评估成千上万个潜在DS，以确定它们是否是此给定DSCR所期望的DS(这样的过程称为DS识别处理)。为了识别那些DS，可以利用具有发现能力的某些LFN，它们可以用作DS发现者(DSD)。例如，在oneM2M场景中，具有资源发现能力的任何AE或CSE都可以用作DSD。但是，以有效的方式进行DS识别处理至关重要。主要挑战在于，LFA中可以有多个LFN可以用作DSD，但是这些LFN中的每一个可以具有不同/有限的DS识别能力或不同的访问特权。作为示例，一个LFN可以识别属于特定组织A的某些DS，而另一个LFN只能识别属于另一个组织B的某些DS。这两个LFN都可以用作DSD以帮助特定的DSCR，这可以是从两个组织识别期望DS所要求的。因此，可以看出，LFA中的多个LFN需要“合作地”一起工作，以充分利用和整合它们各自的发现能力，以便为给定DSCR识别所期望的DS。然而，当前不能以整体的方式利用不同DSD的各种DS识别能力来实现LFA中的合作式DS识别。
RDS制作处理：在DS识别处理之后，下一步(称为RDS制作处理)针对如何处理从所期望DS中收集的原始数据、制作RDS并将其交付给用户。特别地，从DS收集的原始数据可以是大量的，并且需要合作完成对大量原始数据的数据处理。如果LFN可以处理IoT原始数据，则LFN可以用作原始数据处理者(RDP)。但是，主要的挑战是，LFA中可以有多个LFN可以用作RDP，并且这些LFN可能属于不同的组织，并且这些LFN中的每个LFN都可能具有不同和/或有限的数据处理能力(例如，有些只能执行数据预处理，有些可以进行基本的数据聚合处理，而有些可以进行高级的数据分析处理)。因此，还可以看出，LFA中的多个LFN需要合作地一起工作，以便充分利用/整合它们各自的数据处理能力，从而为给定的DSCR生成RDS。但是，当前没有可以在LFA中为了服务DSCR而进行合作式RDS制作的方案。
本文公开了用于基于雾的服务层(SL)的合作式DS识别和RDS制作的方法和***。该方法和***可以包括但不限于：
合作式数据源(DS)识别：对于与DSCR对应的RDS中的每个DE，LFA中可以有成千上万的潜在DS需要被发现和/或被评估以确定它们是否是用于服务此DSCR的期待的DS。LFA中可用作数据源发现者(DSD)的不同本地雾节点(LFN)可以具有不同的DS识别和发现能力。因此，提供了方法和***，可允许一个或多个LFA中的多个LFN(作为DSD)合作式地共同工作以识别给定DSCR的期望DS。
给定的LFN可以具有DS识别能力，但可以不具有数据收集能力(例如，从期望的/已识别的DS收集数据)或特定的数据处理能力(例如，处理原始数据以制作RDS)。因此，本文公开的DS识别处理不仅是指根据给定DSCR的要求为RDS中的每个DE识别期望的DS，而且还指找到可以用作原始数据收集者(RDC)以从那些已识别的DS收集原始数据的合适的LFN，以及找到可以用作原始数据处理者(RDP)以处理原始数据以制作RDS的适当的LFN。本文公开的用于合作式DS识别的方案包括但不限于具有RDC发现的DS识别和DS识别结果整合以及RDC/RDP作业分配。
合作式RDS制作：在RDS制作过程中，主要工作与如何处理收集的原始数据并制作RDS有关。从DS收集的原始数据可以非常大量，而对海量原始数据的数据处理也需要合作地完成。对于给定的DSCR，其数据处理可以跨越多个RDP，因为不同的LFN可以具有为该DSCR制作RDS所要求的各种数据处理能力。本文公开的用于合作式RDS制作的主要方案包括但不限于触发给定DSCR的RDS制作、给定DE的RDS制作以及给定DSCR的RDS组装。
以下描述了贯穿本公开使用的一些术语的示例定义：
云节点(CN)：具有云能力的节点，该节点管理在部署层次结构中较低的其他雾节点的操作。注意，在本公开中，术语“云”可以用于指代云节点。云监视和管理不同雾节点之间的交互，这些雾节点共同为应用启用雾服务层。
数据样本收集请求(DSCR)：DSCS的用户可以在DSCR中指定其需求，该需求可以包括有关他们打算接收哪种类型的RDS的细节。
即用型的数据样本(RDS)：对于给定的DSCR，其相应的RDS指的是已经处于即用阶段供用户使用(例如，用以绘制分析图)的数据样本。可以通过由LFA中的LFN执行的RDS制作处理来获得RDS。例如，对于给定的DSCR，DSCS可以进行有效的IoT原始数据收集和数据处理，以通过利用雾计算范式来制作RDS。使用智慧城市用例为例，对于DSCR-1中的DE-1(这是最近三分钟LFA-1的平均温度)，部署在LFA-1中的DSCS需要从LFA-1中所涉及的温度传感器中收集原始数据、对原始数据进行平均聚合操作、并为DSCR-1的每个RDS制作DE-1部分。DSCR-1的每个RDS的DE-2部分也可以类似的方式制作。通过上下文对准，可以相应地组装DE-1部分的数据和DE-2部分的数据以制作RDS。例如，如果一条DE-1部分的数据和一条DE-2部分的数据是在相同的三分钟时间间隔内，则可以将这两条数据组装在一起以形成针对此特定的三分钟时间间隔的单个/完整的RDS。
数据元素(DE)：DSCR定义在与该DSCR对应的单个RDS中可以包括什么DE(例如，它可以描述其对应的RDS的样子)。换句话说，RDS是其相应DSCR的真实数据样本实例。例如，考虑具有以下两个DE的DSCR-1：DE-1(最近三分钟内的LFA-1平均温度)和DE-2(最近三分钟内的LFA-1平均噪声水平)。DSCR-1的每个RDS可以具有这两个DE(DE-1，DE-2，RDS_Contexts)，其中RDS_Contexts提供有关此RDS的详细上下文信息(例如，此特定RDS与哪个三分钟的时间间隔有关)。
雾节点(FN)：具有任何雾资源(例如计算、存储、通信、分析等)的节点。雾节点可以具有这些资源中的至少一个，并且还可以具有正在雾节点上运行的其他软件或服务。假设FN的部署级别比LFN高一个级别。FN部署可以有多个级别，其中云节点(CN)处于最高级别。在智慧城市用例示例中，FN可以是网络中更高级别的路由器。
本地雾区域(LFA)：可以根据不同的应用场景将地理区域(例如，城市)划分为多个LFA。在智慧城市用例场景中，特定的住宅区可以是LFA，或者市中心的中央商务区(CBD)可以是LFA。
本地雾节点(LFN)：LFN可以是LFA中具有计算、存储和通信能力的节点。LFN可以与其对应的LFA中的LFN引领者(LFNL)通信和/或交互。示例LFN可以是人的手机、移动中的公共汽车、房屋的家庭网关等。LFN是网络最低级别处的一种FN。LFN可以与同一LFA中的其他LFN交互/合作，并且可以进行发现、收集和处理来自各种DS的IoT数据。
LFN引领者(LFNL)：给定的LFA在该区域具有LFN引领者。LFNL是管理、控制和/或协调该LFA中所有LFN的活动的LFN，并且可以连接到更高级别的FN。在智慧城市用例示例中，LFNL可以是特定住宅区的主网关。
DS识别处理：对于与给定DSCR对应的RDS中的每个DE，LFA中可以有成千上万个潜在DS需要被发现和/或被评估，以确定它们是否为此DSCR所期望的DS。这样的处理可以称为DS识别处理。
RDS制作处理：RDS制作处理是指如何处理从期望的DS收集的原始数据并制作RDS。
数据源(DS)：如果节点是IoT数据源，则该节点可以是DS。例如，节点可以是传感器、摄像头、交通信号灯或制造数据的任何IoT装置。路侧单元也可以是DS，因为它会生成与路面有关的感测数据。路侧单元也可以是LFN，因为它可以执行某些数据处理能力和/或可以与LFNL通信。通常，LFA中不仅具有传感能力而且还具有计算、存储和通信能力的节点可以是LFN和DS。
数据源发现者(DSD)：这是个逻辑角色。如果在DS识别处理期间，给定的LFN涉及针对给定DSCR发现DS，则可以将其视为该DSCR的DSD。
原始数据收集者(RDC)：这是逻辑角色。如果给定的LFN涉及从某些DS收集原始数据以服务于给定的DSCR，则可以将其视为此DSCR的RDC。
原始数据处理者(RDP)：这是个逻辑角色。如果在RDS制作处理期间，给定的LFN涉及为给定DSCR处理收集的原始数据，则可以将其视为该DSCR的RDP。注意，通常LFN可以同时承担RDC、DSD和RDP的多个逻辑角色，或者当服务于给定DSCR时，这些逻辑角色可以由不同的LFN承担。特别地，通过定义三个不同的逻辑角色，由于不同的任务是解耦的并且可以由不同的角色执行，因此可以促进工作合作。
值得注意的是，尽管使用与雾有关的术语描述了本公开中提出的想法，但是本公开中提出的想法也可以应用于边缘场景。例如，LFA也可以解释为边缘处的特定区域，LFN可以是边缘侧的节点，LFNL可以是边缘处的网关或边缘处的路侧单元，等等。
本文公开了用于服务层的称为数据样本收集服务(DSCS)的公共服务的两个关键特征。DSCS的高级体系架构在图18中示出。DSCS可以从用户那里接收各种DSCR，并代表其用户处理所有细节。在DSCR中，用户可以清楚地描绘其所期望的数据样本(例如RDS)的样子，以及有关数据样本的各种质量要求。如果服务层节点(例如，在LFN、LFNL、FN或CN上)打算提供与数据样本收集相关的服务，则该服务层节点可以具有DSCS代理。SL节点上的DSCS代理是一款软件，该软件不仅可以与DSCS用户进行交互，而且可以与其他DSCS代理进行合作以服务于用户提出的DSCR。利用DSCS，一旦用户提出了DSCR，用户就不必参与有关如何识别LFA中的合格DS以及如何在这些LFA中配置LFN以进行原始数据处理和RDS制作的任何细节。如图18所示的示例，在CN中的DSCS代理从用户接收到DSCR之后，它可以找出涉及哪些LFA。如果用户只是想从特定的LFA(例如，在图18的左侧所示的那个)中收集数据样本，则可以将此DSCR的相应任务分配给该LFA中LFNL上的DSCS代理。该LFNL可以用作该LFA中所有LFN进行的活动的中央控制者、管理者和/或协调者，这可以涉及此处公开的两个具体技术问题(例如，DS识别和RDS制作)。
合作式数据源(DS)识别：对于对应于DSCR的RDS中的每个DE，LFA中有成千上万个潜在DS需要被发现和/或被评估以确定它们是否是此DSCR所期望的DS。LFA中的LFN可以具有不同的DS识别能力。因此，本文公开了LFA中的多个LFN可以合作地共同工作以识别给定DSCR的期望DS。可以假设LFN-1已经参与了DS识别任务，并为给定的DSCR-1识别了所期望的DS。在这种情况下，LFN-1用作DS发现者(DSD)。但是，由于工作负载容量有限，LFN-1可能无法进一步用作此DS的原始数据收集者(RDC)。因此，另一个LFN-2需要用作RDC，负责进一步从该DS收集原始数据。同样，LFN-2可能无法进一步用作此DS的原始数据处理者(RDP)。因此，另一个LFN-3需要用作RDP，负责进一步处理从此DS收集的原始数据。因此，在本公开中考虑的DS识别处理不仅是指根据给定DSCR的要求为RDS中的每个DE识别期望的DS，而且还指为那些识别的DS找到可以用作RDC以及RDP的合适的LFN。
合作式RDS制作：在RDS制作处理中，主要工作与如何处理收集的原始数据、制作RDS并将其交付给用户有关。从DS收集的原始数据可以很多，需要合作完成对大量原始数据的数据处理(例如，在给定的RDS制作处理期间，IoT数据处理可能会跨越多个RDP)。例如，如果由于意外和/或大量原始数据到达而使用作RDP的LFN-1暂时过载，则它可以将其某些数据处理工作转移到当前工作负荷非常轻且也可以用作RDP的另一个LFN-2上。作为另一个示例，如果LFN-1由于其有限的数据处理能力而仅能够执行一些简单的数据处理，则它可以将其预处理的数据发送到另一个更强大的RDP(例如LFN-2)以进行深度数据处理。
使用本文公开的方法和***，不同的LFN可以承担DS识别处理或RDS制作处理中涉及的不同角色。例如，用作DSD的LFN可以一起工作来发现所期望需的DS。其他节点还可以用作RDC和/或RDP，用于从期望DS(在DS识别处理中识别的期望DS)收集原始数据、处理原始数据以及制作RDS。
值得注意的是，所公开的方法还考虑了在异构雾场景中的动态和不确定性。例如，由于不同的LFN可属于不同的组织，并且具有不同的主要用途，因此，对于LFN参与并继续为与DS识别或RDS制作相关的特定任务做出贡献没有严格的要求。因此，在给定任务中，需要将来自不同LFN的能力整合在一起，以使这些LFN以合作的方式工作。
图18(以及本公开的其他附图)示出了云中的用户向CN中的DSCS代理发送DSCR。可以理解，用户可以额外地或备选地来自LFA，并且在这种情况下，用户可以将其DSCR发送到那些LFA中的相应LFNL上的DSCS代理。本公开中提出的过程和方案也支持这种情况。
在LFN能力注册过程中，给定LFA中的LFNL可以负责管理或协调LFA中LFN的所有活动。因此，为了促进LFNL的管理工作，每个LFN需要先向LFNL报告和/或注册其潜在能力，然后才能参与与DS识别和RDS制作有关的任何任务。由于可以在为不同的DSCR提供服务时共享这些能力，因此可以最大程度地利用不同LFN的能力/功能。具有相同能力的多个LFN可以附加地或备选地被整合，这可以在进行DS识别和RDS制作过程时提高可扩展性。
在图19中示出了用于向LFN引领者注册LFN能力的示例过程，下面进行讨论：
作为前提条件，应当理解，LFN-1可以已经基于任何现有技术识别了LFA-1中的LFNL，即LFNL-1。例如，LFNL-1可以向LFA-1中的所有LFN广播，以声明其已被选择成为该LFA中的LFNL。
在步骤1，LFN-1上的DSCS代理-2打算向LFNL-1上的DSCS代理-1注册LFN-1的能力，以便参与将来的与DS识别和RDS制作有关的任务。
在步骤2，DSCS代理-2向DSCS代理-1发送注册请求，该注册请求包括有关LFN-1的潜在能力和标识符的细节信息。上报给LFNL的信息可以描述LFN-1是否可以担任与DSD、RDC和RDP相关的任何角色(给定的LFN可以担当多个逻辑角色)。以下示例的三个参数描述了LFN-1是否可以为潜在的DSD：
DSD_Capability_List：该参数可以列出可以使LFN-1成为DSD的其所有能力。例如，在oneM2M***中，如果给定的CSE具有oneM2M基本资源发现能力，则它可以是DSD。资源发现能力可以附加地或备选地被包括在该参数中。如果此CSE具有高级语义资源发现能力，则这些能力可以被包含在此参数中。
DSD_Work_Schedule_Availability_List：对于“DSD_Capability_List”中列出的每个能力，相应的工作计划表可以被包括在该参数中。例如，LFN-1可以不想在上午10点至下午2点之间提供用于合作式DS识别的高级语义资源发现能力，因为LFN-1通常在此时间附近具有来自其自身组织的重的工作负载(其具有第一优先级)。
DSD_Capability_Scope：此参数可用于指示“DSD_Capability_List”中列出的DSD能力的任何限制、约束或范围。例如，此参数可以指示LFN-1只能在某些节点或某些位置进行DS识别。LFN-1可以只能识别与LFN-1属于同一组织的DS。换句话说，LFN-1只能识别其自身组织内的DS。在另一个示例中，LFN-1只能在特定地理区域内(例如，位于LFA-1中的单个建筑中)进行DS识别。注意，在需要进一步考虑更细粒度的限制和/或约束的意义上，在该参数中指示的此类限制和/或约束仅是粗粒度的。例如，LFN-1可以在单个建筑中进行DS识别，但是对该建筑内的给定DS-1，可以有进一步的发现规则和策略来限定LFN-1是否被允许发现该建筑内的这样特定的DS-1。
类似地，以下三个参数描述了LFN-1是否可以是潜在的RDC：
RDC_Capability：此参数用于传达LFN-1是否具有IoT原始数据收集能力。
RDC_Work_Availability_Schedule：此参数指示LFN-1的RDC能力的工作计划表。例如，LFN-1可以不想在上午10点至下午2点之间贡献其原始数据收集能力，因为LFN-1通常在此时间附近具有来自其自身组织的重的工作负载(具有第一优先级)。
RDC_Capability_Scope：此参数可用于指示RDC能力的任何限制、约束或范围。例如，此参数可以指示LFN-1只能在某些节点或某些位置上收集原始数据。LFN-1可以只能从其自己组织内的DS收集原始数据。作为另一个示例，LFN-1也可以只能从部署在特定地理区域(例如，位于LFA-1中的一栋建筑)的DS中收集原始数据。
类似地，以下三个参数描述了LFN-1是否可以是潜在的RDP：
RDP_Capability_List：此参数是列出可以使其成为RDP的LFN-1的所有能力。例如，LFN-1可支持简单的数据聚合能力(例如执行取平均值、取最大值、取最小值运算等)。因此，简单的数据聚合能力可以包括在该参数中。如果LFN-1还具有高级的数据处理能力(例如分类、回归或其他基于机器学习的方法)，则此能力也可以包括在此参数中。
RDP_Work_Schedule_Availability_List：对于“RDP_Capability_List”中列出的每个能力，该参数中还可包括一个或多个相应的工作计划表。
RDP_Capability_Scope：该参数可用于指示“RDP_Capability_List”中列出的RDP能力的任何限制、约束或范围。例如，此参数可以指示在将数据发送或输入到LFN-1进行处理时应使用特定的数据格式。因此，如果输入数据(例如，从DS收集的原始数据)与该参数所指示的要求数据格式不兼容，则在LFN-1之前需要另一个RDP(例如，由LFN-2充当)，该另一个RDP可以先按照LFN-1的要求将原始输入数据转换为所需的数据格式。
附加地或备选地，每个LFN可以注册关于其自身的一些其他上下文信息，例如其地理位置、其所属组织等。
在步骤3，DSCS代理-1记录LFN-1的能力以备将来使用。DSCS代理-1上可以有一个可用的能力注册表，用于记录所有信息，如表9所示。
表9、LFN能力注册表
/>
在步骤4，DSCS代理-1确认成功注册。换句话说，在哪些LFN可以用作DSD、RDC和RDP的意义上，DSCS代理-1现在拥有资源池。因此，当接收将来的DSCR时，DSCS代理-1可以使用池中的那些资源为这些DSCR提供服务。
LFN可以动态地更新其能力(例如，添加新能力、更新现有能力的工作计划表、删除能力等)，这也可以导致表9所示的能力注册表的更新。其更新过程可以类似于图19中所示的过程。
在示例性合作式DS识别过程中，当LFNL接收DSCR时(例如，用户向CN提出了DSCR，并且CN将该DSCR进一步分派给了相关的LFNL)，LFNL可以通过利用由该LFNL管理的多个LFN提供和/或注册的DS识别能力开始发起合作式DS识别处理。通常，特定的合作式DS识别处理涉及两个阶段，下面将对此进行详细讨论。
阶段1可以包括具有RDC发现的DS识别。在阶段1，主要任务是识别可以为特定接收的DSCR服务的所有期望DS。期望的DS可以是将原始数据提供给该特定DSCR的相应RDS中的特定DE的实体。为此，LFNL首先需要根据LFN能力注册表中所述的信息，选择可以可以用作DSD的LFN列表。然后，LFNL指定那些选定的DSD来合作地进行DS识别操作。在许多情况下，LFN-1可以用作DSD并为接收的DSCR识别期望的DS。但是，由于实际的RDS制作处理可能会在晚些时候开始，LFN-1可能在那个时间附近不再可用，因此需要另一个LFN-2作为RDC，以便之后进行原始数据收集。另一个可能性是，LFN-1是一个专用节点，从其工作专长仅是DS识别的意义上讲，它具有复杂的DS识别能力。换句话说，为了促进LFN物理节点的实现，不同的LFN可以具有各自的工作专长。因此，当DSD(例如，LFN-1)识别期望的DS时，它可能还需要收集有关允许谁从该DS取回原始数据的相关信息，并且需要此类信息才能在后期阶段为此DS找到合适的RDC。以oneM2M为例，CSE(作为DSD)已发现<容器-1(container-1)>资源，该CSE存储了温度传感器的所有读数(作为期望的DS)。CSE可以检查与此<容器-1>资源相关的访问控制策略(ACP)。例如，如果<容器-1>资源正在使用在<ACP-1>资源中描述的访问控制策略，则CSE可以进一步检查<ACP-1>资源以识别哪些实体具有“取回”<容器-1>资源的特权。LFN-1可以将其DS识别结果以及RDC候选发送回LFNL。
在一个示例中，数据样本收集服务可以被配置为执行如下操作：接收识别与数据样本相关联的一个或多个数据元素的数据样本收集请求；以及为所述数据元素中的至少一个确定一个或多个数据源发现者，其被配置为识别所述至少一个数据元素的一个或多个数据源；向一个或多个数据源发现者发送请求，以识别至少一个数据元素的一个或多个数据源；从一个或多个数据源发现者接收数据源识别结果，该结果识别至少一个数据元素的一个或多个数据源；基于数据源识别结果，选择本地雾节点，所述本地雾节点被配置为执行以下至少一项：从数据源收集原始数据和处理从数据源收集的原始数据；以及向所选择的本地雾节点发送指示以执行以下至少一项：从数据源收集原始数据和处理从数据源收集的原始数据。
数据样本收集请求可以包括与数据样本相关联的信息，该信息包括如下一项或多项：应以怎样的频率产生数据样本、何时应当实施数据样本收集请求的计划表、数据样本所应发往之处的标识符、以及与数据样本相关联的上下文信息。一个或多个数据元素中的数据元素可以包括以下至少之一：该数据元素的标识符、要为该数据元素收集的原始数据的类型、与该数据元素的该原始数据相关联的单位、以及数据元素的数据处理操作。识别一个或多个数据源的请求可以包括待识别的数据源的类型和执行数据源识别的工作范围中的至少一项。数据源识别结果可以包括数据源的数据速率、数据源的数据单位、数据源的地理位置、数据源的可用性计划表以及配置为访问数据源的一个或多个本地雾节点中的至少一项。执行从数据源收集原始数据和处理从数据源收集的原始数据中的至少一项的指示可以包括任务描述和任务标识符中的至少一项。数据样本收集服务可以在本地雾节点、本地雾节点引领者、雾节点或云节点之一中实现。该操作还包括：整合从多个数据源发现者接收到的一个或多个数据源识别结果；以及根据整合的数据源识别结果，确定一个或多个要从中收集数据的数据源的列表。
在图20中示出了用于通过RDS发现进行DS识别的示例过程，下面将进一步讨论。
在步骤1，LFA-1中LFNL-1上的DSCS代理-1接收DSCR-1。如果用户居住在LFA-1中，则用户可以直接向LFNL-1上的DSCS代理-1提出DSCR-1，或者如果用户在云中，则可以向CN中的另一个DSCS代理提出DSCR-1，然后该另一个DSCS代理将DSCR-1转发到LFNL-1上的DSCS代理-1以进行处理。通常，DSCR-1描述了有关用户打算接收哪种RDS的所有细节。如下所示，DSCR可以包括以下信息：
参数的第一部分用于特定DSCR-1的RDS的总体信息和要求：
Data_Sample_Frequency：“Data_Sample_Frequency”指示应该多久制作一次RDS。例如，用户可能每隔一分钟需要RDS。在智慧城市分析用例中使用的另一个示例中，由于两个DE分别计算每三分钟的平均温度和湿度，因此应每三分钟创建一个RDS。
RDS_Production_Schedule：这是可选参数。“RDS_Production_Schedule”指示何时应为此DSCR-1进行RDS制作。换句话说，不必在LFNL-1处理DSCR-1之后立即开始DSCR-1的RDS制作处理。实际上，这是关于如何控制DSCR-1的RDS制作的方法之一。例如，此参数可以指示RDS制作应仅在每天的上午8点至上午10点以及下午5点至晚上8点之间进行。备选地，控制RDS制作的另一种方法可以基于某些触发(例如，可以基于特定的触发请求或基于某些事件来开始RDS制作处理)。
RDS_Contexts：该参数指示对于该DSCR的每个单个RDS，除了要包括的所有DE之外，还应该在RDS中包括哪些其他上下文信息。例如，可能有必要将时间戳和DSCR_ID信息嵌入RDS中，以便他者可以知道此RDS与哪个DSCR兼容以及针对生成该RDS的时间间隔。通常，以后需要使用的任何有用的上下文信息应携带在RDS中。因此，给定的RDS-1可以具有以下形式：RDS-1＝(DE-1，DE-2…DE-N，RDS-上下文-1，RDS-上下文-2，…)。
RDS_Sending_Address_List：此属性指示该DSCR-1的RDS可以发送到的地址列表。例如，可以存在以下两种情况：
如果直接从用户发送了DSCR-1，则可以将DSCR-1的RDS发送给用户。从某种意义上说，这是最简单的情况，即DSCR-1在处理期间不会被拆分。
在更高级的场景下，由于要为DSCR-1收集的数据可来自不同的LFA，因此DSCR-1可以与多个LFA交互，因此在处理期间可能会拆分DSCR-1。考虑以下示例：DSCR-1是通过将父DSCR拆分为两个DSCR(例如DSCR-1a和DSCR-1b)而创建的。换句话说，用户最初提出了父DSCR-1，该父DSCR-1涉及覆盖两个LFA(例如LFA-1和LFA-2)的大地理区域。因此，此父DSCR-1被拆分以进行适当处理。例如，DSCR-1a是子(sub)DSCR之一，它被发送到LFA-1中的LFNL-1，因为DSCR-1a的任务是处理LFA-1中的DS识别和RDS制作。类似地，DSCR-1b可以处理与另一个LFA-2相关的DS识别和RDS制作。结果，DSCR-1a(从父DSCR-1的角度来看，DSCR-1a的RDS可以只是父DSCR-1的部分RDS)和DSCR-1b的RDS需要由RDP进一步组合和/或组装在一起，以制作父DSCR-1的RDS。DSCR-1的RDS_Sending_Address_List可以是DSCR-1的用户提供的RDS接收地址。DSCR-1a和DSCR-1b的RDS_Sending_Address_List可以是用于父DSCR-1的RDS组装的RDP。
DSCR-1的每个RDS可以具有DE的列表。RDS中的每个DE可以都有以下项，这些项定义了此DE的所有细节：
DE_ID：“DE_ID”是该DSCR-1中的DE的标识符。作为在智慧城市分析用例中使用的示例，DSCR的每个RDS中都有两个DE，DE-1和DE-2分别是它们的DE_ID。
Raw_Data_Type：这指示应该为此DE收集哪种类型的原始数据。作为在智慧城市分析用例中使用的示例，DE-1的原始数据类型可以是温度。
Unit：这指示该DE应该是什么单位。根据智慧城市分析用例中使用的示例，DE-1的原始数据类型为温度。特别是，尽管DE-1的原始数据可以是摄氏温度或华氏度，但可以在RDS中要求DE-1部分应以摄氏温度为单位(这是DE-1的单位)。
Data_Processing_Operation：这是针对RDS中的给定DE指示应针对为此DE收集的原始数据执行哪种类型的数据处理操作。常见操作包括但不限于：取平均值、取最大值、取最小值等。作为在智慧城市分析用例中使用的示例，DE-1的数据处理类型应为“执行平均聚合操作”。用户还可以使用定制的数据处理操作。在这种情况下，此参数的值可以为“定制”。
Customized_Processing_Details：如果“Data_Processing_Operation”的值为“定制”，则该参数可以指示如何进行这样的定制数据处理操作。例如，它可以具有以下操作：
用户计算出通过机器学习处理获得的数学公式或模型，并且该模型可用于处理为此DE收集的原始数据。在这种情况下，该公式可以直接嵌入此参数中。
用户具有自己的数据处理代码段，该代码段可以由LFA中的RDP运行以处理为此DE收集的原始数据。在这种情况下，此参数可以指示数据处理代码段的存储位置(例如URI)。
Quality_Requirements：这指示该DE的任何质量要求。作为在智慧城市分析用例中使用的示例，对于单个RDS中的DE-1，要求从部署在LFA-X中的至少100个不同温度传感器收集温度读数，以确保准确性。
在步骤2，DSCS代理-1检查LFN能力表(如表9所示)，并选择适当的LFN(例如LFN-1)作为DSCR-1的DSD。作为在智慧城市分析用例中使用的示例，两个DE(例如DE-1和DE-2)可以分别每三分钟计算一次平均温度和湿度。因此，对于每个DE-1和DE-2，DSCS代理-1可以选择一个或多个DSD的列表。为此，DSCS代理-1需要检查有关潜在DSD候选的细节信息，例如其能力、工作计划表以及表9中所示的DSD范围。如果部署在LFA-X中的温度传感器属于不同的组织，并且每个选定的DSD也都具有一定的能力限制(例如，每个DSD只能对属于同一组织的特定DS进行DS识别)，则需要多个DSD来识别DE-1所需的DS。作为另一个示例，LFA-X可覆盖很大的地理区域。因此，需要多个DSD，并且每个DSD都可以对LFA-X中的小区域进行DS识别。通常，可能存在许多其他情况需要多个DSD来执行给定DE的DS识别，并且本文公开的方法和***可以应用于所有这些情况。
总的来说，DSCS代理-1可以为每个DE选择DSD列表，并为每个选定的DSD分配详细的DS识别计划，该计划可以包括以下信息：
将识别什么类型的DS。例如，对于给定的DE，在步骤1中引入的“Raw_Data_Type”指示要识别的DS类型。给定的DSD可以用于识别多个DE的潜在DS。在这种情况下，给定的DSD可以具有多个DS识别计划，每个计划都对应于给定的DE。
用于进行DS识别操作的工作范围是什么(例如，在哪个组织内或在哪个地理区域内等)。
对DS的任何其他要求。根据智慧城市分析用例中使用的示例，DE-1将计算每三分钟的平均温度。因此，对于DE-1，对DE-1的潜在DS的要求之一可以是温度传感器(作为DS)应该是室外温度传感器，而不是室内温度传感器。
在步骤3，对于每个DE，DSCS代理-1向每个所选的DSD(例如LFN-1上的DSCS代理-2)发送请求以对该DE进行DS识别操作并发送为每个选定的DSD创建的详细的DS识别计划。换句话说，对于每个DE，每个选定DSD的DS识别计划都是不同的，因此它们可以一起工作以合作地完成此DE的DS识别任务。如果选定的DSD参与了多个DE的DS识别任务，则DSCS代理-1可以向该选定的DSD发送单个请求，其中包含了不同DE的所有DS识别任务。
在步骤4，每个选定DSD上的DSCS代理可以根据其各自的DS识别计划进行DS识别。例如，LFN-1上的DSCS代理-2负责对DS-1进行DS识别，以评估DS-1是否为期望的DS(例如，评估DS-1是否为温度传感器，以及是否位于户外)。LFN-1需要访问DS-1才能进行DS识别。以oneM2M为例，如果具有语义能力的CSE-1(作为DSD)打算发现温度数据源，则可以使用语义发现机制来识别托管在CSE-2上的<容器-1>资源(作为DS-1)以及存储温度读数。附加地或备选地，DS-1可以向CSE-1注册(例如，<容器-1>资源由CSE-1托管)，CSE-1可以用作DSD。在这种情况下，CSE-1可以直接检查DS-1的注册信息以进行DS识别，并且可以不需要与DS-1对话。每个DSD上的DSCS代理可能还需要收集有关每个已识别/候选DS的更多有用信息。相关信息可以包括但不限于以下几个方面(以DS-1为例)：
DS-1的数据速率；
DS-1的数据单位；
DS-1的地理位置；
具有访问权限以从DS-1取回原始数据的LFN(即，将作为RDC候选者)；和
DS-1的可用性计划表。
在步骤5，每个选定DSD上的DSCS代理(例如LFN-1上的DSCS代理-2)将其DS识别结果连同在步骤4中引入的关于已识别DS的相关信息一起发回。
阶段2可以包括DS识别结果整合和RDC/RDP任务分派。在阶段2，LFNL的主要任务是整合在阶段1来自DSD的所有DS识别结果，并为每个DE确定期望DS的列表。换句话说，可以从那些选择的DS中收集原始数据。对于每个选定的DS，LFNL需要根据关于阶段1中识别的DS的相关信息为其分派适当的RDC。LFNL可能还需要为每个选定的DS分派适当的RDP，这些RDP可以负责处理那些选定DS的原始数据并制作RDS。DS识别结果整合和RDC/RDP任务分派的示例过程在图21中示出并在下面讨论。
在步骤1，DSCS代理-1从多个DSD接收到DSCR-1的DS识别结果(这是图20的步骤5的结果)。例如，对于DSCR-1的RDS中的每个DE，可以存在由不同DSD识别的多个DS。因此，DSCS代理-1可以为每个DE评估所有已识别的DS。请注意，即使不是所有识别的DS都将被选作DSCR-1的期望DS，DSCS代理-1仍可以记录所有识别的DS。原因是当服务于其他/将来的DSCR时，此类DS识别结果可能会重用。因此，阶段1的另外的改进之一是在图20的步骤2中，在为特定的DSCR选择适当的LFN作为DSD之前，DSCS代理-1可以首先检查DS识别结果历史记录，并查看是否可以将为先前DSCR识别的任何现有DS重利用于服务于此新DSCR。这样，可以减少DS识别操作的开销。
在步骤2，DSCS代理-1为每个DE选择期望DS的列表。可以执行该步骤以从要为该DE识别的所有DS中选择要收集原始数据的DS。
对于给定的DS，要考虑和包括的相关信息可以包括以下内容，这些信息可以是在DS识别处理中获得的(例如，在图20的步骤4中)：
DS的数据速率；
DS的数据单位；
DS的地理位置；
具有访问权以从DS取回原始数据的LFN；和
DS的可用性计划表。
作为在智慧城市分析用例中使用的示例，对于DE-1(这是每三分钟的平均温度)，假定已在阶段1期间由多个DSD识别了200个温度传感器(作为DE-1的DS候选者)并且这些温度分布在LFA-X覆盖的整个地理区域中。
还需要考虑关于DE本身的某些信息，如在图20的步骤1中引入的DSCR-1中所述的(例如，在“Quality_Requirements”参数中)。根据智慧城市分析用例中的示例，对于DE-1，需要从LFA-X中部署的至少100个不同的温度传感器中收集温度读数，以确保准确性。
通过考虑关于给定的DE及其对应的识别的DS的信息，DSCS代理-1可以决定哪些DS是从中收集原始数据的期望DS。根据智慧城市分析用例中使用的示例，对于DE-1(这是每三分钟的平均温度)，可以在LFA-X中的总共200个温度传感器(作为DS候选)中选择100个温度传感器作为DE-1的期望DS。
在步骤3，对于每个期望的DS，DSCS代理-1进一步为其选择一个RDC。通常，每个选定的DS都需要RDC，该RDC从DS收集原始数据并将原始数据发送到相应的RDP进行处理。为了使提出的方案更通用，值得注意的是RDC和RDP只是逻辑角色，因此，对于给定的DS以及该DS的RDP，LFN也可以是RDC。尽管可以为每个期望的DS选择RDC，但是给定的LFN可以用作多个DS的RDC。换句话说，给定的LFN可以负责从多个DS收集数据。为了便于说明，在以下描述中，假定对于给定的DS，其RDC和RDP可以由不同的LFN担任。
为了进一步为每个期望的DS选择RDC，需要评估以下信息：
DSCS代理-1需要检查关于DS的相关信息：关于哪些LFN拥有访问权限以从该DS中取回原始数据(可以已在阶段1中获得)。这样的信息可以描述为粗粒度或细粒度。例如，给定的DS-1可以具有粗粒度的访问控制信息，例如与DS-1属于同一组织的任何LFN都可以从DS-1取回数据。作为另一个示例，它可以具有另一个粗粒度的访问控制信息，例如与DS-1相距200米以内的任何LFN都可以从DS-1取回数据。对于细粒度的访问控制信息，一个示例可以是只有特定的LFN(例如LFN-1和LFN-27)才能从DS-1取回数据。另一个示例可以是oneM2M示例，其中特定<容器>资源(作为DS)的ACP规则指示了对该资源具有“取回”特权的特定CSE/AE(作为RDC候选)的列表。
DSCS代理-1需要检查LFN能力表，以识别哪些LFN可以用作并且愿意用作RDC。给定的LFN可以具有复杂的DS识别能力，但不愿意做出贡献。在这种情况下，当将其能力注册到相应的LFNL(在LFN能力注册处理中引入)时，它可以表示它不愿意用作RDC。“Other_Context_Information”参数描述特定LFN的一般上下文，例如其所属组织及其地理位置等。
可以将关于特定DS的访问控制信息与同特定LFN相关的访问特权信息进行比较，以便为该DE选择合适的LFN作为RDC。继续前面的示例，对于给定的LFN-1，如果它与DS-1隶属于同一组织，则如果DS-1的访问控制规则定义了与DS-1属于同一组织的任何LFN都可以从DS-1取回数据(例如，DS-1的访问控制策略与LFN-1的访问特权匹配)，则可以将LFN-1选择为DS-1的RDC。注意，为了提高可靠性，可以为给定DS选择多个RDC，以便可以将一个RDC指定为该DS的主RDC，而将其他RDC指定为辅助/备用RDC。结果是，主RDC是用于从该DS收集原始数据的主要或“主管”RDC，但如果主RDC不能进行原始数据收集，则可由辅助RDC代替。
在步骤4，DSCS代理-1为每个DE创建RDP任务分派计划。给定DE-1的示例工作流程如下：
对于DE-1，DSCS代理-1首先计算从DE-1的DS收集的原始数据到RDS中的DE-1的最终形式之间需要多少数据处理阶段。根据智慧城市分析用例中的示例，DE-1是每三分钟的平均温度。换句话说，在单个RDS中，DE-1的最终形式是“在给定的三分钟时间间隔内LFA-X的平均温度”，而DE-1的原始数据是从多个温度传感器收集的这三分钟的时间间隔期间的温度读数。因此，此示例可以具有两个数据处理阶段：
数据处理阶段1：对于一条温度读数，第一处理是在从温度传感器收集的最初的原始数据中提取数据读数和其他有用的上下文信息(例如时间戳)。也需要其他预处理，例如，如果DE-1的最终形式要求数据以摄氏度为单位，则如果原始数据以华氏度为单位，则需要进行单位转换。因此，可以为此阶段确定RDP，作为用于接收由RDC收集的原始数据的第一级RDP节点。
数据处理阶段2：需要对从DE-1的所有期望DS收集的原始数据一起进行处理，以便计算每三分钟的平均温度，这是每个RDS中的DE-1的最终形式。因此，也可以为该阶段决定RDP，该RDP是用于接收由RDP在数据处理阶段1中输出的已处理数据的第二级RDP节点。注意，如果需要使用更特定的数据处理操作进一步处理数据，则在此阶段之后可以还有其他阶段。
下一步是为上述每个定义的阶段选择合适的LFN。例如，对于阶段1，需要某些定制的数据处理代码段，以便从原始数据中提取有用的数据。因此，作为RDP候选的LFN是可以在其上运行定制代码或软件的LFN。在另一个示例中，需要具有简单数据聚合能力的LFN作为阶段2的RDP。DSCS代理-1可以进一步检查LFN能力表，以识别哪些LFN可以用作上述每个阶段的RDP。由于要收集和/或处理的原始数据可以很多，因此需要多个LFN并将其选择为每个特定数据处理阶段的RDP。根据智慧城市分析用例中使用的示例，对于DE-1(这是每三分钟的平均温度)，可以从100个期望的DS(例如温度传感器)中收集100个温度读数。阶段1可以选择两个LFN作为两个RDP。在阶段1期间，每个RDP可以负责处理来自一半DS(例如50个温度传感器)的原始数据。如果给定阶段有多个RDP，一个RDP可以指定为该阶段的主RDP，而其他RDP为辅助/备用RDP。结果，主RDP是此阶段中用于数据处理的主要RDP，但是如果主RDP无法执行所要求的数据处理操作，则可以由辅助RDP代替。如果主RDP过载，它也可以将其工作负载转移到那些辅助RDP。对于阶段2由于要计算100个温度读数的平均值(这是阶段1之后处理的100个温度读数)，因此取平均值运算需要在单个LFN中执行。因此，可以选择强大的LFN作为阶段2的RDP。
最后一步是将不同数据处理阶段中的选定RDP连接或链接在一起，以构建完整的数据处理流程计划。当为第一阶段选择了多个RDP(例如，智慧城市分析用例中的阶段1)时，DSCS代理-1需要在第一阶段将每个DS分配给特定的RDP。换句话说，来自给定DS的原始数据应发送到其分配的RDP，以便在第一阶段进行处理。如果对于第一阶段(例如，阶段1)仅选择一个RDP，则所有DS的原始数据可以在第一阶段中发送到该单个RDP。由于RDC负责从期望的DS收集原始数据，因此对于给定的DS，需要通过此RDP分配决定通知其相应的RDC，以便RDC可以知道将原始数据发往何处(例如，哪个RDP)进行处理。
类似地，对于最后阶段中的RDP(例如，智慧城市分析用例中的阶段2)，DSCS代理-1可需要决定在此阶段之后应将处理后的数据发送到何处。根据智慧城市分析用例，在阶段2生成特定三分钟的平均温度读数时，由于该数据仅适用于DE-1，因此仍不是完整的RDS。完整的RDS可以包括两个DE(例如DE-1和DE-2)。因此，下一步可以是通过组装DE-1和DE-2的最终形式数据来生成完整的RDS(可以通过称为RDS-组装RDP的另一个RDP完成)。对于处于两个不同/相邻阶段的RDP，DSCS代理-1还需要决定在阶段i中由RDP处理的哪些数据应该在下一个阶段i+1中将其发送到哪个RDP。
最后，DSCS代理-1选择LFN作为RDS组装RDP，它在最后一个数据处理阶段中为每个DE接收RDP处理的数据，并将不同DE的数据组装在一起以构建RDS。以智慧城市用例为例，对于DE-1，其最后数据处理阶段的输出/处理数据可以是特定三分钟时间间隔内的平均温度。可以将此类数据与DE-2的其他数据(例如，相同的三分钟时间间隔内的平均湿度)进行组装。由于根据此示例中的RDS定义，每个RDS的格式为(DE-1，DE-2，时间戳)，因此可以将这两个数据组装在一起成为一个完整的RDS。
在步骤5中，对于给定/期望DS(如步骤3中所确定)的每个选定LFN(作为RDC)，DSCS代理-1可以联系那些LFN以分派数据收集任务。例如，当DSCS代理-1向特定的LFN-1发送RDC任务分派请求时，以下信息描述了特定DS的示例原始数据收集任务(换句话说，对特定LFN的RDC任务分派可以包括多个DS的数据收集任务列表)：
任务ID。这是此任务的特定任务ID。当RDC在第一数据处理阶段将原始数据发送到RDP时，需要指示该原始数据与哪个任务有关(并且可以进一步指示该任务与哪个DSCR和哪个DE有关)；
DS的ID(例如，URL)；
数据收集计划表(例如，何时从该DS收集数据)。该计划表可以与DSCR-1的RDS_Production_Schedule参数对准；和
RDP的ID。这指示应该将DS的原始数据发送到何处。换句话说，RDC可以从DS收集原始数据，并将原始数据发送到RDP，如该参数所指示的。
某些LFN可能无法按照DSCS代理-1的要求接受任务分派。因此，在此步骤中可以会有多个协商处理。
在步骤6，DSCS代理-1选择LFN-1作为与DSCR-1相关的特定DE的RDC，并且LFN-1上的DSCS代理-2确认RDC分派。
在步骤7，对于每个选定的LFN(作为RDP)(如在步骤4中所确定的)，DSCS代理-1可以联系那些LFN以分派数据处理任务。例如，DSCS代理-1可以向特定的LFN-2发送RDP任务分派请求，该请求也可以包括分派给LFN-2的多个任务。例如，给定的LFN可以在特定DE的不同数据处理阶段中用作RDP。更一般而言，给定的LFN可以用作RDP，以为不同的DE进行数据处理。例如，LFN-2可以用作DE-1的RDP，在此期间LFN-2进行DE-1的数据处理阶段1所要求的数据处理。LFN-2还可以用作DE-2的RDP，在此期间LFN-2进行DE-2的数据处理阶段2所要求的数据处理。为了描述LFN(例如，LFN-2)需要对每个涉及的任务做什么，可以包括如下信息：
任务ID：这是此任务的特定任务ID。当上游数据发送方将处理后的数据发送到下游数据接收方时，需要指示该处理后的数据用于哪个任务。
上游数据发送方的ID和相关的任务ID：这是指示谁将已处理的数据发送到LFN-2进行处理。从上游发送方发送的数据还可以与另一个任务ID(这是上游数据发送方完成的任务的ID)相关联。例如，如果LFN-2是DE-1的第一数据处理阶段的RDP，则DE-1的RDC可以是上游数据发送方(其将从DE-1的期望DS中收集原始数据并发送给LFN-2进行处理)。在另一个示例中，如果LFN-2是DE-1的第二数据处理阶段的选定RDP，则LFN-2的上游数据发送方可以是DE-1的第一数据处理阶段的RDP(其发送已处理的RDP到LFN-2以进行第二阶段的处理)。值得注意的是，用作RDP的LFN也可以承担RDC的角色。例如，可以选择LFN-2作为RDC，以收集特定DE-1的原始数据。LFN-2也可以具有数据处理能力，并且也被选作DE-1的第一数据处理阶段的RDP。在这种情况下，LFN-2充当用作RDC和RDP两者的组合角色。
Required_Data_Processing_Operation：这指示要进行哪些特定的数据处理操作。如果需要下载定制代码，则此参数还指示到何处下载数据处理代码。
下游数据接收方的ID：这表示LFN-2完成此特定任务的处理后，将处理的数据发送到何处。例如，如果LFN-2是DE-1的第一数据处理阶段的选定RDP，则DE-1的第二数据处理阶段的RDP可以是下游数据接收方(其基于据LFN-2处理的数据进行进一步的数据处理操作)。当LFN-2将其处理后的数据发送到其下游数据接收方时，可能还需要将处理后的数据与任务ID相关联，该任务ID是LFN-2本身完成的任务的ID(例如，如任务ID中所定义的)。
还有可能某些LFN无法接受DSCS代理-1要求的任务分派。因此，在此过程中可能会有多个协商步骤。
另外，对于给定的LFN，如果将其选择为RDC以及用于服务给定DSCR的RDP，则DCCS代理-1可以仅向该LFN发送一个消息以进行RDC和RDP任务分派。在这种情况下，步骤5和步骤7可以组合。
在步骤8，LFN-2上的DSCS代理-3确认RDP分派。
最后，DSCS代理-1可以为DSCR-1创建作业分派配置文件，该配置文件可以包括关于以下的所有细节：哪些LFN被选择为每个DE的RDC或哪些LFN被选择为RDP以进行制作DSCR-1的RDS所要求的数据处理操作。
本文公开了用于合作式RDS制作和交付的方法和***。在下面的示例中，公开了一种用于在LFA中开始RDS制作处理的过程。
对于给定的DSCR，在完成DS识别和RDC/RDP分派之后，可能没有必要立即开始为此DSCR制作RDS。换句话说，RDS制作可以在稍后的时间(例如，基于触发)或基于特定的计划表(例如，如图21的步骤1中包括的“RDS_Production_Schedule”参数中指示的信息)开始。通常，RDS制作激活可以由用户发起(例如，RDS制作触发可以从CN发送到LFA)。对于给定的DSCR，LFNL需要为此DSCR的RDS的每个DE确定哪些DS是期望的DS或选定的DS。附加地或备选地，LFNL可能需要为每个期望的DS确定哪个LFN是选定的RDC，和/或为每个DE确定哪些LFN是用于处理从该DE的期望DS收集的数据的选定RDP(所有这些任务分派可以已在合作式DS识别处理的阶段1和阶段2决定)。然后，LFNL可以将触发以及有关现在需要执行哪些特定任务的指南发送到每个涉及的LFN。
在一个示例中，数据样本收集服务可以被配置为执行包括以下的操作：接收包括发起与特定数据样本收集请求相关联的数据样本的制作的指示的触发；确定被配置为执行原始数据收集的至少一个本地雾节点和被配置为执行原始数据处理的至少一个本地雾节点；向被配置为执行原始数据收集的至少一个本地雾节点发送发起原始数据收集的指示；从被配置为执行原始数据收集的至少一个本地雾节点接收指明已经发起原始数据收集的指示；向被配置为执行原始数据处理的至少一个本地雾节点发送发起原始数据处理的指示；和从被配置为执行原始数据处理的至少一个本地雾节点接收指明已经发起原始数据处理的指示。
发起原始数据收集的指示和发起原始数据处理的指示中的每一个可以包括任务标识符。可以从云节点接收触发。确定被配置为执行原始数据收集的至少一个本地雾节点和被配置为执行原始数据处理的至少一个本地雾节点包括访问存储在数据样本收集服务处的作业分派配置文件。可以在同一本地雾节点中实现被配置为执行原始数据收集的至少一个本地雾节点和被配置为执行原始数据处理的至少一个本地雾节点。数据样本收集服务可以在本地雾节点引领者中实现。
在另一示例中，本地雾节点可以被配置为执行以下操作，包括：从数据样本收集服务接收执行原始数据收集和原始数据处理操作中的至少一项的请求，其中，数据样本收集服务在本地雾节点引领者中实现；发起原始数据收集和原始数据处理操作中的至少一项；向所述数据样本收集服务发送指明已经发起了所述原始数据收集和原始数据处理操作中的至少一项的指示。
执行原始数据收集和原始数据处理操作中的至少一项的请求可以包括任务标识符。接收执行原始数据收集和原始数据处理操作中的至少一项的请求可以包括：接收执行原始数据收集的第一请求，第一请求包括第一任务标识符；以及接收执行原始数据处理的第二请求，第二请求包括第二任务标识符。执行原始数据收集和原始数据处理操作中的至少一项的请求可以基于存储在数据样本收集服务处的工作分派配置文件。可以基于数据收集操作的至少部分的完成自动地执行数据处理操作。执行原始数据收集和原始数据处理操作中的至少一个的请求可以基于存储在数据样本收集服务处的计划表。
在图22中示出了用于触发LFA中的RDS制作的示例过程，如下所述：
在步骤1，DSCS代理-1接收触发以发起DSCR-1的RDS制作。例如，发起DSCR-1的用户可以通过向CN发送触发请求来直接激活此DSCR-1。CN可以进一步将该触发请求转发给LFA-1中的LFNL。
在步骤2，DSCS代理-1找出涉及哪些LFN作为DSCR-1的RDC/RDP。特别地，DSCS代理-1可以检查DSCR-1的作业分派配置文件(在图21中所示的过程结束时创建)，其包括有关在RDC/RDP任务分派期间哪些LFN被选择为RDC或RDP的所有细节。
在步骤3，DSCS代理-1与所涉及的LFN(被选择为服务于DSCR-1的RDC)联系，以便从期望的DS开始数据收集。对于DSCR-1的对应RDS的每个DE，DSCS代理-1可以检查哪些DS是每个DE的期望DS。DSCS代理-1可以附加地或备选地基于DSCR-1的作业分派配置文件中包括的信息，检查哪个LFN已被分配为每个DS的RDC。注意，给定的LFN可以是多个DS的RDC。因此，当DSCS代理-1将激活触发发送到特定的LFN(作为RDC)时，该激活触发中也可以包括所有涉及的任务ID、可以开始被分派给该LFN的与DSCR-1相关的所有数据收集任务。
在步骤4，RDC(例如LFN-1)确认开始数据收集。对于给定的LFN(例如LFN-1)，RDC可以根据步骤3中指示的任务列表开始原始数据收集活动。
在步骤5，DSCS代理-1与所涉及的LFN(被选择为服务于DSCR-1的RDP)联系，以开始在RDC/RDP任务分派期间配置的数据处理任务(如在图21所示的过程结束时创建的作业分派配置文件中所述的)。DSCS代理-1可以根据DSCR-1的作业分派配置文件中包括的信息，检查哪些LFN是DSCR-1的每个DE的分派RDP。注意，对于给定的DE，在该DE的多个数据处理阶段中，特定的LFN可以是RDP。特定的LFN可以是用于不同DE的RDP。因此，当DSCS代理-1向特定的LFN(作为RDP)发送激活触发时，该激活触发中还包括所有涉及的任务ID、可以开始被分派给该LFN的与DSCR-1相关的所有数据处理任务。
在步骤6，RDP(例如LFN-2)确认服务于DSCR-1的数据处理已经开始(例如，准备接收来自RDC的数据以进行处理)。对于给定的LFN(例如LFN-2)，RDP可以根据步骤5中所指示的任务列表开始数据处理活动。作为备选，可以在步骤3和/或步骤4之前执行步骤5和步骤6。
注意，作为备选方案，在仅需要将触发发送到RDC的意义上，可以不需要步骤5和/或步骤6。原因是RDC可以从DS收集数据并知道将数据发送到哪里进行处理。因此，当第一次接收到从RDC发送的数据时，可以触发RDP。例如，当RDC正在将第一批数据发送到RDP时，RDC可以包括任务ID，以便RDP可以开始其相应的任务来处理接收到的数据。
如果DSCR-1的RDS制作基于如在图21的步骤1中包括的“RDS_Production_Schedule”参数中所指示的某个计划表，则已经被选择为用于服务于DSCR-1的RDC或RDP的一个或多个所涉及的LFN可以通过遵循工作计划表而自动开始工作。
一旦针对给定DSCR的RDS制作开始，所涉及的RDC/RDP可以开始工作。在图23中示出了用于特定DE的实际RDS制作的示例过程并在下面描述。该过程以智慧城市分析用例为例，其中单个RDS中的DE-1是每三分钟的平均温度。特别地，已经将100个温度传感器识别为DE-1的期望DS。
在步骤1，假定根据RDC任务分派，LFN-2(作为RDC)上的DSCS代理-3负责从DS-1到DS-50收集原始数据。DSCS代理-3可定期访问DS-1和DS-50，以查看是否有新数据正在生成。附加地或备选地，代替通过进行取回操作从期望的DS收集原始数据，RDC可以对期望的DS进行订阅，以使那些DS可以通过通知而将其新数据发送到RDC。
在步骤2，假定根据RDC任务分派，LFN-1(作为RDC)上的DSCS代理-2负责从DS-51到DS-100收集原始数据。
在步骤3，DSCS代理-3将原始数据(从DS-1到DS-50收集)发送到LFN-3，后者用作DE-1的第一数据处理阶段的RDP。特别是，当DSCS代理-3将第一批数据发送到LFN-3时可以包括任务ID，以便LFN-3知道如何处理接收到的数据。
在步骤4，类似于LFN-2上的DSCS代理-3，DSCS代理-2将原始数据(从DS-51到DS-100收集)发送到LFN-3，LFN-3用作DE-1的第一数据处理阶段的RDP。
在步骤5，LFN-3上的DSCS代理-4在DE-1的第一数据处理阶段处理原始数据。例如，在第一阶段的主要数据处理操作是对由原始温度读数组成的整体进行的。RDP将从初始的原始数据中提取数据读数和其他有用的上下文信息(例如时间戳)。如果DE-1要求最终形式的数据以摄氏度为单位，则如果原始数据最初以华氏度为单位，则可以进行单位转换。
在步骤6，一旦LFN-3上的DSCS代理-4完成第一数据处理阶段的数据处理，就可以将处理后的数据发送给LFN-4，该LFN-4用作DE-1的第二数据处理阶段的RDP。同样，当LFN-3上的DSCS代理-4将其处理后的数据发送到LFN-4时可以包括任务ID，以便LFN-4知道如何处理接收到的数据。
在步骤7，LFN-4上的DSCS代理-5在第二数据处理阶段处理数据，并制作DE-1的数据，该数据可以是最终形式。DE-1的数据是特定三分钟时间间隔内的平均温度值，这是DE-1的最终形式。因此，LFN-4的输出可以是每三分钟LFA-1的平均温度值，该温度值是根据在第一数据处理阶段从两个RDP(例如，从LFN-2和LFN-3)发送的已处理数据计算的。之后，LFN-4上的DSCS代理-5可以将处理后的数据发送到DSCR-1的相应RDS-组装RDP，后者是为DSCR-1生成最终RDS的最后RDP。对于LFN(用作RDC或RDP)，它可以与多个对等LFN(分别是辅助RDC或RDP)相关联。因此，如果初始选择的RDC或RDP不能进行期待的要求任务(例如工作过载或停止工作)，工作负载可以卸载给相应的辅助RDC或RDP。
RDC/RDP可以仅仅是“逻辑”实体。特别地，在图23所示的示例中，为便于说明，不同的LFN可以扮演不同的角色(这不应限制所提出想法的普遍性)。可以理解的是，LFN在第一数据处理阶段的数据处理中既可以作为RDC又可以作为RDP。例如，DSCS代理-3可以同时用作RDC和第一阶段RDP。作为不同的示例配置，假设现在DSCS代理-3可以从所有100个DS收集数据，然后可以从这100个DS收集数据，直接对原始数据进行取平均值运算，然后将处理后的数据发送到DSCS代理-5(这是第二阶段RDP)以进行进一步处理。
一旦针对给定的DE完全处理了数据，则其可以是其最终形式，并且可以准备好被组装。在图24中示出了用于给定DSCR的RDS组装的示例过程并将在下面进一步讨论。图24的过程以智慧城市分析用例为例，其中单个RDS中的DE-1是给定LFA-1的每三分钟的平均温度，单个RDS中的DE-2是同一给定LFA-1的每三分钟的平均湿度。相应地，图24中的步骤7的输出是最终形式的DE-1。
在步骤1(从图24的步骤7继续)，LFN-4上的DSCS代理-5处理了第二数据处理阶段的数据，并制作了DE-1的最终形式数据。DSCS代理-5将处理后的数据发送到LFN-6进行组装。特别是，来自LFN-4上的DSCS代理-5的DE-1的每个输出数据都可以与某些上下文信息相关联，这些上下文信息可以在以后的RDS组装期间使用。对于在图23的步骤7期间制作的给定的DE-1数据，相关联的信息可以指示所计算的平均温度对应于特定的三分钟时间间隔。
在步骤2，假定LFN-5上的DSCS代理-6是DE-2的最后一个数据处理阶段中的RDP，其为DE-2制作了最终形式的数据。在此，DE-2是每三分钟的平均湿度。类似地，DE-2的每个最终形式数据也可以与某些上下文信息相关联，这些上下文信息可以在以后的RDS组装期间使用。DSCS代理-6可以将与DE-2相关联的处理后的数据发送到LFN-6，以进行最终的RDS组装。
在步骤3，LFN-6上的DSCS代理-7组装DE-1和DE-2的最终形式数据，并为DSCR-1制作RDS。如果一条DE-1数据和一条DE-2数据与同一特定的三分钟时间间隔相关联，则可以将它们组装在一起。结果，可以生成符合DSCR-1中描述的RDS定义的格式(DE-1，DE-2，context_information)的RDS。
在步骤4，将制作的RDS送达到指定的地址。通常，RDS交付(“送达”)可以具有以下选项：
选项1：RDS-组装RDP可以将RDS数据样本逐一发送给DSCR-1的用户；
选项2：RDS-组装RDP可以批量发送RDS(例如，每100个RDS样本)；
选项3：RDS-组装RDP可以根据DSCR-1用户的要求在特定时间点发送RDS数据样本；和/或
选项4：RDS-组装RDP可以在本地存储RDS，并允许DSCR-1的用户拉回数据。
所提出的DSCS方案可以被视为oneM2M服务层中的新的CSF，如图15所示。应该理解，不同类型的M2M节点可以实现DSCS服务，例如IoT装置、M2M网关、M2M服务器、移动节点(例如车辆、手机等)等。特别地，取决于这些节点的各种/不同的硬件/软件容量，由这些节点实现的DSCS服务的容量也可以是变化的。
所定义的相关实体的oneM2M实施例如下：
数据源(DS)可以是oneM2M AE或CSE。因此，通过AE或CSE产生的原始数据可以存储在<容器>，<时间序列>或<弹性容器>资源中，这可以通过在DS识别处理期间的oneM2M资源发现而被识别；
本地雾节点(LFN)可以是oneM2M CSE(例如ASN-CSE)。
LFN引领者(LFNL)和雾节点(FN)可以是oneM2M CSE(诸如MN-CSE)；
云节点(CN)可以是oneM2M CSE(例如IN-CSE)；和
DSCS用户可以是oneM2M AE(例如，IN-AE)或CSE。
在图16中示出了称为<dscs>的新虚拟资源。如果CSE具有DSCS能力(例如，DSCS代理正在此CSE上运行)，则它可以具有<dscs>子资源。可以向该资源提出所有与DSCS相关的请求。例如，用户可以将DSCR创建请求发送到CSE-1上托管的<dscs>资源。同样，当CSE-1打算对DSCR-1进行DS识别时，它可以将DSCR-1发送到LFA中另一个CSE-2托管的<dscs>资源，该LFA用作LFNL并管理和协调该LFA中的LFN进行的所有DS识别和RDS制作活动。当CSE(作为LFN)向其他用作LFNL的CSE注册其能力时，<lfnCapability>资源可以在用作LFNL的CSE上创建。该资源可以描述有关给定LFN可以提供哪些能力的所有信息(例如，是否可以用作DSD、RDC和/或RDP)。此外，对于LFNL和LFN之间的所有通信(例如，当LFNL将RDC或RDP相关任务分派给LFN，或者LFNL向LFN发送触发以开始所分派的RDC或RDP相关任务时)，请求发起方(例如，用作LFNL的CSE)可以将其请求发送到接收方(例如，用作LFN的CSE，由LFNL管理)的<dscs>资源。
揭示DSCS的另一种方法是为<CSE>资源定义被称为“dscs_capability”的新属性，该属性可以指示此CSE是否具有DSCS能力。因此，所有与DSCS相关的请求都可以发送到<CSEBase>资源。
提出了新的<lfnCapability>资源来记录LFN的能力(例如，当LFN将其能力注册到相应的LFNL时，可以创建<lfnCapability>资源)。资源属性可以对应于表9中定义的参数。
通常，当LFN(例如CSE-1)将其能力注册到用作LFNL的另一个CSE-2时，可以在用作LFNL的CSE-2上创建<lfnCapability>资源。例如，<lfnCapability>资源可以用作CSE-2的<CSEBase>资源的子资源。附加地或备选地，<lfnCapability>资源可以用作充当LFN的CSE-1的<remoteCSE>资源的子资源。
还可以为用作LFN的CSE-1的<remoteCSE>资源定义称为“lfnCapability”的新属性，该属性可用于指示CSE-1的LFN能力。<lfnCapability>资源可以包含表10中指定的子资源。
表10、<lfnCapability>资源的子资源
<lfnCapability>资源可以包含表11中指定的属性。
表11、<lfnCapability>资源的属性
/>
/>
表12中所示的过程可用于创建<lfnCapability>资源。
表12、<lfnCapability>创建
/>
表13中所示的过程可用于取回<lfnCapability>资源的属性。
表13、<lfnCapability>取回
表14中所示的过程可以用于更新<lfnCapability>资源的属性。
表14、<lfnCapability>更新
表15中所示的过程可用于删除<lfnCapability>资源。
表15、<lfnCapability>删除
/>
在图25中示出了示例GUI界面，可用于人类用户监视DS识别和RDS制作处理。使用该界面的用户可以指定一些有关他们要检查的特定LFA的常规信息。在一个示例中，用户可以有两种使用该用户界面的方式：第一种，用户可以检查用作特定角色的LFN(例如RDC或RDP)。因此，可以显示所有用作所选角色的LFN，以供用户查看。第二种，用户可以直接输入特定LFN的ID。因此，该LFN的所有注册能力(例如，其RDC能力、DSD能力或RDP能力)可以显示给用户以供查看。
执行图1、4-14和18-24所示的步骤的任何实体，诸如服务层、服务层装置、服务层应用程序、应用实体等可以是可以以软件(即，计算机可执行指令)形式实现的逻辑实体。该软件存储在被配置用于无线和/或网络通信的装置或计算机***(例如，如图26C或图26D所示的)的存储器中并在其处理器上执行。即，在图1、4-14和18-24中示出的方法可以以存储在诸如图26C或图26D所示的装置或计算机***之类的装置的存储器中的软件(即，计算机可执行指令)的形式来实现，当该计算机可执行指令由装置的处理器执行时，执行图1、4-14和18-24中所示的步骤。还应理解，在图1、4-14和18-24中示出的任何发送和接收步骤都可以在装置的处理器及其执行的计算机可执行指令(例如，软件)的控制下，由装置/实体的通信电路来执行。
图26A是可以实现一个或多个所公开的实施例的示例性机器对机器(M2M)、物联网(IoT)或物网(WoT)通信***10的图。通常，M2M技术为IoT/WoT提供了构建块，任何M2M装置、M2M网关、M2M服务器或M2M服务平台都可以是IoT/WoT以及IoT/WoT服务层等的组件或装置。任何在图1-25中示出的实体可以包括通信***的网络装置，诸如图26A-26D所示出的。
服务层可以是网络服务体系架构内的功能层。服务层通常位于应用协议层(例如HTTP、CoAP或MQTT)之上，并为客户端应用程序提供增值服务。服务层还在较低资源层(例如控制层和传输/访问层)提供到核心网络的接口。服务层支持多种类别的(服务)能力或功能，包括服务定义、服务运行时的启用、策略管理、访问控制和服务群集。最近，一些行业标准主体(例如oneM2M)已经在开发M2M服务层，以解决与将M2M类型的装置和应用整合到诸如因特网/网(Web)、蜂窝、企业和家庭网络之类的部署中所关联的挑战。M2M服务层可以向应用和/或各种装置提供对由服务层支持的一组上述能力或功能的访问，这可以被称为CSE或SCL。一些示例包括但不限于安全、收费、数据管理、装置管理、发现、供应和连接性管理，这些能力或功能可由各种应用共同使用。通过使用由M2M服务层定义的消息格式、资源结构和资源表示形式的API，这些能力或功能对这样的各种应用可用。CSE或SCL是可以由硬件和/或软件实现的功能实体，并且提供可揭示给各种应用和/或装置(即，这些功能实体之间的功能接口)的(服务)能力或功能，以使它们能够使用这样的能力或功能。
如图26A所示，M2M/IoT/WoT通信***10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息、广播等的内容的多个接入网络。例如，通信网络12可以采用一种或多种信道接入方法，例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。此外，通信网络12可以包括其他网络，诸如核心网络、互联网、传感器网络、工业控制网络、个人局域网、融合个人网络、卫星网络、家庭网络或企业网络。
如图26A所示，M2M/IoT/WoT通信***10可以包括基础设施域和场域。基础设施域是指端到端M2M部署的网络侧，而场域是指通常在M2M网关后面的区域网络。场域和基础设施域都可以包括网络的各种不同的网络装置(例如，服务器、网关、装置等)。例如，场域可以包括M2M网关14和装置18。应当理解，根据期望，可以在M2M/IoT/WoT通信***10中包括任意数量的M2M网关装置14和M2M装置18。M2M网关装置14和M2M装置18中的每一个被配置为使用通信电路经由通信网络12或直接无线电链路来发送和接收信号。
M2M网关14允许无线M2M装置(例如，蜂窝和非蜂窝)以及固定网络M2M装置(例如，PLC)通过诸如通信网络12的运营商网络进行通信或直接无线电链路进行通信。例如，M2M装置18可以收集数据并且经由通信网络12或直接无线电链路将数据发送到M2M应用20或其他M2M装置18。M2M装置18还可以从M2M应用20或M2M装置18接收数据。此外，还可以通过M2M服务层22向/从M2M应用20发送/接收数据和信号，如下所述。M2M装置18和网关14可以经由各种网络进行通信，这些网络例如包括蜂窝、WLAN，WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。示例M2M装置包括但不限于平板电脑、智能手机、医疗装置、温度和天气监视器、联网的汽车、智能仪表、游戏机、个人数字助理、健康和健身监视器、灯、恒温器、器具、车库门以及其他基于执行器的装置、安全装置和智能插座。
参考26B，所示的场域中的M2M服务层22为M2M应用20、M2M网关14、以及M2M装置18和通信网络12提供服务。将理解的是，M2M服务层22根据期望可以与任何数量的M2M应用、M2M网关14、M2M装置18和通信网络12进行通信。M2M服务层22可以由网络的一个或多个网络装置来实现，该网络装置可以包括服务器、计算机、装置等。M2M服务层22提供应用于M2M装置18、M2M网关14和M2M应用20的服务能力。M2M服务层22的功能可以通过多种方式实现，例如，作为网络(web)服务器、在蜂窝核心网络中、在云中等。
类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12提供服务。M2M服务层22'还为场域中的M2M网关14和M2M装置18提供服务。将会理解，M2M服务层22'可以与任何数量的M2M应用、M2M网关和M2M装置进行通信。M2M服务层22'可以与不同服务提供者的服务层交互。M2M服务层22'可以由网络的一个或多个网络装置来实现，该网络装置可以包括服务器、计算机、装置、虚拟机(例如，云计算/存储场等)等。
参考图26B，M2M服务层22和22'提供了各种应用和垂直行业都可以利用的一组核心的服务交付能力。这些服务能力使M2M应用20和20'能够与装置交互并执行诸如数据收集、数据分析、装置管理、安全性、计费、服务/装置发现等功能。实质上，这些服务能力使应用免于负担实现这些功能的过程，从而简化了应用开发并减少了成本和上市时间。服务层22和22'还使M2M应用20和20'能够通过诸如网络12之类的各种网络与服务层22和22'提供的服务进行通信。
M2M应用20和20'可以包括各种行业中的应用，例如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全和监视。如上所述，跨装置、网关、服务器和该***的其他网络装置而运行的M2M服务层支持例如数据收集、装置管理、安全性、计费、位置跟踪/地理防护、装置/服务发现和遗留***整合的功能，并将这些功能作为服务提供给M2M应用20和20'。
通常，服务层(诸如，图26B中所示的服务层22和22')定义了软件中间件层，该软件中间件层通过一组应用编程接口(API)和底层网络接口来支持增值服务能力。ETSI M2M和oneM2M体系架构都定义了服务层。ETSI M2M的服务层称为服务能力层(SCL)。可以在ETSIM2M体系架构的各种不同节点中实现SCL。例如，服务层的实例可以在M2M装置(在此称为装置SCL(DSCL))、网关(在此称为网关SCL(GSCL))和/或网络节点(在此称为网络SCL(NSCL))内实现。oneM2M服务层支持一组公共服务功能(CSF)(即服务能力)。一组一个或多个特定类型的CSF的实例被称为公共服务实体(CSE)，可以在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上托管。第三代合作伙伴计划(3GPP)还定义了一种用于机器类型通信(MTC)的体系架构。在该体系架构中，服务层及其提供的服务能力被实现为服务能力服务器(SCS)的一部分。无论是体现在ETSI M2M体系架构的DSCL、GSCL或NSCL中、体现在3GPP MTC体系架构的服务能力服务器(SCS)中、体现在oneM2M体系架构的CSF或CSE中、还是体现在网络的其他某个节点中，服务层的实例可被实现为在网络中的一个或多个独立节点(包括服务器、计算机和其他计算装置或节点)上执行的逻辑实体(例如，软件、计算机可执行指令等)，或作为一个或多个现有节点的一部分。作为示例，服务层或其组件的实例可以以运行在具有如下述的图26C或26D所示的一般体系架构的网络设备(例如，服务器、计算机、网关、装置等)上的软件的形式来实现。
此外，本文描述的方法和功能可以被实现为使用面向服务的体系架构(SOA)和/或面向资源的体系架构(ROA)来访问服务的M2M网络的一部分。
从部署的角度来看，服务层可以部署在各种类型的网络节点上，包括本文中各个附图所示的服务器、网关和装置。实现服务层功能或以其他方式并入服务层的实例的通信网络的任何此类节点、服务器、网关、装置、设备或其他逻辑实体在本文中可被称为服务层实体。
图26C是诸如图1-25所示的实体之一的网络的设备的示例硬件/软件体系架构，其可以用作M2M网络中的M2M服务器、网关、装置或其他网络设备，例如图26A和26B所示。如图26D所示，网络设备30可包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、键盘40、显示器、触摸板和/或指示器42、电源48、全球定位***(GPS)芯片组50和其他***设备52。网络设备30还可以包括通信电路，例如收发器34和发送/接收元件36。将理解的是，网络设备30可以包括前述元件的任何子组合，同时保持与实施例一致。该网络设备可以是实现诸如关于图1-25示出和描述的方法和操作的用于启动基于雾的数据保护的数据样本模板(DST)管理方法的设备。
处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器，与DSP内核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其他类型的集成电路(IC)、状态机等。通常，处理器32可以执行存储在网络设备的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令，以便执行网络设备的各种所要求的功能。例如，处理器32可执行信号编码、数据处理、功率控制、输入/输出处理和/或使网络设备30能够在无线或有线环境中操作的任何其他功能。处理器32可以运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其他通信程序。处理器32还可以例如在接入层和/或应用层执行诸如认证、安全密钥协议和/或加密操作之类的安全操作。
如图26C所示，处理器32耦接到其通信电路(例如，收发器34和发送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路，以使网络设备30经由其所连接的网络与其他网络设备进行通信。特别地，处理器32可以控制通信电路以便执行本文中(例如，在图1-25中)和权利要求中描述的发送和接收步骤。尽管图26C将处理器32和收发器34描绘为单独的组件，但是应当理解，处理器32和收发器34可以一起集成在电子封装或芯片中。
发送/接收元件36可以被配置为向包括M2M服务器、网关、装置等的其他网络设备发送信号或从其接收信号。例如，在一实施例中，发送/接收元件36可以是被配置为发射和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝网络等。在一实施例中，发送/接收元件36可以是被配置为例如发射和/或接收IR、UV或可见光信号的发射器/检测器。在又一实施例中，发送/接收元件36可以被配置为发射和接收RF和光信号两者。将理解的是，发送/接收元件36可以被配置为发射和/或接收无线或有线信号的任何组合。
另外，尽管在图26C中示出了发送/接收元件36为单个元件，但是网络设备30可以包括任何数量的发送/接收元件36。更具体地，网络设备30可以采用MIMO技术。因此，在一实施例中，网络设备30可以包括两个或更多个用于发送和接收无线信号的发送/接收元件36(例如，多个天线)。
收发器34可以被配置为调制将由发送/接收元件36发送的信号，并且对由发送/接收元件36接收的信号进行解调。如上所述，网络设备30可以具有多模式功能。因此，收发器34可以包括多个收发器，用于使网络设备30能够经由诸如UTRA和IEEE802.11的多个RAT进行通信。
处理器32可以访问来自诸如不可移除存储器44和/或可移除存储器46之类的任何类型的合适存储器的信息并将数据存储在其中，例如，处理器32可以在其存储器中存储上述的会话上下文。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其他类型的存储器存储装置。可移除存储器46可以包括订户身份模块(SIM)卡、存储棒、安全数字(SD)存储卡等。在其他实施例中，处理器32可以访问来自在物理上不位于网络设备30(例如服务器或家用计算机)上的存储器的信息并将数据存储在其中。处理器32可以被配置为控制显示器或指示器42上的照明图案、图像或颜色以反映设备的状态或配置设备，尤其是与网络装置通信的底层网络、应用或其他服务。在一个实施例中，显示器/指示器42可以呈现图26D所示并在此描述的图形用户界面。
处理器32可以从电源48接收电力，并且可以被配置为向网络设备30中的其他组件分发和/或控制电力。电源48可以是用于为网络设备30供电的任何合适的装置。例如，电源48可以包括一个或多个干电池(例如，镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。
处理器32还可耦接到GPS芯片组50，其被配置为提供关于网络设备30的当前位置的位置信息(例如，经度和纬度)。将理解，网络设备30可以通过任何合适的位置确定方法获取位置信息，同时保持与实施例一致。
处理器32可以进一步耦接到其他***设备52，其他***设备52可以包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，***设备52可以包括各种传感器，例如加速度计、生物识别(例如指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其他互连接口、振动装置、电视收发器、免提耳机、蓝牙模块，调频(FM)广播单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等。
网络设备30可以体现在其他设备或装置中，例如传感器、消费电子产品、可穿戴装置(例如智能手表或智能服装)、医疗或电子保健装置、机器人、工业装备、无人驾驶飞机、车辆(例如汽车、卡车、火车或飞机等)。网络设备30可以经由一个或多个互连接口(诸如可以包括***设备52之一的互连接口)连接到这样的设备或装置的其他组件、模块或***。
图26C是示例计算***90的框图，该示例计算***90还可以用于实现网络的一个或多个网络设备(诸如图1-25所示的实体)，其可以操作为诸如图26A和26B所示的M2M网络中的M2M服务器、网关、装置或其他网络设备。
计算***90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，该指令可以是软件形式(无论何时何地或通过任何方式存储或访问这种软件)。这样的计算机可读指令可以在诸如中央处理单元(CPU)91的处理器内执行，以使计算***90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其他机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加机能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于E2E M2M服务层会话的***和方法有关的数据，例如接收会话证书或基于会话证书进行认证。
在操作中，CPU 91经由计算机的主数据传输路径即***总线80来获取、解码和执行指令，并与其他资源之间来回传输信息。这种***总线连接计算***90中的组件并定义数据交换的媒介。***总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断和用于操作***总线的控制线。这样的***总线80的一个示例是PCI(***组件互连)总线。
耦接到***总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。此类存储器包括允许信息被存储和取回的电路。ROM 93通常包含不容易被修改的存储数据。RAM 91中存储的数据可由CPU 91或其他硬件装置读取或改变。可以由存储器控制器92控制对RAM 82和/或ROM 93的访问。存储器控制器92可以提供地址转换机能以在执行指令时将虚拟地址转换为物理地址。存储器控制器92还可以提供存储器保护机能以将***内的进程隔离并且将***进程与用户进程隔离。因此，以第一模式运行的程序只能访问由其自己的进程虚拟地址空间映射的存储器；除非已建立进程之间的内存共享，否则该程序无法访问另一个进程的虚拟地址空间内的存储器。
另外，计算***90可以包含***设备控制器83，其负责将指令从CPU 91传递到***设备，例如打印机94、键盘84、鼠标95和磁盘驱动器85。
由显示器控制器96控制的显示器86用于显示由计算***90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示器控制器96包括生成视频信号所要求的电子组件，该视频信号被发送到显示器86。显示器86与由CPU91执行的计算机可执行指令结合，可以生成和操作图26D中示出及其随附的说明中描述的图形用户界面。
此外，计算***90可以包含通信电路，例如网络适配器97，其可以用于将计算***90连接到外部通信网络，例如图26A-26D的网络12，以使计算***90能够与网络的其他设备通信。单独的或与CPU 91组合的通信电路可用于执行本文(例如，图1-25中)和权利要求中所述的发送和接收步骤。
应理解，本文描述的任何或所有***、方法和处理可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式来体现，该指令在由机器(诸如M2M网络的设备，例如包括M2M服务器、网关、装置等)执行时，实行和/或实现本文描述的***、方法和处理。具体地，可以以这样的计算机可执行指令的形式来实现上述任何步骤、操作或机能。计算机可读存储介质包括以用于存储信息的任何非暂时性(即，有形的或物理的)方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这样的计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储技术、CD-ROM、数字多功能磁盘(DVD)或其他光盘存储、磁带盒、磁带、磁盘存储或其他磁存储装置，或可用于存储所期望信息并可由计算机访问的任何其他有形或物理介质。
以下是可以在以上说明中出现的与服务层技术有关的首字母缩写词的列表。除非另有说明，否则本文中使用的首字母缩写词是指下面列出的相应术语：
/>
以下是可能在以上说明中出现的与服务层技术有关的术语和定义的列表。除非另有说明，否则本文使用的术语和定义是指下面列出的相应术语：
/>
/>
/>
本书面说明使用包括最佳模式的示例来公开本发明，并且还使本领域的任何技术人员能够实践本发明，包括制造和使用任何装置或***以及执行任何结合的方法。本发明的专利范围由权利要求书限定，并且可以包括本领域技术人员想到的其他示例。如果这样的其他示例具有与权利要求的字面语言无区别的元素，或者如果包括与权利要求的字面语言无实质性差异的等效要素，则这样的其他示例也在权利要求的范围内。
Claims (15)
1.一种在数据样本收集服务的第一代理处执行的方法，所述方法包括：
接收用以创建数据样本模板的请求，所述用以创建数据样本模板的请求包括与一个或多个数据元素相关联的信息，其中所述用以创建数据样本模板的请求包括对要创建的数据样本的类型的指示和与所述数据样本的类型相关联的所述数据样本收集服务的第二代理的指示，其中第二代理位于本地雾节点上；
基于与所述一个或多个数据元素相关联的信息，创建所述数据样本模板，所述数据样本模板包括对要创建的数据样本的类型的指示和位于本地雾节点上的第二代理的指示；
向所述本地雾节点上的第二代理发送所述数据样本模板用以识别与所述一个或多个数据元素相关联的一个或多个数据源；和
基于所述数据样本模板从所述本地雾节点上的第二代理接收与所述一个或多个数据源相关联的数据样本。
2.根据权利要求1所述的方法，其中，所述本地雾节点上的第二代理被配置为基于所配置的数据样本模板生成即用型的数据样本。
3.根据权利要求1所述的方法，其中，所述用以创建数据样本模板的请求还包括对一个或多个参数的指示，所述一个或多个参数包括：
与所述数据样本相关联的目标区域；
与所述数据样本相关联的频率；
与所述数据样本相关联的制作计划表；和
与所述数据样本相关联的上下文。
4.根据权利要求3所述的方法，还包括基于所述一个或多个参数确定将多个本地雾节点中的哪个本地雾节点作为目标。
5.根据权利要求1所述的方法，其中，与所述一个或多个数据元素相关联的信息包括以下中的一项或多项：
所述数据元素的原始数据类型；
所述数据元素的单位；
所述数据元素的数据处理操作；
所述数据元素的一个或多个定制处理细节；和
所述数据元素的一项或多项质量要求。
6.一种用于实现数据样本收集服务的第一代理的设备，所述设备包括处理器和存储器，所述存储器存储计算机可执行指令，所述计算机可执行指令在由所述处理器执行时使所述设备执行包括以下的操作：
接收用以创建数据样本模板的请求，所述用以创建数据样本模板的请求包括与一个或多个数据元素相关联的信息，其中所述用以创建数据样本模板的请求包括对要创建的数据样本的类型的指示和与所述数据样本的类型相关联的所述数据样本收集服务的第二代理的指示，其中第二代理位于本地雾节点上；
基于与所述一个或多个数据元素相关联的信息，创建所述数据样本模板，所述数据样本模板包括对要创建的数据样本的类型的指示和位于本地雾节点上的第二代理的指示；
向所述本地雾节点上的第二代理发送所述数据样本模板用以识别与所述一个或多个数据元素相关联的一个或多个数据源；和
基于所述数据样本模板从所述本地雾节点上的第二代理接收与所述一个或多个数据源相关联的数据样本。
7.根据权利要求6所述的设备，其中，所述本地雾节点上的第二代理被配置为基于所配置的数据样本模板生成即用型的数据样本。
8.根据权利要求6所述的设备，其中，所述用以创建数据样本模板的请求还包括对一个或多个参数的指示，所述一个或多个参数包括：
与所述数据样本相关联的目标区域；
与所述数据样本相关联的频率；
与所述数据样本相关联的制作计划表；和
与所述数据样本关联的上下文。
9.根据权利要求8所述的设备，其中，所述指令在被执行时还使所述数据样本收集服务的所述第一代理执行的操作包括基于所述一个或多个参数来确定将多个本地雾节点中的哪个本地雾节点作为目标。
10.根据权利要求6所述的设备，其中，与所述一个或多个数据元素相关联的信息包括以下中的一项或多项：
所述数据元素的原始数据类型；
所述数据元素的单位；
所述数据元素的数据处理操作；
所述数据元素的一个或多个定制处理细节；和
所述数据元素的一项或多项质量要求。
11.一种计算机可读存储介质，其存储有指令，所述指令在由处理器执行时使数据样本收集服务的第一代理执行包括以下的操作：
接收用以创建数据样本模板的请求，所述用以创建数据样本模板的请求包括与一个或多个数据元素相关联的信息，其中所述用以创建数据样本模板的请求包括对要创建的数据样本的类型的指示和与所述数据样本的类型相关联的所述数据样本收集服务的第二代理的指示，其中第二代理位于本地雾节点上；
基于与所述一个或多个数据元素相关联的信息，创建所述数据样本模板，所述数据样本模板包括对要创建的数据样本的类型的指示和位于本地雾节点上的第二代理的指示；
向所述本地雾节点上的第二代理发送所述数据样本模板用以识别与所述一个或多个数据元素相关联的一个或多个数据源；
基于所述数据样本模板从所述本地雾节点上的第二代理接收与所述一个或多个数据源相关联的数据样本。
12.根据权利要求11所述的计算机可读存储介质，其中，所述本地雾节点上的第二代理被配置为基于所配置的数据样本模板生成即用型的数据样本。
13.根据权利要求11所述的计算机可读存储介质，其中，所述用以创建数据样本模板的请求还包括对一个或多个参数的指示，所述一个或多个参数包括：
与所述数据样本相关联的目标区域；
与所述数据样本相关联的频率；
与所述数据样本相关联的制作计划表；和
与所述数据样本相关联的上下文。
14.根据权利要求13所述的计算机可读存储介质，其中，所述指令在被执行时还使所述数据样本收集服务的所述第一代理执行的操作包括基于所述一个或多个参数来确定将多个本地雾节点中的哪个本地雾节点作为目标。
15.根据权利要求11所述的计算机可读存储介质，其中，与所述一个或多个数据元素相关联的信息包括以下中的一项或多项：
所述数据元素的原始数据类型；
所述数据元素的单位；
所述数据元素的数据处理操作；
所述数据元素的一个或多个定制处理细节；和
所述数据元素的一项或多项质量要求。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862723219P | 2018-08-27 | 2018-08-27 | |
| US62/723,219 | 2018-08-27 | ||
| US201862754872P | 2018-11-02 | 2018-11-02 | |
| US62/754,872 | 2018-11-02 | ||
| PCT/US2019/047442 WO2020046667A1 (en) | 2018-08-27 | 2019-08-21 | Data sample template (dst) management for enabling fog-based data processing |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112236979A CN112236979A (zh) | 2021-01-15 |
| CN112236979B true CN112236979B (zh) | 2023-10-13 |
Family
ID=67847791
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980037993.0A Active CN112236979B (zh) | 2018-08-27 | 2019-08-21 | 用于启用基于雾的数据处理的数据样本模板(dst)管理 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20210336862A1 (zh) |
| EP (1) | EP3804232A1 (zh) |
| JP (1) | JP7458377B2 (zh) |
| KR (1) | KR20210049812A (zh) |
| CN (1) | CN112236979B (zh) |
| WO (1) | WO2020046667A1 (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11902385B2 (en) * | 2021-02-25 | 2024-02-13 | Insight Direct Usa, Inc. | IoT device reading transformations |
| CN113873024B (zh) * | 2021-09-23 | 2022-09-23 | 中国科学院上海微***与信息技术研究所 | 一种边缘雾网络中数据差分化下载方法 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7428699B1 (en) * | 2003-01-15 | 2008-09-23 | Adobe Systems Incorporated | Configurable representation of structured data |
| CN104950837A (zh) * | 2014-03-26 | 2015-09-30 | 洛克威尔自动控制技术股份有限公司 | 云清单配置管理*** |
| WO2017189527A1 (en) * | 2016-04-25 | 2017-11-02 | Convida Wireless, Llc | Methods for enabling data analytics service at service layer |
| CN108353034A (zh) * | 2016-01-11 | 2018-07-31 | 环球互连及数据中心公司 | 用于数据中心基础设施监测的架构 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4606543B2 (ja) * | 2000-04-13 | 2011-01-05 | パナソニック株式会社 | 光学特性計測装置における被検溶液量確認方法および計測系制御方法 |
| CN103986743A (zh) * | 2013-02-07 | 2014-08-13 | 伊姆西公司 | 用于在物联网中采集数据的方法、装置和*** |
| US10380105B2 (en) | 2013-06-06 | 2019-08-13 | International Business Machines Corporation | QA based on context aware, real-time information from mobile devices |
| US10319469B2 (en) * | 2014-04-22 | 2019-06-11 | Cerner Innovation, Inc. | Rule-based low-latency delivery of healthcare data |
| US10362113B2 (en) * | 2015-07-02 | 2019-07-23 | Prasenjit Bhadra | Cognitive intelligence platform for distributed M2M/ IoT systems |
| US10007513B2 (en) * | 2015-08-27 | 2018-06-26 | FogHorn Systems, Inc. | Edge intelligence platform, and internet of things sensor streams system |
| KR102471665B1 (ko) * | 2015-08-27 | 2022-11-25 | 포그혼 시스템스 인코포레이티드 | 에지 인텔리전스 플랫폼 및 사물 인터넷 센서 스트림 시스템 |
| JP2018010421A (ja) | 2016-07-12 | 2018-01-18 | 株式会社日立製作所 | 計算機システム、計算機及びデータフィルタリング方法 |
| KR102304309B1 (ko) * | 2017-02-02 | 2021-09-23 | 삼성전자주식회사 | 전자 장치에게 센싱 데이터를 제공하는 시스템 및 방법 |
| US10317888B2 (en) | 2017-03-01 | 2019-06-11 | PLETHORA IloT, S.L. | Device and system including multiple devices for supervision and control of machines in industrial installation |
| CN110474790B (zh) * | 2018-05-11 | 2022-11-01 | 西门子股份公司 | 对边缘设备进行配置的***、云平台、设备和方法 |
-
2019
- 2019-08-21 CN CN201980037993.0A patent/CN112236979B/zh active Active
- 2019-08-21 WO PCT/US2019/047442 patent/WO2020046667A1/en unknown
- 2019-08-21 JP JP2021510347A patent/JP7458377B2/ja active Active
- 2019-08-21 KR KR1020217005636A patent/KR20210049812A/ko unknown
- 2019-08-21 EP EP19762889.4A patent/EP3804232A1/en active Pending
- 2019-08-21 US US17/271,626 patent/US20210336862A1/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7428699B1 (en) * | 2003-01-15 | 2008-09-23 | Adobe Systems Incorporated | Configurable representation of structured data |
| CN104950837A (zh) * | 2014-03-26 | 2015-09-30 | 洛克威尔自动控制技术股份有限公司 | 云清单配置管理*** |
| CN108353034A (zh) * | 2016-01-11 | 2018-07-31 | 环球互连及数据中心公司 | 用于数据中心基础设施监测的架构 |
| WO2017189527A1 (en) * | 2016-04-25 | 2017-11-02 | Convida Wireless, Llc | Methods for enabling data analytics service at service layer |
Non-Patent Citations (1)
| Title |
|---|
| Mengsong Zou等.D3W: Towards self-management of distributed data-driven workflows with QoS guarantees.《2016 IEEE 9th International Conference on Cloud Computing》.2016,第148-155页. * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3804232A1 (en) | 2021-04-14 |
| JP7458377B2 (ja) | 2024-03-29 |
| KR20210049812A (ko) | 2021-05-06 |
| JP2021536606A (ja) | 2021-12-27 |
| WO2020046667A1 (en) | 2020-03-05 |
| CN112236979A (zh) | 2021-01-15 |
| US20210336862A1 (en) | 2021-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Hu et al. | A survey on mobile social networks: Applications, platforms, system architectures, and future research directions | |
| Botta et al. | Integration of cloud computing and internet of things: a survey | |
| Toczé et al. | A taxonomy for management and optimization of multiple resources in edge computing | |
| EP4020880A1 (en) | Method, apparatus and machine-readable storage to verify trained models in an edge environment | |
| Ghanbari et al. | Resource allocation mechanisms and approaches on the Internet of Things | |
| CN106797392B (zh) | M2m-iot服务的发布和发现 | |
| De | Mobile cloud computing: architectures, algorithms and applications | |
| Ahuja et al. | A survey on wireless grid computing | |
| KR102091069B1 (ko) | 향상된 RESTful 동작들 | |
| US20230208780A1 (en) | Enhanced real-time linking methods and systems | |
| JP6623312B2 (ja) | サービス層におけるデータ分析サービスを有効にする方法 | |
| CN104159294A (zh) | 一种基于蓝牙4.0技术的云定位平台 | |
| Al-Qamash et al. | Cloud, fog, and edge computing: A software engineering perspective | |
| JP2017533523A (ja) | マシンツーマシンシステムにおけるアプリケーション関係の管理 | |
| CN112236979B (zh) | 用于启用基于雾的数据处理的数据样本模板(dst)管理 | |
| CN112243579A (zh) | 通信网络中的服务层实体的自动化关系管理 | |
| US20200220919A1 (en) | Overlay resource trees in a communication network | |
| Kaur | A comprehensive survey on architecture for big data processing in mobile edge computing environments | |
| US20230305895A1 (en) | Systems, apparatus, articles of manufacture, and methods for data driven networking | |
| US20240147404A1 (en) | Multi-access edge computing (mec) application registry in mec federation | |
| Oteafy et al. | Dynamic wireless sensor networks | |
| Alam | Federated learning approach for privacy-preserving on the D2D communication in IoT | |
| WO2023081202A1 (en) | Mec dual edge apr registration on behalf of edge platform in dual edge deployments | |
| Anitha et al. | A neuro-fuzzy hybrid framework for augmenting resources of mobile device | |
| Naqvi et al. | A quality-aware federated framework for smart mobile applications in the cloud |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |