OSGi-Based Smart Home Architecture for Heterogeneous Network-20090924

OSGi-Based Smart Home Architecture for Heterogeneous Network

曾庆峰

学习时间           

2009-9-24

研究方向

OSGI ，Smart home 异构网络

中文题目

一种基于OSGi的面向异构网络的智能家居架构

来源作者

Red-Tom Lin, Chin-Shun Hsu, Tee Yuen Chun and Sheng-Tzong Cheng, OSGi-Based Smart Home Architecture for Heterogeneous Network，3rd International Conference on Sensing Technology, Nov. 30 - Dec. 3, 2008, Tainan, Taiwan.

作者简介

Red-Tom Lin, Chin-Shun Hsu,林若德汤姆，许进顺

Networks and Multimedia Institute,网络和多媒体研究所

Institute for Information Industry, Taiwan.台湾信息工业研究机构

Tee Yuen Chun袁正特 and Sheng-Tzong Cheng,郑宪宗

Department of Computer Science,National Cheng Kung University, Taiwan. 台湾成功大学资讯工程学系 教授兼系主任 无线与行动通讯实验室http://www.csie.ncku.edu.tw/new/nckucsie/index.php?content=teacher_person&id=9

http://www.inm.ntu.edu.tw/                 台湾大学，资讯网路多媒体研究所

联系方式

[e-mail]              [e-mail]

关键字眼

OSGi，DPWS，蓝牙，智能家居，soa，zigbee，Tmote

问题背景

家庭网络和服务应用的发展，提出了很多不同的协议和传输模式。也开发实现了很多遵从这些协议的数字设备和家庭电器。但这些建议的协议通常不能互相通信。家庭网络及设备通信协议很多如UPNP，IGRS，JINI，DPWS，DLNA等等。这些协议的竞争导致不同实现设备之间根本不能互相通信，也就不能真正的组成智能家居乐。通信协议不能交互，家居网络中设备的动态性和分布式连接也是一个问题。家庭网络中的服务是动态配置的，智能家居不仅要执行请求的指令，还要主动收集周围环境的上下文信息，三个主要挑战：动态，异构和分布式。

文章概述

为了整合家庭网络中的众多协议，设计和实现了一种构建于OSGi之上的面向服务的智能家居架构来整合当前流行的协议，并使Tmote，Zigbee，蓝牙相互协作来覆盖多种面向服务的应用。而且在这个平台上建议了三种新的基本驱动来整合不同的设备间的通信。另外给出了一个服务Resolving Bundle来弥补OSGi本身机制的缺陷。该面向服务机制的架构可以容纳不同领域的各种具体实现应用，允许系统中的组件间的互动。

主要内容

s1、介绍为什么要开发这个osgi based的架构。

S2、相关工作，介绍了OSGi，开放服务网关初始容器，本来设计用于在有限环境中使用，如嵌入式，但经过扩展可以用于各种领域。

S3、架构

A：系统概览，B：系统架构，C：基本驱动，D：Tmote 基本驱动，

S4、平台中的XML传输服务

A：OGSi机制的缺点，B：服务Resolving bundle

S5、分析和讨论

A：性能分析，B：性能评估

S6、总结

 

S3系统架构

A：系统概览

利用OSGi的包容性和模块化思想，家庭应用可以包含各种异构的网络和各领域的应用程序，整合来自不同领域的设备和服务，远程实体本地化，用户首先查询服务Bundle，再通过该bundle发送相关指令。

B：系统架构，将各领域的服务联系起来的是OSGi网关

 

C：基本驱动的架构是相同的，但根据不同的领域有不同的工作过程。

D：以Tmote驱动为例说明

