物联网终端远程管理架构及功能研究Word文件下载.docx

资源描述

物联网终端远程管理架构及功能研究Word文件下载.docx

《物联网终端远程管理架构及功能研究Word文件下载.docx》由会员分享，可在线阅读，更多相关《物联网终端远程管理架构及功能研究Word文件下载.docx（42页珍藏版）》请在冰豆网上搜索。

物联网终端远程管理架构及功能研究Word文件下载.docx

目前在宜居通应用中，从管理平台到网关以及网关到传感器之间都使用的是私有的内部协议。

图2中国移动智能家居应用

图3是中国移动的智能交通应用——车务通的示意图。

在车务通系统中，每个车辆上安装一个3G上行的车务通终端，用以对车辆位置、行车参数、车辆状况进行监控，并上报给车联网管理平台。

在网络侧有一个车联网终端接入网关，具备终端连接、登陆、链路维护、终端接入转发、非标准协议转换标准协议、终端状态监控、远程升级等功能。

车联网的客户可以通过网络登录到车联网管理平台，对车辆的运行情况进行查看。

在车联网管理平台和车联网终端接入网关之间，运行专门的车务通协议，在接入网关与车联网终端之间运行自定义的协议。

图3中国移动智能交通应用

物联网的应用多种多样，以上只是列举了几种比较典型的应用，主要是希望从中能看到物联网的体系架构尤其是末端传感子网的结构、管理协议的位置、管理的功能等。

1.2物联网终端的远程管理需求

图4是ETSI给出的M2M网络架构。

对终端管理而言，由于在感知层存在着不同的网络结构，其管理方式也有所不同。

感知层简单的结构是直接由一个个的终端构成，类似前面的智能交通应用；

而对有些应用，则是由网关和终端两级网络组成，类似前面的智能农业和智能家居应用。

图4ETSIM2M系统结构

对于物联网应用而言，终端数量众多，而且经常分布在不易接近的地方，因此需要通过远程进行管理。

一般而言，其网络管理功能通常包括配置管理、性能管理、故障管理、安全管理和认证计费管理等功能。

物联网终端管理功能的需求，其中除配置管理和故障管理，其它部分要求比较简单，也基本上与传统电信网要求类似。

因此我们将详细讨论配置管理功能和故障管理功能。

1.2.1配置管理

物联网的终端数量是非常庞大的，并且还可以自身通过不同的方式（预配置、自组织等）灵活的组成很多区域子网，也称作毛细管网。

很多个这样的毛细管网通过网关接入到电信网络中，为上层的应用来提供服务。

显然，在这样一个分布式的网络中，为每一个终端设备分配一个可管理的地址（例如IP地址），让管理平台直接管理到每一个终端并不是解决问题的唯一途径。

M2M网关以下的区域子网内部,可以有自己的地址识别机制,以及私有的管理协议,网关作为区域子网的中心控制器,自主的完成部分网管的功能。

管理平台通过对网关的管理,间接的得到整个末梢网络的状态，并对其进行管理。

无论管理方式和管理协议采用哪种具体的解决方案，M2M的配置管理都应该具备以下的一些功能：

1）生命周期管理

生命周期管理是指管理系统通过周期性的发送某种协议报文给所有的终端和网关，通过对端的回复来判断被管理对象的状态，例如是否在线、是否激活、是否休眠、是否掉电等。

管理系统通过生命周期消息来确认终端和网关的状态。

终端和网关也可以定期的向管理系统来发送生命周期消息来报告自己的状态。

2）能力信息上报

物联网网络中的终端和网关是多种多样、形态万千的，每个终端和网关都根据应用场景的不同，具备不同的功能和性能。

因此，终端和网关向管理系统上报自己的能力信息是十分必要的。

管理系统不仅要能对不同类型的网关设备和终端设备的能力、性能等静态信息进行记录和查询，还应能对不同类型的网关设备和终端设备的位置、状态、可用性等动态信息进行监控和查询，并且将动态信息和被管理对象关联起来。

3）即插即用

“即插即用”的配置方式对我们来说并不陌生。

