CN103312573B - 一种家庭网络系统设备发现与识别方法 - Google Patents

Abstract

本发明公开了一种家庭网络系统设备发现与识别协议，旨在用来规范家庭网络系统中设备发现、设备识别的工作流程与协作方式、以及通信接口细节，从而解决家庭网络中家庭设备的发现、离开和识别难的问题，本发明首先给出了家庭网络系统的结构和环境，然后在此基础上给出了网关、中心服务器、家庭设备、设备发现和设备设别的内涵，实现了系统操作时序协议，具体包括设备接入协议、设备识别和离线协议以及补充协议等，最后给出了协议的具体内容和相关信息的格式，本发明完成了上述功能的实现算法、编码和测试工作，相对于当前家庭网络的研究与实践，本发明所述协议的最大特色在于实现的系统具有了较好的实时性和可靠性。

Description

一种家庭网络系统设备发现与识别方法

技术领域

本发明属于智能家居领域，具体涉及一种家庭网络系统设备发现与识别方法、内容和步骤。

背景技术

家庭网络众多功能中最重要的是设备互联功能。智能家居由于缺乏标准，物联网企业各自为政，直接导致智能家居产品的兼容性差，设备互联互通困难，不能实现智能家居行业的整体融合，由此而造成普及难、厂商难以接受的问题。使用HTTP/Web Service协议构建家庭局域网也是最方便、最有效的方法之一。另外，由于目前国内厂商所掌握的技术大多位于网络层和应用层，缺少具有自主产权的核心产品和技术，部分底层核心技术和关键元器件仍然依靠进口，从而导致相关产品整体价位偏高，这也是制约行业发展的主要原因。

发明内容

本发明的目的在于提供一种家庭网络系统设备发现与识别协议。

为了实现上述目的，本发明采用了以下技术方案。

一种家庭网络系统设备发现与识别协议，包括面向Web服务的家庭网络系统架构的系统环境、网关、中心服务器、家庭设备、设备发现、设备识别、系统操作时序协议以及协议内容与格式。

所述系统环境是指家庭网络系统架构中支持有线和无线网络功能的协议标准、局域网中设备的限制以及设备应提供的协议服务；

所述网关是指家庭网络系统接入Internet网络的网络交换机或路由器，具有无线与有线发现智能设备并能自动分配IP地址；

所述中心服务器是指具有访问、管理和控制家庭设备功能的家庭个人电脑，是家庭网络系统的中心，安装有Web服务等功能；

所述家庭设备是指通过有线或无线方式，直接接入家庭网络系统的智能家用电器等家庭设备，如有线、无线摄像头，空调、冰箱等设备使用的控制器以及智能开关等，不含中心服务器、网关等家庭网络系统的基础设施，也不含电灯，空调等需要通过控制器等中间设备接入家庭网络系统的家用电器；

所述设备发现是指当设备接入或离开家庭网络系统后，中心服务器通过某种途径得知这一事件的过程；

所述设备识别是指当设备接入家庭网络系统后，中心服务器通过某种途径得知该设备的类型、名称、状态等基本信息的过程；

所述系统操作时序协议是指设备接入到设备识别和离线过程中设备与中心服务器、网关之间的约定以及操作规程；

所述协议内容与格式是指设备被分配的IP的地址格式、上线通知信息格式、上线确认信息格式、设备信息格式、设备信息确认信息格式、在线通知信息格式、在线确认信息格式、离线请求信息格式和离线确认信息格式。

具体协议内容与格式如下：

1）分配的IP地址

无论是采用静态分配还是动态分配的方法，分配到的IP地址均为C类IPv4地址，且网络号相同。其中，静态分配的主机号小于100，动态分配 的主机号大于100。

以下3个主机号为家庭网络系统保留，其他设备不能使用：

（1）XXX.XXX.XXX.1：宽带路由器使用。

（2）XXX.XXX.XXX.99：系统保留。

（3）XXX.XXX.XXX.100：中心服务器使用。

若设备未遵守上述规定，将导致未定义的结果。

2）上线通知

上线通知为一POST型的HTTP请求，格式如下：

3）上线确认

上线确认为上线通知的HTTP响应，格式如下：

其中，Device ID为家庭网关为每一个设备分配的、用于唯一标识每个设备的序列号。而NeedMoreInfomation则表示是否需要进行设备识别，1表示需要，0表示不需要。

4）设备信息

设备信息为一POST型的HTTP请求，格式如下：

