基于过去历史数据的网络节点可用性预测

摘要

本公开涉及基于过去历史数据的网络节点可用性预测。可以在M2M/IoT网络的服务层使用节点可用性估计服务。增值服务可以利用该节点可用性信息来提高M2M/IoT系统的操作智能、服务质量、通信开销以及能量效率。实时数据收集(DC)组件可以在服务层(例如，其它现有CSF)从输入源收集实时数据。用于估计节点可用性的数据处理组件(DP)可以基于由DC收集的数据执行用于估计节点可用性的数据处理。节点可用性服务供应组件(SP)可以存储来自DP的估计节点可用性结果，并就“节点可用性估计服务”而言将其呈现给服务客户端。

说明书

本申请是申请日为2015年6月30日、申请号为201580041567.6、题为“基于过去历史数据的网络节点可用性预测”的发明专利申请的分案申请。

背景技术

图1是示出支持服务层102的示例性协议栈100的示意图。从协议栈的角度来看，服务层102通常被分层在应用协议层104之上，并向客户端应用提供增值服务。因此，服务层102通常被分类为“中间件”服务。

M2M/IoT服务层是专门针对M2M/IoT类型的装置和应用的一种类型的服务层的示例。图2是示出网络中的M2M/IoT服务层实例的示例性部署场景的示意图。在该示例中，服务层实例202是服务层的实现，且多个服务层实例部署在各种网络节点(网关和服务器)上。服务层实例向网络应用、装置应用、以及网络节点本身提供增值服务。

近来，一些工业标准组织(例如oneM2M)开发了M2M/IoT服务层来解决与将M2M/IoT类型的装置和应用集成到诸如互联网/Web、蜂窝、企业、以及家庭网络这样的部署中相关联的挑战。M2M服务层可以向应用和装置提供对于服务层所支持的M2M中心能力的集合的访问。这种能力的一些示例包括安全性、计费、数据管理、装置管理、发现、供应、以及连接管理。经由API使得这些能力可用于应用，API使用通过M2M服务层定义的消息格式、资源结构、以及资源表示。

oneM2M的目的和目标是开发满足对于公共M2M服务层的需要的技术规范，公共M2M服务层可以容易地嵌入到各种硬件和软件中，并且可以依赖它将域中的很多种装置连接到全世界的M2M应用服务器。

图3是示出支持公共服务功能(CSF)(即服务能力)集合的oneM2M公共服务层302的示意图。一个或多个特定类型的CSF的集合的实例化称为公共服务实体(CSE)304，其可以在不同类型的网络节点上托管，例如基础设施节点(IN)、中间节点(MN)、以及专用节点(ASN)CSE，分别被称为IN-CSE、MN-CSE和ASN-CSE。

图4是示出遵循面向资源架构(RoA)设计原理的oneM2M服务层的示意图。在oneM2MRoA RESTful架构中(如图4所示)，将CSF表示为“资源”集合。资源是架构中具有可经由RESTful方法(例如创建、检索、更新和删除)操纵的表示的唯一可寻址元素。利用通用资源标识符(URI)使得这些资源可访问。资源可包含子资源和属性。子资源是与父资源具有包含关系的资源。父资源表示包含对其子资源的参考。子资源的寿命受父资源寿命的限制。每个资源支持存储资源信息的集合“属性”。

图5示出用于并非基于RESTful的传统系统部署的M2M服务组件架构。该M2M服务组件架构主要适用于其中将CSE 502视为服务组件集合的基础设施域。在服务层中，它包含各种M2M服务，并且多个服务可以分组为服务组件。除了现有参考点之外，它还引入了服务间参考点Msc 504。M2M服务组件之间的通信(通过Msc参考点504传递)利用web服务方法，这是用于构建基于面向服务的架构(SoA)的软件系统的最流行技术。

已知很多M2M/IoT装置具有有限电池电力、小的内存占用(footprint)和低吞吐量链路的某种组合。因此，很多这些装置是“困乏”的，并且偶尔进入睡眠模式以节省能量。这是导致在大多数先前工作中考虑的节点不可用性的主要问题。

无线传感器网络(WSN)是典型的M2M区域网络，它包括具有感测和计算能力的多个低功率装置。在很多传感器网络系统中，用于网络节点的电源通常是可耗尽电源(例如电池)。为了延长传感器网络的寿命，一种电力管理方案是要求每个网络节点周期性地唤醒，以收听无线电信道。例如，S-MAC是为无线传感器网络设计的著名的媒体访问控制(MAC)协议。通过S-MAC，每个节点进入睡眠一段时间，然后唤醒并收听以查看是否有任何其它节点想要与其通话。在睡眠期间，节点关闭其无线电，并设置定时器在以后唤醒它。根据不同的应用场景可以选择用于收听和睡眠的持续时间，并且节点为了同步通过向其所有近邻广播来交换其调度。在清醒状态期间，如果多个邻居想要与节点通话，那么其需要使用载波感测多路访问方案竞争介质。

电源管理方案的另一种方法是使用低功率待机硬件组件来在节点进入睡眠模式时观察环境。例如，节点可以使用待机无线电收发器子系统在节点睡眠时收听无线电信道。当待机无线电收发器接收无线电信号时，它唤醒节点。否则，节点保持睡眠。

已经识别到了关于M2M/IoT使用情形(例如将智能对象连接到互联网)的现有互联网协议的缺点和问题。例如，当前互联网协议的主要缺点是其缺乏对困乏节点的支持。换言之，经常假定网络节点总是保持完全供电，但不幸的是，对于很多M2M/IoT类型的装置(其在本质上是资源受限、电池供电、并且在绝大多数时间中睡眠)而言情况并非如此。因此，最近给予了很多关注来增强互联网的架构和协议，以支持M2M/IoT网络。例如，现有系统描述了睡眠模式控制的机制，其中路由器可以控制IPv6困乏节点并与外部网络来回地传递分组，或者描述具有困乏节点支持的6LoWPAN邻居发现(ND)协议的增强。

IETF受限应用协议(CoAP)是最近开发的专用于受限节点/网络(例如为智能家庭部署的无线传感器网络)的应用协议。它吸引了越来越多的关注，是用于IoT系统的有前途的消息协议。特别地，已经完成了一些工作来增强用于支持困乏节点的CoAP协议。

除了如上所述的CoAP协议增强之外，还做出了其它努力来支持IETF受限RESTful环境(CoRE)工作组中的困乏节点。例如，其中一个想法是采用资源目录(RD)机制，其中困乏节点可以在中央(非困乏)RD服务器上注册/更新其资源列表(及其睡眠相关状态)。这允许客户端从用于困乏节点的RD发现资源的列表，并确定目标资源是否位于困乏节点上、困乏节点当前是否处于睡眠模式、或者什么时候困乏节点将再次处于清醒状态。另一个示例涉及镜像服务器(MS)，它是允许困乏节点在MS资源树中创建资源的web服务器。特别地，为了能量效率，困乏节点是仅客户端端点，因此不能自己提供内容。换言之，MS充当困乏节点与客户端之间的邮箱。

图6是示出来自oneM2M功能架构规范的称为的资源的示意图。资源602表示在其父资源语境下的调度信息。当602是资源的子节点时，它可以表示在资源604中存储的睡眠调度信息，因此服务层可以知道节点睡眠。

以前述作为背景信息，本申请公开一种用于实现节点可用性估计服务的新方法和系统。

发明内容

实施例在服务层包括支持节点可用性估计的新服务。很多新增值服务可以利用这个节点可用性信息，它提高用于M2M/IoT系统的操作智能、服务质量、通信开销、以及能量效率。

在一个实施例中，在服务层的节点可用性估计(NAE)服务有三个主要组件：实时数据收集组件(DC)、用于估计节点可用性的数据处理组件(DP)、以及节点可用性服务供应组件(SP)。

DC可以在服务层(例如其它现有CSF)从输入源收集实时数据。DC可以使用用于数据收集关系和政策建立的规程以及相关的新消息结构、用于数据收集和报告的规程以及相关的新消息结构；以及用于数据收集关系和政策更新的规程。

DP可以基于DC收集的数据执行用于估计节点可用性的数据处理。DP的功能架构可包括多个模块，包括信息推演、信息融合、输入格式解析、构建节点可用性估计器、节点可用性估计、估计器评估和数据收集策略确定、以及输出生成和反馈收集。

SP可以存储来自DP的估计的节点可用性结果，并根据“节点可用性估计服务”将其呈现给服务客户端。SP可以是服务供应门户。

多个DC、DP和SP可以为了合作和数据共享相互交互，包括两个DP之间在数据收集方面的合作以及两个DP与两个SP之间在服务供应和估计结果共享方面的合作。

可以提供很多新增值服务，包括节点可用性感知会话建立、智能存储转发资源预取、以及由服务层支持的主动节点触发。