Tmote驱动由Import和Export构成，import负责监听由设备或服务发送过来的广告消息，然后将所有发现的设备和服务都导入到当前OSGi环境中，使得他们对其他OSGi环境是可见和可用的实体，即将非OSGi环境设备和服务映射为OSGi设备和服务。而Export则是将OSGi设备和服务根据Tmote规范映射为Tmote域可视别的Tmote设备和服务实体。这些设备和服务都带有注册属性TMOTE_TMPORT或TMOTE_EXPORT。

 

 

因此根据OSGi和Tmote(或其他领域UPNP，DPWS，JINI等)规范，有两个转换过程：

1、  Tmote到OSGi的转换，首先Tmote base 驱动发现Tmote领域的灯和音乐播放器，然后发现他们提供开灯和放音乐的服务，那么就把他们都注册到OSGi环境中。

2、  OSGi到Tmote的转换，使得在OSGi中的服务不必再注册为Tmote服务了，驱动代为执行。大大减少了Tmote服务的定义和注册复杂性。服务注册表以XML格式的数据存储服务的相关信息。

 

 

S4、OSGi平台中各领域设备和服务的XML转换

A：OSGi本身的缺陷

发现：OSGi的发现机制是基于句法匹配的，只能取得与请求参数匹配或使用过滤器时服务属性中包含该关键字的的服务接口。因此会产生同义和同音异议的现象。例如以“Printing”搜索可能会丢失名为“print”的服务。

选择：也是基于句法选择的。

调用：OSGi阻止不可识别的bundle(没有服务接口前缀信息的)动态调用服务。

B：服务Solving bundle “SInfo”，监听网络中服务请求

关键角色，任何OSGi服务都要遵循Service Resolving XML规范。服务使用者还需知道调用该服务以获取目标服务更多信息的方法。

1）  服务注册，SInfo时刻监视有没有要注册的服务，有的话就取得其SRXML，记录相关服务提供者的服务接口名称。

2）  发现服务，因为得到OSGi服务要求请求bundle预先知道太多服务的信息，建议使用存储了服务信息的SRXML文件来实现发现过程，并增加了两个方法来提高查询的灵活性：supGetServiceReference(String SupplementURI)和 supGetServiceReference(String SupplementURI，String actionFilter)，都返回满足查询条件的服务的数组。

3）  OSGi服务的调用，SInfo管理服务的XML文件中的附加描述，SRXML负责记录同义，同音异议，和属性值等相关关键字，是基于UPnP模板描述的，添加多个标签。

4）  同义词和同音异议词

 

S5、分析和讨论

A：性能

n个客户同时向服务器请求服务，每次耗i个网络流量单元，每个服务包含m个服务提供者(SPs)和y个控制点(CP)，耗费提供者p个计算时间单元。每一服务需要与控制点交互j条消息，每条消息每次用掉h网络流量单元，控制点要与服务器交互z条消息，每条每次耗流量e。

主要考虑了网络流量和计算负载分别比较了传统智能空间和他们的OSGi空间的性能。

S6、系统评估

A：应用场景和原型系统实现

Knoplerfish2.0.5，JINI1.2.1，OdonataDPWS1.0.6，UPnPDomoware，Zigbee的light灯，和音乐播放器。

B：性能评估，给出了两种模型下面的性能时间比较图。

进阶问题

性能评价模型，过于简单，没有QoS，搜索服务，匹配，选择描述的过于粗糙

客观分析

工作很多，有实际工程支持，实现了UPNp，JINI，Zigbee，OSGi等环境下的设备互相转换文章写的不是很清楚，关键部分描述不清楚。

文章精华

将各个领域和OSGi环境下的设备和服务相互转换机制，利用SRXML文件存储已注册的信息，同时添加了同义词与同音异议词的标签

发现漏洞

QoS没有涉及，服务组合，具体映射机制没有提及

对我何用

知道了一种智能空间的基本架构，各种领域下的设备和服务要实现互通，可以用OSGi中间件将某种设备和服务翻译成本领域的设备和服务即可，也可以从协议转换角度考虑，通过OSGi翻译各个领域发送的消息。