其中，XML部分的主要标签意义如下：

（1）DeviceKind：一个整数，表示设备的类型。目前规定1代表摄像头，2代表智能家电，3代表智能开关，4及4以上未定义，表示其他设备。

（2）DeviceName：表示设备名称。

（3）ProductCompany：设备的制造商名称。

（4）Authorization：可选部分。如果设备的某些功能需要登录才可以使用，可以附上该段，其中的DefaultUserName和DefaultPassword表示设备的默认用户名和默认密码。

（5）HttpServerSupported：表示访问设备HTTP服务器的入口地址。

（6）Features：包含零个或多个Feature标签，表示设备支持的不同特性。其中，Feature标签包含一个Name属性，表示该特性的名称。Feature的内部又由如下标签组成：RequestString：表示要获得该特性的值，需要向设备发送的HTTP请求字符串，它还具有一个authorization属性，取值为0或1，表示在发送该请求时是否需要先登录设备；Return：包含一个正则表达式，用于发送RequestString请求后，从返回的数据中提取该特性的内容，其中index属性表示需要的内容位于正则表达式的第几个组中。

5）信息确认

信息确认为设备信息的HTTP响应，格式如下：

6）在线通知

在线通知为一POST型的HTTP请求，格式如下：

7）在线确认

在线确认为在线通知的HTTP响应。格式如下：

8）离线请求

离线请求为一POST型的HTTP请求，格式如下：

9）离线确认

离线确认为离线请求的HTTP响应。格式如下：

本发明进一步的改进在于：系统环境包括网络协议标准、家庭中设备的限制和要求。

所述网络协议标准是一个以太局域网构成的家庭网络系统中支持有线网络功能的IEEE802.3协议标准（例如TCP/IP、HTTP和XML协议），以及支持无线网络功能使用的IEEE802.11n协议标准；

所述家庭中设备的限制和要求是指局域网中的设备不超过250个，全部使用IPv4的C类地址来进行区分。如192.168.2.xx。每个设备通讯接口仅对应一个IP地址；所有设备均应提供HTTP协议服务，可以响应HTTP请求。

本发明进一步的改进在于：所述系统操作时序协议包括设备接入协议、设备离线协议和附加协议。

所述设备接入协议是指家庭设备接入家庭网络后，与中心服务器、网关之间的互动约定。网关动态分配IP地址；设备的上线通知、在线通知以及给中心服务器发送设备信息，中心服务器发现设备并获得设备MAC地址、向设备发送上线确认、在线确认和设备识别确认信息；

具体过程如下：

1）设备接入时发出DHCP请求，网关动态分配IP地址；设备也可以自行静态绑定IP地址。

2）设备的IP地址确定后，向网关发送上线通知进行设备发现，通知内容包括设备的IP地址和MAC地址。

3）中心服务器收到上线通知后，注册设备信息，同时检索中心服务器上的数据库，检查该设备的MAC地址曾经是否已完成设备识别，然后向设备发送上线确认，确认内容包括是否要求进行设备识别的信息。

4）如果设备在10秒内未收到上线确认信息，将返回步骤2重新进行设备发现。如果设备收到上线确认，则需根据上线确认的内容决定是否进行设备识别。

5）如果需要进行设备识别或设备信息的更新，设备向中心服务器发送设备信息，（其中，应包含设备类型、名称、状态等），则转入步骤6执行。如果需要进行设备识别，但设备未发送设备信息，那么在中心服务器收到设备发送的无设备信息的数据信息后，该设备将被识别为未知设备。如果不需要进行设备识别，可以直接转入步骤8。

6）中心服务器在收到设备信息后，注册该设备的相关信息，完成设备识别。然后，向设备发送信息确认。

7）如果设备在10秒内未收到信息确认，那么将返回步骤5执行，直到收到确认为止。如果连续3次发送设备信息均未收到确认，则回到步骤2执行。

8）设备每隔10秒向服务器发送在线通知。从步骤5之后，如果中心服务器在任意连续的40秒内未收到该设备的在线通知，则判定该设备离线，在中心服务器上注销该设备，并转入步骤2等待设备的上线通知。否则，向设备发送在线确认。

9）如果设备在发送在线通知10秒后仍未收到在线确认，则继续重发在线通知。如果在3次发送后仍未收到，则判断为本设备已掉线，转入步骤2重新进行设备发现。

所述设备离线协议是指设备主动从家庭网关注销的过程。因网络等原因导致在线通知/在线确认无法及时发送的注销情况不在此列；