实施例可包括oneM2M功能架构实施例、oneM2M服务组件架构实施例、关于在oneM2M服务层中从输入源收集数据的实施例、关于在DP的信息推演模块和信息融合模块执行的数据处理的实施例、以及通过定义新资源的节点可用性估计服务供应的oneM2M实施例。

提供本发明内容以采用简化形式介绍将在以下详细描述中进一步描述的概念的选择。本发明内容并非要识别所要求保护的主题的关键特征或本质特征，也不是要用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中指出的任何或所有缺点的限制。

附图说明

根据结合附图通过示例方式给出的以下描述可以得到更详细的理解，在附图中：

图1是示出支持服务层的示例性协议栈的示意图。

图2是示出网络中的M2M/IoT服务层实例的示例性部署场景的示意图。

图3是示出支持公共服务功能(CSF)集合的oneM2M公共服务层的示意图。

图4是示出遵循面向资源架构(RoA)设计原理的oneM2M服务层的示意图。

图5示出考虑并非基于RESTful的传统系统部署而开发的M2M服务组件架构。

图6是示出来自oneM2M功能架构规范的称为的资源的示意图。

图7是示出具有不同节点不可用性情形的M2M/IoT系统的示意图。

图8A和图8B是示出在没有节点可用性信息的情形下具有低效资源检索操作的使用情形的示意图。

图9A是示出NAE怎样纳入服务层的一个实施例的示意图。

图9B是示出NAE的功能架构的示意图。

图10是示出与NAE以及逻辑和物理节点相关的术语的示意图。

图11是示出用于数据收集关系和政策建立的示例性规程的流程图。

图12是示出用于从DC发送的请求的示例性通用消息结构的示意图。

图13是示出用于数据收集和报告的示例性规程的流程图。

图14是示出用于数据报告消息的通用消息结构的示意图。

图15是示出用于数据收集关系和政策更新的示例性规程的流程图。

图16是示出DP的示例性通用架构的示意图。

图17是示出构造的节点可用性估计器函数的简单示例的示意图。

图18是示出在SP供应服务的方法的流程图。

图19是示出从DC到客户端的示例性响应消息的示意图。

图20是示出用于节点可用性感知会话建立的规程的流程图。

图21A和图21B是示出用于智能存储和转发预取的规程的流程图。

图22A和图22B是示出用于主动节点触发的示例性规程的流程图。

图23是示出多个DC、DP和SP之间的交互的示意图。

图24是示出两个DP关于数据收集过程合作的流程图。

图25是示出两个DP关于服务供应过程合作以及两个SP之间相互分享信息的流程图。

图26A和图26B是示出用于增强现有的oneM2M功能架构以支持NAE服务的示例性实施例的示意图。

图27是示出在oneM2M服务组件架构中NAE的实施方式架构的示意图。

图28是示出在oneM2M服务层的NAE的示例性数据收集、处理以及节点可用性服务供应实施例的示意图。

图29是示出在oneM2M服务层的示例性数据处理实施例的示意图。

图30A和图30B是示出可以在实施例中使用的示例性资源的示意图。

图31是一个实施例的图形用户界面的示意图。

图32A是示出其中可以实施一个或多个公开实施例的示例性机器对机器(M2M)、物联网(IoT)或万物网(WoT)通信系统的示意图。

图32B是示出其中可以实施一个或多个公开实施例的示例性M2M服务层的示意图。

图32C是示出示例性装置(例如UE或其它装置)的示意图。

图32D是示出可用于实施公开实施例的任何一个节点或逻辑实体的示例性计算机系统或服务器的示意图。

具体实施方式

图7是示出具有不同节点不可用性情形的M2M/IoT系统的示意图。应当理解，图7所示功能可以以在M2M网络的节点(例如服务器、网关、装置、或其它计算机系统)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施，例如下面所述图32C或图32D中所示的其中一个。

大多数现有系统关注物理节点睡眠问题，这主要是由于用于资源受限装置的能量效率设计原理所致。不是限于困乏节点，在可通过不仅表示物理节点而且表示逻辑节点来扩展节点概念的意义上来讲，实施例涉及“节点可用性”，例如服务层实例或应用实例(例如分别是oneM2M域中的CSE或AE)，其实际上可以是在物理装置上运行的软件模块。

对于给定的(物理/逻辑)节点，以下原因可导致其不可用性。

·装置702进入睡眠状态，使得物理节点本身不可用(在PHY(物理)层)。这是在前面部分中讨论的典型情况。

·底层网络有例行操作(例如在蜂窝网络中用于释放资源的常规连接拆卸操作)或网络问题(例如网络业务拥堵)，使得节点被隔离并且不能与其它对等体交互(即，在网络层不可用)。

·装置704耗尽其计算资源(例如CPU、RAM等等)，使得上层运行软件不能响应从无线电接口接收的任何信息。类似地，装置上的特定软件模块可能崩溃(例如软件错误)或者被操作系统禁用。对于上述两种情况(即在服务和应用层不可用)，如果软件与服务层实例(例如CSE)相关，那么该CSE将不可用。作为比较，如果软件与应用规程实例(例如AE)相关，那么只有这个AE将变得不可用。

从服务层的角度来看，在本说明书中考虑的节点概念可以是物理装置，也可以是逻辑节点(例如在oneM2M语境下的CSE或AE)。因此，“节点可用”意味着节点能够与其它对等体交互和通信。由于“节点”的扩展概念，除了像物理节点(例如传感器)为了能量效率目的而睡眠的典型原因之外，很多新因素可能导致节点的不可用性。

节点可用性信息对于M2M/IoT系统中在服务层的有效端对端通信非常有价值。例如，如果CSE(比如CSE-1)学习到CSE-2长时间不可用，那么它可以智能地选择不向CSE-2发起通信连接请求，而不是尝试联系CSE-2但是以失败的连接建立操作结束。特别地，节点可用性知识通常不是立即清楚或事先知道的(例如，物理节点可能没有固定的睡眠调度或逻辑节点可能由于运行时间问题(例如软件过载或错误)而不时地变得不可用)。因此，基本问题是当在服务层丢失这种节点可用性信息时怎样估计节点可用性。现有服务层缺乏这种能力来估计节点可用性，并且以前没有工作解决怎样增强服务层来提供这种独特的特征。

交叉协议栈节点可用性。虽然可以跨协议栈支持节点可用性(但是采用下面提及的反应方式)，但是怎样根据估计节点可用性来主动处理节点可用性并不属于来自低层的任何现有工作的范围。例如，MAC层可以启用困乏节点支持以用于节能，但是对于CSE实例而言，它不知道或者不能理解在服务层的例如由于软件错误的CSE不可用性事件。特别地，MAC层经常在它具有定时器的意义上反应性地处理在上层的不可用性问题，并且如果在经过定时器所指示的等待周期之后没有从更高层获得响应，那么MAC层可以释放无线电资源(PHY和MAC)。类似地，虽然在网络层的现有工作关注具有睡眠节点支持的IPv6邻居发现，但是在高层的CSE不可用性事件也不在其范围内。利用MAC层，IP层只能通过使用定时器在超时后释放资源来反应性地处理在上层的不可用性问题。同时，确实，如果在服务层没有配置睡眠，那么服务层可以向低层查询困乏节点的可用性。但是，如果在没有预定义的/清楚的睡眠调度的情况下采用事件驱动的方式操作装置(在大多数M2M/IoT场景中情况如此)，那么低层只能提供当前时间的节点可用性(即现在正在发生的)，并且不能提供估计的可用性模式或调度。总之，希望服务层(其更接近那些连接发起者)具有估计节点可用性的能力，由此它可以主动地终止连接建立过程，或者对那些由于可能的节点不可用性而具有低成功概率的请求甚至不启动连接建立过程。通过这种方式，服务层不必依赖低层来反应性地解决不能建立的连接。

服务层节点可用性。在水平地检查服务层本身时，它当前不支持节点可用性估计。如果通过检查垂直网络栈在服务层完成节点可用性估计将是有益的，但是不幸的是，现有服务层不支持这种服务。确实，在oneM2M服务层中定义了资源来表示节点睡眠调度，但是，尚未充分研究怎样获得该信息。迄今为止，通常假设节点睡眠调度由节点报告并且事先已知(即已经准备好使用)，但是显然情况并非如此，特别是在CSE由于运行时软件错误而变得不可用的时候。不仅如此，前面提及的更具挑战性和更常见的情况是节点可能根本没有清楚或预定义的调度。在这种情况下，应该在服务层启用节点可用性估计。此外，在服务层(与底层网络和低层交互)有很多现有实体，其提供大量实时数据(其可能不直接反映节点可用性，但是作为估计节点可用性的数据源非常有价值)，这使得处在独特位置的服务层成为节点可用性估计的良好候选。

现有服务层不能帮助可能受节点可用性影响的增值服务。在处理节点可用性问题时，在服务层的很多现有操作可能不够智能。本部分仅简单给出一个代表性示例，如图8A和图8B所示。