物联网区域子网的网元和网络的末梢设备应尽可能的使用“即插即用”的配置方式获得网络连接，特别是对于用户自己动手进行业务安装的设备，这一功能非常的实用。

“即插即用”使得设备能够独立的完成网络配置，而不需要借助其他的辅助设备（例如个人电脑等）。

这一功能简化网络配置的过程，提高网络部署的效率，进一步的推动物联网设备的应用。

4）区域子网的自动配置

区域子网中的传感器节点、控制器节点应具备本地的自测试的能力，不需借助外部设备就能够确定通信连通性和自身的运行情况。

区域子网中的设备可能散落在不同的地方，位于不同位置的多个设备可能同时在进行初始的安装。

自测试的能力能够保证这些设备在自配置的时候能够无缝地融合成完整的系统，以完成区域子网的自动配置。

5）区域子网的网络连接

为了增加区域子网的可靠性或是性能，可以适当的添加和安置一些节点。

当区域子网中有新设备加入或是有节点掉电时，网络应具备自动修复连通性的能力。

管理系统需要能够定位网络拓扑的变化。

物联网系统中的部分节点出现故障时，也不应影响整个网络的正常运行。

6）时间同步和时钟管理

在物联网系统中，经常会出现多个物联网设备在某一个精确的时间完成某个动作的情况。

例如休眠的设备，为了维持有效的网络连接，必须以某个特定的周期发送生命周期消息。

因此，在一个足够大的物理区域X围内，物联网系统的时间同步至少应达到毫秒级甚至更高的精度。

这就要求管理系统应能提供精确的、可靠的时间同步功能。

在ETSI的标准草案中，物联网网络中的所有时钟使用国际协调时间（UTC），并根据UTC进行校准。

如果需要，事件的时间可以显示为本地时间，但事件的时间顺序必须是唯一确定的。

7）其他

为了方便物联网应用供应商提供业务，已及运营商对网络的有效管理，配置管理还应包含其他一些物联网特有的功能，例如对系统的安全软件以及防火墙等功能进行配置、对物联网应用的签约用户信息进行管理、以及针对具体的物联网应用的管理等。

1.2.2故障管理

和配置管理相类似，物联网系统的故障管理除了包含对电信网络的性能监测和故障定位之外，也应根据物联网的特点和需求，进行优化和扩展。

这一部分主要是对物联网区域子网的性能监测以及故障诊断，并上报给管理系统。

这些物联网特有的故障管理功能包括：

1）可靠性监测

为了预防故障的发生，确保系统能够可靠地运行，物联网的网关、设备以及与网络连接相关的功能实体都应主动地进行性能的监测，以及时地修正错误。

2）诊断模式

诊断模式是一种非正常工作的调测模式，能够提供系统和网络的附加信息。

通过物联网系统或其中的某些部分配置为诊断模式，能够帮助系统对出现的故障进行诊断。

物联网系统也能通过这样的方式来验证物联网业务和应用的机能是否良好。

3）中心控制器的连通性测试

当某个物联网应用需要运行在更大的物理区域时，管理系统可以提供特定的时隙，对某个或某些中心控制器的连通性进行测试。

发起测试的可以是某个应用，也可以是中心控制器，或是在部分物联网区域子网的网络连通性不明确的情况下，由某个事件来启动中心控制器的连通性的测试。

4）故障发现和报告

中心控制器的的运行状态必须是可监控、可管理的。

当异常状况出现时，中心控制器能够在特定的时隙向管理系统报告。

5）通过远程管理进行故障恢复

物联网设备可能会被放置在野外工作很多年，或是位于一些人迹罕至的地方或是对于人类是危险的场所，人是很难直接介入到这类设备的运行的。

由于物联网系统中通常都规划了大量的物联网设备，当这些设备发生了故障时，如果能够对其进行远程管理将延长其服务期。

故障可能是多种多样的，例如由于严苛的环境导致的，或是系统出现的失误，以及安全入侵等等。

发生故障的物联网设备通过远程管理的方式来进行某些补救。

例如通过连接到一个安全的管理服务器以获得固件的升级和更新，更新结束后，设备可以自动重启，回复到一个正常的工作状态。

