基于UPnP的通用型桥接器设计与实现

李 想，蒋 芸，周泽寻，谢国城，陈 娜，陈 珊



基于UPnP的通用型桥接器设计与实现

李 想，蒋 芸，周泽寻，谢国城，陈 娜，陈 珊

(西北师范大学计算机科学与工程学院，兰州 730070)

在现代物联网中，各类异构网络协议在设备互联上存在不兼容性问题。为此，设计一种能够同时支持多种异构网络协议互联的新型通用型桥接器，该桥接器以UPnP协议为标准。在协议的通用性桥接上，桥接器采用分层处理的方法，在底层为每个异构网络协议编写独立的、协议相关的插件模块，并动态加载到桥接器中，形成一个半开放式的转接引擎。实验结果表明，在不改变原有内部结构的情况下，该桥接器可动态加载或取消对任一异构网络协议的桥接，并对新协议的支持具有完全的开放性和独立性。桥接器可较好地完成各类异构网络设备间的互联，实现资源的共享和异构网络的融合。

UPnP协议；ZigBee协议；轻量级设备；异构网络；转接引擎；网络融合

1 概述

随着物联网的飞速发展，为了解决设备间的互联互通及资源共享问题，各类网络协议可谓层出不穷。在商业利益的推动下，许多网络在设备间的互联上都趋于成熟，因此，单一网络下的设备可轻易地实现互联。然而，如何实现这些异构网络间的融合成了一个新的问题。

UPnP[1]作为一个中间件协议，具有零配置、跨平台以及底层无关性等优点。其向上可形成统一的接入层，为上层应用提供统一的连接、交互和通讯机制。因此，以UPnP为核心，可以较容易地桥接各种异构网络，实现异构网络的融合。基于UPnP协议，现今国内外不少学者提出了各种类型的桥接方案，如用于传感器网络的桥接器[2-3]、ZigBee网络桥接器[4]、Bluetooth网络桥接器[5-6]以及IGRS和UPnP间的协议转换[7]等。这些桥接器都是面向单一网络协议提供桥接功能，但随着物联网的发展，已不能够满足更多网络间互联的需求。于是也有学者提出了多协议桥接器[8-9]，但其也只是对特定的几种网络协议进行桥接，是一种封闭的集成化桥接机制，无法再为新协议的动态加入提供支持。在现代物联网体系中，由于设备的更新和新协议的出现是迅速和频繁的，因此有必要提出一个多功能的桥接器，即该桥接器支持多协议桥接并对新的未知协议具有扩展支持功能。同时文献中的桥接器，大多缺乏明确的桥接器管理单元，尤其对于多协议间的桥接，更需管理单元对其进行管理、配置以及维护。

为实现对多异构网络设备的桥接，并能向后动态地兼容新的未知协议，本文提出一种通用型的桥接器(Common Bridge of UPnP, CBU)方案。CBU采用半开放式的转接引擎，对异构协议的支持具有动态性和良好的扩展开放性。为了实现对CBU透明化的使用和配置，并在管理功能上具有最大限度的可扩展性，该CBU设计采用独立式的管理单元。

2 通用型桥接器的框架

本文提出的CBU模型采用模块化设计方法，使CBU各个单元具有很强的通用性和松耦合性。对于异构协议，其能够提供动态的桥接支持。CBU由3大部分组成：虚拟UPnP设备(Virtual UPnP Device, VUD)单元，协议相关插件(Protocol Related Plug, PRP)单元，管理(Manager)单元，如图1所示。

图1 通用型桥接器框架

2.1 虚拟UPnP设备

VUD是非UPnP设备在CBU中的映射。VUD把下层传递的非UPnP标准的消息请求(如公布、控制、事件等)进行标准化后转发到UPnP网络中，是CBU实现桥接功能的核心单元。并且在该CBU中，为了提高对VUD资源的利用率，CBU提供了2种非UPnP设备到VUD的映射方式：独立式映射和嵌入式映射。

独立式映射(一对一映射)是指一个非UPnP设备占用一个VUD，而嵌入式映射(多对一映射)则是使多个非UPnP设备共用一个VUD。前者的优点在于独占VUD资源，如VUD中的Web服务器，消息通讯管道、线程池等，相应的消息响应速率快，但缺点是会增大系统开销，尤其对轻量级设备(Light Weight Device, LWD)进行映射时，会造成大量的资源浪费。这时采用嵌入式映射就显得十分高效，多个非UPnP设备共享单个VUD的许多资源，减少了不必要的开销。但缺点是过多的非UPnP设备共用一个VUD，在和控制点进行通讯时就有可能造成消息的阻塞或延迟。

CBU的管理单元会负责处理映射问题，对这2种映射方式进行合理的配置和管理，如限制一个VUD中的最大非UPnP设备的映射量等，以达到对资源的最优利用。