图8A和图8B是示出在没有节点可用性信息的情况下具有低效资源检索操作的使用情形的示意图。应当理解，进行图8A和图8B所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D所示的)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图8A和图8B所示方法可以采用在网络节点(例如图32C或图32D所示的节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令在由节点的处理器执行时进行图8A和图8B所示的步骤。此外应当理解，图8A和图8B所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统进行。

根据其应用操作要求，要求基础设施域中CSE(即IN-CSE 804)上的AE-1 802从在区域网络中的十个不同装置(例如装置-1到装置-10)上的十个CSE(例如CSE-1到CSE-10)检索资源(例如数据-1到数据-10)。假设CSE-1到CSE-9刚刚向MN-CSE 806报告了其资源，那么AE-1 802可以容易地从MN-CSE 806直接获得这些资源(即数据-1到数据-9)。但是，如果当前在MN-CSE 806上存储的数据-10已经过时，那么MN-CSE 806可能必须从CSE-10再次检索数据-10。但是如果装置-10已经长时间进入睡眠，并且其睡眠调度没有预定义并未报告给服务层(例如，存储在MN-CSE中的资源中)，那么如果低层机制在这种情况下不能帮助，则这种资源检索操作可能不会成功。例如，虽然IETF CoRE工作组在应用协议层实施代理或镜像服务器以支持睡眠节点，但是如果在镜像服务器或代理中存储的资源也变得过时，那么AE-1可能仍然需要联系装置-10。因此，装置-10上的不成功操作将使得所有先前努力(即从CSE-1到CSE-9成功地检索数据-1到数据-9)无效，导致对于AE-1的整个操作的失败。除此之外，先前操作消耗的网络资源都被浪费，而没有带来任何益处。实际上，如果服务层可通过某种方式估计节点可用性，那么可以在本质上改善以上操作，并且可以启用操作要求知道资源检索操作(作为增值服务)。总之，没有现有工作专门研究在处理节点可用性问题时通过服务层可以启用什么增值服务。

作为以下一些计算的理论背景，在给定目标变量y(是时刻t的函数)时，可以基于过去时间单元中的历史值来估计其当前值和未来值。

在形式上，对于给定的感兴趣节点i，定义布尔变量y

y

可以看出，f

仅作为简单示例，假设节点i具有以下历史可用性调度，它在过去20个时间单元期间睡眠4个时间单元，然后在再次进入睡眠之前清醒另外6个时间单元。基于这些信息，可以构建估计器且估计器具有以下具体表达式(即整个方程没有任何未确定参数。注意：MOD表示模运算)：

因此，通过将任何当前或未来时间单元t输入方程(2)，它将输出0或1值，这是节点i在该时间单元的估计节点可用性。

节点可用性估计(NAE)服务可以在其每个组件具有单独功能的意义上采用松散连接的方式来实施。图9A是示出NAE怎样纳入服务层的一个实施例的示意图。图9A和下面的很多附图将使用oneM2M服务层作为示例。虽然本说明书关注oneM2M示例，但是所述实施例不限于oneM2M，并且可以推广到任何服务层。

在图9A的示例中，可将NAE 902视为CSF。NAE 902可通过与现有CSF(例如会话管理CSF、通信管理传递处理CMDH CSF等等)进行交互来完成节点可用性估计。根据怎样部署NAE902(例如采用集中式或者采用分布式)，将影响不同的参考点(例如mac、mcc、mcc'或mcn)。

图9B是示出NAE 902的功能架构的示意图。在图9B的示例中，NAE902有三个组件。

数据收集(DC)904。为了得到或估计节点可用性，NAE 902可利用DC 904从输入源(例如可以是在oneM2M服务层的现有CSF)收集实时数据。DC 904和DP 906之间的交互可以如下：一方面，DC 904将收集的数据输入到数据处理(DP)906组件，其中将收集的数据进行处理，用于估计不同节点的可用性；另一方面，DP 906还通过评估节点可用性估计结果的准确性或置信度将数据收集策略动态地通知DC 904。换言之，DC 904可通过遵守DP 906提供的数据收集策略，从输入源收集数据。

数据处理(DP)906。DP 906可以执行多个处理步骤(例如数据解释、信息演绎、信息融合、构建节点可用性估计器等等)，并且可以基于从DC 904收集的数据产生用于节点可用性的估计结果。此外，DP 906可以评估估计结果的准确性，然后可以动态地调整数据收集策略，数据收集策略是DC 904的操作指南。

服务供应(SP)908。DP 906可将节点可用性估计结果输出到SP908，SP 908是客户端与NAE 902交互的门户，用于查询节点可用性信息。特别地，DP 906将这些估计的节点可用性信息作为“节点可用性估计服务”提供给服务客户端。

在图9B的示例中，在输入源或服务客户端之间存在交互循环。特别地，一方面，当与DC 904交互时，输入源910(例如oneM2M服务层中的不属于NAE的现有CSF)向DC 904提供各种实时数据(例如与性能、配置、事件日志、错误报告、统计信息等等相关的数据)。另一方面，当访问SP 908提供的节点可用性估计服务时，这些CSF也是NAE 902的服务客户端910。

应当理解，图9A-B所示功能可以采用在M2M网络的节点(例如服务器、网关、装置、或其它计算机系统)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施，例如下面所述图32C或图32D中所示的其中一个。

图10是示出与NAE以及逻辑和物理节点相关的术语学的示意图。如下所述，目标节点可以是逻辑节点(诸如oneM2M服务层中的CSE)，而CSE是实施一个或多个特定类型的CSF的集合的实例。NAE可以与另一个CSF(比如CSF-1)交互，并且这可以涉及两个CSE(其分别实施NAE和CSF-1)之间的通信。当讨论“估计的节点可用性”时，这通常是指物理节点或逻辑节点(如AE或CSE)。但是，当讨论例如与怎样收集实时数据以及怎样提供估计结果相关的NAE的设计细节时，为了便于呈现，讨论可以具有CSF的语境。

DC 904可通过遵守DP做出的数据收集策略，从输入源收集数据。通常，数据收集策略中的一个项可包括以下信息(但不限于)：

-源，例如DC 904打算从哪个输入源(例如，oneM2M业务层中的会话管理CSF)收集数据。

-感兴趣的节点，例如DC 904对哪个节点感兴趣以估计其可用性。

-感兴趣的数据，例如DC 904想要从源收集感兴趣的节点的什么类型的数据，例如CSE-1(即感兴趣的节点)的会话日志数据，它可以从上述会话管理CSF(作为源)收集。

-消息格式，即用于数据交换的格式。

-如果不能满足初始政策中的期望值，那么关于期望的数据报告频率、持续时间、优先级、以及最低程度接受的QoS要求的政策。

对于数据收集策略中的每个项，DC 904可以与对应的输入源交互。特别地，在数据收集过程期间可以涉及下面将要讨论的三个规程。

应当理解，图10所示功能可以采用在M2M网络的节点(例如服务器、网关、装置、或其它计算机系统)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施，例如下面所述图32C或图32D中所示的其中一个。

当DC 904需要根据如上所述的数据收集策略中的项从输入源收集数据时，可以发起与源的数据收集关系。图11是示出用于数据收集关系和政策建立的示例性规程的流程图。

在图11的步骤1中，DP 906确定新的数据收集策略。可以想象，数据策略类似于数据库表，且每个项包括由多个属性(例如源、感兴趣的节点、感兴趣的数据、数据交换格式、以及数据收集策略等等)定义的数据收集需求。实际的数据交换格式取决于各种实施方式选择。

在图11的步骤2中，DP 906将数据收集策略通知DC 904，数据收集策略是DC 904执行任何数据收集操作的触发器或指南。换言之，DC 904不对数据收集作出它自己的决定，而只是遵守来自DP 906的数据策略(这种功能分区设计原理有益于构建松连接系统)。

在图11的步骤3中，在接收数据收集策略之后，DC 904逐项检查它并确定要采取的必要操作。当处理数据收集策略中的每个特定项时，可能存在两种情况：情况1)DC 904需要发起新的数据收集关系(如本部分所讨论的)以满足该项中指示的需求；情况2)DC 904只需要更新现有的数据收集关系，以满足项指示的需求。

在图11的步骤4中，DC 904向源发送用于建立新的数据收集关系的请求。图12是示出用于该步骤中使用的请求的示例性通用消息结构的示意图，它主要承载数据收集策略的每个项的属性。特别地，接收器ID(ReceiverID)1202可以指示消息接收器。以oneM2M服务层为例，它可以是支持特定CSF(即，作为源)的CSE实例的CSE-ID。类型域1204可以指示该请求消息来自NAE 902，用于数据收集关系和政策建立。有效载荷部分1206承载子消息的列表(每个子消息对应于属于情况1的项，并且所有这些对应的项都具有相同的源(如同接收器ID所指示的))。每个子消息(如图12下部所示)包括以下信息：1)节点ID(NodeID)指示感兴趣的节点是哪个；2)关于该节点需要收集什么数据('D'域指示以下字段用于描述要收集哪n个感兴趣的数据)；3)'T'域指示以下一个字段用于描述数据收集过程的持续时间；以及4)关于该数据收集关系的政策由“P”域之后的m个字段描述。