因此，在物联网系统中的设备出现故障时，管理系统对设备进行远程的诊断、恢复、复位或隔离等操作是十分必要的。

但是需要特别注意的是，并非所有的物联网应用场景都需要远程管理系统。

本研究报告所说的远程管理系统主要面向提供公共服务能力的运营商物联网应用（M2M应用），而对一些内部使用的物联网应用，如车间机械监控，应用场景比较简单，网络X围也不大，可以省略终端管理系统。

在有需要的情况下，也可以参照公用物联网建设远程管理系统。

如无特别说明，本报告可能会混用物联网和M2M，但其含义并无差异。

2.物联网终端远程管理架构

2.1物联网终端远程管理架构现状

总结一下第1章中各种应用场景下的终端远程管理架构，目前运营商各种物联网应用网络架构的简单示意图如图5所示。

图5物联网远程终端管理架构现状

由图中可以看到，在物联网应用初期，各种应用独立发展，分别建设自己的管理平台来对末端网络进行管理，有以下几个特点：

末端网络可能直接是物联网终端，也可能分几级网络最终由网关接入管理平台；

管理平台既负责相应的物联网业务，又负责终端设备管理（一般只管到网关）；

管理平台与末端网络（网关）之间采用的协议不同，有公有协议，也有私有协议；

末端网络内部多采用私有协议。

目前的这种架构存在的问题也是显而易见的，因为各种应用虽然有其各自的特点，但也有许多共性的工作，因此各种业务平台上存在一些重复的工作。

同时，目前这种条状的架构导致网络结构和协议复杂，给管理带来不便。

2.2设备与业务分离的物联网远程管理平台架构

针对目前物联网管理中的不足，我们提出将设备管理与业务管理相分离的物联网管理平台架构。

在这一架构下，将各种应用共同的部分提取出来，放在一个公共的M2M运营管理平台上来完成，实现设备的集中管理，而各种业务平台则专注于特定业务的管理。

设备与业务分离的物联网远程管理平台架构如图6所示。

图6设备与业务分离的物联网远程管理平台架构

其中，M2M运营管理平台将公共能力进行打包，包括系统硬件、第三方软件、数据网络、IDC机房、安全服务、无线通道、投诉受理、收费结算等。

同时，将终端能力进行抽象和标准化，从而在平台与物联网网关或终端之间运行统一的管理协议，简化协议实现。

基于这一通用的管理平台，各种业务作为物联网应用之一接入，便于物联网应用的推广。

这样的架构具备以下优点：

抽象出通用、共有的模块，如数据采集通讯模块、报警模块等，采用可配置的方法动态实现各行业应用；

在基础平台上开发各行业套件，以满足不同行业的需求；

通过统一的门户，管理各套件及其他资源，最终形成一个可满足所有物联网行业需求的通用、统一的大平台；

社会分工明确，集成商专注于擅长的商务运作、市场开拓，运营商负责技术方面和后期繁琐的系统维护；

增强了运营商在市场中的主导地位和市场掌控能力，与各集成商紧密配合，提高了市场占有率；

降低集成商的各种项目成本，提高了利润。

通过M2M运营管理平台，一方面可以提高电力、石油等行业客户的粘性，另一方面通过提供标准的能力调用接口，方便各种行业应用集成商进行快速应用开发，还有助于快速的向个人、家庭用户进行业务推广。

2.3业务流与管理流的分离模式

引入M2M运营管理平台后，业务流和管理流被分离开来。

管理流指承载M2M终端管理相关信息的数据流，业务流是指承载M2M应用相关的数据流。

业务流与管理流的分离模式有2种，分别为管理流–业务流并行模式和管理流–业务流分离模式。

对于终端管理流，两种模式都由终端发送给M2M平台，或再由M2M平台转发给应用。

对于业务流，在管理流–业务流并行模式下，业务流通过终端传递到M2M平台，再由M2M平台转发给M2M应用业务平台或者对端的M2M终端；

在管理流–业务流分离模式下，业务流直接从终端送到M2M应用业务平台或者对端的M2M终端，不通过M2M平台转发。

