基于OSGi的家庭网关的应用感知QoS控制的研究外文翻译资料

 2022-01-18 10:01


A study on OSGi based home gateway employing application-aware QoS control

Daisuke Takahashi , Eiichi Horiuchi

Abstract

To improve response time of time-sensitive application in a network using low speed communication channel, a mechanism which adjusts bandwidth usage between applications on a OSGi based home gateway (HGW) is proposed. The proposal is to equip a service bundle on HGW which enables QoS control by analyzing and scheduling packets of each application. We also perform a comparable calculation, for example, an application-aware scheme. As a result, the waiting time of a time-sensitive event driven packet is reduced from 283 ms to 144 ms in the considered case.

Keywords: Home Gateway; OSGi; Application-aware

I. Introduction

Home ICT services, such as home energy management system (HEMS) deploying sensors in a house, have been actively proposed, and OSGi based home gateway (HGW) for such Home ICT services also have been studied variously [1]–[2][3]. By using OSGi system, it becomes possible to remotely install and maintain the applications. Figure 1shows how the OSGi system works. By downloading and installing application software (called “bundle”) from the server, HGW will be able to give a Home ICT service such as connecting sensors with appliances.

In addition, the specified low power radio of 920 MHz has recently drawn keen attention because of its low power consumption and long reach performance. It also has been studied to apply specified low power radio between HGW and sensors, or HGW and appliances for Home ICT services [4]. With growth of Home ICT services, the features of low power consumption is increasingly more important because HGW can accommodate vast amounts of sensors.

However, there is a problem with time-sensitive applications when using the specified low power radio for Home ICT services due to its low speed communication.

In this paper, we describe this issue in detail and propose a solution system.

II. Issue in Application Response

There are applications that require time-sensitive response. They include, for example, television control systems in response to a detected signal of a voice sensor, and illumination control systems in response to a detected signal of a motion sensor. These applications are considered as event driven type applications that start their sequences when some user actions are detected. To meet the user demand, it is reported that the response time needs to be in some limited time [5].

On the other hand, applications which don#39;t require real-time response also exist. They include, for instance, HEMS system which periodically monitors the power consumption of appliances, an auto air-conditioning system utilizing temperature and humidity sensors, and home health-care service monitoring medical sensors. These examples are considered as polling type applications that pick up the sensor data in several periods for analyzing and providing specific services. Although these applications don#39;t require fast responses, the total communication traffic from all polling type applications will increase significantly when varieties of applications emerge such as Home ICT services.

Figure 1. OSGi Home ICT Platform

Figure 2. Congested sensor network

In actual home networks, these two types of applications co-exist. In a case where dozens of sensors designed to send packets co-exist, the response time of event driven type applications may be adversely affected.