在图11的步骤5中，对于给定的数据收集关系，可能源不能满足/达到政策中指示的QoS要求。因此，针对每个数据收集关系在DC 904与源之间可以有若干回合的协商过程。换言之，DC 904将首先在初始请求消息中包括期望的QoS要求和政策，但是如果其不能被满足，那么DC 904可以妥协，直到DC 904和源两者达成对于QoS要求和政策的一致同意。但是，如果最低程度接受的QoS甚至都不能满足，那么DC 904可以放弃建立这种数据收集关系。

在图11的步骤6中，在达成一致的QoS要求同意时，源可以定义用于支持新建立的数据收集关系的新触发器，以便适当地向DC 904报告相关的实时数据。

在图11的步骤7中，一旦源建立了新的触发器，它就可以向DC 904发回确认，以指示已经成功建立数据收集关系，与“数据收集关系ID(dataCollectionRelationshipID)”相关联以用于未来参考。

在图11的步骤8中，因为由DP 906确定初始数据收集策略，并且可以在通过DC 904与源进行协商时修改QoS要求，所以DC 904还可以向DP 906发回确认让它知道。

应当理解，执行图11所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图11所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图11所示的步骤。此外应当理解，图11所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如，软件)的控制下由节点的通信电路系统执行。

图13是示出用于数据收集和报告的示例性规程的流程图。一旦建立了数据收集关系，DC 904就可以从源接收数据报告。

在图13的步骤1中，如最后一部分中所提及的，可以在源内部定义一些触发器(例如当已经报告了DC感兴趣的特定数据片段时)(参见图11的步骤7)。因此，一旦记录了DC感兴趣的新数据，它就可以触发数据报告操作。

在图13的步骤2中，新数据从源发送到DC。图14是示出用于该步骤中使用的数据报告消息的通用消息结构的示意图。特别地，发送者ID(SenderID)1402可以指示数据来自哪里。有效负载部分1404还携带子消息的列表(每个子消息对应于用于正在进行的数据收集关系的数据报告记录)。对于每个子消息(如图14底部所示)，它包括以下信息：1)数据收集关系ID指示数据与哪个现有数据关系相关；2)节点ID指示数据与哪个节点相关；3)“D”域之后的字段是n个感兴趣的数据。下面讨论示出怎样在oneM2M服务层从现有CSF收集数据的子消息的具体实施例。替选地，不是如图14所示将与各种感兴趣的节点相关的数据放入一个消息，源可以聚集针对每个感兴趣的节点的数据，且每个消息只包括与一个节点相关的数据。

在图13的步骤3中，在从源接收新数据之后，DC 904可以首先检查数据完整性，然后通过抽象有用信息来解释数据。

在图13的步骤4中，DC 904针对成功的数据接收操作向源发回确认。

在图13的步骤5中，DC 904还将数据转发到DP 906，用于进一步处理。

应当理解，执行图13所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图13所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图13所示的步骤。此外应当理解，图13所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

图15是示出用于数据收集关系和政策更新的示例性规程的流程图。可能DC 904已经具有与源的正在进行的数据收集关系，但是需要必要的修改以便满足新接收的数据收集策略。在这种情况下，DC 904只需要发出更新请求。本部分给出用于数据收集关系和政策更新的对应规程。

图15的步骤1-3与图11的步骤1-3相同。

在图15的步骤4中，当需要对现有数据收集关系(即在图11的步骤3中所讨论的情况2)进行更新时，DC 904将向源发送更新请求。同时，不是发送所有信息，DC 904只需要发送与所需更改相关联的数据收集关系ID。采用来自oneM2M服务层的示例，DC 904可以指示它需要针对感兴趣的节点(例如CSE-1)扩展的数据收集持续时间的会话管理CSF。除此之外，数据收集更新可能需要收集更多数据元素，修改数据报告频率、优先级，或者终止当前数据收集关系。此外，更新请求的消息格式可以与图12中所示的消息格式非常相似(只需要在子消息中添加字段以包括数据收集关系ID)，因此，为了简明起见，这里没有示出。

在图15的步骤5中，一旦源接受更新请求，它还对对应的触发器进行修改以反映这种改变。注意，对于更新请求，可能在达成一致的服务质量(QoS)要求同意之前在DC 904与源之间存在协商过程(与图11中相同)。图15不反映这个过程。

在图15的步骤6中，一旦已经基于更新请求成功地重新配置了触发器，源将向DC904发回确认。

在图15的步骤7中，DC 904还向DP 908发回确认，让它知道。

应当理解，执行图15所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图15所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图15所示的步骤。此外应当理解，图15所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

图16是示出DP 906的示例性一般架构的示意图。应当理解，图16所示功能可以采用在M2M网络的节点(例如服务器、网关、装置、或其它计算机系统)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施，例如下面所述图32C或图32D中所示的其中一个。

该示例性架构具有多个具有不同子功能的模块。DP 906可以基于从输入源收集的数据来估计节点可用性。图16还示出不同模块之间的信息流(如箭头所示)。这些都是本文提出的新颖想法。此外，后续部分将介绍每个模块的实施例的设计细节，以逐步示出怎样估计节点可用性。特别地，使用特定技术作为示例以介绍每个模块的细节(例如怎样预处理数据的方式、使用多项式模型来构建估计器等等)，但是值得注意的是，可以使用任何技术或方法来实施DP 906的每个模块，并且没有通用方法。

模块A 1602是信息推演模块。模块A 1602可以从DC 904接收各种实时数据；该数据可以转换为可用于构建估计器的归一化值(例如指示节点可用性的布尔值“0”或“1”)。对于与感兴趣的节点i相关的给定数据片段j，将y

在基于数据j中包括的信息推演出用于节点i的变量y

模块B 1604是信息融合模块。模块B 1604关注的焦点仍然是节点i在一个特定时间单元t≤t

Y

对于Y

在数据融合过程之后，Y