在并行模式中，业务数据从M2M终端传送到M2M平台，再由M2M平台转发给M2M应用业务平台或者对端的M2M终端，如图7所示。

这种模式下，管理数据和业务数据均由M2M平台统一接收，再根据不同的消息类型和目标地址进行分发或处理。

图7M2M管理流-业务流并行模式

在分离模式中，业务数据不通过M2M平台，直接从M2M终端传送到M2M应用业务平台或者对端的M2M终端。

管理数据发送到M2M平台，再根据目标地址进行转发或者处理。

如图8所示。

图8M2M管理流-业务流分离模式

在物联网应用发展初期，由于各项应用独立开展，因此两种模式可能同时存在。

对于分离模式而言，存在以下缺点：

管理平台和业务应用平台可能位于2个网络；

目前的终端不具备同时接入2个网络的能力，需要进行切换，导致效率较低；

终端协议不统一，容易影响终端稳定性；

后期升级较为麻烦，终端需要支持实现两种协议升级。

而对并行模式，则需要解决以下问题：

为了使用统一的协议，需要将业务协议封装在M2M管理协议内

M2M平台支持对业务数据的目的地进行解析并转发

综合考虑，现阶段可以两种模式同时存在，但建议后续向并行模式过渡。

3.远程管理平台功能分析

3.1M2M远程管理平台的接口

M2M远程运营管理平台在网络中的位置及与其他子系统的接口如图9所示。

图9M2M运营管理平台在网络中的位置

平台与网关/M2M终端的接口：

前面提到，管理平台与网关或M2M终端之间运行统一的物联网管理协议，实现对设备的全方位的管理。

协议的具体实现将在下节中进行介绍。

平台与网络能力系统的接口：

管理平台主要是调用各种网络能力，例如SMS、GPRS等，以实现通知、通信等功能。

平台与行业应用系统的接口：

管理平台对接行业应用系统，为行业应用系统提供终端监测控制服务和行业应用数据转发服务，能够实现应用连接的建立和维护、应用连接流控、终端监测控制请示处理和应用数据转发请示处理功能。

行业应用系统可以是运营商自己建立并发布的行业应用系统，也可以是某些行业客户自己发布的应用系统。

平台与运营支撑系统的接口：

主要实现终端的认证、计费、服务开通和业务管理等功能。

3.2远程管理平台功能

运营商的M2M业务管理平台，分为终端管理子平台和业务管理子平台，负责终端管理、M2M业务管理、终端与应用之间的安全消息交互、终端厂家和应用厂家管理、客户管理，为运营商运营M2M业务提供了平台支撑。

还有合作方提供的标准化应用，与M2M平台集成，为用户提供可租用的M2M业务。

M2M平台的系统总体架构如图10所示。

图10M2M平台系统总体架构

M2M平台的核心业务处理模块包块终端资源管理、运营管理和机器卡管理三个子模块，下面分别描述其具体功能。

终端资源管理子模块包括终端管理、感知子网管理、感知外设管理和感知能力管理。

终端管理主要实现终端序列号分配、故障管理、配置管理、软件升级、安全管理和厂商管理等功能。

感知子网管理主要实现接入网关管理、节点管理、拓扑管理、安全管理、配置管理和软件升级等功能。

感知外设管理主要实现外设编号管理、故障管理、配置管理、软件升级、安全管理和厂商管理等功能。

感知能力管理负责对终端感知能力的即插即用、感知能力状况的维护和管理。

运营管理子模块包括用户信息管理、产品信息管理、订购关系管理、合作方管理、Qos管理、安全管理、业务统计和能力管理。

用户管理主要实现用户信息存储、用户信息与PBOSS同步和用户信息与业务平台同步等功能。

产品信息管理主要实现对全网产品以及未建管理平台省托管本地业务的产品信息保存等功能。

订购关系管理主要实现订购关系存储、订购关系与省物联网运营管理平台同步、订购关系与业务平台同步等功能。

合作方管理主要实现终端设备厂商、应用合作方、能力提供方的信息存储、信息统计等功能。

