轻量级机器对机器协议与装置管理协议的互工作的制作方法

有关申请的交叉引用本申请要求2014年7月22日提交的美国临时专利申请第62/027,395号的权益，其公开内容通过引用并入本文如同在本文中整体提出。
背景技术：
：开放移动联盟(oma)已经针对网络中的装置管理开发了若干协议，包括oma装置管理(dm)协议、oma网关管理对象(gwmo)协议以及oma轻量级机器对机器(lwm2m)协议。omadm协议可以用于管理网络中的独立式装置(如移动装置)。omagwmo协议可以用于管理网关后面的终端装置，而omalwm2m可以用于管理受约束机器对机器(m2m)或者物联网(iot)装置。图1示出了omadm协议的通用架构。dm服务器102(有时也称为管理服务器)是向在装置或者网关(如装置或者网关104)上操作的dm客户端发送命令以管理该装置或者网关的主实体。dm客户端是在装置或者网关上操作以提供与dm服务器102通信的实体，该dm客户端也称为管理客户端。dm会话是在dm服务器与dm客户端之间创建的omadm协议管理会话。在这两个实体之间的这种会话内发送dm命令。命令在节点上操作，这些节点被逻辑地聚组(group)成在装置上的管理对象(mo)。mo是共同提供一些管理操作(诸如，软件下载(scomo)或者装置信息(devinfomo))的dm节点的集。该mo被组织成称作dm树或者管理树的分层树结构(在图1中的106处示出)。图2图示了示例dm树。dm节点是管理对象或者dm树内的单个元素。该dm节点可以是内部节点或者叶节点。内部节点具有子节点；叶节点不具有子节点并且将包含一些值或者可以由执行命令操作。在omadm协议中，通过oma装置描述框架(ddf)对每个mo进行描述。该ddf是可扩展标记语言(xml)文档，该可扩展标记语言(xml)文档由dm服务器读取以充分描述包含在管理对象内的所有节点，并且该可扩展标记语言(xml)文档描述了可以对每个节点执行什么动作。在ddf中找到的元素是与叶节点相关联的节点名称、节点属性和值。节点属性包括描述框架属性(dfproperties)。这些dfproperties包含关于每个节点的元数据。dfproperties是在mo的指定期间定义的属性，并且示例包括接入类型、默认值、描述、df格式、出现、范围、df标题、df类型以及情况感测。另外，在运行时间生成运行时间属性(rtproperties)，并且其包括诸如接入控制列表(acl)、格式、名称、大小、标题、时间戳、类型、以及版本号的属性。图3示出了ddf文档的简单示例。注意，已经出于简洁之目的省略了dfproperties的细节。在该示例中，ddf描述了具有uri“vendor/isp/gwinfo”的内部节点，并且具有命名为“gwname”的子节点，该子节点包含值“gw.yyy.se”。“vendor”、“isp”、和“gwinfo”是内部节点的名称，而“gwname”是叶节点的名称。ddf文件示出了管理对象的格式和每个节点可以采用的可能的值。客户端和/或服务器负责将值分配给每个节点。将ddf文件提供至dm服务器和dm客户端以实现对应的mo的端到端支持。通常，这是通过dm协议的标准操作在带外进行的。图4图示了gwmo协议的架构。gwmo协议定义中间omadm网关402，该中间omadm网关协助将装置管理功能扩展到不可由dm服务器406直接访问的终端装置。终端装置(诸如，终端装置404a、404b、以及404c)与omadm网关402通信，该网关然后警报新终端装置的dm服务器406。将装置管理命令从dm服务器406发送至omadm网关402，该omadm网关然后根据若干不同操作模式中的一种将命令分布至终端装置。定义了三种模式：透明模式、代理模式和适配模式。在透明模式和代理模式中，终端装置理解本机omadm命令，而适配模式需要从omadm协议转换到非omadm协议。omadm网关402的操作的核心是gwmo组件(未示出)。该实体提供5个mo以管理网关后面的终端装置：装置库存、网关配置、扇出、图像库存以及终端装置触发。这些mo的功能重用与omadm协议相同的消息格式，因此，该实体旨在与omadm系统无缝地发挥功能。gwmo组件的定义允许oma扩展其范围以支持非omadm装置，与现有omadm装置相比，一些非omadm装置可能更受约束。开发lwm2m协议是为了将m2m通信网络的日益普及作为管理这种网络中的m2m装置的一种方式。lwm2m是基于与omadm相同的客户端-服务器架构，但是lwm2m使用具有更适用于受约束装置(诸如，在m2m通信网络中发现的那些装置)的更简单且更扁平化的资源树的不同通信协议。具体地，lwm2m使用受约束应用协议(coap)，并且将其资源树定义为具有在具有较少层级的扁平结构中组织的底层资源的对象。lwm2m中的对象和资源的定义类似于omadm协议中的mo和节点的定义。图5图示了lwm2m架构。如图所示，lwm2m服务器502是omalwm2m协议中的主实体。该lwm2m服务器与lwm2m客户端(例如，lwm2m客户端504)通信以提供装置管理和信息报告能力。lwm2m客户端在m2m或者iot系统内的向lwm2m服务器提供装置管理和信息报告能力的受约束装置(诸如，m2m装置506)上运行。除了支持装置管理之外，lwm2m协议还支持由受约束装置提供的服务使能(serviceenablement)。因为受约束装置主要向其特定应用提供数据测量，所以信息报告是协议中指定的主服务使能中的一种。同样，对象的设计将重点放在提供会支持装置管理和信息报告的资源上。技术实现要素：本文公开的实施例提供对现有omadm和gwmo协议的增强，该增强在能够实现与lwm2m互工作(interworking)的同时提供附加的功能。根据本申请的一个方面，创建新ddfmo以使得能够将lwm2m对象定义添加至dm服务器和网关。该mo允许dm服务器/网关接受新定义的mo(如lwm2m对象定义)。在另一方面，将新过程定义为向新创建的ddfmo注册ddf文档。另一方面涉及将新注册接口添加到gwmo协议中以使lwm2m服务器向dm网关注册终端装置。再一方面引入协议转换机制以在非restful协议与restful协议(如omadm和/或gwmo到lwm2m)之间搭建起了桥梁。提供该
发明内容是为了以简化形式介绍对下面详细说明中进一步描述的构思的选择。该
发明内容不想标识所要求的主题的关键特征或者必要特征，也不想限制所要求保护主题的范围。此外，所要求保护的主题并不限于解决在本公开的任何部分中提到的任何或者全部缺点。附图说明通过下面结合附图以示例的方式给出的具体实施方式可以得到更详细的理解，其中在整个附图中相同的标记指示相同的元件。其中：图1是图示了omadm协议的通用架构的框图。图2示出了omadm协议dm树的示例。图3示出了omadmddf文档的简单示例。图4图示了omagwmo协议的架构。图5图示了omalwm2m协议的架构。图6是根据一个实施例的omagwmo架构的一个实施例的框图，其中，还图示了lwm2m系统的覆盖和本申请的各种方面。图7是图示了根据其一个实施例的新ddfmo的节点的示意图。图8是图示了可以由本文描述的ddfmo注册过程在dm服务器内触发的处理步骤的一个实施例的流程图。图9是图示了用于向ddfmo注册新ddf的方法的一个实施例的调用流。图10a示出了注册ddf警报消息的一个示例，其中，将ddf文件嵌入在该消息中。图10b示出了注册ddf警报消息的另一示例，其中，由uri指定ddf文件的位置。图11是图示了新gwmo装置注册过程的一个实施例的调用流。图12是图示了装置库存mo的结构(如omagwmo协议规范中描述的，但是添加了新节点(所支持的mo)及其子节点)的一个实施例的示意图。图13a示出了装置注册消息的一个示例。图13b示出了注销消息的一个示例。图14示出了包含两个添加命令和一个删除命令的序列命令的示例。图15a和15b共同包括图示了根据其一个实施例的可以由协议转换器执行的协议转换的一个示例的调用流。图16示出了通过使用omagwmo适配操作模式在lwm2m系统和omadm系统之间提供互工作的系统的实施例。图17a、17b、和17c包括图示了根据一个实施例的图16的系统的操作的调用流。图18示出了根据其一个实施例的可以显示的图形用户界面的一个示例。图19a是其中可以实施一个或者多个公开的实施例的示例机器对机器(m2m)、物联网(iot)、或者万物网(wot)通信系统的示意图。图19b是图示了图19a的系统的进一步细节的示意图。图19c是图示了可以用于各种实施例的终端装置的示例架构的示意图。图19d是可以用于实施本文图示和描述的任何逻辑实体的计算机系统或者服务器的框图。具体实施方式上述oma协议的发展反映了作为oma处理的新兴技术的渐进演化。随着对于m2m、iot和万物网(wot)装置的日益高涨的兴趣omalwm2m协议试图提供的更多受约束装置的管理。lwm2m协议不同于前述的omadm和gwmo协议。lwm2m协议使用更有助于受约束装置的具有更扁平化且更简单的资源树的通信协议。数据类型被简化，而且载荷更为高效。因此，lwm2m协议目前与omadm和gwmo协议不兼容。此外，omadm协议缺乏动态支持新装置mo的添加的机制。ddf文档完整地定义在mo内的所有节点及其关联功能，并且该ddf文档由dm服务器、dm网关和dm客户端用来构建其相应的管理树。如果客户端包括dm服务器不具有ddf文件的mo，则dm服务器无法识别该mo。这种机制的省略妨碍了将lwm2m对象定义添加至omadm的能力，并且使lwm2m与omadm的互工作变得更加困难。另外，omagwmo协议缺乏向dm网关动态注册装置的能力。gwmo具有装置库存mo以追踪其在网关后面管理的装置，但是gwmo不定义装置可以用来向其进行注册的接口。不能按照即插即用的方式添加m2m/iot装置——需要首先在gwmo内提供m2m/iot装置。在终端用户正安装装置以与网关通信的部署场景中，缺乏即插即用特征是不可取的。最终，协议转换机制需要在omadm与omalwm2m协议之间搭建起桥梁。这些协议具有极为不同的消息发送要求，并且这些协议是针对不同细分市场而设计的。命令结构和使用是不同的，并且底层传输层协议也是不同的。这些差异需要一些完善定义的转换机制来使系统尽可能无缝地进行互操作。为了解决上面提到的缺陷，本申请公开了允许omalwm2m系统与omadm和gwmo系统进行互操作的互工作机制。根据本文公开的第一方面，将新装置描述框架(ddf)管理对象(mo)定义为允许dm服务器和dm网关识别lwm2m对象。该mo将允许dm服务器/网关接受新定义的mo(如lwm2m对象定义)。根据本文公开的第二方面，将新ddf注册过程定义为支持动态添加或者更新新定义的ddf。一旦将lwm2m对象转换为ddf格式，则可以向dm服务器或者dm网关注册生成的文档。该特征允许dm服务器和dm网关将lwm2m对象识别为dmmo。根据本文公开的第三方面，将新gwmo注册过程定义为允许装置通过lwm2m服务器向dm网关注册其自身。新注册过程将lwm2m装置“注册”操作扩展为向dm网关注册装置。在lwm2m服务器已经完成了“注册”操作之后，lwm2m服务器将其具有的关于装置的信息发送至dm网关作为新注册过程的一部分。dm网关转而使用关于装置的信息来更新装置库存mo。该特征允许m2m/iot装置动态地“即插即用”到omadm系统中。根据本文公开的第四方面，将协议转换机制定义为支持lwm2m到omadm协议的互工作。omadm不是restful协议，而lwm2m是restful——需要一些转换来使lwm2m到dm互工作。另外，一些dm命令需要保持状态信息以处理命令——需要将这些命令转换为restful命令，并且由互工作的功能保持状态信息以协助转换。图6是omagwmo架构的一个实施例的框图，其中，还图示了lwm2m系统的覆盖和本申请的各种方面。如所示，在该实施例中，omadm服务器601与omadm网关602通信。omadm网关602可以经由其透明模式与一些终端装置(如移动装置604)通信，并且可以经由其代理模式与其它终端装置(如计算机606)通信。另外，omadm网关602可以经由其适配模式与omalwm2m服务器608通信。lwm2m服务器608与若干典型受约束装置(如m2m装置610a、610b、和610c)通信，并且管理该若干典型受约束装置。图6进一步图示了本文描述的机制和过程可以如何覆盖在图示的架构上。例如，可以将新定义的ddfmo612存储在omadm服务器601与omadm网关602两者中。可以在omadm服务器601与omadm网关602之间以及在omadm网关602与omalwm2m服务器608之间执行本文描述的ddfmo注册过程614的方面。可以在omalwm2m服务器608与oma-dm网关602之间执行协议转换功能/实体616和gwmo装置注册过程620。在各种实施例中，lwm2m服务器608和dm网关602可以位于同一位置或者它们可以分离地定位。协议转换功能/实体616可以是分离的实体或者其可以是dm网关602或者lwm2m服务器608的一部分。本文描述的机制和过程的益处是它们进一步使装置管理操作与m2m服务层体系结构趋同。目前，如etsim2m和onem2m这样的体系结构已经将omadm指定为用于执行装置管理的手段。然而，并未完全指定在当前omadm和gwmo协议内的m2m/iot装置的管理。随着引入lwm2m协议和本公开中呈现的机制与协议，可以用服务层架构来充分实现m2m/iot的管理。部署然后可以利用这些增强，例如，在dm服务器601是m2m服务器的一部分而dm网关602是m2m网关的一部分的情况下。终端装置，如终端装置604、606、或者610a-c，可以包括能够在无线网络中进行通信的任何无线装置(如m2m或者mtc装置)，包括：例如，机器、传感器、电器等、移动站、固定或者移动用户单元、寻呼机、个人数字助理(pda)、计算机、移动电话或者智能电话或者能够在有线或者无线环境中操作的任何其它类型的装置。下文结合图19c描述了终端装置的示例架构。在本申请中，终端装置(如终端装置604、606、和610a-c)还可以称为omadm客户端。在一个实施例中，omadm服务器601、omadm网关602、协议转换器616、和omalwm2m服务器608可以是存储在计算系统或者服务器的存储器中、并且由该计算系统或者服务器的处理器执行的体现为计算机可执行指令的形式的逻辑实体(如软件)。下文结合图19d描述了其中可以实施这些逻辑实体的示例计算系统或者服务器。在其它实施例中，可以将这些实体整体实施在硬件或者硬件和软件的任何组合中。尽管图中将图6中图示的各种网络实体(诸如，omadm服务器601、omadm网关602、协议转换器616、和omalwm2m服务器608)图示为分离的计算机系统或者服务器，但是要理解，可以将这些网络实体中的任何两个或者更多个体现为单个计算系统或者服务器中的分离的逻辑实体。而且，要理解，在实施或者执行本文描述的ddfmo注册过程614、协议转换功能616、和gwmo装置注册过程620的omadm服务器601、omadm网关602、和omalwm2m服务器608中的功能还可以实现为在相应的服务器601、602、或者608中的一个或者另一计算机系统或者服务器(未示出)的处理器上执行的计算机可执行指令(如软件)、或者硬件和软件的任何其它组合的形式。装置描述框架管理对象(ddfmo)在omadm协议中，oma装置描述框架(ddf)定义在管理对象内的所有节点、它们相关联的属性以及它们的值。同样在omadm协议中，dm服务器、dm网关和dm客户端可以使用ddf中的信息来构建其相应版本的omadm管理树。通常，从带外将ddf文档提供给这些实体，并且该提供在实际操作之前发生。本文公开的内容是用于使具有新定义的ddf的装置在不中断dm服务器的操作的情况下通知dm服务器并且上传其ddf文档的机制。具体地，本文公开了新ddfmo612，以供在dm服务器(例如，dm服务器601)和dm网关(例如，dm网关602)中使用。要理解，以下关于在dm服务器中使用新ddfmo的任何讨论同样适用于在dm网关中使用该ddfmo，反之亦然。在本实施例中，新定义的ddfmo612可以驻留在与其它mo相同的dm树中，并且将保存dm服务器支持的所有mo的ddf的副本。在各种实施例中，可以或者在dm服务器中的接口内通过web服务api接口、或者通过由dm客户端执行的新ddf注册过程向dm服务器注册mo——下面进一步描述了其所有方法。图7示出了用于新ddfmo612的结构的一个实施例。在该实施例中，结构允许dm服务器支持mo的多个版本。同样，在该实施例中，可以将ddfmo预先提供给dm服务器以在启动时在dm树的dm服务器的版本中建立ddfmo的结构。在一个实施例中，ddfmo可以驻留在dm树的根节点处，然而，在其它实施例中，其可以驻留在另一位置处(若需要)。下文使用omadm技术描述了对图7的ddfmo的每个节点的描述。列出的所有uri与./ddfmouri(即，ddfmo的基本uri)相关。在下面的描述中，“状态”指示节点是必选的还是可选的，“树出现”指示在ddfmo中可以出现节点的多少实例，“格式”指示节点的数据格式，并且“访问类型”指示可以对节点执行的操作(如获取、添加、复制和删除)。uri:./<moname>该占位符节点包含mo的名称，在子节点中引用该mo的ddf。示例包括scomo、fumo、devinfo等。状态树出现格式访问类型必选零个或更多个节点获取、添加、复制、删除uri:./<moname>/<mover>该占位符节点包含mo(在子节点中引用该mo的ddf)的版本。该节点的存在允许dm服务器支持相同mo的不同版本，例如，版本1.0和1.1。状态树出现格式访问类型必选一个或更多个节点获取、添加、复制、删除uri:./<moname>/<mover>/objectid该叶节点包含dm服务器可以用来识别mo的对象id。优选地，其是dm树内唯一指定的id。状态树出现格式访问类型必选一个int/chr获取、添加、替换uri:./<moname>/<mover>/ddfname该叶节点包含ddf的名称。状态树出现格式访问类型可选零个或一个chr获取、添加、替换uri:./<moname>/<mover>/description该叶节点包含在上代节点中引用的mo版本的描述。状态树出现格式访问类型可选零个或一个chr获取、添加、替换uri:./<moname>/<mover>/status该叶节点包含节点的操作的状态。当创建上代节点(<moversion>)时，dm服务器自动将该节点设定为默认值(0)。然后，dm服务器将根据由客户端执行的操作来适当地设定该节点。在一个实施例中，可允许的值为：·0-不存在ddf(默认):这是指定不存在ddf的默认状态。·1-已上传：该状态指定ddf已经上传到dm服务器/网关。·2-已启用：该状态指定mo可供使用——dm服务器/网关已经验证了上传的ddf格式正确。·3-错误：如果ddf文档异常，则dm服务器将状态字段设定为错误以指示无法处理ddf。·4-已禁用：该状态指定先前启用的mo现在被禁用。当处于该状态时，无法创建新的mo，但是可以呈现现有mo。该状态用于在保留较旧版本的功能的同时升级到mo的较新版本。状态树出现格式访问类型必选一int/chr获取、无替换uri:./<moname>/<mover>/protocolname该叶节点包含底层ddf的协议名称，并且由dm服务器/网关用来确定要使用哪个gwmo模式。可允许的值为：·0-omadm(默认)·1-omalw2mw状态树出现格式访问类型必选一个int/chr获取、添加、替换uri:./<moname>/<mover>/ddffile该叶节点包含本地存储在dm服务器中的ddf的实际文件。该节点与./<moname>/<moversion>/ddfuri节点相互排斥。每次只有一个节点是活跃的。状态树出现格式访问类型必选零个或一个空(null)获取、添加、替换uri:./<moname>/<mover>/ddfuri该叶节点包含存储ddf文件所在处的uri。状态树出现格式访问类型必选零个或一个chr获取、添加、替换uri:./<moname>/<mover>/operations该内部节点是针对ddfmo支持的所有动作的父节点。状态树出现格式访问类型必选一个节点获取、不可替换uri:./<moname>/<mover>/operations/upload该叶节点是用于使执行命令上传ddf文件的目标节点。一旦执行命令完成，则由dm服务器将状态设定为上传。状态树出现格式访问类型必选一个空获取、执行uri:./<moname>/<mover>/operations/uploadactivate该可选叶节点是执行命令上传ddf文件并且一旦上传完成则启用其操作的目标节点。一旦执行命令完成，则由dm服务器将状态设定为启用。状态树出现格式访问类型可选一个空获取、执行uri:./<moname>/<mover>/operations/activate该叶节点是执行命令在其已经进行了上传之后启用引用的ddf的目标节点。一旦执行命令完成，则由dm服务器将状态设定为启用。状态树出现格式访问类型必选一个空获取、执行uri:./<moname>/<mover>/operations/deactivate该叶节点是执行命令在其已经被置于操作之后禁用所引用的mo的目标节点。当mo被禁用时，dm服务器将基于ddf不会允许新mo的创建，但是将允许现有mo操作。该特征用于在保持与较旧版本的兼容性的同时更新mo版本。一旦执行命令完成，则由dm服务器将状态设定为禁用。状态树出现格式访问类型必选一个空获取、执行uri:./<moname>/<mover>/operations/ext该内部节点向ddfmo提供对供应商专有的或未来的omadm扩展。状态树出现格式访问类型可选零个或一个节点获取uri:./<moname>/<mover>/ext该内部节点向ddfmo提供对供应商特定的或未来的omadm扩展。状态树出现格式访问类型可选零个或一个节点获取uri:./<moname>/ext该内部节点向ddfmo提供对供应商专有的或未来的omadm扩展。状态树出现格式访问类型可选零个或一个节点获取uri:./ext该内部节点向ddfmo提供对供应商特定的或未来的omadm扩展。状态树出现格式访问类型可选零个或一个节点获取ddfmo注册过程614根据一个实施例，一旦dm服务器正在运行并且已经创建了上述的ddfmo的节点，则可以通过向dm服务器注册其ddf文件而添加新mo或动态更新现有mo。此处描述了用于注册新mo的ddf的多个实施例。在第一实施例中，可以由dm服务器管理员或授权用户，例如通过使用dm服务器的管理用户界面，向dm服务器本地注册新mo的ddf或用于对现有mo进行更新的ddf。在该第一实施例中的注册过程与如何提供当前mo类似，但是不同的是可以在dm服务器标准操作期间动态提供mo。通过使用到dm服务器的用户接口，dm服务器管理员甚至授权用户可以将ddf文件上传到dm服务器。这可以在dm服务器正在处理用于装置和来自装置的正在进行的dm命令时进行。一旦上传了ddf文档，则可以启用ddf，并且可以通过相同的用户接口来使用该ddf。在启用过程期间，可以相对于新上传的文件运行ddf检查器以确保其具有有效语法，即，确保其符合由omadm协议指定的ddf文件的要求。如果ddf检查器验证ddf文档有效，则dm服务器将ddfmo中的新mo的状态节点(如上文描述的)设定为启用；如果ddf检查发现ddf文档中的错误，则dm服务器将状态节点设定为错误。图8是示出可由本文描述的ddfmo注册过程在dm服务器内触发的处理步骤的一个实施例的流程图。一旦已经上传了xml格式的ddf文件，则在步骤802中，由ddf读取器读取ddf文档以解析xml文档。然后，在步骤804，可以做出关于是否要验证ddf文档的决策。如果不进行验证，则控制转到步骤808，在步骤808中，为了进行处理将ddf文档传递到实施omadm协议功能的dm服务器的软件组件(下文称为“dm引擎”)。如果要执行验证，则控制转到步骤806，在步骤806中，ddf检查器可以在将新ddf文件发送至dm引擎之前验证是否符合正确的ddf规则/语法。例如，ddf检查器可以分析ddf文档以确保其语法和格式符合omadm协议规范的要求。如果在ddf文件的格式中检测到错误，则控制可以转到步骤814，其中，dm服务器的dm引擎创建./ddfmo/<moname>/<mover>/status节点并且将值设定为错误状态。如果在步骤806中未检测到错误并且ddf文件已经过验证，则控制转到步骤808，并且将ddf文件传递至dm引擎。在步骤810，dm引擎然后将继续到为新ddf文件表示的mo创建图7中示出的对应的ddfmo。即，dm引擎将在存储器中创建实现每个这些节点的数据结构。在节点创建之后，在步骤812，dm引擎将./ddfmo/<moname>/<mover>/status节点设定为启用状态。在第二实施例中，可以通过使用由dm服务器提供的web服务应用编程接口(api)来向dm服务器注册新的或更新的mo的ddf。该实施例允许非omadm实体将其资源树传送至dm服务器以提供更无缝的互工作。可以使用该机制的非omadm实体的一个示例是lwm2m服务器。可以将每个lwm2m对象转换为ddf文件，并且通过web服务api将每个lwm2m对象上传至dm服务器。在已经上传了ddf之后，如上文描述的那样执行图8的步骤。在第三实施例中，可以使用新注册过程经由dm协议从dm客户端或dm网关向dm服务器动态注册新mo或更新的mo的ddf。可以通过创建新的注册ddf警报消息来实施该实施例。当前，dm客户端可以使用具有警报代码1201的警报消息来创建针对dm服务器的dm会话。这指示与dm服务器建立dm会话的“客户端发起的管理会话”请求。在该第三实施例中，添加可以用于指示dm客户端具有新ddf文件要上传的附加警报代码。在一个实施例中，新的警报消息可以包括以下数据：·<meta>/<type>元素：包含警报内容的媒体类型。示例值可以是“urn:oma:at:oma-ddfmo:registerddf:1.0”。·<meta>/<format>元素：包含警报的格式。根据是否分别指定<source>/<locuri>元素或<item>/<data>元素，该值可以是“chr”或“xml”。·<source>/<locuri>元素：包含ddf文件可以由dm服务器检索之处的uri。在一个实施例中，该元素与<item>/<data>元素相互排斥。如果一个存在，则另一个将不存在。·<target>/<locuri>元素：包含应该存储ddf文件的目标dm树的目标uri。·<item>/<data>元素：在<data></data>标签内包含xml格式的ddf文件的内容。如提到的，在上述的一个实施例中，该元素与<source>/<locuri>元素相互排斥。如果一个存在，则另一个将不存在。应理解，执行图8中图示的步骤的dm服务器是可以被实现为存储在网络节点或计算机系统(诸如，图19d(说明如下)中图示的计算机系统)的存储器中的、并且在该网络节点或计算机系统的处理器上执行的软件(即，计算机可执行指令)的形式的逻辑实体。图8中图示的方法可以实现为存储在dm服务器的存储器中的软件(即，计算机可执行指令)的形式，该计算机可执行指令在由dm服务器的处理器执行时，执行图8中图示的步骤。还应理解，可以由dm服务器的通信电路系统(例如，图19d的电路系统97)在其处理器和该处理器执行的计算机可执行指令(例如，软件)的控制下执行图8中图示的任何传输和接收步骤。图9是图示了用于向ddfmo注册新ddf的该第三实施例的一个示例的调用流。在该示例中，由dm网关/客户端902和dm服务器904执行步骤。注意，dm客户端还可以按照与图9中概述的方式相同的方式来对dm网关或dm服务器执行ddfmo注册过程。如图所示，在步骤1中，dm网关获得新ddf文档。在步骤2中，dm网关发起与dm服务器的dm会话。另外，其发送注册ddf警报消息和对ddfmo的上传启用节点的执行命令。在该实施例中，假设是在注册ddf警报消息而不是在包含ddf文件本身的文本的警报消息中提供ddf文件的位置的uri。在步骤3中，dm服务器接收注册ddf警报消息并且从所提供的uri取得ddf文档。dm服务器然后可以使用ddf检查器来验证ddf文档。如果验证成功，则dm服务器可以将./<moname>/<moversion>/status节点设定为启用。然后，在步骤4中，dm服务器可以将执行命令的状态连同用于确认注册过程完成的警报一起发送至dm网关。在步骤5中，dm网关可以发送注册完成的状态。在步骤6中，dm服务器可以应答客户端状态，并且关闭dm会话。图10a示出了注册ddf警报消息的一个示例，其中，将ddf文件嵌入在消息中。图10b示出了注册ddf警报消息的另一示例，其中，由uri指定ddf文件的位置。gwmo装置注册过程620omagwmo协议规范定义装置库存mo，该装置库存mo向dm网关提供一种用于维持一系列终端装置连接到网关的方式。然而，不存在被指定为如何向dm网关注册终端装置的机制。作为本申请的另一方面，本文公开的内容是其中lwm2m服务器可以向dm网关注册终端装置并且向该dm网关提供装置支持的mo列表的新的装置注册过程620。在一个实施例中，该装置注册过程可以被应用于任何非omadm服务器(诸如，coap资源目录(rd)、etsim2m服务器、或onem2m公共服务实体)。另外，lwm2m服务器可以直接与dm服务器而不是dm网关通信并且可以提供与dm网关相同的功能。图11是图示了新的gwmo装置注册过程620的一个实施例的调用流。如图11中图示的，过程中涉及的实体为lwm2m客户端906、lwm2m服务器608、协议转换器616、和dm网关602。可以按照相应的omalwm2m协议和omadm协议规范中陈述的方式来实施lwm2m客户端、lwm2m服务器和dm网关实体，但要根据需要对其进行修改以实施本文描述的新gwmo装置注册过程。协议转换器616是新的逻辑实体，这在下文中进一步详细描述。在图11中，将协议转换器616示出为分离的实体。然而，在其它实施例中，可以将协议转换器616集成为lwm2m服务器608或dm网关602的一部分。参照图11，在步骤1，lwm2m客户端(装置)906向lwm2m服务器608进行注册并且提供装置支持的lwm2m对象的列表。根据现有omalwm2m协议规范指导该注册步骤。在步骤2b，lwm2m服务器用创建的消息来对装置作出响应，并且在步骤2a，将关于装置及其所支持的对象的信息转发至协议转换器。在其它实施例中，lwm2m服务器还可以在该步骤期间提供ddf文档。如果lwm2m服务器在该步骤期间提供ddf文档，则可以省略下面描述的步骤6至9。在步骤3，协议转换器使用其接收的信息来创建装置注册请求。在其中协议转换器提供有由装置支持的lwm2m对象的ddf文档的其它实施例中，其还可以将该ddf文档与装置注册请求一起进行发送。另外，这将移除对执行下文描述的步骤6至9的需要。在步骤4，协议转换器将装置注册请求发送至dm网关。在步骤5，dm网关将发现其无法在ddfmo中针对该装置支持的lwm2m对象找到mo。如果提供了ddf文档，则控制将直接转到步骤10，其中，针对每个被提供了ddf文档的新lwm2m对象——这被dm网关视为新的mo，dm网关将在其ddfmo中创建节点集合以存储该新lwm2m对象(即新mo)的ddf文档和其它信息。按照这种方式，向dm网关的dm树注册并且添加了新对象(mo)。然而，如果尚未向ddf文档提供装置注册请求，则控制继续到步骤6。在步骤6，dm网关将对ddf文档的请求发送至协议转换器。在步骤7中，协议转换器将请求转发至lwm2m服务器。在步骤8中，lwm2m服务器通过发送回lwm2m客户端装置的对象(即，mo)的ddf文档或这些ddf文档的uri来进行响应。在步骤9，协议转换器将注册ddf警报消息发送至dm网关。在步骤10，dm网关如上述更新其ddfmo并且完成注册过程。该dm网关也更新其装置库存mo。在步骤11，dm网关通过协议转换器将装置注册完成消息发送至lwm2m服务器。图12是图示了根据实施例的装置库存mo的结构的图——如omagwmo协议规范中描述的，但是添加了新节点——所支持的mo820及其子节点822和824。可以使用这些新节点按照与omadm协议规范的列表mo相似的方式来追踪特定装置支持的mo(如lwm2m对象)。在装置库存mo内包含所支持的mo节点820确保合适的ddf文档存在于dm网关的ddfmo中。如果文档不存在，则dm网关可以向lwm2m服务器或协议转换器进行警报以在上述装置注册过程期间提供ddf文档。在一个实施例中，在lwm2m服务器上传并且启用ddfmo中的ddf条目之后，由dm网关填写节点。下面是根据一个实施例的对新的节点及其dfproperties的说明：uri:./<x>/inventory/records/<x>*/supportedmo该内部节点820是用于列出装置支持的所有mo的父节点。状态树出现格式访问类型必选一个节点获取uri:./<x>/inventory/records/<x>*/supportedmo/<x>*该占位符节点822提供装置支持的mo的名称。状态树出现格式访问类型必选零个或更多个节点获取、添加、替换、删除uri:./<x>/inventory/records/<x>*/supportedmo/<x>*/moverref该叶节点824的值在指向装置支持的ddf的版本的dm树内提供uri的节点名称。该值必须与ddfmo中的注册的ddf文件的值相匹配，例如，./ddfmo/<moname>/<moversion>。如果值不匹配，则dm网关需要在装置注册过程期间从lwm2m服务器或协议转换器请求ddf文档。状态树出现格式访问类型必选一个chr获取在一个实施例中，可以通过新的dm命令(本文中称为注册命令)实施图11中图示的装置注册过程。在实施例中，注册命令将1.2.1版oma装置管理表示协议的原子命令和序列命令的属性要求进行组合，这意味着要求dm网关按照从属命令的指定次序并且以统一的方式来处理注册命令内的所有从属命令。这些要求对确保将关于装置的所有信息正确输入到dm网关中非常重要。优选地，已经向涉及的装置提供凭证以与dm网关适当通信，无论该装置是工厂引导还是动态引导。在一个实施例中，可以在注册命令中指定以下信息：1.其中创建了装置库存记录的目标路径，例如，其中指定<x>的./<x>/inventory/records/<x>。在一个实施例中，该项在注册消息中是必选。2.装置id字段——在一个实施例中，如果装置具有在devinfomo中找到的devid，应该指定该字段。如果装置不具有这种节点，则注册消息可以不包括该字段——在未指定该字段时，dm网关可以分配值。如果提供图12的装置库存mo的deviceid(设备id)节点作为装置注册过程的一部分，则将对该deviceid节点填充该值。3.装置类型字段——指定devdetailmo的devtype节点中找到的装置类型。在一个实施例中，针对非omadm装置，可以指定诸如“m2m装置”的值。在一个实施例中，该项在注册消息中是必选。如果提供图12的装置库存mo的devtype节点作为装置注册过程的一部分，则将对该devtype节点填写该值。4.操作模式——如果向装置提供其可以在哪个gwmo操作模式中操作的知识，则其可以指定该字段的值。如果装置是非omadm兼容的，则在一个实施例中，可以将该字段设定为4，其指定使用适配模式。如果提供图12的装置库存mo的模式节点作为装置注册过程的一部分，则将对该模式节点填充该值。在接收注册命令时，dm网关可以创建在装置注册消息的从属添加命令(例如，图13a的示例从属添加命令)中找到的指定节点，并且如果成功，则其将提供装置库存mo的网络连接性节点lanref826，addresstype(地址类型)828、和address(地址)830。该信息对dm网关已知。即，dm网关提供(潜在地)装置可以连接的各种网络连接(wifi、蓝牙等)。当部署dm网关时，dm网关知道这些连接选项。针对每个连接性选项在装置库存mo树的./<x>/inventory/lan节点下方(参见图12)存在一个条目。图13a示出了装置注册消息的一个示例。在装置注册过程期间，如果在dm网关的ddfmo中未找到所支持的mo，则lwm2m服务器或协议转换器可以使用ddfmo注册过程来上传ddf。一旦装置注册过程完成，则dm网关将装置附接警报发送至dm服务器以通知该dm服务器已经向dm网关注册了新的装置并且现在可以对其进行管理。当装置向lwm2m服务器注销其自身时，可以执行装置注销过程以通知dm网关该装置不再可用。可以发送相同的注册命令，但是该注册命令内部带有删除命令而不是添加命令。这会删除由初始装置注册过程创建的记录条目。dm网关转而可以从装置库存mo移除指定节点，并且向dm服务器发送装置分离警报以通知服务器装置不再可用于管理。图13b中示出了注销消息的一个示例。协议转换互工作可以使用本文公开的协议转换功能来将omadm协议转换为lwm2m协议，反之亦然。在各种实施例中，这可以按照三种不同方式中的一种来实现：1)在lwm2m服务器内内部地；2)在与lwm2m服务器分离的接收所有消息的实体外部地；或3)作为dm网关的组件。在第一种实施方式的情况下，dm客户端可以集成到lwm2m服务器，并且可以将其更新为支持上述针对ddfmo注册和装置注册的新的注册过程。对第二种实施方式，lwm2m服务器可以向外部协议转换互工作实体发送其接收的所有消息，并且让该实体执行这部分中提出的转换。对第三种实施方式，dm网关可以支持接收lwm2m消息，并且还可以更新为支持针对ddfmo注册和装置注册的新的注册过程。表1根据本文公开的协议转换器的一个实施例(例如，图11中图示的协议转换器)，表1描述了在omadm命令与lwm2m操作之间的协议转换和从lwm2m操作到omadm命令的协议转换。可以根据请求者是哪一方由协议转换器来执行该转换。如表1中提到的，协议转换器处理原子和序列dm命令的转换的方式将在下文中进行更完整地描述。通过附加背景的方式，omadm协议在http/tcp顶部操作，且因此依赖tcp协议以在服务器与客户端之间维持面向会话的通信。在另一方面，omalwm2m在coap/udp上操作，且因此其需要利用coap的可确认和重传机制来获得接收者的认可。这在为原子和序列dm命令服务时尤为重要，其中指定要一起处理一组dm命令。如先前提到的，在omadm协议中，在dm服务器与dm客户端之间创建dm会话以在这两个实体之间传输dm命令。该管理会话是在tcp协议的上下文内创建的，该tcp协议是在这两个端点之间提供可信且有序的通信的面向连接的协议。omalwm2m使用称为udp的较轻量级的传输层协议，该传输层协议是提供适用于受约束装置的低开销和降低延迟的无连接协议。因此，在将lwm2m和omadm互工作时，需要在面向连接的协议与无连接协议之间(反过来亦然)搭建起桥梁的机制。在omadm协议中，可以将命令作为单个命令传输或将其分组在一起在原子命令或序列命令内传输。每个命令具有相关联的命令id(cmdid)，用于将其自身与其它命令区分开。在一个实施例中，在发送单个命令时，可以将该cmdid用作用于从omadm到lwm2m的转换的coap令牌。针对原子命令和序列命令，可以有针对该组命令的cmdid，且针对该组内的每个命令有分离的cmdid。图14示出了包含两个添加命令和一个删除命令的序列命令的示例。序列命令具有cmdid，并且添加命令和删除命令中的每一个具有其自己的cmdid。原子命令的结构与具有多个cmdid的序列命令的结构相似。针对这些情况，在一个实施例中，可以将原子命令或序列命令内的命令的cmdid映射至coap消息id，而原子命令或序列命令的cmdid可以映射至令牌。除了将cmdid映射至coap令牌和消息id之外，本申请的协议转换器对原子命令和序列命令两者的要求做出了解释。针对原子命令，要求是将所有从属命令作为集合执行，并且作为一个单元成功或失败。如果未满足该要求，则所执行的所有从属命令需要回到其先前状态。因此，本文描述的协议转换功能在执行所有从属命令之前和之后追踪受到影响的节点的状态。如果在原子命令内任何从属命令执行失败，则协议转换器必须撤销所有之前执行的从属命令。因此，在一个实施例中，协议转换器首先检索节点的状态，并且在执行从属命令之前保存该状态。序列命令也提供将命令分组在一起的能力，但是序列命令的不同之处在于：其唯一的要求是要按照指定次序执行命令。在原子命令内的从属命令不保证按照次序执行。在这种情况下，在一个实施例中，协议转换器追踪从属命令的执行序列。针对其中lwm2m服务器具有从dm服务器的装置采集的数据的信息报告情况，lwm2m服务器可以将瞄准lwm2m对象的uri的通用警报与从装置采集的数据一起发送至dm网关，该dm网关然后会将消息中继至dm服务器。替选地，在另一实施例中，可以将警报节点添加至lwm2m对象的ddf文件，lwm2m服务器然后可以对该lwm2m对象的ddf文件执行普通omadm命令。图15a和15b共同包括图示了可以由本文公开的协议转换器616针对dm序列命令(其在与dm网关602相关联的第一文本框850中示出)执行的协议转换的一个示例的调用流。注意，在该示例中，图中将协议转换器616和lwm2m服务器608示出为两个分离的实体。然而，在其它实施例中，协议转换器616和lwm2m服务器608可以作为一个实体共存。由协议转换器按照次序处理从属命令获取(get)、替换(replace)、和执行(excute)，并且分别将其转换为读取(read)、写入(write)、和执行操作。如图所示，用于lwm2m操作的令牌都指向序列命令的cmdid而不是单独的从属命令。根据lwm2m技术规范，oma的候选版本1.0，示出的uri与具有前缀“/3”的lwm2m装置对象对应。转换的细节如下。将序列cmdid映射至在协议转换器与lwm2m服务器608之间使用的coap令牌。该coap令牌还在lwm2m服务器608与lwm2m客户端906之间使用。将get/3/0从属命令映射至read/3/0操作，其对装置上的/device/manufacturer(/3/0)资源执行读取。针对/3/0资源返回值“开放移动联盟”。将replace/3/1从属命令映射至write/3/1操作，其对装置上的/device/modelnumber(/3/1)资源执行写入。将值“轻量级m2m客户端”写入到/3/1资源中。将execute/3/4从属命令映射至执行装置的重启的execute/3/4操作。在装置将“2.04更改的”响应返回至执行操作之后，协议转换器处理对dm网关的状态响应。在对dm网关的响应中，首先给出针对每个dm命令的状态，并且随后是获取操作的结果。使用gwmo的omalwm2m至omadm的互工作随着m2m/iot装置的市场需求的增长，因为装置通常部署在难以到达的位置(如楼宇、桥梁、交通信号灯等)中，所以拥有管理这些m2m/iot装置的机制变得更为重要。omadm服务提供商可以提供dm服务器和dm网关的主干基础设施，并且将其服务提供给m2m/iot服务提供商，该m2m/iot服务提供商然后提供并且操作m2m装置。图16示出了通过使用omagwmo适配操作模式而在lwm2m系统和omadm系统之间提供互工作的系统700的实施例。在该实施例中，lwm2m系统包括lwm2m装置712，该lwm2m装置712包括lwm2m对象714、lwm2m客户端706、和lwm2m服务器708。omadm系统包括gwmo组件(dm网关)702和dm服务器704。如在上文的其它实施例中讨论的，dm网关702和dm服务器704两者均保持ddfmo(即，如本文中描述的ddfmo612)作为其dm树的一部分以允许注册新的mo。使用上述提出的ddfmo注册过程的实施例中的一个来将lwm2m对象714转换成ddf格式并将其提供给dm网关702。可以例如由标准机构或由供应商在带外执行lwm2m对象到ddf格式的转换。执行这种转换的一种方式使将lwm2m对象一对一地映射至omadmmo，从而进行数据类型转换。dm网关702将转而使用上述的新的ddfmo注册过程614来通知描述lwm2m对象714的新的ddf的dm服务器704。这些过程允许dm网关702和dm服务器704两者均在其相应的dm树内识别lwm2m对象并且支持对其执行的动作。一旦将lwm2m对象714添加至ddfmo，则lwm2m服务器708可以使用上述新的gwmo装置注册过程620来将其数据库中的装置信息提供给dm网关702。dm网关702然后将使用omagwmo协议规范的装置附接警报消息来警报dm服务器新的装置704。此时，dm服务器704将具有关于装置的所有信息并且可以使用omadm协议来执行装置管理。针对信息报告情况，装置将其测量报告给lwm2m服务器708，该lwm2m服务器708然后通过协议转换器616来将消息转发至dm网关702。dm网关702可以在omadm协议的通用警报消息中将装置测量发送至dm服务器704。图17a、17b、和17c包括详细图示了根据图16中图示的实施例的上述过程的调用流。如图17a所示，在步骤1至2中，在装置712上运行的lwm2m客户端706根据omalwm2m协议规范向lwm2m服务器进行注册。在步骤3至6中，执行上文详细描述的新的gwmo装置注册过程620。在步骤7至6中，执行上文详细描述的新的ddfmo装置注册过程614。在步骤9至10中，dm网关702将装置附接警报发送至dm服务器704。现在参照图17b，在步骤11至19中，dm服务器704执行getdevinfo请求。根据omadm协议执行步骤11和18，根据lwm2m协议执行步骤14至15，并且根据本文描述的互工作过程执行剩余步骤。最后，参照图17c，在步骤20至24中，lwm2m客户端706将具有传感器测量的通知消息发送至dm服务器704。根据lwm2m协议执行步骤20，根据本文公开的互工作过程执行步骤21至22，并且根据omadm协议执行步骤23。如上文提到的以及下文描述的，执行图9、11、15a-b、和17a-c中图示的步骤的实体是可以被实现为存储在连接至网络的计算机系统(诸如，图19d(说明如下)中图示的计算机系统)或服务器的存储器中的、并且在该计算机系统或服务器的处理器上执行的软件(即，计算机可执行指令)的形式的逻辑实体。而且，可以按照存储在相应实体的存储器中的软件(即，计算机可执行指令)的形式来实施图9、11、15a-b、和17a-c中图示的方法，该计算机可执行指令在由实体的处理器(例如，图19d的处理器91)执行时执行图9、11、15a-b、和17a-c中图示的相应步骤。还要理解，在这些图中图示的任何传输和接收步骤可以在实体的处理器和该处理器执行的计算机可执行指令(例如，软件)的控制下由通信电路系统(例如，图19d的电路系统97)执行。示例图形用户界面图18示出了根据一个实施例的可以由dm服务器或dm网关(诸如，图6的dm服务器601或dm网关602、或图16的dm网关702或dm服务器704)显示的图形用户界面950的一个示例。可以将图形用户界面950显示在dm服务器或dm网关的显示器上(诸如，如下所述，可以实施dm服务器或dm网关的图19d的计算机系统的显示器86)。如图所示，可以使用图形用户界面950来向用户(例如，网络管理员)指示lwm2m协议集成到dm协议中。在示出的实施例中，图形用户界面可以包括显示由服务器/网关支持的管理对象(mo)列表的第一窗口952，根据上述方法，该列表可以包括omadmmo对象以及lwm2m对象。可以将由服务器/网关管理的装置显示在界面950的窗口954中。同样在该实施例中，另一窗口956可以显示所选择的装置(从窗口954中的列表选择的)的资源树，其中，根据本文公开的原理，装置可以包括lwm2m装置。示例m2m/iot/wot系统图19a是可以实施一个或更多个公开的实施例的示例机器对机器(m2m)、物联网(iot)、或万物网(wot)通信系统10的示意图。通常，m2m技术为iot/wot提供建筑块，并且任何m2m装置、网关、或服务平台可以是iot/wot以及iot/wot服务层的组件等。如图19a所示，m2m/iot/wot通信系统10包括通信网络12。该通信网络12可以是固定网络(例如，以太网、光纤、isdn、plc等)或无线网络(例如，wlan、蜂窝等)或异构网络的网络。例如，通信网络12可以由将内容(诸如，语音、数据、视频、消息、广播等)提供给多个用户的多个接入网络组成。例如，通信网络12可以采用一个或多个信道接入方法，诸如，码分多址(cdma)、时分多址(tdma)、频分多址(fdma)、正交fdma(ofdma)、单载波fdma(sc-fdma)等。进一步地，通信网络12可以包括其它网络，诸如，例如，核心网络、互联网、传感器网络、工业控制网络、个人区域网络、融合的个人网络、卫星网络、家庭网络、或企业网络。如图19a所示，m2m/iot/wot通信系统10可以包括基础设施域和场域。基础设施域指端对端m2m部署的网络端，而场域指区域网络，通常在m2m网关后面。例如，场域包括m2m网关14和终端装置18。要了解，若需要，可以将任何数量的m2m网关装置14和m2m终端装置18包括在m2m/iot/wot通信系统10中。每个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应用20接收数据和信号。m2m装置18和网关14可以经由各种网络(包括，例如，蜂窝、wlan、wpan(例如，zigbee、6lowpan、蓝牙)、直接无线电链路、和有线)通信。参照图19b，在场域中图示的m2m服务层22向m2m应用20、m2m网关装置14、m2m终端装置18、和通信网络12提供服务。要理解，若需要，m2m服务层22可以与任何数量的m2m应用20、m2m网关装置14、m2m终端装置18、和通信网络12通信。可以通过一个或者多个服务器、计算机等(诸如，图19d中图示的和下文描述的计算机系统)实施m2m服务层22。m2m服务层22提供应用于m2m终端装置18、m2m网关装置14、和m2m应用20的服务能力。可以利用各种方式(例如，作为web服务器、在蜂窝核心网络中、在云中等)来实施m2m服务层22的功能。与图示的m2m服务层22相似，在基础设施域中有m2m服务层22’。m2m服务层22’向在基础设施域中的m2m应用20’和底层通信网络12’提供服务。m2m服务层22’还向在场域中的m2m网关装置14和m2m终端装置18提供服务。要理解，m2m服务层22’可以与任何数量的m2m应用、m2m网关装置、和m2m终端装置通信。m2m服务层22’可以通过不同的服务提供商来与服务层交互。可以通过一个或者多个服务器、计算机、虚拟机(例如，云/计算/存储场等)等来实施m2m服务层22’。仍然参照图19b，m2m服务层22和22’提供不同的应用和行业可以利用的服务交付能力的核心集。这些服务能力使m2m应用20和20’能够与装置交互并且执行功能(诸如，数据收集、数据分析、装置管理、安全、开票、服务/装置发现等)。本质上，这些服务能力使应用解除了实施这些功能的负担，从而简化应用开发并且降低成本和上市时间。服务层22和22’还使m2m应用20和20’能够通过与服务层22和22’提供的服务有关的各种网络(诸如，网络12)通信。通常，服务层22和22’定义通过应用编程接口(api)和底层网络接口的集合来支持增值服务能力的软件中间件层。etsim2m和onem2m架构都定义服务层。etsim2m的服务层称为服务能力层(scl)。可以将scl实施在m2m装置(在这种情况下，其称为装置scl(dscl))、网关(在这种情况下，其称为网关scl(gscl))、和/或网络节点(在这种情况下，其称为网络scl(nscl))内。onem2m服务层支持公共服务功能(csf)(即，服务能力)集合。将一个或更多个特定类型的csf的集合的实例化称为公共服务实体(cse)，可以将该公共服务实体托管在不同类型的网络节点(例如，基础设施节点、中间节点、专用应用节点)上。m2m应用20和20’可以包括在各种行业(诸如，但不限于，运输、健康与保健、联网家庭、能源管理、资产追踪、和安全和监督)中的应用。如上所述，跨系统的装置、网关、和其它服务器运行的m2m服务层支持功能(诸如，例如，数据收集、装置管理、安全、开票、位置追踪/地理围墙、装置/服务发现、和遗留系统集成)，并且将这些功能作为服务提供给m2m应用20和20’。可以利用新的ddfmo612、ddfmo注册过程614、gwmo装置注册过程620、和协议转换功能616作为对服务层(诸如，图19b中图示的服务层22和22’，包括例如由etsim2m或m2m架构定义的服务层)的装置管理解决方案的一部分。这种服务层可以发起ddf注册和gwmo装置注册过程614和620，因为服务层将了解其想要管理的m2m装置。本文描述的过程和功能可以协助其中dm服务器(修改为执行上述过程)是m2m服务器的一部分、而dm网关(修改为执行上述过程)是m2m网关的一部分的部署。图19c是示例终端装置30(诸如，图6的终端装置604、606、或610a-c、图16的lwm2m装置712、以及图19a和图19b的m2m装置18和网关14)的示意图。如上所述，终端装置可以包括能够在无线网络中进行通信的任何无线装置，诸如，m2m装置、mtc装置、或lwm2m装置，包括例如，机器、传感器、电器等、移动站、固定或移动用户单元、寻呼机、个人数字助理(pda)、计算机、移动电话或智能电话、或能够在有线或无线环境中操作的任何其它类型的装置。如图19c所示，终端装置30可以包括处理器32、收发器34、传送/接收元件36、扬声器/麦克风38、键盘40、显示器/触摸板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(gps)芯片集50、和其它外设52。要了解，终端装置30可以在与实施例保持一致的同时包括前述元件的任何子组合。处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(dsp)、多个微处理器、与dsp核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(asic)、现场可编程门阵列(fpga)电路、任何其它类型的集成电路(ic)、状态机等。处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理、和/或使终端装置30能够在无线环境中操作的任何其它功能。处理器32可以耦合至收发器34，该收发器34可以耦合至传送/接收元件36。虽然图19c将处理器32和收发器34描绘为分离的组件，但是要了解，可以将处理器32和收发器34集成在电子封装或芯片中。处理器32可以执行应用层程序(例如，浏览器)和/或无线电接入层(ran)程序和/或通信。处理器32可以诸如例如在接入层和/或应用层处执行安全操作(诸如，认证、安全密钥协议、和/或密码操作)。处理器32可以执行计算机可执行指令，该计算机可执行指令在装置30上实施dm客户端或lwm2m客户端的功能。传送/接收元件36可以配置为将信号传送至另一对等方或从另一对等方接收信号。例如，在实施例中，传送/接收元件36可以是配置为传送和/或接收rf信号的天线。传送/接收元件36可以支持各种网络和空中接口(诸如，wlan、wpan、蜂窝等)。例如，在实施例中，传送/接收元件36可以是配置为传送和/或接收ir、uv、或可见光信号的发射机/检测器。在再一实施例中，传送/接收元件36可以配置为传送和接收rf和光信号两者。要了解，传送/接收元件36可以配置为传送和/或接收无线或有线信号的任何组合。另外，尽管在图19c中将传送/接收元件36描绘为单个元件，但是终端装置30可以包括任何数量的传送/接收元件36。更具体地，终端装置30可以采用mimo技术。因此，在实施例中，终端装置30可以包括传送和接收无线信号的两个或更多个传送/接收元件36(例如，多个天线)。收发器34可以配置为调制待由传送/接收元件36传送的信号并且解调制由传送/接收元件36接收的信号。如上文提到的，终端装置30可以具有多模式能力。因此，例如，收发器34可以包括用于使终端装置30能够经由多个rat(诸如，utra和ieee802.11或802.15)通信的多个收发器。处理器32可以从任何类型的合适的存储器(诸如，不可移动存储器44和/或可移动存储器46)访问信息，并且将数据存储在任何类型的合适的存储器中。不可移动存储器44可以包括随机存取存储器(ram)、只读存储器(rom)、硬盘、或任何其它类型的存储器存储装置。可移动存储器46可以包括用户识别模块(sim)卡、记忆棒、安全数字(sd)存储器卡等。在其它实施例中，处理器32可以从并未在物理上位于终端装置30的存储器(诸如，在服务器或家庭计算机上)访问信息，或将数据存储在并未在物理上位于终端装置30的存储器中。处理器32可以接收来自电源48的电力，并且可以配置为分布和/或控制电力到终端装置30中的其它组件。电源48可以是用于对终端装置30充电的任何合适的装置。例如，电源48可以包括一个或者多个干电池(例如，镍-镉(nicd)、镍-锌(nizn)、镍金属氢化物(nimh)、锂离子(li离子)等)、太阳能电池、燃料电池等。处理器32还可以耦合至配置为提供关于终端装置30的当前位置的位置信息(例如，经纬度)的gps芯片集50。要了解，终端装置30可以在与实施例保持一致的同时通过任何合适的位置确定方法来获得位置信息。处理器32可以进一步耦合至其它外设52，该外设52可以包括提供附加特征、功能、和/或有线或无线连接的一个或者多个软件和/或硬件模块。例如，外设52可以包括加速度计、电子罗盘、卫星收发器、传感器、数码相机(针对照片或视频)、通用串行总线(usb)端口、振动装置、电视收发器、免提耳机、(蓝牙)模块、调频(fm)无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块、互联网浏览器等。图19d是可以用于实施图6、9、11、15a-b、16、17a-c、和19a-b中图示的任何逻辑实体(包括，例如，dm服务器、dm网关、lwm2m服务器、协议转换器、m2m装置、m2m网关、m2m服务层等)的计算机系统或服务器90的框图。图19d的计算机系统或服务器90可以主要由计算机可读指令控制，该计算机可读指令可以是软件的形式，无论这种软件存储在何处或可以通过何种手段存储或访问。可以在处理器(诸如，中央处理单元(cpu)91)内执行这种计算机可读指令，以使计算机系统90工作。在许多已知的工作站、服务器、和个人计算机中，中央处理单元91由称作微处理器的单片机cpu来实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主cpu91不同的、执行附加功能或协助cpu91的可选处理器。cpu91和/或协处理器81可以接收、生成、并且处理与p2p通信有关的数据。在操作中，cpu91取得、解码并且执行指令，并且经由计算机的主数据传递路径系统总线80将信息传递至其它资源并且传递来自其它资源的信息。这种系统总线连接在端节点90中的组件，并且定义数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线、和用于发送中断并且用于操作系统总线的控制线。这种系统总线80的示例是pci(外围组件互连)总线。耦合至系统总线80的存储器装置包括随机存取存储器(ram)82和只读存储器(rom)93。这种存储器包括允许信息被存储并且检索的电路系统。rom93通常包含不能轻易修改的存储数据。存储在ram82中的数据可以由cpu91或其它硬件装置读取或改变。可以由存储器控制器92控制访问ram82和/或rom93。当指令被执行时，存储器控制器92可以提供将虚拟地址转换成物理地址的地址转换功能。存储器控制器92还可以提供将系统内的进程隔离并且将系统进程与用户进程隔离的存储器保护功能。因此，在第一模式中运行的程序仅可以访问通过其自身的进程虚拟地址空间映射的存储器；该程序不能访问在另一进程的虚拟地址空间内的存储器，除非已经建立了在进程之间共享的存储器。另外，计算机系统或服务器90可以包含负责将指令从cpu91传送到外设(诸如，打印机94、键盘84、鼠标95、和磁盘驱动器85)的外设控制器83。由显示控制器96控制的显示器86用于显示由计算机系统或服务器90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形、和视频。可以使用基于crt的视频显示器、基于lcd的平板显示器、基于气体等离子体的平板显示器、或触摸板实施显示器86。显示控制器96包括生成发送至显示器86的视频信号所需的电子组件。进一步地，计算机系统或服务器90可以包含网络适配器97，该网络适配器97可以用于将计算机系统或服务器90连接至外部通信网络。应理解，本文描述的任何或所有系统、方法、和进程(包括，ddfmo注册过程614、gwmo装置注册过程620、和协议转换功能616)可以体现为存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式，该指令在由机器(诸如，计算机、服务器、终端装置、处理器等)执行时，执行和/或实施本文描述的系统、方法、和进程。具体地，本文描述的任何步骤、操作、或功能可以按照这种计算机可执行指令的形式来实现。计算机可读存储介质包括以任何用于存储信息的方法或技术实现的易失性和非易失性介质以及可移动和不可移动介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于，ram、rom、eeprom、闪速存储器或其它存储技术、cdrom、数字多功能光盘(dvd)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储装置、或可以用于存储期望的信息并且可以由计算机访问的任何其它物理的介质。当前第1页12