模块C 1606是针对用于构建节点可用性估计器的算法的输入格式解析模块。对于给定节点i，通过重复最后一部分所示的过程，可以针对模块B中不同的先前时间单元(即t

L

L

模块D 1608是构建节点可用性估计器模块。模块D 1608的工作是在给定多个历史可用性信息(即先前部分中讨论的L

这里，我们仅示出用于示出怎样构建估计器的简单示例，其重新使用前面的示例。观察到节点i具有以下历史可用性调度，其在过去20个时间单元期间睡眠4个时间单元，然后在再次进入睡眠之前在另外6个时间单元唤醒。换言之，如方程(5)中定义的有序列表L

L

为了构建估计器，首先需要选择候选/原型函数，并且主要考虑的是原型函数通常应该具有与历史数据的趋势类似的趋势。例如，如果历史数据反映线性趋势，那么原型函数也应该具有线性表达式。在我们的示例中，由于节点历史可用性调度反映了一些周期性，并且y

在这个时间点没有确定方程(7)的原型函数中的参数，并记住MOD是模运算，如方程(2)所述。接着，通过利用历史数据，将在确定方程(7)中所有参数的值(即a

在确定参数的值之后，原型函数现在将变为估计器(如方程(9)的右边部分所示，其中出现在方程(7)中的所有参数具有数值)：

实际上，这种估计器构建过程可能耗时，并且可能需要大量的计算资源以关于准确的估计器f

模块E 1610是节点可用性估计模块。在模块D1608产生针对节点i的估计器f

为了说明模块D 1608和E 1610的主要思想，图17示出解释针对给定节点i的对应过程的简单示例。如图所示，基于过去时间单元中的历史可用性数据(用蓝点表示)的列表(其从模块C 1606获得)，可以构建估计器，在图17中示出为实曲线。同时，通过输入未来时间单元，红色虚曲线从实线部分延伸，即红色曲线上的绿点是用于未来时间单元的估计可用性(实际上，估计器可能只针对下一个或几个时间单元估计可用性是准确的)。

模块F 1612是估计器评估和数据收集策略确定模块。应当注意，存在可能影响节点可用性估计的准确性的若干因素。首先，如果模块D1608缺乏足够的历史节点可用性输入(例如针对很多过去时间单元而言丢失了很多节点可用性数据)，那么可以根据不准确性构建具有内在缺陷的估计器。第二，针对给定节点i和给定时间单元t，因为DC 904收集的不同数据片段针对节点可用性具有不同的意见，并且模块B 1604被设计为融合这些不同意见，所以很可能由于各种噪声或偏差等等在推演历史节点可用性时出现错误。最后，即使假设所有历史可用性数据都准确并且充分，这也不一定表示对应的估计器f

因此，利用估计器f

模块G 1614是输出生成和反馈收集模块。模块G 1614未来自模块F1612的估计结果包裹为客户端可以理解的格式。然后，将这些结果转发到SP 908。例如，可以采用以下格式描述时间单元10和20之间的AE1(ID为1232)的估计可用性：

{NodeID＝1232,Status:Available,Interval＝[t＝10,t＝20],

Confidence＝0.55} (10)

此外，模块G 1612还可如上所述解析从SP 908收集的反馈信息。

从DP 904接收节点可用性估计结果之后，SP 908可以向客户端提供这些信息作为节点可用性估计服务。图18是示出在SP 908供应服务的方法的流程图，如图18所示。

在图18的步骤1中，当客户端需要知道给定节点的可用性信息以用于它自己的需要时，如果这种信息不是立即明确的，那么它将联系NAE902以获得帮助。

在图18的步骤2中，客户端向NAE 902发送查询请求。通常，查询请求中的消息元素可包括(但不限于)以下信息：

-感兴趣的节点ID：节点的标识符。

-感兴趣的时间间隔：客户端感兴趣的时间周期。

-置信度要求：例如，估计可用性信息的最低程度接受置信度。

在图18的步骤3中，在从客户端接收请求之后，NAE 902将检查其存储库以查看是否可以满足该请求。如果例如1)SP 908不具有与感兴趣的节点相关的任何估计可用性信息；或者2)估计可用性的置信度太低，无法满足客户的要求，那么该请求将被拒绝。

在该示例中的替选使用情形是在步骤2期间，客户端可以只关于节点类型指定其需要，而不是查询特定节点的可用性。换言之，该类型的任何节点都可以服务客户端，只要它当前可用。然后，在步骤3中，NAE 902将负责选择用于服务该请求的特定可用节点。

在图18的步骤4中，如果请求可以满足，那么DC 904将所需信息发回客户端，或者发送带有解释的拒绝通知。特别地，响应消息可以具有图19所示的结构，并且这种消息的实施例可以具有与方程10所示示例类似的信息。

除了上述基于拉动的服务供应之外，替选地，还可以在客户端可以为给定的感兴趣的节点向NAE 902建立订阅并且NAE 902将周期性地向客户端报告关于节点可用性的任何更新的意义上设计基于推送的服务供应。

应当理解，执行图18所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图18所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图18所示的步骤。此外应当理解，图18所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

基于在服务层提出的新的NAE 902服务，可由NAE 902启用若干增值服务。图20是示出针对节点可用性感知会话建立的规程的流程图。一旦在服务层实施NAE 902，其就可以支持可用性感知会话管理服务，并且在图20中示出具体示例来说明相关规程。如图20所示，当在CSE-12004上运行的AE-1 2002想要与在远程CSE-2 2008(其由于例如软件崩溃而实际上不可用)上运行的另一个AE-2 2006交互时，其首先向其本地CSE-1 2004发送会话建立请求。不是立即初始化会话建立过程，CSE-1 2004首先通过在CSE-2 2008(其实施NAE 902服务)查询AE-22006的估计可用性来评估这种操作的成功概率。从NAE 902通知CSE-12004很可能AE-2 2006不可用，基于此，CSE-1 2004将决定不继续。结果，将直接从其本地CSE-12004拒绝AE-1的请求。

应当理解，执行图20所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图20所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图20所示的步骤。此外应当理解，图20所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

图21A和图21B是示出用于智能存储和转发预取的规程的流程图。使用在服务层提出的NAE 902服务，可以支持更智能的存储转发资源预取。图21A和图21B中示出具体示例以说明相关规程。实际上，针对给定的逻辑节点AE 2102，NAE 902不仅可以估计其可用性，而且可以基于从DC 904收集的数据来估计其活动行为/模式。如图21A和图21B所示，CSE-12104通过查询在不久的未来AE-1 2102(在CSE-1上运行)的估计活动性，联系在MN-CSE2106上运行的NAE 902。使用从NAE902返回的估计结果，CSE 2104学习到AE-1 2102可能需要在时间单元t

应当理解，执行图21A和图21B所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图21A和图21B所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图21A和图21B所示的步骤。此外应当理解，图21A和图21B所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

图22A和图22B是示出用于主动节点触发的示例性规程的流程图。应当理解，执行图22A和图22B所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图22A和图22B所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图22A和图22B所示的步骤。此外应当理解，图22A和图22B所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

使用在服务层提出的NAE服务902，可以启用主动节点触发服务，并且在图22A和图22B中示出具体示例以示出相关规程。如图22A和图22B所示，前五个步骤与图21A和图21B中所示步骤类似。情况是，CSE-1从NAE 902学习到根据AE-1的应用要求其需要频繁地(但是关于固定工作调度，不是周期性地)将感测命令推送到装置-1 2202用于特定任务，并且下一个推送时间在后来的时刻t。但是，NEA指示装置-1 2202在那个时刻附近可能不可用。因此，不是当在时刻t接收AE-1的推送请求时反应性地触发装置-1 2202来唤醒(这可能导致潜在的延迟)，通过利用例如oneM2M服务层中的网络服务呈现、服务执行和触发(NSSE)CSF，CSE-1 2204可以决定在适当的时间单元(比如比t稍微早一点的t’)向底层网络2208主动调度触发器消息。最后，底层网络将唤醒装置-1 2202。使用这种触发器，装置-1 2202可以在时刻t立即可用，并且显著的益处是装置-1 2202不必太早被唤醒(这导致不必要的能量消耗)。结果，不仅AE-1 2206成功地将固件推送到装置-1 2202，而且实现了能量效率目的。

客户端不需要完全地或者仅仅基于NAE 902提供的估计的节点可用性做出其操作决定。关于低置信度，节点可用性估计可能不够精确，或者有时候没有准备好用于使用的这种信息。为了在这种情况下做出真正智能的决定并纠正NAE 902可能的估计不准确性，可以考虑更多的信息用于整体评估节点可用性，包括：

1)来自低层的跨层信息报告也可以具有有用性，特别是针对具有很低占空比的那些装置(从大多数时间其保持在睡眠状态的意义上而言)。在这种情况下，由NAE 902提供的那些节点的估计可用性总是不可用是可能的(实际上其确实如此)。但是，在MAC/PHY层，其可以在很短的时隙中变得可用，以参与和其它对等体的通信(例如，利用调度的信道轮询技术)。

2)背景信息在一些情况下也有用。例如，如果客户端需要联系刚好在一跳范围内的节点，并且NAE 902估计该节点不可用(但是具有很低的置信度)，那么如果网络业务轻(这可能不会恶化网络业务条件)客户端仍然可以尝试联系节点(这可能不会引起大量开销)。

3)最新的运行时信息。因为对于NAE 902而言总是需要时间来收集数据然后估计节点可用性，所以它可能在一定程度上具有时滞效应。因此，如果客户端具有最新的证据(例如，如果它只是从目标节点窃听到广播分组)，那么可能足以断定目标节点可能是可用的。

总之，建议在确定节点可用性时，不仅需要考虑由NAE 902提供的估计结果，而且需要考虑上述其它类型的信息。关于不同的场景和应用，客户端将具有不同的政策来利用上述信息(例如，在不同的优先级中，具有不同的权重等等)。

图23是示出多个DC 2302和2304，DP 2306和2308以及SP 2310和2312之间的交互的示意图。

从图23可以看出，在如果任何三个组件(就一个DC、一个DP和一个SP而言)全部一起合作来实现先前部分所讨论的节点可用性估计功能则可以将其视为NAE的意义上，每个组件可以与多个实体交互。例如，DC 2202可以收集用于多个DP 2306和2308的实时数据，而DP 2306可以向多个SP 2310和2312提供估计结果。用于这些交互(即DC和DP、DP和SP)的相关规程和消息结构与先前部分中提出的相同。本部分将主要考虑两个DP 2306和2308与两个SP 2310和2312之间的交互。

应当理解，图23所示功能可以以在M2M网络的节点(例如服务器、网关、装置、或其它计算机系统)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施，例如下面所述图32C或图32D中所示的其中一个。

图24是示出两个DP 2306和2308关于数据收集过程合作的流程图。如图24所示，当DP-1 2306和DP-2 2308都具有新的数据收集策略时，不是直接将这些数据收集策略发送到DC 2302和2304，而是两个DP 2306和2308首先交换其数据收集策略并进行协商过程。这种协商过程的潜在益处如下：1)两个DP 2302和2309可以具有相同的数据收集任务，这些任务可以在协商过程期间检测和合并；2)不同的DP可以具有不同数量的可用计算资源，因此可以在其之间平衡节点可用性估计任务；3)类似地，因为不同的DC针对数据收集也可以具有不同的工作负载，所以DP还可以使用调整其数据收集策略来平衡不同DC上的工作负载。4)如果两个数据收集策略是要针对相同的感兴趣的节点收集不同类型的数据，那么将这些数据收集任务组合在一起并将所有数据发送到一个DP 2306用于处理可以显著提高估计结果的准确性。最后，基于步骤5所示的协商过程，DP-1 2306和DP-2 2308将分别将其调整的数据收集策略发送到DC-1 2302和DC-2 2304(这只是示例)。