具体过程如下：

设备离线是指设备主动从家庭网关注销的过程。因网络等原因导致在线通知/在线确认无法及时发送的注销情况不在此列。

1）设备向中心服务器发送离线请求。

2）中心服务器收到离线请求后，在中心服务器上注销该设备，同时向设备发送离线确认。

3）如果设备在10秒后仍然没有收到离线确认，则转入1继续发送；如果连续3次发送均未收到确认，则强制离线。否则，直接执行离线过程。

所述附加协议是指上述协议之外需要补充说明的协议内容。

具体内容包括：

1）所有请求和确认均通过HTTP协议发送，设备作为Client端，中心服务器作为Server端。上线通知/上线确认，设备信息/信息确认，在线通知/在线确认，离线请求/离线确认分别构成HTTP的Request/Response对。

2）在设备获得IP地址之后的任何时候，设备均可向中心服务器发送上线通知，表示设备放弃当前的连接状态，则需重新进行设备发现。

3）任何不按上述时序协议进行数据交互的行为均将导致连接被重置，或者导致HTTP状态码呈现为错误状态码。但这些行为都将不会影响中心服务器的工作状态，也就是说，如果设备在此时向中心服务器发送一个合法的请求，时序协议将继续。

本发明提供一种家庭网络系统设备发现与识别协议，该协议对家庭网络中的网关、中心服务器和家用电器等设备应具有的功能进行了明确，并在此基础上，对设备之间的通信进行了一种约定，主要是在通常的家庭网络系统环境中，中心服务器对设备的接入、设备的设别、设备的离线以及之间的操作时序和所涉及的所有信息格式进行了明确，较好地实现了系统的实时性和可靠性。

本发明所述一种家庭网络系统设备发现与识别协议，该协议是家庭网络系统设计与实现中的一项底层核心技术，旨在用来规范家庭网络系统中设备发现、设备识别的工作流程与协作方式、以及通信接口细节，从而解决家庭网络中家庭设备的发现、离开和识别难问题。

附图说明

图1为面向Web服务的家庭网络系统架构图；

图2为家庭网络各组成单元之间的通信协议图；

图3为中心服务器软件系统用例图；

图4为中心服务器软件系统数据流图；图中：1.在线设备列表，2.更新后的在线设备列表，3.家庭局域网的IP设置，4.设备请求信号，5.设备回应信号，6.设备请求信号，7.设备反馈信息，8.设备驱动信息，9.更新后的设备详细信息，10.在线设备信息，11.设备详细信息，12.设备信息列表，13.设备管理请求，14.修改后的设备信息，15.设备信息，16.设备访问逻辑，17.设备访问与控制请求，18.设备访问控制指令，19.设备反馈信息，20.设备访问和控制结果，21.用户信息，22.修改后的用户信息，23.系统配置信息，24.修改后的系统配置信息，25.用户管理与系统设置反馈信息，26.用户管理与系统设置；

图5为中心服务器软件系统结构框图；

图6为对摄像头SDK中自带的扫描工具进行网络抓包的结果；

图7为设备发现功能执行流程图；

图8为设备识别功能的执行流程图。

具体实施方式

下面结合附图对本发明做进一步详细描述。

参见图1，根据所要支持的设备特性设计完成的硬件之间的连接架构，包括广域网以及局域网，局域网包括家庭网关、家庭设备以及控制器，所述家庭网关包括宽带路由和中心服务器，中心服务器与家庭网关的宽带路由相连，家庭设备直接或者通过控制器与家庭网关的宽带路由相连通过研 究发现，采用什么样的架构，与具体需求尤其是所要支持的设备特性密切相关。家庭中所要支持的设备可分为如下三类：

1）第一类设备：自身包含以太网接口或具有IEEE802.11无线网卡，如大多数网络摄像头。这类设备往往包含HTTP服务器，用户或程序可以访问其自带的Web页面实现设备信息获取和控制。

2）第二类设备：不具有标准的网络接口，或是虽有接口，但不符合以太网或IEEE802.11标准，如普通空调、电视等。这些设备的另一个特点是控制逻辑一般较为复杂，如对于空调来说，不仅有简单的开关功能，还有模式切换、升温降温等功能。这些设备往往使用红外遥控器等进行控制，无网络接口。

3）第三类设备：控制逻辑简单，仅支持开关操作，如电灯等。显然，大多数这种设备没有网络接口。另外，这种设备的数量在家庭网络中往往是比较多的。