2.2 协议相关插件

PRP单元是CBU中唯一与具体异构协议相关的单元，起着屏蔽硬件和异构网络差异的作用。PRP向上为VUD提供一个统一的消息接口；向下一个PRP与一种特定的异构协议相关联。PRP是使CBU具有通用性和可扩展性的关键单元。

为了实现一个半开放式的转接引擎，使得对协议的扩展实现完全开放，CBU把消息的转换机制分成2个部分：UPnP标准消息封装机制和消息统一接口(Message Uniform Interface, MUI)机制。前者完成非UPnP消息的标准化封装，它是与特定异构协议无关的，被嵌入到VUD中；MUI则实现VUD和PRP之间通讯的标准化，提供一个接口规范。在桥接过程中，PRP使用异构网络协议标准接收设备消息，按照MUI标准，对消息进行预处理，统一消息格式及消息类型，最后传递给VUD进行UPnP标准封装。整个过程分为2个部分：预处理和标准封装。在PRP的预处理阶段，CBU就屏蔽了硬件和异构网络的差异，使VUD与具体异构协议无关，即异构网络协议对VUD是透明的。

CBU中只有PRP是异构协议相关的，故对任一异构协议的支持或屏蔽，在实现中，就表现为对PRP动态的加载及卸载，而这一过程一般由管理单元完成。对于新的异构网络，只需要根据其通讯协议编写一个PRP，动态加载到CBU，即可完成新异构协议设备到UPnP网络的映射。

同时，PRP也是整个系统中灵活性最大的部分。如可以通过编写专用PRP来动态生成非UPnP设备的XML文档，以适应对ROM/Flash有限制的芯片；甚至PRP可以简化和非UPnP设备间的通讯方式，以适应小内存的单片机(如标准8051的内存RAM只有128 Byte)。这些都可以根据实际需要进行调整。

2.3 管理单元

CBU把管理单元从协议转接机制中独立出来，提供了一个统一而独立的管理机制，具有良好的可扩展性。管理单元一般提供以下管理功能：

(1)管理单元本身是一个标准的UPnP设备[10]，它为用户抽象出管理和配置CBU的各项服务，屏蔽了桥接器的内部实现机制。

(2)记录所有加入网络的非UPnP设备，可以进行统一管理。

(3)管理VUD的生成及销毁、非UPnP设备的映射方式、PRP的加载及卸载等。

(4)提供异常管理单元，对整个系统出现的异常进行检测和修复。如检测到PRP异常退出时，管理单元首先会把通过该PRP连入的非UPnP设备所映射的VUD删除(对于独立映射)，然后可以选择重新启动该PRP，非UPnP设备便可重新接入。

(5)管理单元对扩展开放。根据需求，可为CBU提供额外的管理机制，如安全接入机制、电源管理机制等，这样可以提高CBU的各项性能。

3 CBU的软件实现

在Linux系统下，把管理单元、VUD、PRP设计为 3种独立的进程。

3.1 模块间的通讯

要进行异构协议的桥接，首先就要实现模块间的通讯。这里采用客户进程-服务器进程以及客户进程-客户进程的通讯方式完成单元模块间的通讯。把管理单元看作服务器进程，把VUD、PRP看作客户进程。管理单元提供一个众所周知的消息通道，这样客户进程可以通过该通道向服务器进程发起通讯，并向管理单元传递自己的专用消息通道，以后服务器进程就使用客户进程的专用消息通道向其发送消息。而客户进程-客户进程的通讯是通过各自的专用消息通道完成的，其中，服务器进程负责传递客户进程彼此的专用消息通道。

Linux系统平台下可采用命名管道(FIFO)作为消息通道，完成3个进程间的消息交互，图2显示了这种通讯机制。

图2 模块间的FIFO通讯

3.2 桥接器的操作流程

UPnP的工作过程分为5个基本步骤：发现，描述，控制，事件和展示。故桥接器的核心作用就是把非UPnP设备中关于这5个部分的消息进行再封装，使其符合UPnP消息标准，然后转发到UPnP网络中。

3.2.1 非UPnP设备的发现与描述

当一个非UPnP设备加入网络时，它需要在网络中发布自己，宣告自己的存在。图3展示了一个非UPnP设备加入UPnP网络的操作过程。

图3 设备加入UPnP网络的操作过程

当非UPnP设备接入网络时，会周期性地向PRP发送设备公告消息。PRP会把此消息传递到管理单元，由它调用设备映射模块，根据配置把设备映射到一个已存在或新生成的VUD中。VUD向PRP发送获取描述文档请求，PRP读取非UPnP设备的XML描述文件或配置信息，在VUD请求所指定的位置动态生成UPnP标准的XML文档。如果文档建立成功，PRP通知VUD，VUD则加载该描述文件，并在本地完成相关配置后，向UPnP网络公告自己的存在，让控制点读取描述文档，完成在网络中的注册。如果注册成功，UPnP控制点便可使用非UPnP设备提供的服务。最后，VUD还会向管理单元注册自己，以便CBU进行管理。