Qos管理主要实现应用Qos策略配置、以及对物联网业务网关的Qos参数配置等功能。

安全管理主要实现安全密码生成、存储和分发。

业务统计主要实现全国物联网业务发展统计和业务运行统计。

能力管理子模块包括能力生命周期管理、能力订购管理、能力提供商管理和能力发布。

机器卡管理子模块包括机器卡运行状态管理、机器卡账务状态管理及机器卡业务配置功能。

机器卡运行状态管理主要实现机器卡在网状态维护、机器卡GPRS在线状态维护，以及机器卡正常通信记录维护和故障信息维护等功能。

机器卡账务状态管理主要实现机器卡账户状态维护、流量统计信息维护以及流量告警信息设置等功能。

机器卡业务配置主要实现根据用户需求，对机器卡管理进行数据配置的功能。

4.物联网终端远程管理协议

4.1概述

一些标准化组织针对终端管理已经提出了一些管理协议，比如BroadbandForum的TR-069和OMA的DM协议。

这些协议虽然并非为物联网终端远程管理而专门设计的，但由于在终端管理方面的共同特性，在进行物联网终端远程管理时，也可以参考使用这些协议。

另外，中国电信、中国移动也特别针对M2M管理提出了自己的管理协议。

本章将对这些协议进行简单的介绍。

4.2BroadbandForumCWMP（TR-069）

4.2.1概述

TR-069是为家庭网络终端远程管理而设计的协议。

从运营、维护和管理的角度看，家庭网络和公用电信网络有很大不同。

首先，公用电信网络的网元数量一般比较少，而家庭网络的网元数量则非常庞大，所以，没有良好的运行和管理工具，无法维护和管理家庭网络；

传统的人工操作和排除故障的方式很难满足家庭网络的维护和管理要求。

其次，家庭网络的使用者是普通用户，普通用户不可能象机房里的专业工作人员那样恪守安全规X，不做有害于网络安全的操作；

更有可能，一些使用者是怀有恶意的；

因此，家庭网络的维护和管理更要注重运营商对设备本身的控制能力以及安全性能。

最后，家庭网络遍布各个地区，远程管理是必不可少的；

上门服务只有在极特别的情形下才进行。

BroadbandForum的TR-069协议在2004年发布以后，在家庭网络终端管理方面得到广泛应用，并且根据应用中出现的新情况，进行了几次修订。

4.2.2TR-069协议栈

TR-069的协议栈如图11所示。

TR-069是基于TCP，面向连接的协议，采用HTTP承载的SOAP消息，使用XML语言定义，对象和方法容易扩展，同时可选的SSL/TLS层可以提供更加可信的安全性

图11TR-069协议栈

4.2.3连接建立

终端可以通过出厂预配置、本地配置或是通过DHCP选项获取远程管理服务器RMS的地址，然后在任何时刻使用预先确定的RMS地址发起到RMS的连接。

在下列情况下，被管理设备必须建立和RMS的连接并发送InformRPC方法。

a）被管理设备初始安装后第一次和接入网建立连接；

b）上电或重置；

c）每隔PeriodicInformInterval时间（例如，每隔24小时）；

d）当通过可选的ScheduleInform方法通知时；

e）当被管理设备接收到来自RMS的合法连接请求（ConnectionRequest）；

f）当RMS的URL改变时；

g）当参数值改变并要求发送Inform方法时；

h）当一个被RMS通过SetParameterAttributes方法标记为“主动通知”的参数值由于RMS以外的其他原因被修改时。

由RMS使用SetParameterValues方法对参数值进行修改不应发起一个新会话。

如果一个参数在被管理设备建立会话进行通知前被修改了多次，则被管理设备应只通知一次。

RMS也可以在任何时刻通过连接请求机制要求被管理设备建立与RMS的连接。

连接请求机制如下所述：

a）连接请求应使用HTTP1.1GET发送到被管理设备指定的特定URL。

URL值在被管理设备上是只读类型的参数。

URL的“path”值建议由被管理设备随机产生以保证其唯一性；

b）连接请求应使用HTTP，不应使用HTTPS。