为了支持上述三类设备，需要分析它们的差异性，针对不同的情况设计不同的策略来处理。设备的差异性主要有两种：语法差异和语义差异。前者是指设备控制所使用的协议或物理连接方式与家庭网络系统中所使用的不同。比如，一般家用电视采用遥控器进行控制，使用的红外信号；而我们的家庭网络系统中使用的是以太网。后者是指协议所承载的内容含义不同。比如，网络摄像头和无线报警灯可能都采用了HTTP协议，但是传输数据的实际含义肯定是不同的。对于三类设备，其差异性特征如表1所示：

表1三类设备的差异性特征

物理架构设计阶段主要解决语法差异，而语义差异则在逻辑架构设计阶段解决。对于第一类设备，由于其使用的协议与家庭网络采用的相同，因此可以直接接在家庭网络的局域网上，家庭网络平台只需要处理其语义差异即可。而对于第二类设备，我们需要开发专用的控制器，比如红外控制器等，用于实现系统所用的网络协议与专有协议（如红外信号等）的相互转换，然后用控制器的专有协议端控制设备，网络协议端与家庭网络相连，进而间接实现家庭网络与设备之间的相互通信。当然，在物理上互联之后，平台还必须解决此类设备在语义上的差异性。而对于第三类设备，与第二类设备类似也必须引入控制器，只是控制器的私有协议端的信号类型非常简单，为开关信号，设备的控制语义也很简单，只有开和关两种状态。鉴于此，第三类设备的控制器表现为智能开关，使用网络信号来控制设备的通断；同时考虑到第三类设备数量较多，因此可以采用一对多的连接方式，使用一个多路控制开关来控制多个设备，以降低控制器成本。

综合以上分析，我们可以设计出该家庭网络系统的物理架构和逻辑架构，其中，逻辑架构从从层次模型、模块划分和协议设计三个方面进行介绍。

图1给出了本发明家庭网络系统的物理架构，广域网被具体化为Internet，而局域网则被具体化为以太网或IEEE802.11无线局域网。相对于家庭网络的一般架构，本架构的最大不同是将家庭网关分拆为宽带路由和中心服务器两部分。这是因为家庭网关兼具宽带接入和家庭网络管理两大 功能，而前者一般由电信部门和ISP提供的宽带路由完成，本身不具备二次开发能力。因此要构建家庭网络的软件系统，实现家庭网络管理功能，就只能部署在另外的机器上，我们称之为中心服务器。中心服务器采用PC机作为硬件平台，这是因为部署家庭网络的家庭一般都有PC机，而且相对于嵌入式平台，PC机在计算速度、存储容量上都有不小的优势，便于实现更复杂的功能，也省去了重新开发嵌入式平台的开发成本和硬件成本。后文中，在提及对家庭网关进行设计时，默认就是指对中心服务器进行设计；反之亦然。

采用什么样的物理架构，与具体需求尤其是所要支持的设备特性密切相关。星形网络架构要求掌握大量的设备资料，而且需要对每一种设备单独编程，工作量很大，这不符合实际情况。而且，更希望使用常见的、标准化的协议来构建家庭网络，而不是使用私有的协议，因此，总线式的以太网以及IEEE802.11无线网更适合。然而，所要支持的设备并不一定采用这种协议。星形网络架构的系统，其支持的电器设备符合Echonet标准，可以通过一个Echonet UPnP网关来进行协议转换；但在需求中，所要支持的设备甚至不包含网络接口（如一般家用的空调、电灯等），即使有接口，也未必使用标准的以太网协议或IEEE802.11无线协议，其协议类型可能是多种多样的。归结而言，所要支持的设备可分为如下三类：

第一类设备：自身包含以太网接口或具有IEEE802.11无线网卡，如大多数网络摄像头。这类设备往往包含HTTP服务器，用户或程序可以访问其自带的Web页面实现设备信息获取和控制。

第二类设备：不具有标准的网络接口，或是虽有接口，但不符合以太 网或IEEE802.11标准，如普通空调、电视等。这些设备的另一个特点是控制逻辑一般较为复杂，如对于空调来说，不仅有简单的开关功能，还有模式切换、升温降温等功能。这些设备往往使用红外遥控器等进行控制，无网络接口。

第三类设备：控制逻辑简单，仅支持开关操作，如电灯等。显然，大多数这种设备没有网络接口。另外，这种设备的数量在家庭网络中往往是比较多的。