3.2.2 非UPnP设备的控制和事件

控制点和UPnP设备间通过设备控制请求和事件订阅进行交互。

当控制点获得VUD的描述文档后，就可以调用VUD服务中的任一动作，对VUD进行控制，这一过程就称作控制请求。图4展示了控制请求的转接机制。

图4 动作请求的内部机制

UPnP使用SOAP协议封装控制请求消息。VUD收到控制请求，会对其进行SOAP解析，之后按照MUI标准进行消息封装，并通过PRP发送到非UPnP设备。非UPnP设备解析控制请求消息并及时做出动作响应，最后返回动作响应消息到VUD。VUD对响应消息进行SOAP封装，然后发送到UPnP控制点。

事件相关消息的转接机制和控制请求相似。要订阅事件，订阅者(一般为UPnP控制点)向VUD发送一条订阅请求，VUD事件订阅机制会记录该订阅请求。如果是第一次订阅还需要向订阅者发送一个专门的初始化事件消息，该事件消息包含所有事件变量的名称和当前值。这时VUD会向非UPnP设备发送一条事件订阅消息，要求其返回当前所订阅服务的所有事件变量的名称和当前值。VUD将对接收到的事件变量名称和值以XML形式重新表示，最后使用GENA协议进行封装后发送到控制点。当非UPnP设备有一个以上变量(前提是该变量被设置了可触发事件)的值发生改变，非UPnP设备就会向VUD发送事件消息，以使订阅者及时获得设备相关服务的准确信息。

3.2.3 非UPnP设备的展示

展示给出了一个基于HTML的用户界面，用以控制或浏览设备状态。展示只是控制和事件的补充，不是必需的。如果设备拥有进行展示的URL，那么控制点就可以通过此URL取得一个HTML页面，在浏览器中加载该页面，并根据页面功能，支持用户控制设备或浏览设备状态。非UPnP设备的HTML页面在描述阶段就已和XML文档一起发送到VUD的Web目录下，故当控制端请求展示页面时，VUD会自动上传。而展示中的控制请求以及对设备状态的浏览，最终都会转换成前面的控制和事件来完成。

4 实验验证与结果

4.1 实验环境搭建

CBU的软硬件平台：处理器为S3C6410，ARM1176JZF- S内核，主频533 MHz/667 MHz。板载资源为128 MB DDRAM，1 GB NAND Flash(MLC)。系统环境为Linux，内核版本为3.0.1。使用Intel的libupnp-1.3.1 SDK构建VUD。

CBU与局域网相连，局域网中部署了一台装有Window XP的PC机，用做UPnP控制点；选用Zigbee网络作为异构网络，网络节点为传感器采集节点；选用8位微处理器STC90C516RD+(1 280 B SRAM，64 KB Flash，系统时钟频率为11.059 2 MHz)作为LWD的控制器。该LWD模拟另一个异构协议，完成流水灯服务(控制流水灯样式和频率)和蜂鸣器服务(控制蜂鸣器蜂鸣频率)的控制。实验中编写了2个PRP，分别通过串口和它们进行通讯。

4.2 实验结果

实验中设置LWD采用独立式的映射方式加入网络，Zigbee网络中的节点以嵌入式的映射方式加入网络。实验结果显示，Zigbee网络中的节点和LWD都能100%地连入网络，并可对设备进行控制和事件订阅，对于UPnP控制点发送的控制信息都可以在1 s左右得到响应。且2个PRP互不影响，都可动态地加载和卸载。

图5为Window XP环境下使用Intel的UPnP开发包(Developer Tools For UPnP Technologies)提供的Device Spy工具作为控制点，搜索到的Zigbee网络设备和LWD所映射的UPnP设备。

图5 非UPnP设备所映射的UPnP设备

在图5中，由上到下，Blind LED是LWD通过独立式映射得到的VUD；Embedded Non UPnP Bridge是由4个ZigBee设备通过嵌入式映射得到的VUD；UPnP Process Manager是CBU对应的标准UPnP设备。

Blind LED有2个服务，分别用于控制流水灯和蜂鸣器。如在控制点可通过调用LedOn()动作打开流水灯，这时Blind LED设备会按照流水灯样式状态变量的缺省值去运行流水灯。还可使用动作ChangeFrequency()传递一个频率值来改变当前流水灯的闪烁频率，或通过动作ChooseStyle()选择流水灯的样式等。总之，本桥接器实现了非UPnP设备到标准UPnP网络的动态连接及通讯，达到了预期效果。