应当理解，执行图24所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图24所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图24所示的步骤。此外应当理解，图24所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

图25是示出两个DP 2306和2308关于服务供应过程合作以及SP2310和2312在相互之间共享信息的流程图。如图25所示，当DP-1 2306和DP-2 2308具有新的估计结果时，不是直接将结果输出到SP 2310和2312，两个DP 2306和2308首先执行协商过程，在此期间其将通过考虑例如在不同SP的负载平衡问题或其它因素，确定将哪些估计结果存储在哪些SP2310和2312。因此，DP-1 2306和DP-2 2308将基于协商过程将其结果输出到对应的SP(例如附图所示的SP-1 2310和SP-2 2312)。注意，关于信息共享，在不同的SP 2310与2312之间也有合作，因为不同的SP可以存储节点可用性信息的不同片段。结果，当客户端向SP-22312发送对特定节点的可用性查询时，可能SP-2 2312没有这种信息，但是SP-1 2310可能有。然后，SP-2 2312将该请求转发到SP-1 2310，并且最后，SP-1 2310可通过将该信息共享到SP-2 2312来提供客户端所需的可用性信息。

应当理解，执行图25所示步骤的实体是逻辑实体，其可以采用在网络节点或计算机系统(例如图32C或图32D中所示)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施。也就是说，图25所示方法可以采用在网络节点(例如图32C或图32D中所示的网络节点或计算机系统)的存储器中存储的软件(即计算机可执行指令)的形式来实施，该计算机可执行指令当由节点的处理器执行时执行图25所示的步骤。此外应当理解，图25所示的任何传送和接收步骤都可以在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下由节点的通信电路系统执行。

图26A-26B是示出用于增强现有的oneM2M功能架构以支持NAE服务的示例性实施例的示意图。如图26A-B所示，NAE可以是CSE中的新CSF。描述了两个选项用于部署NAE。

一方面，如果采用集中方式部署NAE 2602(即就DC 2604、DP2606和SP 2608而言)，NAE 2602的全部三个组件在CSE 2610的单个节点中实施，如图26A所示，CSE 2610可以是MN-CSE，也可以是IN-CSE。特别地，考虑估计在NAE 2602的DP 2606组件执行的节点可用性所需的计算资源，将NAE 2602置于IN-CSE中可能是期望的选择。NAE 2602的帧内和帧间通信描述如下：

当NAE(由CSE-1提供)需要与由不同的CSE 2612(比如CSE-2)提供的另一个CSF通信时，其将通过mcc接口。例如，其可能具有以下情形：

情形1：如果它与关于图11讨论的用于数据收集关系和政策建立的规程相关，那么所涉及的对象是DC和数据源，并且要在其之间交换的消息的结构如图12所示。

情形2：如果它与图13中用于数据收集和报告的规程相关，那么所涉及的对象也是DC和数据源，并且要在其之间交换的消息的结构如图14所示。

情形3：如果它与图15中讨论的用于数据收集关系和政策更新的规程相关，那么所涉及的对象是DC和数据源，并且要在其之间交换的消息的结构如图12所示，加上图15的步骤4中讨论的dataCollectionRelationshipID。

情形4：如果它与5.4部分的图18中讨论的用于服务供应的规程相关，那么所涉及的对象是SP和CSE客户端，并且要在其之间交换的消息的结构在图18的步骤2(与查询消息相关)中讨论以及图19中定义的结构(与响应消息相关)。

当NAE 2606需要与由相同CSE 2610提供的CSF通信时，或者当NAE 2602中的三个组件需要相互交互时，通信将使用mff接口，mff接口指定相同的服务层中不同服务功能之间的通信。

当使用位于相同CSE-1 2610上的AE查询NAE 2602服务(由CSE-12610提供)时，其将使用mac接口。它主要与关于图18讨论的用于服务供应的规程相关，但是所涉及的对象是SP和AE客户端(而不是上述情形4中的CSE)。要在其之间交换的消息的结构与在情形4中所示的相同。

另一方面，在其三个基本组件(DC、DP和SP)可以驻留在不同节点中并且还可以在多个DC、DP和SP之间具有交互(如5.6部分所讨论的)的意义上，NAE也可以采用分布式方式部署(如图26B所示)。例如，DC可以部署在包括端节点的所有节点上，而DP和SP可以部署在MN-CSE和In-CSE上(原因与前面提到的类似)。NAE的帧内和帧间通信描述如下：

当DC 2620(部署在CSE-1 2622)需要与由不同CSE(例如CSE-22624)提供的另一个CSF(用于在NAE的DC的数据收集)通信时，其将使用mcc接口。如前所示的四种情形(Case-1至Case-4)也应用于相关对象以及要交换的消息的结构。

当DC 2620(部署在CSE-1 2622)需要与由相同CSE提供的另一个CSF通信时，其将通过mff接口。如前所示的四种情形(Case-1到Case-4)仍然应用在mff接口上。

当由位于相同CSE-1 2622上的AE 2628查询SP 2626(由CSE-12622部署)时，其将通过mac接口。它主要与关于图18讨论的用于服务供应的规程相关，并且涉及的对象是SP2626和AE 2628客户端。要在其之间交换的消息的结构与在情形4中所示的相同。

当位于另一个CSE-2 2624上的AE 2630查询SP 2626(由CSE-12632部署)时，其将通过mcc和mac接口两者。同样，其与服务供应相关，并且要在其之间交换的消息的结构与在情形4中所示的相同。

对NAE的任何两个组件(即DC、DP和SP)之间的通信，如果将其部署在相同的CSE，那么其将通过mff接口。否则，其将通过mcc接口。例如，针对DC与DP之间的交互，其之间的消息结构可以类似于图12所示的消息结构(当DC将收集的数据输入DP时使用该结构)以及当DP向DC发送数据收集策略时使用的消息元素。

应当理解，图26A-B所示功能可以采用在M2M网络的节点(例如服务器、网关、装置、或其它计算机系统)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施，例如下面所述图32C或图32D中所示的其中一个。

图27是示出oneM2M服务组件架构中的NAE 2702的实施方式架构的示意图。如图所示，可通过插入称为“节点可用性估计组件”2702的单独服务组件来实施NAE 2702，其可以通过'Msc'参考点2704与其它组件交互。

应当理解，图27所示功能可以采用在M2M网络的节点(例如服务器、网关、装置、或其它计算机系统)的存储器中存储并在其处理器上执行的软件(即计算机可执行指令)的形式来实施，例如下面所述图32C或图32D中所示的其中一个。

图28是示出在oneM2M服务层的NAE的示例性数据收集、处理以及节点可用性服务供应实施例的示意图。DC从输入源收集实时数据。在oneM2M域的语境下，这些实体可以是现有CSF。特别地，因为很多现有CSF被呈现为资源，所以图28示出根据最新的oneM2M功能架构规范可以从哪些特定资源NAE收集实时数据。特别地，图28是通过示出怎样从oneM2M服务层的现有CSF收集数据的数据报告消息(如图14所定义)的具体实施例。例如，当NAE需要从CMDH CSF(被表示为oneM2M服务层中的资源)收集数据时，其可以收集关于CSE或AE的数据。关于感兴趣的数据，“source(源)”和“target(目标)”指示谁涉及这种资源(显然，其中一个应该是感兴趣的节点)，“lifespan(寿命)”显示传递的持续时间，“deliveryMetaData(递送元数据)”表示传递状态等等。类似地，NAE可以从资源收集数据。对应的感兴趣节点可以是物理节点，并且感兴趣的数据可包括节点的“存储器使用(memory)”、“存储(storage)”、“电力(power)”、以及“睡眠调度(schedule)”(由资源描述，其是NAE可以从其收集数据的另一种类型的资源节点)。

图29是示出在oneM2M服务层的示例性数据处理实施例的示意图。DP可以基于从DC收集的数据来估计节点可用性。图29示出关于以下的实施例：1)怎样从三个不同的数据片段推演节点可用性信息(在DP的模块A完成)；以及2)怎样融合从三个数据抽象的信息(在DP的模块B完成)。如图29所示，DC从不同的源接收三个数据。例如，数据-1是关于AE-1(即感兴趣的节点)的并且从服务统计收集记录收集。数据-2是关于CSE-1(即感兴趣的节点)并且从会话管理功能收集。

针对感兴趣的节点i(在本示例中可以是AE-1或CSE-1)及其每个相关数据j(即，针对AE-1的数据-1、针对CSE-1的数据-2和数据-3)，模块A将执行推演过程，并且仅基于从数据j抽象的信息针对变量y