为了支持上述三类设备，需要分析它们的差异性，针对不同的情况设计不同的策略来处理。设备的差异性主要有两种：语法差异和语义差异。前者是指设备控制所使用的协议或物理连接方式与家庭网络系统中所使用的不同。比如，一般家用电视采用遥控器进行控制，使用的红外信号；而家庭网络系统中使用的是以太网。后者是指协议所承载的内容含义不同。比如，网络摄像头和无线报警灯可能都采用了HTTP协议，但是传输数据的实际含义肯定是不同的。

物理架构设计阶段主要解决语法差异，而语义差异则在逻辑架构设计阶段解决。对于第一类设备，由于其使用的协议与家庭网络采用的相同，因此可以直接接在家庭网络的局域网上，家庭网络平台只需要处理其语义差异即可。而对于第二类设备，需要开发专用的控制器，比如红外控制器等，用于实现系统所用的网络协议与专有协议（如红外信号等）的相互转换，然后用控制器的专有协议端控制设备，网络协议端与家庭网络相连，进而间接实现家庭网络与设备之间的相互通信。当然，在物理上互联之后，平台还必须解决此类设备在语义上的差异性。而对于第三类设备，与第二 类设备类似也必须引入控制器，只是控制器的私有协议端的信号类型非常简单，为开关信号，设备的控制语义也很简单，只有开和关两种状态。鉴于此，第三类设备的控制器表现为智能开关，使用网络信号来控制设备的通断；同时考虑到第三类设备数量较多，因此可以采用一对多的连接方式，使用一个多路控制开关来控制多个设备，以降低控制器成本。

下面介绍中心服务器软件系统的设计和实现细节。

1.功能分析

根据家庭网络系统的功能需求，结合中心服务器的功能特性，从中提取中心服务器应当完成的功能以及执行该功能的角色，将分析结果表示成用例图，如图3所示。

首先，该系统的参与者包含两大类：用户和系统时钟。所指用户不仅包含家庭网络的最终用户，也包含第三方应用程序；而管理员则是一种特殊的用户，他们可以执行一些有关系统管理的特权功能。显然，这两类参与者所能执行的用例具有明显区别。系统时钟主要执行更新设备信息的用例，这是因为家庭网络中设备的状态每时每刻都可能发生变化，比如用户可以随时插上一个设备或是拔掉一个设备，因此需要每隔几秒就重新扫描一下网络，更新设备的信息。而对于用户所能执行的用例，如管理个人账户、查看设备状态等，它们只在用户请求执行时执行。在家庭网关软件架构设计时，应充分考虑这种差别。

另外，从用例功能的角度，也可以把用例分为两类：一类如查看设备状态、管理设备、访问与控制设备、更新系统信息等用例，与设备密切相关，实现家庭网络的主要功能，为核心用例；另一类如管理个人账户、管 理用户信息、配置系统参数等用例，与设备关系不大，主要实现系统配置、用户管理等功能，为辅助用例。

图3中各用例的功能如下所述：

管理个人账户：用户登录系统后，可以修改自己的登录密码。

查看设备状态：用户可以查看当前家庭网络中连接了什么设备，它们的IP地址、MAC地址、设备类型分别是什么，可以查看各设备的厂商信息，功能特性等。

管理设备：用户可以从当前在线设备中添加设备进入“已添加设备列表”，表示用户已将该设备添加入家庭网络中。当然，也可以从该列表中删除设备。

访问与控制设备：用户可以登录到某一在线设备的Web服务器上，实现对该设备的访问和控制。

管理用户信息：该功能只有管理员才能完成，用来添加、删除或修改家庭网络的用户账户信息，包括用户名和密码等。

配置系统参数：该功能只有管理员才能完成，用来修改家庭网络的运行参数，如设置家庭网络的IP段、IP列表等。

更新系统信息：该用例由时钟触发，每隔一定的秒数执行一次，用来检查局域网中各设备的状态，从设备获取信息，然后更新数据库，以保证用户所查询的信息均为最新信息。该用例的执行需要调用两个子用例：设备发现和设备识别。前者用来获取当前网络中新接入了哪些设备，又有哪些设备离线；而后者则用来判断接入设备的类型，以确定合适的逻辑与之通信。

2.模块划分与结构框架设计

根据以上论述的需求特点，对中心服务器的软件系统进行了功能模块划分，将各模块的功能与相互关系使用数据流图（DFD）来表达，如图4所示。

