基于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