接着，暂时只关注CSE-1并且关注的时间单元仅针对t＝8。因为存在与在时间单元t＝8的CSE-1的可用性相关的三个推演结果，所以这三个推演结果将在DP的模块B融合(即图29中的分段V)并且在分段VI中示出融合节点可用性结果(即y

图30A和30B是示出可以在实施例中使用的示例性资源的示意图。这些资源可以在SP被读取到供应节点可用性估计服务，图30A示出资源3002；且图30B示出资源3004。通常，3002可以位于资源下。同时，3002本身可包括多个子3004资源。特别地，每个3004资源将表示一个估计的节点可用性结果，并且该资源的属性对应于如方程10所列的数据元素。替选地，估计的节点可用性结果还可以通过添加新属性(例如置信度等等)存储在现有资源中。

诸如图形用户界面(GUI)的界面可用于帮助用户在服务层控制和/或配置与节点可用性估计服务相关的功能。图31是示出界面3102的示意图。应当理解，可以利用诸如下面描述的图32C-D所示的显示器来产生界面3102。

如同所讨论的，图16所示的DP内的一般架构模块D用于在给定多个历史可用性信息(即在先前部分中讨论的L

值得注意的是，可以使用任何可用的解决方案作为构建估计器的插件(换言之，本公开不限于用于实施模块D的任何特定方法)。因此，针对任何插件解决方案，用户可能需要在开始构建估计器之前进行一些配置。因此，为了向用户提供方便的方式来配置例如使用哪个基本函数f

示例性M2M/IoT/WoT通信系统

图32A是其中可以实施一个或多个公开实施例的示例性机器对机器(M2M)、物联网(IoT)或万物网(WoT)通信系统的示意图。通常，M2M技术为IoT/WoT提供构建块，并且任何M2M装置、M2M网关、M2M服务器、或M2M服务平台可以是IoT/WoT以及IoT/WoT服务层等等的组件或节点。通信系统10可用于实施公开实施例的功能，并且可包括功能和逻辑实体(诸如节点可用性估计器902、DC 904、DP 906、和/或SP 908以及逻辑实体)以产生图形用户界面3102。

如图32A所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如以太网、光纤、ISDN、PLC等等)或无线网络(例如WLAN、蜂窝等等)或异构网络的网络。例如，通信网络12可包括向多个用户提供诸如语音、数据、视频、消息、广播等的内容的多个接入网络。例如，通信网络12可以采用一种或多种信道接入方法，例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等等。此外，通信网络12例如可包括诸如核心网络、互联网、传感器网络、工业控制网络、个人区域网络、融合个人网络、卫星网络、家庭网络、或企业网络这样的其它网络。

如图32A所示，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应用或M2M终端装置18接收数据20。此外，可以经由M2M服务层22向M2M应用20发送数据和信号以及从M2M应用20接收数据和信号，如下所述。M2M终端装置18和网关14例如可以经由包括蜂窝、WLAN、WPAN(例如Zigbee、6LoWPAN、蓝牙)、直接无线电链路、以及有线的各种网络进行通信。

示例性M2M终端装置18包括但不限于平板电脑、智能电话、医疗装置、温度和天气监视器、连接的汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门、以及其它基于致动器的装置、安全装置和智能插座。

参考图32B，所示场域中的M2M服务层22为M2M应用20、M2M网关装置14、以及M2M终端装置18和通信网络12提供服务。通信网络12可用于实施公开实施例的功能性，并且可包括功能和逻辑实体(例如节点可用性估计器902、DC 904、DP 906、和/或SP 908以及用于产生图形用户界面3102的逻辑实体)。可由一个或多个服务器、计算机、装置、虚拟机(例如云/存储库等等)来实施M2M服务层22，例如包括下述图32C和32D中所示的装置。应当理解，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'由网络的一个或多个节点(可包括服务器、计算机、装置、虚拟机(例如云计算/存储库等等)等等)构成。

仍然参考图32B，M2M服务层22和22'提供多种应用和垂直面可以利用的服务交付能力的核心集合。这些服务能力使得M2M应用20和20'能够与装置交互并执行诸如数据收集、数据分析、装置管理、安全性、计费、服务/装置发现等等功能。实际上，这些服务能力免除了应用实施这些功能的负担，从而简化应用开发、降低成本并缩短上市时间。服务层22和22'还使得M2M应用20和20'能够通过与服务层22和22'提供的服务相关的各种网络12和12'进行通信。

本申请的方法可以被实施为服务层22和22'的一部分。服务层22和22'是通过应用编程接口(API)和底层网络接口集合支持增值服务能力的软件中间件层。ETSI M2M和oneM2M两者均使用可以包含本申请的连接方法的服务层。ETSI M2M的服务层称为服务能力层(SCL)。SCL可以在M2M装置中实施(其中将其称为装置SCL(DSCL))、在网关中实施(其中将其称为网关SCL(GSCL))、和/或在网络节点中实施(其中将其称为网络SCL(NSCL))。oneM2M服务层支持公共服务功能(CSF)(即服务能力)集合。一个或多个特定类型的CSF的集合的实例化称为可以在不同类型的网络节点(例如基础设施节点、中间节点、专用节点)上托管的公共服务实体(CSE)。此外，本申请的连接方法可以被实施为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问诸如本申请的连接方法的服务的M2M网络的一部分。

在一些实施例中，M2M应用20和20'可以与所公开的系统和方法结合使用。M2M应用20和20'可包括与UE或网关交互的应用，并且可用于与其它所公开的系统和方法相结合。

在一个实施例中，诸如节点可用性估计器902、DC 904、DP 906、和/或SP 908这样的逻辑实体以及用于产生图形用户界面3102的逻辑实体可以在由M2M节点(例如M2M服务器、M2M网关、或M2M装置，如图32B所示)托管的M2M服务层实例中托管。例如，诸如节点可用性估计器902、DC 904、DP 906、和/或SP 908这样的逻辑实体以及用于产生图形用户界面3102的逻辑实体可包括M2M服务层实例内的单独服务能力或者作为现有服务能力中的子功能。

M2M应用20和20'可包括各种行业中的应用，例如但不限于交通、健康、连接的家庭、能量管理、资产跟踪、以及安全和监视。如上所述，跨越装置、网关、服务器、以及其它系统的节点运行的M2M服务层例如支持像数据收集、装置管理、安全、计费、定位跟踪/地理栅栏、装置/服务发现以及传统系统集成这样的功能，并将这些功能作为服务提供给M2M应用20和20'。

通常，服务层22和22'定义通过应用编程接口(API)和底层网络接口集合支持增值服务能力的软件中间件层。ETSI M2M和oneM2M架构两者均定义了服务层。ETSI M2M的服务层称为服务能力层(SCL)。SCL可以在ETSI M2M架构的各种不同节点中实现。例如，服务层的实例可以在M2M装置中实施(其中将其称为装置SCL(DSCL))、在网关中实施(其中将其称为网关SCL(GSCL))、和/或在M2M装置网络节点中实施(其中将其称为网络SCL(NSCL))。oneM2M服务层支持公共服务功能(CSF)(即服务能力)集合。一个或多个特定类型的CSF的集合的实例化称为可以在不同类型的网络节点(例如基础设施节点、中间节点、专用节点)上托管的公共服务实体(CSE)。第三代合作伙伴计划(3GPP)还定义了用于机器类型通信(MTC)的架构。在该架构中，服务层及其提供的服务能力被实施为服务能力服务器(SCS)的一部分。无论是在ETSI M2M架构的DSCL、GSCL或NSCL中、在3GPP MTC架构的服务能力服务器(SCS)中、在oneM2M架构的CSF或CSE中、或者在网络的一些其它节点中具体实施，服务层的实例都可以被实施为在网络中的一个或多个单独节点(包括服务器、计算机、以及其它计算装置或节点，或者作为一个或多个现有节点的一部分)上执行的逻辑实体(例如软件、计算机可执行指令等等)。作为示例，服务层或其组件的实例可以以在具有图32C或图32D所示的一般架构的网络节点(例如服务器、计算机、网关、装置等等)上运行的软件的形式实现。

此外，本申请的逻辑实体(例如节点可用性估计器902、DC 904、DP 906、和/或SP908以及用于产生图形用户界面3102的逻辑实体)可以被实施为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问本申请的服务的M2M网络的一部分。

图32C是M2M网络节点30(例如M2M装置18、M2M网关14、M2M服务器等等)的示例性硬件/软件架构的框图。节点30可以执行或包括逻辑实体(诸如节点可用性估计器902、DC904、DP 906、和/或SP 908以及用于产生图形用户接口3102的逻辑实体)。装置30可以是M2M网络的一部分(如图32A-B所示)或者非M2M网络的一部分。如图32C所示，M2M节点30可包括处理器32、不可移动存储器44、可移动存储器46、扬声器/麦克风38、键盘40、显示器、触摸板、和/或指示器42、电源48、全球定位系统(GPS)芯片集50、和其它外围设备52。节点30还可包括通信电路系统(诸如收发器34和传送/接收元件36)。应当理解，M2M节点30可包括前述元件的任何子组合，同时保持与实施例一致。该节点可以是实施本文所述+SMSF功能的节点。

处理器32可以是通用处理器、专用处理器、传统处理器、数字信号处理器(DSP)、多个微处理器、与DSP核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等等。通常，处理器32可执行在节点的存储器(例如存储器44和/或存储器46)中存储的计算机可执行指令以执行节点的各种所需功能。例如，处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理、和/或使得M2M节点30能够在无线或有线环境中操作的任何其它功能。处理器32可以运行应用层程序(例如浏览器)和/或无线电接入层(RAN)程序和/或其它通信应用。处理器32还可以例如在接入层和/或应用层中执行安全操作，例如认证、安全密钥协商、和/或加密操作。

如图32C所示，处理器32连接到其通信电路系统(例如收发器34和传送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路系统以使得节点30经由它所连接的网络与其它节点通信。特别地，处理器32可以控制通信电路系统以执行本文和权利要求所述的传送和接收步骤。虽然图32C将处理器32和收发器34描述为单独的组件，但是应当理解，可将处理器32和收发器34一起集成在电子封装或芯片中。

传送/接收元件36可以被配置为向其它M2M节点(包括M2M服务器、网关、装置等等)传送信号或从其接收信号。例如，在实施例中，传送/接收元件36可以是被配置为传送和/或接收RF信号的天线。传送/接收元件36可以支持各种网络和空中接口，例如WLAN、WPAN、蜂窝等等。在实施例中，传送/接收元件36可以是被配置为传送和/或接收IR、UV、或可见光信号的发射器/检测器。在另一个实施例中，传送/接收元件36可以被配置为传送和接收RF和光信号两者。应当理解，传送/接收元件36可以被配置为传送和/或接收无线或有线信号的任何组合。

此外，虽然在图32C中将传送/接收元件36描述为单个元件，但是M2M节点30可包括任何数量的传送/接收元件36。更具体而言，M2M节点30可以采用MIMO技术。因此，在实施例中，M2M节点30可包括用于传送和接收无线信号的两个或更多个传送/接收元件36(例如多个天线)。

收发器34可以被配置为调制要由传送/接收元件36传送的信号，并解调由传送/接收元件36接收的信号。如上所述，M2M节点30可具有多模式功能。因此，收发器34可包括多个收发器，用于使得M2M节点30例如能够经由多个RAT(例如UTRA和IEEE 802.11)进行通信。

处理器32可以从任何类型的适当存储器(例如不可移动存储器44和/或可移动存储器46)访问信息并将数据存储在其中。例如，处理器32可将会话语境存储在其存储器中，如上所述。不可移动存储器44可包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、或任何其它类型的存储器存储装置。可移动存储器46可包括用户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等等。在其它实施例中，处理器32可以从在实体上并非处于M2M节点30的存储器(例如在服务器或家庭计算机上)访问信息，并将数据存储在其中。处理器32可以被配置为控制显示器或指示器42上的照明模式、图像、或颜色，以反映M2M服务层会话迁移或共享的状态，或者从用户获得输入，或者向用户显示关于节点的会话迁移或共享能力或设定的信息。在另一个示例中，显示器可以示出关于会话状态的信息。本公开定义了oneM2M实施例中的RESTful用户/应用API。可以在显示器上示出的图形用户界面可以被分层在API的顶部，以允许用户经由本文所述的底层服务层会话功能交互式地建立和管理E2E会话或者其迁移或共享。

处理器32可以从电源48接收电力，并且可以被配置为向M2M节点30中的其它组件分配和/或控制电力。电源48可以是用于为M2M系统供电的任何适当的装置节点30。例如，电源48可包括一个或多个干电池(例如镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等等)、太阳能电池、燃料电池等等。

处理器32还可以连接到GPS芯片集50，GPS芯片集50被配置为提供关于M2M节点30的当前定位的定位信息(例如经度和纬度)。应当理解，M2M节点30可由任何适当的定位确定方法获取定位信息，同时保持与实施例一致。

处理器32还可以连接到其它外围设备52，外围设备52可包括提供附加特征、功能、和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外围设备52可包括加速度计、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口、振动装置、电视收发器、免提耳机、

图32D是也可用于实施M2M网络的一个或多个节点(例如M2M服务器、网关、装置、或其它节点)的示例性计算系统90的方框图。计算系统90可包括计算机或服务器，并且可以主要由计算机可读指令控制，计算机可读指令可以采用软件形式(不管在什么地方或者通过什么手段存储或访问这种软件)。计算系统90可以执行或包括逻辑实体(诸如节点可用性估计器902、DC 904、DP 906、和/或SP 908以及用于产生图形用户界面3102的逻辑实体)。计算系统90可以是M2M装置、用户设备、网关、UE/GW、或者任何其它节点(包括例如移动护理网络的节点)、服务层网络应用提供商、终端装置18、或M2M网关装置14。这种计算机可读指令可以在处理器(例如中央处理单元(CPU)91)中执行，以使得计算系统90进行工作。在很多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单片CPU实现。在其它机器中，中央处理单元91可包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助CPU91。CPU91和/或协处理器81可以接收、生成、以及处理与所公开的用于E2E M2M服务层会话的系统和方法相关的数据，例如接收会话凭证或基于会话凭证进行认证。

在操作中，CPU 91取得、解码和执行指令，并经由计算机的主数据传送路径(系统总线80)往来于其它资源传送信息。这种系统总线连接计算系统90中的组件，并定义用于数据交换的媒介。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线、以及用于发送中断和用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围组件互连)总线。

连接到系统总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许存储和检索信息的电路系统。ROM 93通常包含不容易修改的存储数据。在RAM 82中存储的数据可由CPU 91或其它硬件装置读取或改变。对RAM 82和/或ROM 93的访问可由存储器控制器92控制。存储器控制器92可以提供地址转换功能，该功能在执行指令时将虚拟地址转换为物理地址。存储器控制器92还可以提供存储器保护功能，该功能隔离系统中的处理并将系统处理与用户处理隔离。因此，在第一模式中运行的应用可以仅访问由它自己的进程虚拟地址空间映射的存储器；它不能访问另一个进程的虚拟地址空间中的存储器，除非建立了进程之间的存储器共享。

此外，计算系统90可以包含外围设备控制器83，外围设备控制器83负责将指令从CPU 91传递到外围设备(诸如打印机94、键盘84、鼠标95、以及硬盘驱动器85)。

由显示控制器96控制的显示器86用于显示计算系统90产生的视觉输出。这种视觉输出可包括文本、图形、动画图形、以及视频。可使用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器、或触摸面板来实施显示器86。显示控制器96包括产生发送到显示器86的视频信号所需的电子组件。

此外，计算系统90可以包含可用于将计算系统90连接到外部通信网络(例如图32A和图32B的网络12)以使得计算系统90能够与网络的其它节点通信的通信电路系统(例如网络适配器97)。

应当理解，本文所述系统、方法和处理中的任何一个或全部都可采用在计算机可读存储介质上存储的计算机可执行指令(即应用代码)的形式具体实施，该指令当由机器(诸如M2M网络的节点，例如包括M2M服务器、网关、装置等等)执行时执行和/或实施本文所述系统、方法和过程。具体而言，上述任何步骤、操作或功能(包括网关、UE、UE/GW或移动核心网、服务层或网络应用提供商的任何节点的操作)都可以采用这种计算机可执行指令的形式来实施。逻辑实体(例如节点可用性估计器902、DC 904、DP 906、和/或SP 908以及用于产生图形用户界面3102的逻辑实体)可以采用在计算机可读存储介质上存储的计算机可执行指令的形式具体实施。计算机可读存储介质包括采用用于存储信息的任何非暂时性(即有形或物理)方法或技术实施的易失性和非易失性、可移动和不可移动介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字通用盘(DVD)或其它光盘存储器、磁带盒、磁带、磁盘存储器、或其它磁性存储装置、或可用于存储所需信息并可由计算机访问的任何其它有形或物理介质。

在描述本公开的主题的优选实施例时，如图所示，为了清楚起见采用特定术语。但是，要求保护的主题并非要限于这样选择的特定术语，并且应当理解，每个特定元件都包括以类似方式操作以实现类似目的的所有技术等同物。

本书面描述使用示例来公开本发明，包括最佳实施方式，并且还使得本领域技术人员能够实践本发明，包括制造和使用任何装置或系统以及执行任何并入的方法。本发明的可专利范围由权利要求书限定，并且可包括本领域技术人员能想到的其它示例。如果其它示例具有与权利要求书的字面语言没有不同的元件，或者如果其它示例包括与权利要求的字面语言没有实质差异的等同元件，那么其将落入权利要求书的范围内。