图4所示的数据流图与图3所示的用例图具有紧密关联。用例图中的角色（Actor，人形图标）基本对应于DFD中的数据源（方框），只是后者还包括家庭局域网，这是因为家庭网关的所有通信都需要经过局域网，因此是重要的数据源；然而它并不是主动的通信发起者，故不是角色。用例图中的用例（Use Case）则对应于DFD中的处理流程（圆角矩形），不过由于1、5、6号用例不是关键用例，其功能较为简单，故在DFD中统一画作一个处理流程：用户管理与系统设置。所有这些功能都对数据存储提出了要求，需要存储的信息有五大类：用户信息、系统配置、在线设备列表、设备详细信息和设备驱动信息，在DFD上用向右开口的方框表示。所有这些元素之间的相互关系和通信数据在DFD上均有明确表示。

从图4上还可以看出，由系统时钟驱动的网络扫描（设备发现）和设备识别等功能与用户驱动的设备访问、管理等功能相对独立，它们之间主要通过一系列数据存储建立关系。这也体现了我们构建此系统的主要思路：即由一个监护进程不断与设备进行通信，更新设备的相关信息，存储在数据库中；而用户则可以随时从数据库中查看信息，并且只在必要时，直接与设备进行通信。这种方式可以明显提高用户访问系统时系统的响应速度，也符合该系统作为一个软硬件平台的定位。将这种思想具体化，我们可以得到如图5所示的软件结构框图。

由图5可以看出，整个系统主要由两大模块组成：

①系统监控模块，完成系统时钟驱动的设备信息更新功能；

②Web页面与Web Service API功能，主要完成用户驱动的各种功能，以及向外界以Web Service/SOAP协议的方式提供API。

这两个模块共享位于系统中层的各种服务，主要包括与网络通信相关的服务，以及与设备、虚拟化相关的服务。位于系统底层，操作系统上层的是数据库系统，其中包括存储驱动文件的驱动库和存储系统所需其他信息的主数据库。数据库之上是数据访问层和驱动加载器，它们的作用是将操作数据库的方法进行封装，方便数据库的访问。

3.动态特性设计

所谓动态特性设计，是指对于系统中的各关键用例，其执行时的流程及算法如何，采用什么方式实现功能。对于本系统而言，最大的难题在于如何完成设备发现和设备识别。因此本节对其进行详细介绍。

1）设备发现

设备发现有三大任务：

①能够监控到设备是否断开连接。

②能够监控到设备何时接入家庭网络。

③记录已接入设备的IP地址和MAC地址。

其中，第一个任务相对比较简单，只需要每隔一段时间Ping在线设备列表中的所有设备，如果有些设备没有响应，就意味着该设备离线，然后将此设备从在线设备列表中去除即可。

第二个问题比较麻烦。因为在以太网中，各网络设备是相互对等的，没有 哪台机器地位比其他设备高。因此，当一个设备连入时，它没有义务向其他设备发出通知。符合某些家庭网络标准的设备会主动进行设备注册，即通知家庭网关它刚刚连入，但是我们的系统支持的设备大多数不具备这种功能。

为了解决这个问题，可能的方法有如下几种：

Ping广播地址。在IP网中，每个网段的最后一个地址为广播地址，意为本网段的所有IP。如果我们Ping这个IP，那么理论上就相当于Ping本网段的所有机器，因此，通过分析返回包的IP地址，就可以得到当前在线设备的IP列表。然而，经过我们的测试，大多数网络设备（如摄像头、PC等）都不对广播Ping响应（可能是因为安全问题）。因此本方法行不通。

从宽带路由处获得设备是否在线的信息。该方法主要适用于无线网。按IEEE802.11的要求，无线设备接入无线基站（如无线路由）时，需要在基站处完成注册，表明其已经连入该无线网。该方法只能获得设备的MAC地址，不能获得IP地址。并且，需要考虑不同品牌、型号的宽带路由信息获取方法的差异性。

使用UDP协议发送特别构造的数据包，目的地址是全局广播地址（255.255.255.255）。之前我们通过实验发现，很多网络摄像头SDK中都带有IP扫描工具，可以迅速发现局域网中有没有相应型号的摄像头。为了了解其工作原理，我们对此类工具进行抓包分析，发现了如图6所示的数据包。该包为UDP包，源地址为本机IP，目的地址为全局广播地址，包的内容不定，随摄像头型号不同而不同。实验发现当指定型号的摄像头收到特定的UDP包后，会往广播地址发一个反馈包，其中包含了它的IP地址。这 些工具正是通过该反馈包获得指定设备的IP地址的。然而目前，我们只发现网络摄像头使用了这种方法，对于其他设备还没有见到。而且不同型号的摄像头，其包的格式有很大差别。总之，该方法应用面十分有限。