For example, the function of performing illumination control sensor activated by the motion detector is considered (figure 2). In this case, the Sensor A(motion detector) detects movement of user and notifies the HGW of the event. However, the other Sensor B and C are in the process of sending the signal and Sensor A has to stand by until the transmission is completed ((Twaiting1). Even if Sensor A completes sending the signal, the HGW has to continue to wait for Sensor D and E to complete their transmissions (Twaiting2). In such a situation, the waiting times ((Twaiting1 and Twaiting2)cannot be controlled because sensors operates based on CSMA/CA control. Therefore, the total response time defined by the sum of each process/sending/waiting time may become longer.

Figure 3. Configuration of proposal

III. Proposed System

To improve the response time of the event driven type applications, it is necessary to consider the application-aware timing control. Toward this issue, we propose to add an application-aware QoS control function as an OSGi service.

Figure 3 shows the overview of the proposal. This proposal uses the OSGi mechanism which enables a bundle to provide its function to other bundles as a service. Each application bundle uses the provided service by making request to send or receive messages. When the service bundle accepts a request, it performs communication control by using each of the following functions.

Analysis: monitor the communication status of each bundles to determine what type of bundle communicates in. (Polling or event driven)

Scheduling: allocate bandwidth to each application based on the result of Analysis function.

Transceiving: sending or receiving packets according to the decided scheduled timing

IV. Evaluation of Proposed System

We describe a comp

全文共49526字,剩余内容已隐藏,支付完成后下载完整资料



基于OSGi的家庭网关的应用感知QoS控制的研究

Daisuke Takahashi , Eiichi Horiuchi

摘要

为了提高低速通信信道下网络中对时间敏感的应用的响应时间,提出了一种在基于OSGi的家庭网关(HGW)上调整应用间带宽使用的机制。该方案是在HGW上配置一个服务包,通过分析和调度每个应用程序的包来实现QoS控制。我们还执行类似的计算,例如,一个应用程序感知方案。因此,在所考虑的情况下,时间敏感事件驱动数据包的等待时间从283 ms缩短到144 ms。

关键词:家庭网关;OSGi;应用感知

第一章 绪论

已经提出的家庭ICT服务,如家庭能源管理系统(HEMS)在家庭中部署传感器,并对基于OSGi的家庭网关(HGW)在家庭ICT服务中的应用进行了各种研究[1]–[2][3]。通过使用OSGi系统,可以远程安装和维护应用程序。图1显示了OSGi系统的工作原理。通过从服务器下载和安装应用软件(称为“软件包”),HGW将能够提供家庭ICT服务,如将传感器与设备连接起来。

此外,920兆赫的指定低功率无线电由于其低功耗和长距离的性能,最近引起了人们的关注。还研究了将特定的低功率无线电应用于HGW和传感器之间,或用于家庭ICT服务的HGW和设备[4]。随着家庭ICT服务的增长,低功耗的特性变得越来越重要,因为HGW可以容纳大量的传感器。

然而,当使用指定的低功率无线电为家庭ICT服务时,由于其低速通信,时间敏感的应用存在问题。

本文对这一问题进行了详细的描述,并提出了解决方案体系。

第二章 应用程序响应中的问题

有些应用程序需要时间敏感的响应。例如,它们包括响应声音传感器的检测信号的电视控制系统和响应运动传感器的检测信号的照明控制系统。这些应用程序被视为事件驱动类型的应用程序,当检测到某些用户操作时,这些应用程序启动其序列。为了满足用户的需求,据报告,响应时间需要在某个有限的时间内[5]。

另一方面,不需要实时响应的应用程序也存在。例如,它们包括HEMS系统,该系统定期监测电器的功耗,利用温度和湿度传感器的自动空调系统,以及家庭保健服务监测医疗传感器。这些示例被认为是轮询类型的应用程序,可以在几个时间段内收集传感器数据,用于分析和提供特定的服务。尽管这些应用程序不需要快速响应,但当出现各种应用程序(如家庭ICT服务)时,来自所有投票类型应用程序的总通信流量将显著增加。

图1. 基于OSGi的家庭ICT平台

图2. 拥塞的传感器网络

在实际家庭网络中,这两种类型的应用程序共存。在设计用于发送数据包的传感器共存的情况下,事件驱动类型应用程序的响应时间可能会受到不利影响。

例如,考虑执行由运动检测器激活的照明控制传感器的功能(图2)。在这种情况下,传感器A(运动检测器)检测用户的运动并通知HGW事件。但是,另一个传感器B和C正在发送信号,传感器A必须待命,直到传输完成((twaiting1)。即使传感器A完成发送信号,HGW也必须继续等待传感器D和E完成其传输(twating2)。在这种情况下,等待时间(twating1和twating2)无法控制,因为传感器基于CSMA/CA控制运行。因此,由每个进程/发送/等待时间之和定义的总响应时间可能会变长。

图3. 配置方案

第三章 提出的系统

为了提高事件驱动型应用程序的响应时间,有必要考虑应用程序感知的定时控制。针对这个问题,我们建议添加一个应用程序感知的QoS控制功能作为OSGi服务。

图3显示了提案的概述。此建议使用OSGi机制,该机制使捆绑包能够将其功能作为服务提供给其他捆绑包。每个应用程序包通过发出发送或接收消息的请求来使用所提供的服务。当服务包接受一个请求时,它通过使用以下每个函数来执行通信控制。

1.分析:监控每个bundle的通信状态,确定bundle的通信类型。(轮询或事件驱动)

2.调度:根据分析功能的结果,为每个应用分配带宽。

3.收发:根据确定的定时发送或接收数据包。

第四章 拟议系统的评估

我们描述了一个比较评估的例子来确认NRONOSED系统的效果。

1.CSMA/CA调度:在CSMA/CA中,传感器或设备等各节点进行载波感知,确认竞争对手不在,等待随机时间后,各节点发送其包。在这种情况下,由于不区分应用程序类型之间的差异,发送节点是随机确定的。因此,单独使用CSMA/CA很难控制响应时间。

2.CSMA/CA 时隙调度:以应用感知控制为例,考虑时隙分配控制方案。图4说明了这个概念。这是一种控制方案,它为特定时间段内的事件驱动通信分配具有高优先级的时间段(在x ms时间段内表示为y ms)。在分配的时间段内,轮询通信被抑制。这类似于IEEE 802.11e HCCA[6]。在这种方案中,即使在信道中充满了轮询数据包的情况下,带宽也会以固定的间隔(x ms)变为空闲。因此,检测事件的传感器将能够无大延迟地传输数据包。

图5显示了比较CSMA/CA调度和CSMA/CA 时隙调度的计算结果。作为计算条件,假设1个事件驱动包(127字节)和50个轮询包(127字节)并发。这相当于100 kbps通信线路中50%的利用率。在此条件下,我们计算了事件驱动包的等待时间与其发生频率之比之间的关系。

图4. 调度方案

图5. 等待时间计算结果

从计算结果(图5)可以看出,对于没有任何应用程序感知控制的CSMA/CA调度,等待时间是不受控制的,并且似乎是随机分散的。平均等待时间283ms,最大等待时间500ms以上。另一方面,对于图4所示的时间段调度,参数x=200 ms和y=50 ms,等待时间更短。平均等待时间为144ms,最坏情况下的等待时间也小于200 ms。

由此可知,应用时隙调度可以缩短139ms的事件驱动包等待时间。

第五章 总结

为了提高低速通信信道中的时间敏感应用响应,提出了一种调整基于OSGi的HGW上应用程序之间带宽使用的机制。为了评估所提出的机制,我们对时隙调度方案进行了比较计算。结果表明,在所考虑的情况下,时间敏感事件驱动包的等待时间由283ms缩短为144ms,并证实了该系统的积极作用。

一种基于面向服务架构用于解决物联网中的异构问题(msoah-iot)的中间件

Yasser Mesmoudi , Mohammed Lamnaour, Yasser El Khamlichi,

Abderrahim Tahiri, Abdellah Touhafi, An Braeken

摘要

如今,许多物联网(IOT)应用已经成为解决日常生活问题的创新解决方案,出现在智能城市、环境监测、医疗保健、交通监控等不同领域。然而,大多数这些解决方案都是使用专有解决方案垂直构建的,这增加了异质性出血。为了解决这个问题,许多研究工作都集中在中间件解决方案上。然而,这种方法有一些局限性。在整个工作中,我们设计并实现了一个基于面向服务体系结构的中间件,能够处理异构问题。该解决方案分三步实施,首先使用RESTAPI从许多异构传感器硬件收集数据,然后引入异构网络接口,最后在不同操作系统上的网关上测试中间件。

关键词:中间件;智能网关;SOA;restful webservices;IoT

第一章 绪论

网络传感设备的使用正在快速增长。这种现象导致了数据量的增加、设备的异质性、数据格式和测量程序。管理传感器节点和评估伴随的数据量是当今的挑战。这些能够连接和交换数据的传感设备的网络称为物联网(IOT)。每天都有许多新的传感设备被制造出来,它们被安装在智能手机、智能手表上,或者仅仅安装在传感器节点上,这些节点可以被称为智能对象或事物。最近,一些垂直物联网解决方案已针对特定领域开发,如智能家居、智能建筑、汽车、智能环境、智能健康等。在最佳情况下,这些解决方案处理从数据收集和处理到应用程序使用的基于开放云平台上提供数据的整个过程。离子显影剂。大行业玩家生态系统的例子有:iotivity(英特尔 合作伙伴)、agileiot(华为)、alljoyn(高通)、homekit(苹果)、brillo(谷歌)。为了不被锁定在其中一个系统中,需要开放标准或至少公开文档化的应用程序接口(API)。今天,新技术不能作为一个组件出售,因为市场还没有准备好。因此,如果有兴趣将这些不同生态系统的特性结合起来,他们需要能够发现和访问数据源,并理解这些异构系统使用的语义。

正如摘自最具影响力文章的摘要(Liu等人,2017年)所述,大多数这些解决方案不支持不同通信技术的异构性,并且使用不同格式的交换数据。因此,需要在硬件端和应用程序端之间开发一个中间件作为中间软件层。为了有效地利用现有通信技术的能力,提供更灵活、可重构和高效的网络,所提出的中间件模型应提供数据兼容性、带宽管理、确保异构设备之间的连接以及解决安全问题。

我们的中间件架构是基于RESTAPI的面向服务的,它允许使用不同的网络接口(IP和非IP)和操作系统支持各种智能对象,并统一各种数据格式,用于向在不同平台上工作的最终用户提供所需的信息。推荐的中间件可以在不同的网关上实现,在我们的例子中,Raspberry PI配备了不同的网络接口,使该网关智能化,从而可以管理网络边缘的通信,并处理上面提到的异构问题。本文的其余部分组织如下:第2节提供中间件概念和准备工作,第3节介绍了相关工作。第4节描述了中间件的软件和硬件架构。第5节重点介绍了中间件的实现场景,并讨论了结果。最后,第6节总结了本文。

第二章 物联网中间件概念和准备工作

一般来说,中间件充当解释程序的角色,填补了不同物联网应用程序的高级别需求与底层传感器节点硬件中不同操作的复杂性之间的差距(Bhuyan等人,2014年)。

物联网中间件的设计需要满足几个挑战(Cec_lio和Furtado,2014年,Ajana等人,2015年):

bull;管理有限的电池电源和资源:为智能对象设计的中间件应为使用有限的内存提供适当的机制,并确保高效的功耗。

bull;可扩展性、移动性和动态网络拓扑:中间件应在网络环境不断增长的同时保持所需的性能。

bull;异构性:硬件、通信设备和配置操作之间的异构性必须由中间件处理。

bull;真实世界集成:中间件应提供实时服务,以适应最终的更改和数据更新。

bull;数据聚合:网络内的数据聚合确保不会生成冗余数据,通过内存使用节省成本,通过处理时间节省能源。

bull;应用知识:中间件必须包含注入物联网基础设施应用知识的机制。

bull;服务质量(QoS):在应用程序级别和网络级别都很重要,因为它定义了数据的准确性、覆盖率和容忍度。

bull;安全性:必须实现数据保密性和完整性,因为通过网络传输的收集信息很容易受到恶意入侵的攻击。

bull;容错:系统中恢复方法的集成对于启用抗故障网络是必要的。

继(Cec_lio和Furtado,2014年)之后,中间件方法可以根据其工作方式分为两大类:仅在网络内部运行的方法(经典方法),以及仅在网络外部集成和处理数据的方法。

2.1 网络中的WSN中间件

基于(Razzaque等人,2016年,Cec_lio和Furtado,2014年,Alshinina和Ellethy,2017年)网络内的WSN中间件方法分类如图1所示。

图1 中间件体系结构分类

每个方法都有几个中间件,如Cougar(Yao和Gehrke,2002)和Sina(Shen等人,2001)用于数据库方法,Agila(Fok等人,2005)和Impala(Liu和Martonosi,2003)用于模块化方法,Mat_(Levis和Culler,2002)和Swissqm(Mueller等人,2007)用于虚拟机方法,Mires(Souto等人,2005)和T。Inysoa(Rezgui和Eltoweissy,2007)用于消息导向方法,米兰(Murphy和Heinzelman,2002)用于应用驱动方法。

研究(Ajana等人,2015年,Bhuyan等人,2014年,Cec_lio和Furtado,2014年,Delicato等人,2014年)描述了每种中间件的优势和障碍,如前面提到的,并得出结论,为特定平台开发了经典方法。它们不提供网络异构部分之间的异构

全文共12686字,剩余内容已隐藏,支付完成后下载完整资料


资料编号:[965]

原文和译文剩余内容已隐藏,您需要先支付 30元 才能查看原文和译文全部内容!立即支付

以上是毕业论文外文翻译,课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。