5 结束语

UPnP通用型桥接器解决了异构网络和LWD加入UPnP网络的问题。该桥接器可以作为家庭网络中的转换器，连接各种异构网络(尤其是家庭网络中的无线网络，其易于安装、便于使用的优点已使其成为家电控制中不可或缺的一部分)以及轻量级家电设备。这样就可以形成一个统一的UPnP感知层，向应用层提供统一的UPnP规范的设备抽象服务。目前实验中的管理单元只是实现了管理模块中的基本功能，下一步将加入一些扩展功能，如安全策略及电源管理等，以进一步增强CBU的管理性能，使CBU更健壮。

[1] The Universal Plug and Play Forum. Universal Plug and Play[EB/OL]. (2000-01-04). http://www.upnp.org.

[2] Song H, Kim D, Lee K, et al. UPnP-based Sensor Network Management Architecture[C]//Proc. of the 2nd International Conference on Mobile Computing and Ubiquitous Networking. Osaka, Japan: [s. n.], 2005.

[3] Dobrescu R, Dobrescu M, Nicolae M, et al. Embedding Wireless Sensors in UPnP Services Networks[J]. NAUN International Journal of Communications, 2007, 1(2): 62-67.

[4] Kim K S, Park C, Seo K S, et al. ZigBee and The UPnP Expansion for Home Network Electrical Appliance Control on the Internet[C]//Proc. of the 9th International Conference on Advanced Communication Technology. Gangwon-Do, Korea: [s. n.], 2007.

[5] Jo Tae-Wook, You Yong-Duck, Choi Hoon, et al. A Bluetooth- UPnP Bridge for the Wearable Computing Environment[J]. IEEE Transactions on Consumer Electronics, 2008, 54(3): 1200-1205.

[6] Delphinanto A, Lukkien J J, Koonen A M J, et al. Architecture of a Bi-directional Bluetooth-UPnP Proxy[C]//Proc. of the 4th IEEE Consumer Communications and Networking Conference. Las Vegas, USA: IEEE Press, 2007.

[7] 胡艳萍, 杨 威, 陈援非, 等. IGRS和UPnP协议转换引擎的设计方法[J]. 计算机工程, 2011, 37(22): 28-31.

[8] Cheng D Y. UPnP Enabling Device for Heterogeneous Networks of Slave Devices: USA, US09/742, 278[P]. 2000-12-19.

[9] 张 全, 朱珍民, 罗海勇, 等. 泛在设备互联桥接器设计及实现[J]. 计算机工程, 2011, 37(20): 230-232.

[10] The UPnP Forum. UPnP Device Architecture 1.1[EB/OL]. (2012-03-13). http://upnp.org/specs/arch/UPnP-arch-Device Architecture-v1.1.pdf.

编辑 顾逸斐

Design and Implementation of Universal Bridge Based on UPnP

LI Xiang, JIANG Yun, ZHOU Ze-xun, XIE Guo-cheng, CHEN Na, CHEN Shan

(College of Computer Science & Engineering, Northwest Normal University, Lanzhou 730070, China)

In order to resolve the incompatibility of interconnection for many kinds of heterogeneous network device in the modern internet of things, this paper presents a new universal bridge which can support multiple network protocols at the same time, and the bridge based on the UPnP protocol. In the matter of protocol’s universal bridging, the bridge using the method of hierarchical processing, it provides an independent, protocol-related plug-in module for each heterogeneous network protocol at the bottom, and load to the bridge dynamically. This method results in a semi-open adapter engine. Experimental results show that under the condition without changing the bridge’s original structure, the bridge can dynamically provide or cancel the bridging support to any single network protocol, and provides a completely open and independent support for the new protocol. The bridge perfectly resolves the connectivity among many kinds of heterogeneous network device, and achieves a resource sharing and fusion of heterogeneous networks.

UPnP protocol; ZigBee protocol; lightweight device; heterogeneous network; forwarding engine; network fusion

1000-3428(2014)03-0294-04

A

TP368.1

国家自然科学基金资助项目(61163036, 61163039)；甘肃省自然科学基金资助项目(1010RJZA022, 1107RJZA112)；2012年度甘肃省高校基本科研业务费专项基金资助项目；甘肃省高校研究生导师基金资助项目(1201-16)；西北师范大学第三期知识与创新工程科研骨干基金资助项目(nwnu-kjcxgc-03-67)。

李 想(1989－)，男，硕士研究生，主研方向：嵌入式系统；蒋 芸，副教授、博士；周泽寻、谢国城、陈 娜、陈 珊，硕士研究生。

2013-01-05

2013-03-06 E-mail：nwnuxiang@gmail.com

10.3969/j.issn.1000-3428.2014.03.062