监控网络中ARP包的收发情况。局域网中的两个设备进行要进行通信，首先需要知道对方的MAC地址。然而一般发送方只知道对方的IP地址，这时就要使用ARP协议。发送方首先构造一个ARP包，询问谁的IP地址是某个指定的地址。由于ARP包是广播形式发送的，于是当某个设备发现它的IP恰好就是ARP包询问的IP时，它就会发一个反馈包，告诉发送方自己的MAC地址。由此可见，ARP包在局域网中是大量存在的，因为只要有通信，就可能产生ARP包。于是，可以通过侦听互联网中的ARP包的收发情况，记下发送方和接受方的IP地址，经过一段时间以后，便可以获得局域网中所有接入设备的IP列表。然而，该方法也有不少问题。首先，它的耗时较长，需要很久才能得到完整的IP列表；并且我们实验发现，有些网络设备接入局域网后根本不进行主动通信，只是等着别人来访问它，这样便不会有和它相关的ARP包存在。因此，该方法无论是可靠性还是性能都是比较差的。

循环Ping当前网段中的所有IP。考虑到家庭网络中的设备一般不会超过200个，因此用C类IP就可以了，地址范围从1到254共254个不同地址（最后一个255是用来做广播地址的）。由于有效地址并不是很多，因此可以循环Ping每个IP，通过回应情况，确定哪些IP被设备占用。

在对上述5种方法进行了分析比较之后，确定了使用最后一种方法。之所以这样选择主要是由于这种方法的适应期较好，不依赖具体设备，而且较 为方便快速。不过在循环Ping时要注意使用多线程技术，因为如果Ping的那个IP没有设备，程序必须等待较长时间（至少50ms左右）才能确定该IP确实没有设备对应，期间线程被阻塞住，无法继续推进，这样的话，200多个IP Ping下来需要很长时间。而通过多线程技术，则可以并行地Ping各个地址，速度会快很多。但是线程数太多的话，也会消耗系统资源，影响速度。我们经过试验，认为开20到40个线程会取得比较好的效果。

另外，有些设备的IP地址是用户手工设置的，用户知道这些设备的IP地址。此时，我们可以添加IP列表功能，当用户知道所有设备的IP地址时，可以编辑此IP列表。启用该功能后，Ping的范围被局限在该列表中，进一步加快了设备发现的速度。

现在来讨论第3个问题，即如何获得设备的IP地址和MAC地址。IP地址的列表在完成上述循环Ping后就已经得到了，因此关键在于如何从IP地址得到设备的MAC地址。其实，该问题的解决方法已经在第2个问题的解决方法4中提到了，即使用ARP协议。通过构造ARP包，询问对应IP的MAC地址，此时设备就会回传ARP应答包，其中包含设备的MAC地址。这样就解决了问题。

至此，设备发现功能的三个主要问题都已经解决。可以构造其执行流程图，如图7所示。

上述流程只要中心服务器一开机就会被反复调用，直到服务器关机。

2）设备识别

设备识别的任务是确定设备的类别，以及匹配与之通信所需要的驱动文件。

每个设备都有一个独一无二的特征，即向设备发送一个指定的请求时，设备将返回一个独一无二的结果。在制作驱动文件时，会提取设备的此种特征，并把它记录在驱动文件中。该特征可以用来识别不同的设备。首先，程序遍历驱动文件，比如说遍历到A的驱动时，向待检测的设备发送A的特征请求，如果此设备的返回刚好和A驱动文件中的规定符合的话，就说明该设备的类型就是A；否则，继续检验其他的驱动是否符合。

由于在总体架构中，已经规定家庭局域网中全部使用HTTP或Web Service方式进行通信，因此，这些特征请求事实上就是HTTP请求字符串，很容易在驱动文件中加以表示。设备识别功能的执行流程图如图8所示。

由图8还可以看出，检测出的设备类型被记录在了设备详细信息表中，而不是在线设备列表中。之所以这样设计，是因为这样在某一设备断开后又重新接入家庭网络时，可以立刻知道其设备类型，而无需重新检测（由于MAC地址的唯一性，直接在设备详细信息表中查找MAC地址相同的项即可）。毕竟，设备识别过程还是毕竟慢的。上述流程同样会在服务器启动后不断执行，直到服务器关机。

Claims (3)

1.一种家庭网络系统设备发现与识别方法，其特征在于：包括面向Web服务的家庭网络系统架构的系统环境、网关、中心服务器、家庭设备、设备发现、设备识别以及系统操作时序协议以及协议内容与格式；

所述系统环境是指家庭网络系统架构中支持有线和无线网络功能的协议标准、局域网中设备的限制以及设备应提供的协议服务；

所述网关是指家庭网络系统接入Internet网络的网络交换机或路由器；

所述中心服务器是指具有访问、管理和控制家庭设备功能的家庭个人电脑，是家庭网络系统的中心，安装有Web服务功能；

所述家庭设备是指通过有线或无线方式，直接接入家庭网络系统的智能家用电器；

家庭中所要支持的设备可分为如下三类：

1)第一类设备：自身包含以太网接口或具有IEEE 802.11无线网卡；

2)第二类设备：不具有标准的网络接口，或是虽有接口，但不符合以太网或IEEE 802.11标准；

3)第三类设备：控制逻辑简单，仅支持开关操作；

物理架构设计阶段主要解决语法差异，而语义差异则在逻辑架构设计阶段解决；

对于第一类设备，由于其使用的协议与家庭网络采用的相同，因此可以直接接在家庭网络的局域网上，家庭网络平台只需要处理其语义差异即可；

对于第二类设备，需要开发专用的控制器，用于实现系统所用的网络协议与专有协议的相互转换，然后用控制器的专有协议端控制设备，网络协议端与家庭网络相连，进而间接实现家庭网络与设备之间的相互通信；而对于第三类设备，与第二类设备类似也必须引入控制器，只是控制器的私有协议端的信号类型非常简单，为开关信号，设备的控制语义也很简单，只有开和关两种状态；同时考虑到第三类设备数量较多，因此可以采用一对多的连接方式，使用一个多路控制开关来控制多个设备，以降低控制器成本；

所述设备发现是指当设备接入或离开家庭网络系统后，中心服务器得知这一事件的过程；设备发现有三大任务：

①能够监控到设备是否断开连接

每隔一段时间Ping在线设备列表中的所有设备，如果有些设备没有响应，就意味着该设备离线，然后将此设备从在线设备列表中去除即可；

②能够监控到设备何时接入家庭网络

由于有效地址并不是很多，因此可以循环Ping每个IP，通过回应情况，确定哪些IP被设备占用；

③记录已接入设备的IP地址和MAC地址

IP地址的列表在完成上述循环Ping后就已经得到了，从IP地址得到设备的MAC地址时，通过构造ARP包，询问对应IP的MAC地址，此时设备就会回传ARP应答包，其中包含设备的MAC地址；

所述设备识别是指当设备接入家庭网络系统后，中心服务器得知该设备的类型、名称、状态的过程；

所述系统操作时序协议是指设备识别和离线过程中设备与中心服务器、网关之间的约定以及操作规程；

所述协议内容与格式是指设备被分配的IP的地址格式、上线通知信息格式、上线确认信息格式、设备信息格式、设备信息确认信息格式、在线通知信息格式、在线确认信息格式、离线请求信息格式和离线确认信息格式。

2.如权利要求1所述一种家庭网络系统设备发现与识别方法，其特征在于：所述网络协议标准是一个以太局域网构成的家庭网络系统中支持有线网络功能的IEEE 802.3协议标准，以及支持无线网络功能使用的IEEE802.11n协议标准；所述设备的限制是指局域网中的设备不超过250个，全部使用IPv4的C类地址来进行区分，每个设备通讯接口仅对应一个IP地址；所有设备均应提供HTTP协议服务，可以响应HTTP请求。

3.如权利要求1所述的一种家庭网络系统设备发现与识别方法，其特征在于：所述系统操作时序协议包括设备接入协议、设备离线协议和附加协议；

所述设备接入协议是指家庭设备接入家庭网络后，与中心服务器、网关之间的互动约定，网关动态分配IP地址；设备的上线通知、在线通知以及给中心服务器发送设备信息，中心服务器发现设备并获得设备MAC地址、向设备发送上线确认、在线确认和设备识别确认信息；

所述设备离线协议是指设备主动从家庭网关注销的过程；

所述附加协议是指上述协议之外需要补充说明的协议内容。