initial dissemination & exploitation plan and activities · paper performance study of a video...

Initial Dissemination & Exploitation plan and activities

Cooperative Hybrid Objects Sensor Networks

DELIVERABLE NO 5.1 DELIVERABLE TITLE Initial Dissemination & Exploitation plan and activities AUTHOR Many PEER REVIEWER DATE SUBMITTED

Date of preparation: 01/07/2009

Project: CHOSeN Contract Number: INFSO – ICT - 224327S

Deliverable 5.1 Date: 1/7/2009

Version: 1.0 of 64

Proposal Acronym CHOSeN Deliverable 5.1 Abstract This deliverable serves to document the CHOSeN project dissemination at an initial stage of development. This document contains all publications made as a result of the research done on the CHOSeN project, including papers and posters published at scientific conferences, workshops offered as well as submissions to standardizing organizations. This document also details the venues at which the items were, or will be as the case may be, published. This information was gathered from the authors of the papers who are employees of or associated with partners of the CHOSeN project, the publications themselves. Additionally, the web presences of the different venues and their calls for papers were used as sources of information.

Standardization ITU-R WP 5B2 25.05.09 Workshop Concertation Meeting on Monitoring and Control for Energy Efficiency 04.03.09 Workshop Energy Scavenging Workshop 23.04.09 Panel “10 years of networked sensing systems- a look back and an outlook” 19.06.09 Demo Web-Based Internet Gateway for Wireless Sensor Networks Ongoing Paper Performance Evaluation Framework for Video Applications in Mobile

Networks 18.06.09

Paper Performance Study of a Video Application over Multi-Hop Wireless Networks with Statistic-Based Routing

12.05.09

Paper D-Bridge: A Platform for Developing Low-Cost WSN Product Solutions 17.06.09 Paper A Study on the Use of Wireless Sensor Networks in a Retail Store 11.05.09 Poster CHOSeN - Cooperative Hybrid Objects Sensor Networks 22.06.09



Version: 1.0 of 64

Table of contents 1 Standardization 5 1.1 ITU-R: Working Party 5B (WP 5B) - Maritime mobile service including Global Maritime

Distress and Safety System (GMDSS); aeronautical mobile service and radiodetermination service

5

2 Industrial Dissemination 5 3 Organized Workshops and Conferences 5 3.1 WORKSHOP: Concertation Meeting on Monitoring and Control for Energy Efficiency 5 3.2 WORKSHOP: Energy Scavenging Workshop 6 3.3 PANEL: “10 years of networked sensing systems - a look back and an outlook“ 6 4 Demos 6 4.1 Continuous Demo: Web-Based Internet Gateway for Wireless Sensor Networks 6 5 Papers and Posters 7 5.1 PAPER: Performance Evaluation Framework for Video Applications in Mobile Networks /

Alexander Klein und Jirka Klaue 7

5.2 PAPER: Performance Study of a Video Application over Multi-Hop Wireless Networks with Statistic-Based Routing / Alexander Klein and Jirka Klaue

7

5.3 PAPER: D-Bridge: A Platform for Developing Low-Cost WSN Product Solutions / Dawud Gordon and Michael Beigl

8

5.4 PAPER: A Study on the Use of Wireless Sensor Networks in a Retail Store / Dawud Gordon, Michael Beigl, Masayuki Iwai

9

5.5 POSTER: CHOSeN - Cooperative Hybrid Objects Sensor Networks / Thomas Herndl, Giuliana Zennaro, Jirka Klaue, Pierre-Damien Berger, Álvaro Álvarez Vázquez, Stefan Mahlknecht, Miroslav Konecny, Michael Beigl, Wolfgang Pribyl

9

6 Appendix 11 6.1 ITU-R: Working Party 5B (WP 5B) - Maritime mobile service including Global Maritime

Distress and Safety System (GMDSS); aeronautical mobile service and radiodetermination service

12

6.2 WORKSHOP: Concertation Meeting on Monitoring and Control for Energy Efficiency 28 6.3 WORKSHOP: Energy Scavenging Workshop 30 6.4 PAPER: Performance Evaluation Framework for Video Applications in Mobile Networks /

Alexander Klein und Jirka Klaue 33

6.5 PAPER: Performance Study of a Video Application over Multi-Hop Wireless Networks with Statistic-Based Routing / Alexander Klein and Jirka Klaue

41

6.6 PAPER: D-Bridge: A Platform for Developing Low-Cost WSN Product Solutions / Dawud Gordon and Michael Beigl

54

6.7 PAPER: A Study on the Use of Wireless Sensor Networks in a Retail Store / Dawud Gordon, Michael Beigl, Masayuki Iwai

59

6.8 POSTER: CHOSeN - Cooperative Hybrid Objects Sensor Networks / Thomas Herndl, Giuliana Zennaro, Jirka Klaue, Pierre-Damien Berger, Álvaro Álvarez Vázquez, Stefan Mahlknecht, Miroslav Konecny, Michael Beigl, Wolfgang Pribyl

63



Version: 1.0 of 64

List of Figures Figure 1. The D-Bridge Wireless Sensor Network Internet Gateway..................................................................... 7



Version: 1.0 of 64

1. Standardization

1.1. ITU-R: Working Party 5B (WP 5B) - Maritime mobile service including Global Maritime Distress and Safety System (GMDSS); aeronautical mobile service and radiodetermination service

“ITU is the leading United Nations agency for information and communication technology issues, and the global focal point for governments and the private sector in developing networks and services. For nearly 145 years, ITU has coordinated the shared global use of the radio spectrum, promoted international cooperation in assigning satellite orbits, worked to improve telecommunication infrastructure in the developing world, established the worldwide standards that foster seamless interconnection of a vast range of communications systems and addressed the global challenges of our times, such as mitigating climate change and strengthening cybersecurity. The ITU Radiocommunication Sector (ITU-R) plays a vital role in the global management of the radio-frequency spectrum and satellite orbits - limited natural resources which are increasingly in demand from a large and growing number of services such as fixed, mobile, broadcasting, amateur, space research, emergency telecommunications, meteorology, global positioning systems, environmental monitoring and communication services - that ensure safety of life on land, at sea and in the skies.”. EADS IW are co-authors (with Airbus) of the working document entitled “TECHNICAL CHARACTERISTICS AND OPERATIONAL OBJECTIVES FOR INSTALLED WIRELESS AVIONICS INTRA-COMMUNICATIONS.” The document can be briefly described as a “Working document toward a preliminary draft new report on technical characteristics and operational objectives for installed WirelessAvionics Intra-Communications (WAIC)” Their role is to support the demand for a dedicated frequency band for wireless avionics intra-communications (WAIC) with information about applications (justification of frequency band request).

2. Industrial Dissemination

None yet.

3. Organized Workshops and Conferences

3.1. WORKSHOP: Concertation Meeting on Monitoring and Control for Energy Efficiency

This workshop was conducted in October of 2008 in Brussels Belgium. The workshop in Brussels was organized by the EC project officer Jorge Pereira, intended to create synergies between the several ongoing EU projects dealing with (wireless) communication technology for monitoring and control applications supporting energy efficiency in the industries and public. The workshop included several presentations of results and demonstrations on the topic of monitoring and control for energy efficiency. The presenters and participants had international backgrounds, both from industry and academia. Among the presentations were results and proceedings from several projects on the topics of energy efficiency for monitoring and control in home and building applications, power grids and automobile engines. Participants included representatives of Telefonica (ES), EDF (FR), Lund University, TU Eindhoven, Univ. dell’Aquila, and Acciona (ES)..



Version: 1.0 of 64

3.2. WORKSHOP: Energy Scavenging Workshop

This conference occurred in April of 2008 in Ottobrunn, Germany and was organized by EADS IW. The purpose was to bring together researchers and industry to align the efforts regarding energy harvesting research (technologies, applications, integration) for autonomous wireless sensor nodes for monitoring and control. Topics covered included power harvesting to increase battery lifetime or create battery-independent applications, battery technologies to better save energy gathered, and energy transmission methods to improve redistribution of power sources. Participants were invited from EADS Innovation Works, Electronics and Information Technology Laboratory of the French Atomic Energy Commission, Airbus, Fraunhofer-Gesellschaft and Saft.

3.3. PANEL: “10 years of networked sensing systems - a look back and an outlook“

The International Conference on Networked Sensing Systems 2009 (INSS09) is an event dedicated to wireless networked systems and sensing systems. The INSS community crosses several traditional disciplines, including sensor development, wireless networks and computing system. The INSS conference series traditionally has a strong industrial background as well, bringing people from industry and research together. This year the panel will take a look back into the past and forward to the future of wireless sensor systems as a whole: Networked wireless systems is a very active research area for almost a decade now. This panel will a take a critical look back into the past and to the future, identifying promising developments, pitfalls, open issues and future potentials in engineering and research of wireless sensor networks and will be mediated by Prof. Michael Beigl. Panellists are expected to talk about the following issues in a short introduction talk

their personal view on past developments of networked sensing systems research and technology the 5 most interesting research findings and/or technical developments within the last 10 years related to

networked sensing systems the 5 greatest wrong assumptions in the field of networked sensing systems the 5 most important or promising open issues and problems related to networked sensing systems

either for industry or for research The panel will then continue, asking more detailed questions about past and future of networked sensing systems. Panellists include:

Phil Gibbons Nicolaie Fantana Hideto Iwaoka Yoshito Tobe

4. Demos

4.1. Continuous Demo: Web-Based Internet Gateway for Wireless Sensor Networks

A running demonstration of an Internet gateway for wireless sensor networks was demonstrated to Masayuki Iwai of Tokyo University as well as DB Schenker AG. The gateway connects wireless sensor networks to the Ethernet internet environment allowing the exchange of information between applications on the network and the sensor nodes. The gateway uses an embedded processor to enable communication between a RF communications module and an Ethernet module and the corresponding controller. The communications module handles communication



Version: 1.0 of 64

between the gateway and the individual wireless sensor nodes, and the Ethernet module handles corresponding communication with entities on the network. The device operates independent of a PC and is dynamically programmable in order to allow runtime changes to gateway behaviour. The demonstration was conducted in the Microprocessor Laboratory of the Technische Universität Braunschweig where development on the system is ongoing.

Figure 1. The Wireless Sensor Network Internet Gateway

5. Papers and Posters

5.1. PAPER: Performance Evaluation Framework for Video Applications in Mobile Networks / Alexander Klein und Jirka Klaue

This paper will be published at the Second International Conference on Advances in Mesh Networks, MESH 2009, in Athens, Greece, in June of 2009. The paper discusses routing techniques for wireless multimedia networks. The MESH conference handles the theme of MESH networking, which is a method for routing information in networks. MESH networking is often used for routing data, audio and command packets in an ad-hoc network. Subject matter handled by the conference within the MESH subject area includes architectures and algorithmic frameworks, protocols and applications. “Abstract - We present a framework for performance evaluation and optimization of video applications in mobile multi hop networks. We focus on the perceived video quality depending on the simulated mobility model, traffic pattern, retransmission strategy, and the configuration of the routing protocol. Moreover, the functionality of the framework is demonstrated by evaluating the performance of a video surveillance application with multiple mobile sources and sinks. The application is designed for exchanging multimedia content, e.g. audio and video streams, in wireless networks where all nodes are highly mobile.”

5.2. PAPER: Performance Study of a Video Application over Multi-Hop Wireless Networks with Statistic-Based Routing / Alexander Klein and Jirka Klaue



Version: 1.0 of 64

This paper was published at the Networking Conference in Aix-La-Chappelle, Germany in May of 2009 and discusses routing techniques for wireless multimedia networks. Networking 2009 is the 8th event of the series of International Conferences on Networking. It is organised by RWTH Aachen University's Chair of Computer Science 4 and sponsored by the IFIP Technical Committee on Communication Systems (TC 6). Networking 2009 aims at bringing together members of the networking community from academia and industry, to discuss recent advances in the broad and fast-evolving field of telecommunications, and to highlight key issues, identify trends and develop visions. The conference goals will be pursued through technical sessions as well as keynote talks on hot topics offered by invited experts. The technical sessions will be structured into two tracks in the following areas: Applications and services Wireless Networks Next Generation Internet

“Abstract. In recent years, technologies like Ultra Wideband (UWB) were developed that can be used to boost the data rate of wireless nodes to a new level. The higher data rate makes wireless networks capable of transporting multimedia content for real time applications like In Flight Entertainment (IFE), surveillance applications, or structural health monitoring. In this paper we measure and simulate the performance of a video application for IFE over a high data rate multi hop wireless network using a Directed Diffusion based routing protocol. Therefore, we take a look at the perceived video quality instead of focusing solely on the packet delivery ratio. Furthermore, we discuss the parameters of the Statistic-Based Routing (SBR) protocol which are relevant for this particular application and focus on their impact on the video quality during topology changes.”

5.3. PAPER: D-Bridge: A Platform for Developing Low-Cost WSN Product Solutions / Dawud Gordon and Michael Beigl

This paper has been accepted to the Sixth International Conference on Networked Sensing Systems from June 17 - 19, 2009 at Carnegie Mellon University in Pittsburgh, USA. In the paper, a hardware prototype is put forth which allows developers to simplify wireless sensor network applications and their development by extracting from the sensor network hardware interface. The International Conference on Networked Sensing Systems handles the fields of sensor technology, wireless networking, or application of networked sensor systems. The conference especially encourages submissions that investigate research issues shared between all three areas. The INSS provides a forum to hear about the latest developments in these areas, to exchange ideas, and to start up collaborations within these fields and between industry and academia. “Abstract—Today the construction of wireless sensing systems requires the use of rather high-priced pieces of hardware and the assembly of these hardware parts (wireless transmission core, sensor module, gateway device), as well as the implementation of the according software (sensor mote software, gateway software, end user software). This makes overall development and the thereby resulting product costly in terms of both time and money. With the D-Bridge concept that we present in this paper we will show an approach that is much cheaper than any other solution in terms of hardware and development costs. This D-Bridge is a combination of a gateway between the wireless sensor network and the IP network which also includes a Web-based application server at the wireless sensor network appliance’s location.“



Version: 1.0 of 64

5.4. PAPER: A Study on the Use of Wireless Sensor Networks in a Retail Store / Dawud Gordon, Michael Beigl, Masayuki Iwai

This workshop paper was accepted to the Pervasive Computing Conference in May of 2009 in Nara Japan. The paper discusses experiences gathered while conducting a study on the adoption of sensor network applications in a retail environment. The Pervasive Computing annual conference is the premier forum for researchers to present their latest results in all areas related to architecture, design, implementation, application and evaluation of pervasive computing. The conference covers innovations in mobile and pervasive computing, including but not limited to the following topics: Technologies and devices for pervasive computing Software aspects including middleware and operating systems for pervasive computing Tools, infrastructures, architectures and techniques for designing, implementing & deploying pervasive

computing systems Applications of pervasive computing technologies, Interfaces and modes of interactions between people

and pervasive computing devices, applications or environments Evaluations and evaluation methods, for assessing the impact of pervasive computing devices,

applications or environments Privacy, security, trust & social issues and implications of pervasive computing

“Abstract—This paper presents the outcome of a formative study - experiences and requirements - on using wireless sensor network technology in retail stores. The study was carried out in several steps. First, a simple approach to implementing a wireless sensor network system was used by a developer for

building a retail store application. Here we collected experiences about the problems in the application implementation process.

Second, the system was deployed in a real retail store. Here we collected feedback from customers and from retail store staff about the system, its usefulness and integration into the overall daily business workflow.

Third, we analyzed requirements for the next generation of improved wireless sensor network systems by performing a requirements study.

We will report our initial results of the requirements analysis study. The findings indicate a lack of abstraction from the technical details of the system needed to enable a high-level developer to create an application for a retail scenario, and we will list some of the important issues that need to be addressed.”

5.5. POSTER: CHOSeN - Cooperative Hybrid Objects Sensor Networks / Thomas Herndl, Giuliana Zennaro, Jirka Klaue, Pierre-Damien Berger, Álvaro Álvarez Vázquez, Stefan Mahlknecht, Miroslav Konecny, Michael Beigl, Wolfgang Pribyl

This paper is to be published at the Sixth Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks - SECON 2009, in Rome Italy. The poster is meant to inform about the CHOSeN project as well as show the progress made within the first 10 months of project development IEEE SECON provides a forum to exchange ideas, techniques and applications, discuss best practices, raise awareness and share experiences among researchers, practitioners, standards developers and policy makers working in sensor, ad hoc and mesh networks and systems. The conference is on the topics of communications, networking, applications, systems and algorithmic aspects of mesh and sensor networks, as well as practical deployment and implementation experiences.



Version: 1.0 of 64

“Abstract— The high level objective of the CHOSeN project is to develop application-specifically adaptable communication technologies enabling the real deployment of smart wireless sensor networks in large-scale, performance-critical application fields like the automotive and the aeronautic. Application scenarios in these fields entail a complex and heterogeneous set-up, in which different nodes require or provide different performance. An important aspect is the support and the compatibility with other vehicle networks, both new and legacy. The CHOSeN project is on the way to develop a new hardware and software platform enabling distributed optimal execution and scalable performances. The new middleware architecture will also support the system auto-configuration through dynamic resources discovery and management. The following paper provides an overview on the motivation and targets of the project and summarizes the project status after 10 months duration.”



Version: 1.0 of 64

6. Appendix



Version: 1.0 of 64

ITU-R: Working Party 5B (WP 5B) - Maritime mobile

service including Global Maritime Distress and Safety

System (GMDSS); aeronautical mobile service

and radiodetermination service

EADS IW, Airbus

25.05.2009 No Location



Version: 1.0 of 64

Radiocommunication Study Groups

Source: Document 5B/175(Annex 32), 5B/212, 58/240, 5B/248

WORKING DOCUMENT TOWARD A PRELIMINARY DRAFT NEW REPORT ON TECHNICAL CHARACTERISTICS AND OPERATIONAL OBJECTIVES

FOR INSTALLED WIRELESSAVIONICS INTRA-COMMUNICATIONS (WAIC)

(DRAFT NEW QUESTION ITU-R [WAIC])

1 Introduction

Installed wireless avionics intra-communications (WAIC) consist of radiocommunications between two or more points on a single aircraft. Points of communication may include integrated wireless components and/or installed components of the system. In all cases communication is assumed to be part of a closed, exclusive network required for operation of the aircraft. WAIC systems do not provide air-to-ground or air-to-air communications. Only safety related applications are being contemplated for WAIC systems. It is not anticipated that spectrum utilized for WAIC systems will be used for non-safety related aircraft applications such as in-flight entertainment (IFE) communications nor include communications with consumer devices, such as radio local area network (RLAN) devices that are brought on board the aircraft by passengers. Also, WAIC systems transmissions may not be limited to the interior of the aircraft structure, depending on the type of aircraft. For example, sensors mounted on the wings or engines could communicate with systems within the airplane. WAIC systems may be used on regional, business, wide-body, and two-deck aircraft, as well as helicopters. These different aircraft types may place different requirements on the WAIC systems and may also impact the type of propagation path between the WAIC transmitter and receiver.

Document 5B2c-Doc01rev1 25 MAY 2009

Source: Document 5B/175 Annex 32, 5B/212, 5B/240 5B/248,

Subject: Wireless Avionics Intra-Communications (WAIC) English only

5B2

TECHNICAL CHARACTERISTICS AND OPERATIONAL OBJECTIVES FOR INSTALLED WIRELESS AVIONICS INTRA-COMMUNICATIONS



Version: 1.0 of 64

http://www.itu.int/md/meetingdoc.asp?lang=en&parent=R07-WP5B-C-0212




As the reliance on wireless technology continues to expand, the use of WAIC systems to transmit information important to the safe and efficient operation of an aircraft may provide significant advantages over current wired systems.

2 Discussion

WAIC systems are envisioned to provide communications over short distances between points on a single aircraft. WAIC systems are not intended to provide communications, in any direction, between points on an aircraft and another aircraft, terrestrial systems or satellites. WAIC systems are intended to support data, voice and video (to monitor different areas on the aircraft) communications between systems on an aircraft including communications systems used by the crew. It is also envisioned that wireless sensors located at various points on the aircraft will be used to wirelessly monitor the health of the aircraft structure and all of its critical systems, and communicate information within the aircraft to those who can make the best use of such information.

Points of communication may include integrated wireless components and/or installed components of the system. In all cases communication between two points on a single aircraft is assumed to be part of a closed, exclusive network required for operation of the aircraft. WAIC systems are not intended to provide air-to-ground communications or communications between two or more aircraft. They are also not intended to include communications with consumer devices, such as radio local area network (RLAN) devices that are brought onboard the aircraft by passengers or for in-flight entertainment applications.

WAIC systems are envisioned to offer aircraft designers and operators many opportunities to improve flight safety and operational efficiency while reducing costs to the aviation industry and the flying public.

Because WAIC systems are installed on aircraft, they are as transient as the aircraft itself and will cross national boundaries. Therefore, the ITU-R, national and international organizations involved in radiocommunications and air travel should work together in addressing this issue. The scope of WAIC applications is limited to applications that relate to the safe, reliable and efficient operation of the aircraft as specified by the International Civil Aviation Organization. It is intended that WAIC systems will only be used for safety-related aircraft applications.

WAIC systems are envisioned to provide significant benefits to all who use the sky to travel. Some of the potential benefits of WAIC systems are described below.

2.1 Substitution of wiring

Cabling and wiring present a significant cost to the aircraft manufacturer, operator, and ultimately the flying public. Costs include the wiring harness designs, labour-intensive cable fabrication, reliability and replacement costs of connectors, as well as the associated operating costs of flying copper and connectors that represent 2-5% of an aircraft’s weight.

Wiring harness design is one of the critical factors that determine the time required to design a new aircraft, requiring the designers to specify and determine the routes for miles of wire onboard the aircraft. This includes providing separate routing paths for redundant wiring, so that a single point failure does not affect redundant circuits, and enables safety critical systems to be properly isolated from other system wiring. Wireless products offer solutions that can reduce the time and costs associated with wiring harness design, harness installation design, aircraft manufacturing time, and aircraft lifecycle costs.



Version: 1.0 of 64

Wiring also constitutes over 50 percent of the instances of electromagnetic interference on board aircraft. Wiring can act as antennas and collect unwanted energy that may impact interconnected system immunity. Wiring can also radiate energy with the risk of inducing electro-magnetic interference on surrounding systems. Providing wireless links, in lieu of wiring can provide connectivity without the need for redundant wiring harnesses that are specific to a specific aircraft type, resulting in economies of scale for small, medium and large aircraft.

As an airframe is utilized during its lifetime, it may be necessary to install new sensors to monitor portions of the aircraft structure or aircraft systems either as a result of incident or accident awareness or as a result of the availability of new types of sensing technology. On current aircraft, adding a new sensor is very expensive due to the requirements to install wiring, connections to the central processing system, and modifications to software. WAIC networks could allow new sensors to be mounted with much less difficulty and expense, and enable easier modification of systems and structural monitoring throughout the life of the aircraft, which typically exceeds 25 years.

2.2 Enhance reliability

Wiring is a significant source of field failures and maintenance costs. It is extremely difficult to troubleshoot and repair such failures in aircraft system wiring which occur primarily at interface points where connectors, pins, and sockets come together. The large number of parts and human error also contribute to failure at these interface points. A wireless system may significantly reduce electrical interfaces and thus significantly increase system reliability.

By having fewer wires on an aircraft, the need for wire maintenance to remediate chafing conditions, aging wiring and associated fire hazards is reduced, thereby improving the safety and reliability of the aircraft. Wireless technologies are also intended to offer the means to implement reliability-enhancing systems. Adding new sensors on an aircraft to monitor functions such as equipment cooling status that measure the temperature around components to provide a more accurate status of equipment cooling, has the potential to improve the reliability of aircraft. The introduction of these additional sensors has been limited due to wiring weight and cost impact, but they might be implemented using wireless technology. Aircraft data networks could also take advantage of redundant communication paths offered through mesh networks, which are not cost-effective in hard-wired form.

Critical aircraft functions must be fault-tolerant, which leads aircraft designers to include redundant components and redundant wiring harnesses. However, the use of identical technology (in this case duplicate wiring harnesses) to provide fault tolerance can make a design susceptible to “common mode failures” such as fire or lightning strike. The use of a wireless link as a backup to a wiring harness introduces redundancy through dissimilar means that can in fact enhance reliability in some critical situations, and can provide connectivity without the need for redundant wiring harnesses specific to a particular aircraft type.

2.3 Additional functions

Wireless technologies are also envisioned to provide new functionalities to aircraft manufacturers and operators. Manufacturers are provided additional installation options for previously wired systems, while operators are afforded more opportunities to monitor aircraft systems. Currently, there are few dedicated sensors for monitoring the health of aircraft systems and structure as the aircraft ages. Wireless technologies could provide additional opportunities to monitor more systems without increasing the aircraft’s weight. Some additional functions that could be incorporated on an aircraft with wireless technology that cannot be performed with wires include engine rotator bearing monitoring and lightning damage sensors. Reliably routing wiring harnesses to engine rotator bearings is impractical due to the movement of parts. Utilizing a special temperature sensor and



Version: 1.0 of 64

transmitting this sensor information wirelessly could provide significant benefits by furnishing sensor data while the aircraft is in-flight. Another example includes on-board sensing of lightning or other environmental damage that occurs while the aircraft is in flight.

Another application is wireless voice, video and data crew communications. It is envisioned that cockpit crew voice and video services could provide enhanced aircraft safety by enabling the monitoring of cabin, luggage compartments and other areas in and around the aircraft. In addition, wireless technology could provide more adaptive cabin configurations and potentially more customized subsystems.

3 WAIC System Classification

In discussing the requirements and performance of future wireless aircraft systems, it is useful to simplify the discussion by classifying these systems according to two characteristics: data rate, and internal versus external aircraft location. By classifying aircraft wireless applications accordingly, the discussions can focus on a small number of classes instead of trying to deal with the myriad of sensors and applications.

FIGURE 1

WAIC System Classification

WAIC System Classification

Location Data Rate

I (inside)

3.1 Classification process description

Each of the potential WAIC systems was studied to determine their operational requirements for net data transmission rates per communications link, and possible location (within or outside the aircraft). The net data transmission rate per communications link was then translated into a gross data transmission rate requirement by including typical overhead margins of protocols currently available. It is believed that most applications will be internal to the aircraft structure, but some applications will be outside at least some of the time. Landing gear sensors, for example, will be external when the gear is extended. Some structural health monitoring sensors may be installed outside.

O (outside)

L (low)

H (high)



Version: 1.0 of 64

3.1.1 System data rate classification

Potential wireless applications can be broken down into two broad classes corresponding to application data rate requirements. Low (L) data rate applications have data rates less than 10 kilobits per second (kbps), and high (H) data rate applications have data rates above 10 kilobits per second. These classifications will be signified by “L” and “H” respectively.

3.1.2 System location classification

Applications that are enclosed by the airplane structure (e.g., fuselage, wings) are classified as inside (I). Those applications that are not enclosed are classified as outside (O). Some applications may be classified differently depending upon a specific operational scenario. For sharing study purposes, the “worst case” scenario will be utilized.

3.1.3 Class definition

WAIC applications can be classified by XY following the previous definitions. The parameter X represents the data rate (H, L), and the parameter Y represents the location (I, O). For example, a typical class is LI, representing an application with low data rate requirements, and located internal to the aircraft structure. Detailed descriptions of the applications in each class will be given in the next section.

3.2 Detailed description of applications by class

In this section each potential application is described under the classification for that application.

3.2.1 Classification LI

General: The class of LI applications is characterized by the following main attributes:

data rate: low (<10kbps)

installation domain: inside metallic or conductive composite enclosures.

Most of the LI RF transceiver nodes will be active during all flight phases and on the ground, including during taxiing. Estimates predict the number of LI nodes installed in an aircraft will be around 3,500.

3.2.1.1 LI class member applications

The LI class includes applications from the domain of low data rate wireless sensing and control signals, e.g. cabin pressure control, smoke sensors, as well as door position sensors. Detection of objects that can be removed from the aircraft, like life vests and fire extinguishers, using wireless technology is seen as a member application of this class. Table 1 lists the anticipated applications of the LI class including further attributes associated with each individual application.

TABLE 1

LI class member applications

Application Type of Benefit Net peak data rate per

data-link / (kbps)

Node Quantity

Activity period New or Existing

Application

Cabin Pressure

Wire reduction 0.8 11 ground, takeoff, cruise, landing

Existing



Version: 1.0 of 64

Engine sensors

Wire reduction, maintenance enhancement

0.8 140 ground, takeoff, cruise, landing

Existing

Smoke sensors (unoccupied areas)

wire reduction, maintenance enhancement, safety enhancements

0.1 30 ground, takeoff, cruise, landing, taxi

Existing

Smoke sensors (occupied areas)

wire reduction, flexibility enhancement safety enhancements


Existing

Fuel tank/line sensors

wire reduction, safety enhancements, flexibility enhancements, maintenance enhancement


Existing

Proximity sensors, passenger & cargo doors, panels

wire reduction, safety enhancements, operational enhancements


Existing

Sensors for valves & other mechanical moving parts

wire reduction, operational enhancements

0.2 100

ground, takeoff, cruise, landing, taxi

Existing

ECS sensors wire reduction, operational enhancements


Existing

EMI detection sensors

safety enhancements 1.0 30 ground New

Emergency lighting control

wire reduction, flexibility enhancement


Existing

General lighting control


0.5 1,000 ground, takeoff, cruise, landing

Existing

Cabin removables inventory

operational improvement

0.1 1,000 ground New

Cabin control wire reduction, flexibility enhancement


Existing

3.2.1.2 Expected data rates per application

Per-link data rates are expected to be relatively low, i.e. below 10kbps, because anticipated applications of the LI class are mainly identified for either monitoring or controlling slow physical processes, such as temperature variation at sampling rates of e.g. 1 sample per second or less. Furthermore, transmission delay constraints are not considered an issue for this class. Both of the above aspects allow transmission of data at per-link data rates at or below 10 kbps. However, it is



Version: 1.0 of 64

noted here that these low per-link data rates do not allow any conclusion on overall aggregate data rates without a reasonable estimate of the number and density of concurrently active radio links associated with LI applications, as well as their traffic statistics. For example:

Cabin pressure WAIC applications should require the following net per-link data rates:

- 64 bps for navigation and air data interfaces.

- 320 bps for each controlled valve.

- 800 bps for display information.

As 11 nodes are estimated then the aggregate data rate would be 8.8kbps worst case.

Engine Sensor WAIC application should require the following net per-link data rates:

- 0.8 kbps worse case for each engine sensor (temperature, fuel flow, oil pressure, fire detection, etc.), giving a total of 28 sensors per engine.

Fuel tank line sensors should require the following net per-link data rates:

- 240 bps for refuel/ defuel commands (fuel management and quantity gauging sensors)

- 32 bps for fuel temperature data in the main and collector tanks

Passenger door sensors utilize one sensor for each door position. There are two door positions: closed; locked and handle locked. The expected net per link data rates is 0.2 kbps.

Cargo or baggage door sensors utilize one sensor for each door position. There are two indicate two positions: closed, or handle locked. Each position is managed by 1 sensor. The expected net per link data rates for this application will be 0.2 kbps.

Emergency door sensors utilize one sensor for the door locked position. This will need an 0.2 kbps link.

3.2.1.3 Installation domain

All applications of the LI class are anticipated to operate within the aircraft structure. WAIC devices installed in different compartments may, in some cases, be able to operate on the same communications channel and enjoy the ability to re-use frequencies.

3.2.1.4 Additional class attributes

Different LI applications will have different channel access, duty cycle and activity time characteristics. Some of the LI class applications will be constantly active, while other applications will only be active for limited periods of time.

The expected required communications range will vary between several centimeters to several tens of meters, depending on the installation locations of the RF transceivers and network topology. Propagation conditions are expected to be dominated by non-line-of-sight paths, due to the fact that most of the RF transceivers associated with applications of the LI class are likely to be mounted in hidden locations.

Engine sensors are considered “Inside” only when the nacelle is made of metallic material or some other material that provides EMI attenuation similar to metal.

3.2.2 Classification LO

General: The class of LO applications is characterized by the following main attributes:

data rate: low (<10 kbps)



Version: 1.0 of 64

installation domain: outside aircraft structure

Most of the LO RF transceiver nodes will be active during all flight phases and on the ground. However, some applications will only be active during certain flight phases. The anticipated number of nodes belonging to this class is estimated to be as many as 900 (for a large airliner).

3.2.2.1 LO class member applications

The LO class includes applications from the domain of low data rate wireless sensors such as temperature, pressure, humidity, corrosion detection sensors, structural sensors, and proximity sensors. Also included are cargo compartment sensors of two types; 1) only active while on the ground (at terminal) to transmit information such as a manifest of cargo or baggage, and 2) active in all phases of flight to transmit possible cargo weight distribution shifts. Wheel speed for anti skid control, wheel position for steering control, engine parameters for engine control and flight surface parameters for flight control are included within this class.

Table 2 lists the anticipated applications of the LO class including further attributes associated with each application.

TABLE 2

LO class member applications


data-link / (kbps)

Node Quantity


Application

Ice detection Operational and safety enhancement

0.5 20 Ground, takeoff, cruise, landing

Existing + New

Landing gear (proximity) sensors

Wire reduction, flexibility enhancement


Existing

Landing gear sensors, tire pressure, tire and brake temperature and hard landing detection

Wire reduction, flexibility and operational enhancement

1.0 100 Ground, takeoff, landing

Existing

Landing gear sensors, wheel speed for anti skid control and position feedback for steering

Wire reduction, flexibility and operational enhancement

5.5 40 Ground, takeoff, landing

Existing

Flight control system sensors, position feedback and control parameters

Wire reduction, flexibility enhancement


Existing



Version: 1.0 of 64

Additional proximity sensors, aircraft doors

Wiring reduction, flexibility enhancement


Existing

Engine sensors

Engine performance, wire reduction, flexibility enhancement


Existing + New

Cargo Compartment Data


0.5 25 Ground, takeoff, cruise, landing, taxi

Existing

Structural Sensors

wire reduction, flexibility enhancement, safety enhancements


New

Temp./Hum. And Corrosion detection

wire reduction, safety enhancements, operational enhancements


Existing + New


Per link data rates are expected to be below 10 kbps because some of the anticipated applications will be utilized for monitoring status (e.g. door position) which requires a low sampling rate, while other applications are anticipated to use low amounts of data for relatively fast control loops (e.g. wheel speed for anti-skid control at 2.5 ms).

For this class of sensor, transmission of data will be at low per-link data rates. However, there may be a large number of these transmissions in a small area. Therefore, these low per-link data rates do not allow any conclusion on overall aggregate data rates without a reasonable estimate of the number and density of concurrently active radio links associated with LO applications as well as their traffic statistics.


All applications of the LO class are assumed to operate outside the aircraft structure. A significant number of the LO class applications are anticipated to be mounted on the landing gear and in the landing gear bay. It is a strong desire to remove wiring from this harsh environment to improve aircraft maintenance tasks. It is anticipated that a significant number of wireless transmission devices will be outside the aircraft when the landing gear is down.

Other LO applications may be mounted on exposed areas of the wing where data may be transmitted to and from flight control sensors and actuation devices. These types of sensor are typically mounted on the trailing edge of the wing and are exposed when the flaps, spoilers or ailerons are moved.

Engine sensors may also be included as an LO application depending upon the materials utilized for the nacelle. For this reason, engine sensors are included in both application classes (LI or LO), depending on the nacelle construction.


Different LO WAIC applications will have different characteristics in terms of channel access, duty cycle and activity time. Some devices will be constantly active while other devices will only be active for a limited period of time.



Version: 1.0 of 64

The transmissions range will vary between several meters to several tens of meters, depending on the installation locations of the RF transceivers and the network topology. It is envisioned that some applications will transmit while the aircraft is in close proximity to other aircraft also transmitting. Furthermore, propagation conditions for some applications will be non line-of-sight paths.

3.2.3 Classification HI

General: The class of HI applications is characterized by the following main attributes:

data rate: high (>10 kbps burst rate per node)

installation domain: inside aircraft structure

Most HI RF-transceiver nodes will be active during all flight phases and on the ground. However, the nature of the data source traffic for the transmitters is a mix of regular periodic updates for sensor reporting for the entire duration of the flight, interlaced with irregular message bursts on an on-demand basis (voice, video) that do not reflect any periodic or sustained average loading. The maximum number of nodes which belong to this class is anticipated to be 100 per aircraft. Note that some of these voice/video/imagery source nodes (cameras and microphones) are dual purpose in that they may be utilized by either the flight deck or cabin crew, depending on the situation (emergency or alert vs. routine) and level of service. While, they are shown as separate rows in Table 3, they are actually the same application.

3.2.3.1 HI class member applications

The HI WAIC application class includes flight deck and cabin crew communications throughout the aircraft. These communications are primarily (digitized) voice, but include frame imagery and video, as well as Electronic Flight Operations (EFO) data and other data file transfers. It also includes special higher rate engine (and other) sensor applications for condition based maintenance.

The flight deck crew voice and video/image communications allow expeditious coordination with cabin flight attendants, as well the ability to monitor the conditions of the aircraft cabin, luggage compartments, and other areas only accessible by camera. HI WAIC applications also include engine prognostic sensors, used for in-flight monitoring of various engine parameters for post-flight analysis and preventative condition based maintenance. The prognostic engine monitors are mainly for ground based maintenance, and would not be intended for flight control purposes. They may, however, be used to supplement other sensors in order to optimize fuel efficiency, structural weardown, or passenger comfort (noise reduction), etc. during a flight.

Table 3 lists the anticipated applications of the HI-class, including further attributes associated with each individual application. Note that virtually all voice, video/imagery, and data sources are identical for the cockpit crew and cabin crew applications, although the Quality of Service (QoS) may differ – voice quality, video resolution, update/transfer rates, etc. The difference between application categories is only the intended destination – cockpit headsets or monitors, vs. flight attendant headsets and monitors, as well as possibly cabin PA speakers and screens.

TABLE 3

HI class member applications



Version: 1.0 of 64

Application Type of Benefit Net peak data rate per data-link

(kbps)

Node Quantity


Application


Existing Air data sensors

100 8 ground, takeoff, cruise, landing

FADEC aircraft interface


12.5 10 ground, takeoff, cruise, landing,

Existing

Taxi

4,800 peak New ground, takeoff, cruise, landing,

wire reduction, Engine prognostic sensors

80 average 30 operational enhancements Taxi per sensor

wire reduction, untethered operation,

Existing + New 64 Raw ground, takeoff,

cruise, landing, Cockpit and Cabin crew voice

16 CVSD 10 operational enhancements

Taxi 2.4 MELP

wire reduction, New 2,000

ground, takeoff, cruise, landing,

flexibility enhancement

File sizes to > 1MByte

Cockpit crew fixed imagery

50 Taxi safety

enhancements 2.5s update each

wire reduction, New 1,000

20 (included in above)

flexibility enhancement

ground, cruise, Cabin crew fixed imagery

File sizes to > 1MByte Taxi

safety enhancements

5 sec update each


Existing + New Cockpit crew

motion video safety enhancements

50 (same as above)

64 or 256 Taxi


Existing + New Cabin crew

motion video safety enhancements

20 (same as above)

64 or 256 Taxi

<1,000 New Cockpit crew digital data (EFO…)


ground, takeoff, cruise, landing, Taxi

10 (1,250 KB, >10 sec transfer time)

<100 5 New wire reduction, flexibility enhancement

Cabin crew digital data

ground, cruise, Taxi (125 KB, >10 sec

transfer time) (included in above)



Version: 1.0 of 64


Per-link data rates are expected to be above 10 kbps per source node. The highest peak data rate is anticipated to be 4.8 Mbps from each engine vibration sensor, due to high sample rates and large sample precision (up to 24 bits); however, these sensors are operated at low duty cycle (<2 %), so the average data rate is approximately 80 kbps each. Sampled data can be stored at the sensor, and forwarded in the gaps between imagery and voice, to smooth out the average channel traffic loading. (Alternatively, the sensor network itself can be interlaced so that the sensors report in sequence, instead of simultaneously, if this affords adequate smoothing and rate reduction). Then for a network of 24 sensors, 6 on each of 4 engines, the aggregate data rate could be 1.92 Mbps, or roughly 2 Mbps average. Note that this rate is worst case, and if bandwidth limitations demand it, on-board signal processing at each sensor can be added to reduce the data content per (approximately 2 minute) frame by a factor of 10 or more. However, this does create a larger, more power consuming, and more costly sensor, and will be avoided if traffic capacity supports the raw data flows.

The available rates for the crew voice/video/imagery communications is anticipated to be in the 10’s of kbps for voice and data, in the 100’s of kbps for video, and up to 1-2 Mbps for precision imagery. However, data rates can be traded off against quality of service in order to support numerous simultaneous messages, as usage conditions vary. Quality of service could be automatically controlled by a network monitor that regulates the offered traffic vs. quality of service. In general, cabin applications will tend to have lower priority and thus QoS than cockpit crew communications, and thus draw lower operational data rates to ease the total network traffic load.

Adaptable data rates are beneficial for HI WAIC applications because such actions cannot be achieved by adjusting low data rate traffic, since it could mean dropping essential sensor information. Furthermore, it is anticipated these HI applications will require reasonably low latency (<0.5 sec), as well as a low delay jitter of less than 50 ms, to maintain quality. Therefore, many HI applications readily lend themselves to data rate adaptation.


HI WAIC class applications are assumed to operate within the aircraft structure. Transmitters within engine nacelles are considered as belonging to this class. However, this classification may be revised as the document and study evolves. Other fixed transmitter devices will be installed in different compartments, such as the flight deck, cabin, luggage bays, equipment bays, interior surfaces (interior cameras), etc.


Different HI WAIC applications have different channel access, duty cycle and activity time characteristics. For example, motion video and fixed frame imagery have different purposes; frame imagery may be used for periodic status updates, or to provide a precision view of an equipment failure while motion video could be used to scan/survey an area or to monitor continuously changing conditions, perhaps on a control surface.

The expected required communications range will vary between several centimeters to several tens of meters for WAIC HI class applications. Propagation conditions are expected to be dominated by line-of-sight (LOS) paths in the cabin environment, and non-LOS for other areas of the aircraft.



Version: 1.0 of 64

3.2.4 Classification HO

General: The class of HO applications is characterized by the following main attributes:

Data rate: high (>10kps)

Installation domain: outside aircraft structure

It is anticipated that WAIC HO RF transceiver nodes will be active during all flight phases and on the ground. It is anticipated that the number of nodes belonging to this class will be approximately 300 per aircraft.

3.2.4.1 HO class member applications

The HO application class includes applications from the domain of high data rate sensing and control signals, such as structural health monitoring, and active vibration control. It also includes applications from the domain of voice and video data transfer for cockpit crew communication and for external imaging. Cockpit voice systems may be classified as external for example in rotorcraft applications due to the specific physical layout of the vehicle. Similarly, some avionics data bus applications may be placed without an attenuating enclosure, communicating data from outside sensors, which justifies their inclusion in the HO class. Structural health monitoring applications are also included.

Table 4 lists the anticipated applications of the HO class including further attributes associated with each individual application

TABLE 4

HO class member applications


data-link / (kbps)

Node Quantity


Application

Avionics communications bus


100 30 Ground, takeoff, cruise, landing, taxi

Existing

Audio communications system


20 10 Ground

Existing

Structural Sensors


45 250 Ground, takeoff, cruise, landing, taxi

New

External imaging sensors (cameras etc.)


1000 5 Ground; rotorcraft operations/hover in confined areas

Existing

Active vibration control


50 25 Helicopter cruise Existing



Version: 1.0 of 64


Per link data rates are expected to be above 10kbps. However, not all applications from this class will operate continually and simultaneously at their respective peak rates, which will afford lowering the average data rate through appropriate load control. Data latency and availability requirements of monitoring systems may not be as stringent as those involved in control loops, which may allow further lowering instantaneous data rates by delaying sensor information that is not time-critical. Furthermore, Quality of Service parameters of voice and video communications may be adaptively adjusted during the peak demand period. The resulting average per-system data rates will be carefully evaluated in the subsequent phases of this study taking into account the overall wireless system architecture. Currently, only the worst-case peak data rates are addressed here.

For Avionics Data bus applications, the peak data rate is assumed to be ARINC 429 high rate of 100 kbps. With up to 30 nodes predicted per aircraft, the total data rate may be 3 Mbps

For Audio Communication, as explained above, the per-link data rate depends on the coding scheme chosen and on Quality of Service tradeoffs. The average expected per link data rate is predicted to be 20 kbps. With up to 10 nodes predicted per aircraft, the total data rate may be 200 kbps. The maximum range considered for an audio communications system is anticipated to be 30m under unobstructed radio propagation conditions.

For External Imaging, the per-link data rate may be as high as 1 Mbps. With up to 5 nodes per aircraft, the total data rate may be as high as 5 Mbps.

For Active Vibration Control, the per-link data rate may be as high as 50 kbps. With up to 25 nodes per aircraft, the total data rate may be 1.25 Mbps.


Applications of the HO class are assumed to operate outside the aircraft structure. Devices installed at different locations outside the aircraft could cause mutual interference. The Possibilities of re-using one or more of the same RF channels for various simultaneous HO radio links will be studied in order to ensure maximum spectrum efficiency.


Some HO applications are also listed as members of the previously discussed classes. This overlap occurs mostly for systems installed on rotorcraft. Many systems that fall into the “inside” classification for fixed-wing aircraft may be characterized as “outside” on a helicopter due to the physical layout of the vehicle. For example, a helicopter cockpit is typically much more open to increase the pilot’s visual field of view. In addition, the nature of helicopter propulsion and flight controls dictates significant external control and sensing. Another reason for the category overlap is the impact of sensor data processing. Data rate requirements are implementation-dependent to an extent. For example, Health and Usage Monitoring Systems (HUMS) accelerometer data may fall into the “High” category if it is digitized and “streamed” to an access point in real time, but it could be “Low” rate if the sensor node analyzes the data and sends summary statistics.

4 Typical wireless system characteristics

[Editor’s note: Typical wireless system characteristics are:

– TBD.]



Version: 1.0 of 64

- 15 - 5B/248-E

DAWUD GORDON 13.05.09

5 WAIC Coexistence and WAIC compatibility considerations to ensure compatibility with other existing applications or radio services

- TBD

6 Conclusion

The ability to use WAIC communication systems globally is extremely important to the commercial aviation industry, but presents a significant challenge given the international nature of air travel. The aviation industry is striving to utilize wireless systems for both system upgrades on current aircraft, and in new aircraft design that will be as safe as current wired systems, while reducing costs. This document begins the process of studying the operational and technical characteristics of the WAIC systems so as to help the aviation industry progress in deriving the benefits of wireless technology.

The content presented in this document hence represents the current state of information on WAIC applications anticipated by the international commercial aviation industry; and hence provides a response to Question 1 in 5B/88r1.

OR

Based on the presented set of information, the required amount of spectrum, potential candidate frequency allocations as well as other criteria will be derived in further steps on the way on finding answers to all WAIC questions.

___________



Version: 1.0 of 64

Concertation Meeting on Monitoring and Control for

Energy Efficiency

Jorge Pereira

04.03.2009 Brussels, Belgium



Version: 1.0 of 64

Second Concertation Week on Monitoring and Control

Concertation Meeting on Monitoring and Control for Energy Efficiency

Contact: Jorge Pereira, EC

4 March 2009, Brussels

Final Agenda

Opening – José Cotta, Head of Unit, INFSO G3 1. "M&C for Energy Efficiency – Perspectives and Opportunities", Jorge Pereira, EC

Project Presentation

2. ARTEMIS project eDIANA – José J. de las Heras, Acciona, ES HYDRA Results & Demo

3. "Developing a platform for energy-aware, smart home applications", Peter Rosengren, CNet, SE & Pablo Antolin, Telefonica, ES

HYCON results – Energy Efficient Car Engines

4. "Automotive engine control and hybrid systems", Andrea Balluchi, Luca Benvenuti, Emmanuel Mazzi, A. Sangiovanni-Vincentelli, PARADES, IT; Antonio Bicchi, Univ. Pisa, IT; M. D. Di Benedetto, Univ. dell'Aquila, IT

5. "Hybrid control of homogeneous charge compression ignition (HCCI) combustion engines", Rolf Johansson, Lund University

HYCON results – Power Grid Optimization

6. "Control Challenges around the Stability of Power Networks", Gilney Damm, Univ. Evry, FR

7. "Energy Market Signaling", Mircea Lazar, Andrej Jokic, Paul van den Bosch, TU Eindhoven, NL; Alberto Bemporad, UNISI, IT

Invited presentations

8. "Energy efficient buildings and the current research activities in the Smart Building Cluster", Karsten Menzel, University College Cork, IE

9. "From Telemetry to Home Automation" – José Luís Malaquias, ISA, PT

Mini-Workshop – From Generation to Distribution to Demand Side Integration 10. Advanced metering on Distribution Grids and Energy Efficiency – Olivier Huet,

EDF, FR 11. ADDRESS project – Flexibility issues in Power Systems and focus on Demand Side

Participation – Régine Belhomme, EDF, FR 12. FENIX project – Integration of Distributed Generation through Virtual Power Plants

– Maria Sebastian, EDF, FR 13. PREMIO project – Optimisation of Demand and Distributed Energy Resources at

the local level – Olivier Normand, EDF, FR Conclusions

Close



Version: 1.0 of 64

Energy Scavenging Workshop

EADS Innovation Works

23.04.2008 Ottobrunn/Munich, Germany



Version: 1.0 of 64

AIRBUS A380

EUROCOPTER EC135

A400M

EUROFIGHTERMETEOR

GALILEO ARIANE 5

E A D S I N N O V A T I O N W O R K SE n e r g y S c a v e n g i n g W o r k s h o p

2 3 A p r i l 2 0 0 8V e n u e : W o l f - F e r r a r i - H a u s

R a t h a u s p l a t z 28 5 5 2 1

O t t o b r u n n / M u n i c h G e r m a n y

EADSEADS Innovation WorksIW-SI81663 Munich · GermanyTelephone: +49 (0) 89.6 07-2 36 25Telefax: +49 (0) 89.6 07-2 40 01e-mail: [email protected]



Version: 1.0 of 64

Energy Scavenging Workshop

Organised by EADS Innovation WorksSensors, Electronics and Systems IntegrationChair: Thomas Becker

09:50 Welcome

10:00 Introduction

10:00 Needs and Challenges Josef Schalk, EADS IW

10:20 Requirements for SHMClemens Bockenheimer, Airbus

10:40 Power Harvesting I

10:40 Vibration Energy HarvesterPierre-Damien Berger, CEA LETI

11:00 Vibration Energy Harvester Rob van Schaijk, IMEC NL

11:20 Coffee Break

11:40 Power Harvesting II

11:40 Thermoelectric Generators Harald Böttner, FhG IPM

12:00 Flexible Solar Cells Michael Niggemann, FhG ISE

12:20 Lunch

13:20 Battery Technologies

13:20 Micro Fuel Cells Neus Sabate, CSIC CNM

13:40 Robust Batteries Jean-Marie Bodet, Saft

14:00 Power Feed

14:00 Acoustic Power & Data Transmission Martin Kluge, EADS IW

14:20 RF Power Feed Peter Spies, FhG IIS

14:40 Coffee Break

15:00 System Integration

15:00 Vibration Scavenging for Rotorcraft Martin Kluge, EADS IW

15:20 Energy Scavenging in A/C Thomas Becker, EADS IW

15:40 Conclusion

16:00 The End



Version: 1.0 of 64

Performance Evaluation Framework for Video

Applications in Mobile Networks

Alexander Klein and Jirka Klaue

Second International Conference on Advances in Mesh

Networks (MESH 2009)

18.06.2009 Athens, Greece



Version: 1.0 of 64

Performance Evaluation Framework for Video Applications in Mobile Networks


EADS Innovation Works

Munich, Germany

[email protected]

Abstract

We present a framework for performance evaluation and

optimization of video applications in mobile multi hop

networks. We focus on the perceived video quality de-

pending on the simulated mobility model, traffic pattern,

retransmission strategy, and the configuration of the routing

protocol. Moreover, the functionality of the framework is

demonstrated by evaluating the performance of a video

surveillance application with multiple mobile sources and

sinks. The application is designed for exchanging multimedia

content, e.g. audio and video streams, in wireless networks

where all nodes are highly mobile.

1. Introduction

The interest in wireless mesh networks for transporting

real-time video content has grown, since more and more mo-

bile devices come with high data rate interfaces e.g. UMTS

and IEEE 802.11. Many of these devices have a large display

which is quite sufficient for watching videos. Furthermore,

they provide enough computational power to operate as a

router in wireless networks. If the number of these devices

keeps increasing, it will be possible in the near future to

cover large areas with cheap internet access by using these

devices to build a wireless mesh network. Besides video

applications for entertainment, applications for surveillance

are of great interest. In most of the currently installed

wireless networks for video surveillance, the sources send

the video content to a single data sink which evaluates the

received streams. Both, the sources and the sink are usually

not mobile. Therefore, the topology of these networks can be

calculated in advance. If the topology is known, optimized

routes can be calculated without much effort. However,

the next generation of video surveillance applications will

consist of mobile and fix nodes whereas the fix nodes

build an infrastructure mesh backbone [1]. A large number

of applications can benefit from high data rate wireless

networks. Police patrol cars and stationary cameras can build

a wireless mesh network which could significantly improve

their surveillance possibilities. In addition, the broadcasting

of large outdoor sport events, e.g. Tour de France [2] or Paris

Dakar, could be improved if wireless mesh nodes would be

attached to the bicycles or the support cars. Finally, there

is also interest by the military to enable distributed wireless

video communication between different kind of mobile units.

Due to the high mobility, the used applications and routing

protocols have to deal with frequent link breaks and topology

changes. The protocols have to find new routes within a short

amount of time in order to achieve a high video quality while

limiting the routing overhead to the absolutely necessary.

Another optimization problem is represented by the trade-off

between frame loss and end-to-end delay. Lost frames cause

quality degradations of the video while retransmissions of

lost packets result in additional delay which is unacceptable

for real-time applications. Usually a play-out buffer is used

at the video sink. The size of the buffer depends on the

delay requirements of the application which also limits the

number of possible retransmissions. Typical video players

buffer up to several seconds of video data depending on

the application. For that reason, the retransmission strategy

of the video application and the capability of the routing

protocol to repair broken routes are the two major key

elements in mobile wireless networks.

The modular framework that is presented in this paper

can be divided into two parts. The first part is implemented

using the OPNET Modeler 1 discrete event simulator and is

responsible for the simulation of the wireless mesh network.

It consists of several smaller modules which can be replaced

or modified without much effort to meet given requirements.

We implemented new models for the following tasks: traf-

fic generation, application, routing, MAC, mobility, energy

consumption, overhead calculation, and visualization. The

second part is represented by the video quality evaluation

framework EvalVid [3] which calculates the Peak Signal to

Noise Ratio (PSNR) and the Mean Opinion Score (MOS)

values of the received video in order to get a better im-

pression of the perceived video quality. We demonstrate

the functionality of our framework by evaluating the per-

formance of a video application with a varying number of

traffic sources. The parameters of the routing protocol and

the video application are optimized in respect to the MOS

of the perceived video.

1. OPNET Modeler, University Program, http://www.opnet.com/services/university/



Version: 1.0 of 64

2. Simulation & Video Quality Framework

The framework that is presented in this paper consists of

two parts. The first one is represented by a modular sim-

ulation framework which is implemented with the OPNET

Modeler and is responsible for the simulation of the wireless

communication. The second part is called EvalVid and is

used to generate and evaluate the simulated video traces.

Both parts are introduced in more detail in this section after

a short overview of related evaluation tools.

There are several commercial video quality evaluation

tools available e.g. [4] and [5]. Both tools mainly focus

on the evaluation metrics and do not offer an interface to

connect them directly to network simulators, e.g. OPNET or

ns-2. Another well known tool is represented by the Video

Quality Metric (VQM) Software [6] which is developed

by Wolf and Pinson. The tool offers a large number of

different metrics in order to evaluate and compare the quality

of videos. However, just as its commercial counterparts it

does neither offer the functionality to create trace files nor

an interface to interact with network simulation tools for

performance studies. The video quality evaluation software

Aquavit [7] was developed by Kasai and Nilsson. It offers

almost the same functionality but it is not further developed.

Therefore, it does not support state-of-the-art codecs like

H.264. In one of our previous works we extended the basic

Evalvid tool to simulate rate adaptive MPEG-4 transmis-

sion [8] with ns-2. The ns-2 extension only supports the

MPEG-4 transmission and is based on an older version of

EvalVid. Thus, we decided to use our OPNET simulation

framework since it offers more flexibility due to its modular

structure.

The OPNET simulation framework consists of different

process models that are able to communicate with each other.

Figure 1 shows the configuration of the framework that is

used in this paper. The arrows represent traffic streams which

can be used to pass data packets from one process model

to another. However, process models can also exchange

information without using streams. This kind of information

exchange is used by the Data Sink model and the Overhead

Module to pass the collected statistics to the Statistic Module

for further evaluation.

Traffic Module The Traffic Module is based on the OP-

NET standard traffic generation process, but has advanced

features. The module offers the possibility to generate single

packets and data bursts. In addition, trace files captured by

Wireshark 2 or tcpdump can be used for traffic generation.

Thus, we use the Traffic Module to generate data packets

according to a previously recorded video trace.

Application Module The Application Module is used to

modify the incoming and outgoing data packets to simulate

the behavior of different applications, like the buffer of a

2. Network Protocol Analyzer, http://www.wireshark.org/

Figure 1. OPNET Framework

video application or data aggregation. We added different

kind of retransmission strategies in order to find out which

strategy offers the best performance in our scenario.

Routing Module AODV, OLSR, GBR, and SBR are cur-

rently part of the framework. In fact, AODV and OLSR are

already included in the OPNET Modeler library. However,

we re-implemented them to speed up the simulation since

most of their features, like multiple gateway support, are not

required in most of the scenarios.

Overhead Module The Overhead Module can be placed

in different positions inside the framework to count the

ingoing and outgoing overhead, e.g. application, MAC, and

routing overhead. The collected statistics are forwarded to

the Statistic Module at the end of the simulation.

Mobility Module The Mobility Module includes several

standard mobility patterns, like Random Waypoint, Random

Walk, Random Direction, Manhattan Mobility, and Ran-

dom Group Mobility. The nodes in the simulation can use

different mobility patterns which allows the generation of

more complex and realistic movement. In addition, the shape

of the movement area can be chosen (square or circle).

This feature is necessary since some mobility patterns, like

Random Direction, do not generate suitable traces for all

kinds of movement areas (e.g. high density in corners).

WLAN Modules The models beneath the line in Figure 1

are taken from the OPNET Modeler library. The models are

used to simulate the IEEE 802.11 (a,b,g) MAC and physical

layer. We modified the signal propagation such that packets

can only be exchanged between nodes that are less than 150

meters away from each other which results in a disc model.

However, nodes that are further away will recognize noise

on the radio channel during the transmission.



Version: 1.0 of 64

Table 1. ITU-R quality and impairment

Scale Quality Impairment

5 Excellent Imperceptible

4 Good Perceptible

3 Fair Slightly annoying

2 Poor Annoying

1 Bad Very annoying

Table 2. PSNR to MOS conversion

PSNR [dB] MOS

> 37 > 5 (Excellent)

31 - 37 4 (Good)

25 - 31 3 (Fair)

20 - 25 2 (Poor)

< 20 < 1 (Bad)

Before we start to describe the used evaluation tool, we

want to introduce the two standard methods that are used

to evaluate the video quality. One method to assess the

performance of video transmission systems is to calculate

the PSNR between the source and the received (possibly

distorted) video sequence. It is a differential metric which

is calculated image-wise and very similar to the well-

known SNR but correlating better with the human quality

perception [9]. Thus, this metric is only meaningful if the

quality of the original image sequence is high in terms of

human perception which is not necessarily the case. For

instance, if the video sequence is passed through a state-of-

the-art video encoder to reduce the bit-rate, the compressed

video will be already distorted since modern video-codecs,

like MPEG-4 or H.264, are usually lossy. Loss of packets

will lead to decoding errors at the decoder/player while delay

can cause buffer under-runs. Both will ultimately result in

the loss of images at the player which results in a low video

quality. For a better illustration of the meaning of quality

measures for non-experts, the ITU-R developed a quality

indication scale which is tied to the quality impression of

human observers [10]. This scale is shown in Table 1.

BT.500 further describes a methodology to gain these

quality indicators by subjective assessment series (by a

group of humans). Such a scale is often called Mean Opin-

ion Score and used in several quality assessment systems.

Ohm [11] gives a heuristic mapping of PSNR to MOS values

which can be used to roughly estimate the human quality

perception for videos with relatively low motion (like for

instance videos from surveillance cameras). This mapping

from PSNR to MOS is shown in Table 2.

The tool that is used to evaluate the video quality is

called EvalVid [3]. It is used here to compare the quality

of the source (encoded and already slightly distorted video)

with the received video quality in order to evaluate the

performance of the simulated mobile wireless network. We

recorded a trace of the original video file, containing size

Figure 2. Simulation Scenario

and type of each video packet transmitted over RTP, and use

this trace to generate packets in the OPNET simulation. The

Data Sink modules of the OPNET framework write a trace

file of the received packets at the end of each simulation run.

These traces are used by EvalVid to calculate packet/frame

loss and delay figures as well as reconstructing the received

(possibly distorted) video files. The received videos are then

decoded using FFmpeg 3 to be able to calculate the PSNR

and MOS figures for the video quality evaluation.

3. Scenario

105 fix nodes are placed along a manhattan grid within a

square of 2000 by 2000 meters as shown in Figure 2. The

distance between two nodes along the grid is 125 meters

resulting in an edge length of 375 meters. In addition,

16 mobile nodes are placed in the center of the scenario.

Communication The standard OPNET IEEE 802.11b (ad

hoc) mac and physical layer models are used. We modified

the physical layer such that the transmission range of the

nodes is limited to 150 meters. Nodes which are further

away will only recognize a busy radio channel, but are not

able to communicate with each other.

Mobility The mobile nodes use the Random Group Mobil-

ity [16] mobility model. One of these 16 nodes is randomly

selected as group leader. The group leader moves according

to the Random Walk mobility model. The other 15 fellow

nodes follow the group leader. Their movement in relation

to the group leader is similar to the Random Waypoint

model. The only difference is that the absolute speed of

the fellow nodes is correlated to the speed of the group

leader. Furthermore, their movement is limited such that they

can not move further than 200 meters away from the group

leader. The speed of the group leader is randomly chosen

between 5 m/s and 20 m/s which represents the typical speed

3. FFmpeg - Multimedia Framework,http://ffmpeg.org



Version: 1.0 of 64

(a) Sample image

0

64

128

192

256

320

384

448

512

0 10 20 30 40 50 60 70 80

Time [s]

Av

era

ge

Bit

-ra

te [

kb

it/s

]

0

5

10

15

20

25

30

35

40

PS

NR

[d

B]

PSNR (avg = 37.7)

Bit-rate (avg = 258)

(b) Video profile & quality

Figure 3. Profile of “highway” video clip, (a) sample

image (b) data rate & PSNR profile

of cars within the city area. A new direction and speed are

chosen every 10 seconds.

Video We selected a standard video sequence called ”High-

way” which is used by a large number of video encoding

and transmission studies, like the Video Quality Experts

Group [12]. The sequence consists of 2000 frames with

CIF resolution (352 x 288) and a frame rate of 25 Hz. The

resulting 80 seconds long video was encoded with the state-

of-the-art H.264 video encoder x264 [13] using an average

target bit-rate of 256 kbit/s. A good balance between coding

efficiency and error recovery capabilities was achieved by

encoding a key-frame at least every 10 seconds. Figure 3

shows a snapshot from the original video sequence and the

bit-rate profile in combination with the PSNR of the encoded

video. The average PSNR of 37.7 dB reflects an excellent

video quality. The video file is transmitted in 2205 IP packets

with a maximum size of 1500 bytes which results in an

average rate of ≈ 27.5 packets per second.

Traffic The video sources are randomly selected among the

16 mobile nodes. In contrast to the sources, the sinks are

chosen in a point symmetric way among the fix nodes at the

Table 3. SBR - Configuration

Mode Hybrid

Active Route Timeout 3.00 s

Hello Message Interval 0.80 s

Decrease Routing Interval 0.80 s

Hello Message TTL 32

Maximum Routing Value 20

Routing Value Increase Function Fast

Routing Value Decrease Function Divide

boundary of the manhattan grid, in order to minimize side

effects caused by inhomogeneous traffic load distribution.

Application Wireless links are usually lossy, especially in

the case of a high node density and a high traffic load.

However, packets are not only lost due to bit errors or inter-

ference. Packet loss is often the consequence of link breaks

in mobile networks. Depending on the used routing protocol

it may take up to several seconds until a new route is found.

During this time interval, no communication between nodes

that are using this link, is possible. For that reason, many

applications use waiting queues to buffer data packets, if no

valid route is available to the destination. Some applications

use retransmissions and acknowledgements to guarantee a

loss-free data exchange. The video surveillance application

in our simulation has certain requirements regarding the

maximum end-to-end delay. In fact, a maximum end-to-end

delay of up to two seconds is still acceptable since there is

no direct interaction between the source and the destination.

Therefore, our example application uses selective end-to-

end acknowledgements and retransmits packets up to three

times. A packet is retransmitted if no acknowledgement is

received within 0.6 seconds. Thus, the maximum expected

end-to-end delay will be slightly above two seconds which

meets the given requirements.

Routing The Statistic-Based-Routing (SBR) [14] protocol is

used due to the fact that it is able to detect link breaks within

a short amount of time. Furthermore, the protocol uses

a delay based forwarding mechanism of routing messages

and a continuous cumulative metric which results in a load

balancing effect. The protocol is based on the concept of

Directed Diffusion [15] which is a popular data-centric

approach in wireless sensor networks. However, the higher

data rate of wireless mesh networks allows a more fre-

quent transmission of routing messages compared to sensor

networks. The higher transmission frequency allows a fast

detection of broken links. Nonetheless, the amount of routing

overhead is approximately two percent of the transmitted

video data which is on a quite acceptable level. A more

detailed description of the routing protocol is given in [14]

and [16]. The configuration of the SBR protocol is shown

in Table 3.



Version: 1.0 of 64

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 20.4

0.5

0.6

0.7

0.8

0.9

1

Pro

babili

ty P

(T<

t)

End−To−End Delay in Seconds

# 1

# 2

# 4

# 6

# 8

# 10

IncreasingNumber ofSources

Figure 4. Cumulative Distribution Function of the End-

To-End Delay depending on the Number of Video

Sources

Simulation The duration of each simulation run is 300

seconds. The group mobility pattern of the 16 mobile nodes

starts after 10 seconds and requires additional 10 seconds

until the fellow nodes assemble within the area around the

group leader. The video sources start to transmit after 50

seconds with an uniformly distributed offset of one second.

Due to the fact that the movement of the group leader

has a large impact on the performance, we decided to run

100 simulations per setting in order to produce meaningful

results. The error bars (if present) represent the 90 percent

confidence intervals.

4. Results

The performance of the wireless network was evaluated

in respect to the number of video sources. A single video

source was picked exemplarily for in-depth analysis. For

the evaluation of the video quality only the packets that

arrive within a certain amount of time were considered.

In the following, we use the term end-to-end delay for the

time interval between the creation of a video packet and its

successful reception (first transmission or retransmission) at

the destination.

Figure 4 shows the cumulative distribution function of the

end-to-end delay depending on the number of video sources.

We focus on the packets that arrive within two seconds, since

packets that require a longer amount of time, are discarded

by the application. The end-to-end delay of packets that were

not successfully received after the third retransmission is set

to infinity.

In addition, Figure 4 indicates that almost no retransmis-

sions are required for up to two parallel video transmissions.

The number of packets that do not require a retransmission

decreases, as the number of video sources increases, which is

the consequence of the higher traffic load. It has to be kept in

0 1 2 4 6 8 100.65

0.7

0.75

0.8

0.85

0.9

0.95

1

End−

to−

End R

elia

bili

ty

Number of Sources

Figure 5. 90% Quantile of the End-To-End Reliability

depending on the Number of Video Sources

mind that the routing overhead increases with the number of

sources since the protocol operates in the hybrid mode. Thus,

routing messages are only broadcasted by nodes which are

part of an active route (source or destination). However, the

amount of routing overhead is still low (less than 4 percent),

even in the case of ten video sources. Nonetheless, the node

density in the area around the video sources is relatively

high due to the movement according to the Random Group

Mobility model. As a result of the high node density, the

broadcasting of routing messages in combination with the

higher traffic load, increases the end-to-end delay in a sig-

nificant way. Additionally, the retransmission of data packets

increases the traffic load even further. The loss of packets has

a large impact on the video quality, since most state-of-the-

art encoders compress the original video, such that frames

rely on previous frames. Therefore, the loss of a single frame

leads to a degradation of the video quality of consecutive

frames as well. Nevertheless, the perceived video quality

also strongly depends on the type of the sequence, e.g. action

scene or landscape stills. Figure 5 shows the 90 percent

quantile of the end-to-end reliability on the application layer

depending on the number of video sources. A high reliability

of more than 90 percent is achieved if the number of video

sources is equal or less then four. A higher number of

sources results in a significant drop of the reliability. Due

to the higher number of sources, the traffic load increases

which leads to a significant delay increase of the data and

routing packets. Furthermore, the packet loss on the routing

layer increases, since the routing protocol requires more time

to detect link breaks. As a consequence, more packets have

to be retransmitted by the application layer which further

increases the traffic load. This trend is reflected by the 90

percent quantiles of the average number of retransmissions

which are shown in Figure 6. A significant increase can be

recognized if the number of video sources is increased to

more than four. Unsurprisingly, the length of the waiting



Version: 1.0 of 64



Version: 1.0 of 64

Work in Progress: Performance Study of a Video Application over Multi Hop

Wireless Networks with Statistic-based Routing


Networking Conference 2009 (Networking 2009)

12.05.2009 Aachen, Germany



Version: 1.0 of 64

Work in Progress: Performance Study of a VideoApplication over Multi Hop Wireless Networks

with Statistic-based Routing

Alexander Klein1 and Jirka Klaue2

1 University of Wuerzburg, Institute of Computer Science, [email protected],

WWW home page: http://www3.informatik.uni-wuerzburg.de2 EADS Innovation Works, Munich, Germany,

Abstract. In recent years, technologies like Ultra Wideband (UWB)were developed that can be used to boost the data rate of wireless nodesto a new level. The higher data rate makes wireless networks capable oftransporting multimedia content for real time applications like In FlightEntertainment (IFE), surveillance applications, or structural health mon-itoring. In this paper we measure and simulate the performance of a videoapplication for IFE over a high data rate multi hop wireless network usinga Directed Diffusion based routing protocol. Therefore, we take a look atthe perceived video quality instead of focusing solely on the packet deliv-ery ratio. Furthermore, we discuss the parameters of the Statistic-BasedRouting (SBR) protocol which are relevant for this particular applicationand focus on their impact on the video quality during topology changes.

Key words: routing, wireless, multi-hop, video, performance

1 Introduction

Frequent topology changes represent a serious problem for IFE since most of thetraffic has to be transmitted in real time which limits the possibility of retrans-mitting lost packets. Depending on the used wireless technology, carry-on luggageor clothes that are placed on the back rest might lead to topology changes. Forthat reason, the routing protocol has to frequently send out messages to detecttopology changes and reroute traffic.

Thus, we have to deliberate over the question whether wireless solutions canbe competitive to wired solutions for our particular application of IFE. First ofall, the video quality that is recognized by a customer has to be approximatelyon the same level to allow a comparison of wired and wireless solutions whichmainly depends on the routing protocol if we assume that the used physical layeris capable to achieve a high point-to-point data rate. Other characteristics thathave to be taken into account are the costs for deployment and general mainte-nance work. The installation costs of wired solutions in already assembled planesare more expensive than the installation costs of wireless solutions. Flexibility is



Version: 1.0 of 64

2

a very important issue since the airline companies are interested in adapting theconfiguration of a plane, e.g. by extending the business or the economy class.

Our work is organized as follows. In Section 2 we take a look at wireless net-work simulation tools and the way they simplify the signal propagation to allowlarge-scale simulations. The problem of topology change detection is discussedin Section 3. We describe the simulation of the routing protocol which is usedto evaluate the performance of the video application in Section 4 and its im-plementation in Section 5 respectively. The framework that is used to estimatethe performance of the received video is introduced in Section 6. The resultsare presented and analyzed in Section 7. Finally, we summarize the results andintroduce our future fields of research.

2 Related Work

As a consequence of rapid improvements in technology and miniturization, Wire-less Multimedia Sensor Networks (WMSN)become more and more interestingfor a large number of new applications [1]. However, sensor nodes with UWBor other high data rate wireless interfaces are hardly available at the moment.Thus, simulation is the most common approach to estimate the performance ofWMSNs. Many simulation tools like ns-2 [2] or OPNET Modeler [3] come withsimplified propagation models, e.g. free space, which neglect most of the char-acteristics that have great impact on the communication in a multi-hop wirelessnetwork. Often, these models are even further simplified to allow the simula-tion of large-scale networks within a justifiable amount of time. Kotz et al. [4]summarized the typical assumptions that are made by simulations like circulartransmission area, equal transmission range, and symmetric links. Another workthat is published by the same research group [5] deals with the problem of sim-ulation validation by using measurements from an environment typical to theone of interest. Their results show that it is important to use measurements inorder to find out which propagation model meets the desired requirements.

Therefore, we decided not to focus solely on the standard performance metricslike packet delivery ratio, end-to-end delay and jitter since they do not necessarilyrepresent the perceived link quality by the user. If we take a closer look e.g. atvideo encoding and decoding, we recognize that the video quality over a lossy linkstrongly depends on the way packets are lost. It is important to know whetherconsecutive packets are lost as a consequence of topology changes, single packetswhich might be caused by interference, or a low signal to noise ratio. For thatreason, we focus on the Mean Opinion Score (MOS) of a video transmission toevaluate the performance of our network.

Kuladinithi et al. [6] implemented the AODV [7] protocol using the program-ming language Java to allow the experimental evaluation of different AODVimplementations on various systems. Inspired by the their implementation wedecided to implement the SBR protocol [8] to evaluate its performance in atestbed and compare the measurements with the simulation results gatheredfrom the OPNET Modeler simulation.



Version: 1.0 of 64

3

3 Toplogy Change Detection

Many popular routing protocols like AODV [7] and OLSR [9] use time outs todetect link breaks. In the following we refer the time interval as downtime thatis required by the routing protocol to detect a topology change and to find anew valid route. The problem is to find an optimized expiry interval in orderto minimize the downtime on the one hand, and the probability that a link isuntruly assumed to be broken due to short temporary interference on the otherhand. For that reason, we have chosen the SBR protocol since it is able to detectlink breaks within a short amount of time.

SBR is based on the concept of Directed Diffusion which is a data-centricand application aware paradigm which was introduced by C. Intanagonwiwat et.al. [10]. Each node in the network broadcasts (hello) messages. These messagesare similar to route requests in AODV and are forwarded by intermediate nodes.The neighbor through which a new hello message was received is rated by usinga cumulative function. Thus, a higher routing value corresponds to a higher linkquality as a consequence of the cumulative function. Figure 1 shows the downtimeof the SBR protocol in the average case and in the worst case depending on thedevelopment of the corresponding routing entry values. The graphs representthe routing entry values of node A and B towards a destination node X fromthe perspective of another node C. At time t0 node C receives the first routingmessage via node A and at time tstart from node B respectively. The link betweennode A and node C breaks at tloss. The alternative route via node B becomesthe route with the highest routing entry at thandover.

Node C forwards its data traffic for a destination node X either to node Aor node B. Node C always selects the neighbor with the highest routing entrytowards the destination as next hop. Therefore, the downtime represents thetime until the routing value of the alternative route becomes higher than thepreviously best route. A topology change is detected quickly if the routing valuesare on an equal level from the time when a link break occurs. Thus, the worstcase is represented by a scenario in which the routing entry of a single neighboris very high whereas the routing values of all other neighbors are very low.

(a) Average case (b) Worst case

Fig. 1. Topology change detection



Version: 1.0 of 64

4

4 Simulation

We use a framework for WSNs which we have developed with the OPNET Mod-eler 14.0 [3] software to simulate all layers of the communication stack. For thisparticular simulation, we decided to use the IEEE 802.11 mac and physical layerthat is provided by OPNET to allow the comparison of the simulated perfor-mance of the video application with the performance of a testbed using IEEE802.11g interfaces. Therefore, we put our network and application layer on topof OPNETs mac and physical layer to simulate the communication stack. Tracefiles were recorded from video applications which are used for traffic generationwithin the simulation in order to generate realistic traffic patterns.

In addition, we implemented a filter process which allows us to dynamicallymodify the signal propagation to simulate unpredictable signal loss which leadsto major topology changes in the network. Furthermore, the process is used tolimit the signal propagation such that only a certain topology can be used whichcorresponds exactly to the topology in the testbed. The statistics of the datatraffic are collected by a centralized node to allow a more flexible evaluation andvisualization. Thus, we extended the data source and sink OPNET models tomeet our requirements of traffic generation and evaluation.

5 Implementation

The programming language Java was used to implement the routing protocolto allow its usage on different Operating Systems (OS). Most common OSs, e.g.Linux and Windows, come with tools that allow the modification of their routingtable without much effort. Therefore, the Java routing application has to detectwhich OS is used in order to know which commands are used by the OS. Thisenables us to manipulate routes in the table without the need of notifying otherapplications. The implementation consists of three major packages. The first oneis represented by the network package which is used to receive and transmit datapackets via the IEEE 802.11g interface. We use the Jpcap 0.7 [11] library whichis based on WinPcap to grab packets from the interface. The second packagecovers configuration, routing table, and time management functions, e.g. timerand statistic tasks, which are then used by the routing protocol. The behaviorof the routing protocol and the used messages build the third package. Incomingpackets are detected and evaluated by a receiver task which sends a callback tothe routing task to further evaluate the packet. The routing task then decideswhat actions have to be performed according to the content of the packet, e.g.modification of the routing table, changing of routing entries, forwarding or drop-ping of the packet. Additionally, periodic tasks like hello message transmissiontimer or routing entry decrease timer send callbacks to the routing application.

We added a filter class to the network package which covers the same func-tionality as the filter process within the OPNET simulation. Thus, we can restrictthe topology of the testbed according to the topology used in the simulation.Furthermore, time triggered topology changes can be used to study the behaviorof the protocol to deal with link breaks depending on its configuration.



Version: 1.0 of 64

5

6 Video Quality Evaluation

The standard method to assess the performance of video transmission systemsis to calculate the Peak Signal to Noise Ratio (PSNR) between the source andthe received (possibly distorted) video sequence.It is a differential metric whichis calculated image-wise and very similar to the well-known SNR but correlatingbetter with the human quality perception [12]. The PSNR calculation yields aquality indicator for each image of the video sequence in relation to the originalimage. Thus, this metric is only meaningful if the quality of the original imagesequence is high in terms of human perception which is not necessarily the case.For instance, if the video sequence is passed through a state-of-the-art video en-coder to reduce the bit-rate the compressed video will be already distorted sincemodern video-codecs – like MPEG-4 or H.264 – are usually lossy. Loss of packetswill lead to decoding errors at the decoder/player while delay can cause bufferunder-runs. Both will ultimately cause the loss of images at the player. Sincemodern video-codecs make extensive use of the temporal redundancy (encodingonly the differences) in most videos, the loss of single images also leads to thedistortion of all following images that are differentially encoded based on the lostimage. Lost frames usually will cause the video player to ”freeze” – to show thelast successfully received and decoded image. It is important for an image-by-image metric to reproduce this behavior in case of transmission losses or delay inorder to avoid alignment issues between the source and the received video. For abetter illustration of the meaning of quality measures for non-experts the ITU-Rdeveloped a quality indication scale which is tied to the quality impression ofhuman observers [14]. This scale is shown in Table 1.

ITU-R recommendation BT.500 [14] further describes a methodology to gainthese quality indicators by subjective assessment series (by a group of humans).Such a scale is often called Mean Opinion Score and used in several qualityassessment systems. In [13] there is a mapping of PSNR values to MOS valueswhich can be used to roughly estimate the human quality perception for videoswith relatively low motion (like for instance videos from surveillance cameras).This mapping from PSNR to MOS is shown in Table 2 and used in this paper.

A MOS value is assigned to each image according to Table 2 which is basedon the PSNR values that are calculated for every single image of a received videosequence. These values are averaged over all images of a sequence to produce asingle quality indicator for a video transmission as proposed by the methodology

Table 1. ITU-R quality and impairment

Scale Quality Impairment

5 Excellent Imperceptible4 Good Perceptible3 Fair Slightly annoying2 Poor Annoying1 Bad Very annoying

Table 2. PSNR[dB] to MOS conversion

PSNR MOS

> 37 5 (Excellent)31 - 37 4 (Good)25 - 31 3 (Fair)20 - 25 2 (Poor)< 20 1 (Bad)



Version: 1.0 of 64

6

(a) Sample image

0

20

40

60

80

100

120

140

160

180

200

0 1 2 3 4 5 6 7 8 9 10Time [s]

Dat

a R

ate

[kbi

t/s]

10

15

20

25

30

35

PSN

R [d

B]

PSNR

Data Rate


Fig. 2. Profile of “hall” video clip, (a) sample image (b) data rate & PSNR profile

described in [14]. However, averaging can be problematic for long videos sinceshort temporal distortions will not influence the average significantly. To avoidthis effect another depiction of the MOS values of the single images of the videosequence is given in this paper in addition to the average values. The percentageof images with a certain MOS is displayed and compared to the original video.

In this paper we evaluate the performance of a wireless video transmissionsystem by means of measurements and simulations taking into account the gen-eral principles of video quality evaluation. Therefore, we use a video qualityevaluation tool-set – called EvalVid – which provides the necessary tools [15].

7 Results

We selected one of the standard video sequences which is used by a variety ofvideo encoding and transmission studies by, e. g., the Video Quality ExpertsGroup [16]. This video sequence is called ”Hall Monitor” and consists of 300frames in CIF resolution (352x288 pixel) with 30 Hz frame rate. It is a relativelylow-motion sequence so that the PSNR to MOS mapping shown in Table 2 can beapplied. Due to the fact that it is only 10s long, we concatenated the sequence sixtimes. Since the video is recorded with static camera and there is little motion inthe scene, the influence of this concatenation on the video encoder performanceis low – even at the junctions. The resulting one minute long video was thenencoded with the state-of-the-art H.264 video encoder x264 [17] with an averagetarget bit-rate of 128 kbit/s. A key-frame was encoded every second in order tohave a good balance between coding efficiency and error recovery capabilities. Togive a better impression of the video sequence used, Figure 2 displays a sampleimage together with the bit-rate profile and the PSNR between the encoded andthe original video.

A second video sequence with more motion was selected in order to stress theperformance evaluation methodology with content appropriate for IFE. Figure 3shows a sample image from the one minute long scene from the Movie “StarWars III”. The resolution is 360x216 pixels and the frame rate is 25 Hz. With



Version: 1.0 of 64

7

(a) Sample image

0

100

200

300

400

500

600

700

800

900

1000

0 10 20 30 40 50 60Time [s]

Dat

a R

ate

[kbi

t/s]

0

5

10

15

20

25

30

35

40

45

PSN

R [d

B]

PSNR

Data Rate


Fig. 3. Profile of “sw3” video clip, (a) sample image (b) data rate & PSNR profile

current video encoding technology it is not possible to achieve an acceptablePSNR with an average target bit-rate of 128 kbps. Consequently, the video clipwas encoded with a target bit-rate of 256 kbps. The different content of theselected clips is also reflected in the variations of the size of the encoded framesas shown in Figure 4. While the only variations in the hall clip are basically thedifferent sizes of the I and P frames, the frame size fluctuations in the sw3 clipare much higher.

In order to calibrate the simulation with the measurements we performeda set of test runs in a specific scenario. Five wireless nodes are initially con-nected to each other and transmit the encoded hall video. sequence using RTP(Real-time Transport Protocol) [19] from Node 1 to Node 5. The nodes in thesimulation and the testbed are configured such that they are forced to build astring topology. Thus, they are only able to receive messages from their directneighbors. Node 5 represents an exception since it temporarily connects to theother nodes as shown in Figure 5. We have chosen this extraordinary example

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

0 10 20 30 40 50 60Time [s]

Fram

e Si

ze [B

yte]

(a) hall clip

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

0 10 20 30 40 50 60Time [s]

Fram

e Si

ze [B

yte]

(b) sw3 clip

Fig. 4. Frame sizes of (a) “hall” video clip and (b) “”sw3“” video clip



Version: 1.0 of 64

8

due to the fact that it is the worst case scenario for the routing protocol. A de-scription of the connectivity during the simulation and the measurement is givenin Figure 5. Note, the u1, u2, and u3 are random variables which are selected atthe beginning of the simulation according to a uniform distribution between -1sand 1s. The variables are required to shift the disconnection times in order toavoid the alignment with I frames.

In the 15+u seconds interval, the direct connections between Node 5 andNode 2, 3 and 4 respectively were detached which caused the system to find anew route. This represents a relatively harsh scenario since abrupt disconnectionsrepresent the worst case for real-time applications. The most relevant parametersrepresent the hello message interval and the routing decrease interval whichare set to 1s. Due to the fact that the other parameters have no significantimpact in our scenario we skip their description since a detailed description of allparameters is given in [8]. Furthermore, the implementation and the simulationwill be made available to download from [21].

Using EvalVid, a trace of the video file was generated, containing the sizeand type of each video packet transmitted over RTP. Additionally, an IP-levelpacket trace was created using Wireshark [20] at the transmitting and receivingnode. These traces were used by EvalVid to calculate packet and frame loss fig-ures as well as reconstructing the received (possibly distorted) video files. Thereceived videos were then decoded using FFmpeg [18] to be able to calculatethe PSNR and MOS figures for the video quality evaluation. Figure 6 comparesthe frame loss of the measurements and the simulations while Figure 7 showsthe corresponding MOS values for the received video. The overall frame loss isslightly higher for the measurements which is caused by single packet losses dueto interferences, multi-path propagation, and moving obstacles. Moreover, thepercentage of key I frames lost in the simulation was slightly higher which wasquite suprising. A closer look at the trace files revealed that the starting timesof the disconnections were varying more during the measurements due to thehuman reaction time. Against, in the simulations the disconnection interval wasquite stable and accidentally always during an I frame transmission. This effectis avoided in the following parameter study by equally distributing the discon-nection intervals in a certain range. The bars in Figure 7 show the percentageof frames with a certain MOS in comparison to the reference videos (rightmost)

Virtual

MovementNode 5

Node 1 Node 2 Node 3 Node 4

Time [s]

Connectivity

Interval

30 + u1 45 + u2 60 + u3 7515

Video

Transmission

Fig. 5. Illustration of the connectivity during video transmission



Version: 1.0 of 64

9

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7# Measurement

Fram

e Lo

ss [%

]

IPAll

average

(a) Measurement

0

2

4

6

8

10

12

14

1 2 3 4 5 6# Simulation Run

Fram

e Lo

ss [%

]

IPAll

average

(b) Simulation

Fig. 6. Hall - Comparison of frame loss, (a) measurements (b) simulations

MOS distribution. The reference video reflects the coding loss and consists of100% frames with a MOS of 4 (good). In contrast to the raw frame loss theseresults include the quality degradation caused by frames that could not be cor-rectly decoded due to losses of previous frames. Though the key frame loss inthe simulations was higher the quality of the video was worse in the measuredscenario. This is caused by the rare random single packet losses during the mea-surements which influence all following P frames after the packet loss until thenext I frame. The impact that single packet losses have on the MOS and PSNRdepends on the used encoder, its configuration e.g. the I frame rate, and thetype of video which is encoded e.g. action sequence or landscape stills.

Considering the differences between the measurements and the simulation,the loss and MOS statistics are similar enough such that we can focus on thesimulation in order to evaluate the performance of the testbed. In the followingwe want to demonstrate how to use the simulation for performance evaluation

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 2 3 4 5 6# Measurement

MO

S (P

erce

ntag

e of

Fra

mes

)

5 (excellent)4 (good)3 (fair)2 (poor)1 (bad)

reference

3.67 3.58 3.58 3.62 3.59 3.55 4.00

(a) Measurement

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 2 3 4 5# Simulation Run

MO

S (P

erce

ntag

e of

Fra

mes

)


reference

3.61 3.67 3.64 3.61 3.64 4.00

(b) Simulation

Fig. 7. Hall - Comparison of MOS, (a) measurements (b) simulations



Version: 1.0 of 64

10

0

1

2

3

4

5

6

7

8

9

10

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Hello Message Interval [s]

Prot

ocol

Ove

rhea

d [%

]

0

1

2

3

4

5

6

7

8

9

10

Fram

e Lo

ss [%

]

Routing Protocol Overhead

Frame Loss

(a) Frame loss

0

1

2

3

4

5

6

7

8

9

10

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1


Rou

ting

Prot

ocol

Ove

rhea

d [%

]

3.0

3.1

3.2

3.3

3.4

3.5

3.6

3.7

3.8

3.9

4.0

MO

S


average MOS

(b) MOS

Fig. 8. Hall - Average frame loss (a) and average MOS (b) against the routing overhead

and parameter optimization of the routing protocol to achieve an acceptablevideo quality even in the case of abrupt disconnections. Thus, we varied thehello message interval of SBR from 1.0s down to 0.1s in steps of 0.1s and trans-mitted the video 100 times for each setting. The scenario simulated was againthe multi-hop setup with three abrupt disconnections in a 15s interval. The exactdisconnection times were equally distributed in a window of ±1s to avoid theexact alignment with a key frame.

Figure 8 shows the resulting average frame loss as well as the average MOSagainst the overhead of the routing protocol in percent of the video traffic forthe hall clip. Though the frame loss varies between 1% and 8% the average MOSonly varies between about 3.7 and 3.8. The reason for this is that each lost framecan influences the following frames up to the next key frame. Figure 10 shows thepercentage of frames with a certain MOS. Due to the fact that the expressiveness

0

1

2

3

4

5

6

7

8

9

10

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1


Prot

ocol

Ove

rhea

d [%

]

0

1

2

3

4

5

6

7

8

9

10

Fram

e Lo

ss [%

]


Frame Loss

(a) Frame loss

0

1

2

3

4

5

6

7

8

9

10

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1


Rou

ting

Prot

ocol

Ove

rhea

d [%

]

3.0

3.1

3.2

3.3

3.4

3.5

3.6

3.7

3.8

3.9

4.0

MO

S


average MOS

(b) MOS

Fig. 9. SW3 - Average frame loss (a) and average MOS (b) against the routing overhead



Version: 1.0 of 64

11

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1Hello Message Interval [s]

MO

S (P

erce

ntag

e of

Fra

mes

)5 (excellent)4 (good)3 (fair)2 (poor)1 (bad)

reference

(a) hall

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1Hello Message Interval [s]

MO

S (P

erce

ntag

e of

Fra

mes

)


reference

(b) sw3

Fig. 10. Percentage of frames with certain MOS values depending on the hello messageinterval in comparison to the reference video quality

of the average MOS is limited in case of longer videos. Figure 9 shows the frameloss and MOS statistics for the high-motion scene sw3. Although the frame lossrate is not higher than in the low-motion hall clip, the average MOS is sufferingmore from the losses. This results from the higher differences between adjacentframes which lead to a higher sensitivity to lost frames. Another factor is theappearance of frames with a very low MOS (1-2). In fact, the disturbances of thevideo quality are short in both investigated cases. Figure 10 shows the numberof frames with a certain MOS in comparison to the undistorted reference. Incontrast to the average MOS curves in Figure 8(b) and Figure 9(b), it is shownhere that the quality impact on the sw3 clip is much smaller than on the hallclip, which results from the faster recovering in case of losses due to the highernumber of intra-coded parts.

The overhead of the routing protocol rises exponentially with the downsizingof the hello message interval. It is acceptable up to around 2-3% of the applica-tion traffic, since this is in the range of the protocol overhead of RTP (1.7% inthis scenario). The relative routing overhead is lower for the sw3 scenario sincethe bit-rate is higher than in the hall scenario. The MOS distribution bars inFigure 10 show that the difference in quality between the message interval of 0.3sand 0.4s is not noticeable by human observer. Considering the smaller overheada hello message interval of 0.4s of the SBR protocol would be optimal in thisscenario regarding the perceived video quality.

8 Conclusions & Future Work

We studied the performance of the network to deal with frequent topologychanges depending on the duration of the hello message interval of the SBRprotocol. The parameter hello message interval was adjusted in order to achievean acceptable video quality which was measured by comparing the MOS valueof the source and the received video.



Version: 1.0 of 64

12

The implemented simulation and performance evaluation framework will beused to optimize intra-aircraft applications ranging from surveillance to enter-tainment. Since the criticality of the applications is different, it is essential thatthe evaluation methodology reflects the specific requirements in terms of per-ceived quality. We are confident that the performance evaluation frameworkintroduced in this study is useful for other researchers who want to assess theperformance of a wide range of wireless video transmission systems.

References

1. I.F. Akyildiz, T. Melodia, K.R. Chowdhury, Wireless Multimedia Sensor Networks:A Survey, IEEE Wireless Communications Magazine, Vol. 14, Issue 6, pp. 32-39,December 2007.

2. Network Simulator, ns-2, http://www.isi.edu/nsnam/ns/.3. OPNET Modeler, University Program,http://www.opnet.com/services/university/.4. D. Kotz et al., Experimental Evaluation of Wireless Simulation Assumptions, Pro-

ceedings of the 7th ACM International Symposium on Modeling, Analysis andSimulation of Wireless and Mobile Systems, ACM Press, pp. 7882, 2004.

5. D. Liu et al., Simulation Validation Using Direct Execution of Wireless Ad-HocRouting Protocols, In Proceedings of the 18th Workshop on Parallel and DistributedSimulation PADS, ACM Press, pp. 716, 2004.

6. K. Kuladinithi et al., Experimental Evaluation of AODV Implementations, CEWIT2004, USA, 2004.

7. C.E. Perkins, E.M. Belding-Royer, S.R. Das, Ad Hoc On-Demand Distance Vector(AODV) Routing RFC 3561, IETF MANET Working Group, August 2003.

8. A. Klein and P. Tran-Gia, A Statistic-Based Approach towards Routing in MeshNetworks, IEEE MASS, pp. 1-6, Pisa, Italy, October 2007.

9. T. Clausen and P. Jaqcquet, Optimized Link State Routing (OLSR) RFC 3626,IETF Networking Group, October 2003.

10. C. Intanagonwiwat, R. Govindan, D. Estrin, Directed Diffusion: a Scalable andRobust Communication Paradigm for Sensor Networks, Proceeding of ACM Mo-biCom ‘00, pp. 56-67, Boston, MA, 2000.

11. Jpcap - Java library for capturing and sending network packets, JPCAP,http://netresearch.ics.uci.edu/kfujii/jpcap/doc/.

12. M. Riley et al., Digital Video Communications, Artech House, 1997.13. J.-R. Ohm, Multimedia Communication Technology, Springer, 2004.14. ITU-R, Recommendation BT.500-10, Methodology for the Subjective Assessment

of the Quality of Television Pictures, 2000.15. J. Klaue et al., EvalVid - A Framework for Video Transmission and Quality Evalua-

tion, In Proceedings of the 13th International Conference on Modelling Techniquesand Tools for Computer Performance Evaluation, pp. 255-272, 2003.

16. Video Quality Experts Group, http://www.vqeg.org/.17. L. Merritt et al., x264 - a free h264/avc encoder,

http://www.videolan.org/developers/x264.html.18. FFmpeg - Multimedia Framework, http://ffmpeg.mplayerhq.hu/.19. H. Schulzrinne et al., RTP: A Transport Protocol for Real-Time Applications, RFC

3550.20. Wireshark - Network Protocol Analyzer, http://www.wireshark.org/.21. Overview of Currently Available Routing Protocols(under construction),

http://www.routingprotokolle.de/.



Version: 1.0 of 64

D-Bridge: A Platform for Developing Low-Cost WSN

Product Solutions

Dawud Gordon and Michael Beigl

International Conference on Networked Sensing Systems 2009 (INSS09)

17.06.2009 Pittsburgh, Pennsylvania



Version: 1.0 of 64

D-Bridge: A Platform for DevelopingLow-Cost WSN Product Solutions

Dawud GordonDistributed and Ubiquitous ComputingTechnical University of Braunschweig,

GermanyEmail: [email protected]

Michael BeiglDistributed and Ubiquitous ComputingTechnical University of Braunschweig,

GermanyEmail: [email protected]

Abstract—Today the construction of wireless sensing systemsrequires the use of rather high-priced pieces of hardware andthe assembly of these hardware parts (wireless transmission core,sensor module, gateway device), as well as the implementation ofthe according software (sensor mote software, gateway software,end user software). This makes overall development and thethereby resulting product costly in terms of both time and money.With the D-Bridge concept that we present in this paper we willshow an approach that is much cheaper than any other solutionin terms of hardware and development costs. This D-Bridge is acombination of a gateway between the wireless sensor networkand the IP network which also includes a Web-based applicationserver at the wireless sensor network appliance’s location.

I. INTRODUCTION AND RELATED WORK

Existing wireless sensor network solutions often targetcomplex problems using wireless sensor networks. This isdone by adapting powerful systems of existing wireless sensordevices and infrastructures which provide open programminginterfaces. Examples of such device families are the Motes [5]and BTnode platforms [4].

Developers of wireless networked sensing system appli-cations have to develop multiple system components: Theapplication at the wireless sensor node, the gateway appli-cation to connect the wireless sensor network and the networkcontaining the device running the end-user application, andthat end-user application itself. The basic components e.g.the sensor node hardware, gateway hardware, the sensor nodesoftware etc., are offered as independent, open modules byhardware vendors. This allows the construction of very power-ful applications which are best suited for a complex applicationtask. One example producer is Crossbow (www.xbow.com),that offers 6 types of different wireless modules, 5 differenttypes of gateway solutions and 9 types of sensor modules.

The approach for wireless networked sensing system appli-cations that we want to follow is going in a different direction:our goal is to minimize development and installation timeto enable the rapid implementation and installation of smallwireless sensing system appliances. To our knowledge, thereis currently no other system available in literature or on themarket that follows a similar approach. In order to accomplishthe minimization of development and installation effort we willimplement the following steps:

First, we will employ a wireless sensor node that canbe re-configured but not re-programmed. This avoids onedevelopment step and also reduces overall complexity, thusincreasing reliability in practice. To this end we use our tinyuPart [2] wireless sensor node. This sensor node periodicallyreads its sensors and send the results to a gateway. Period andother parameters can be adjusted by a configuration interface.

Second, we avoid using a client application that requiresinstallation at an end-user computer. Instead, we use a Web-based application. This approach also lowers complexity be-cause in this way we ensure that our application is independentof the operating system on the client computer.

Third, we focus all application functionality on one cen-tral device, the D-Bridge. This devices contains the gatewaybetween sensor network and IP based networks, but also theapplication logic and presentation.

Fourth, we support the development of applications byproviding an interface to the wireless sensor network thatallows the creation of a small networked sensing systemsapplication within a few minutes.

In the next sections we will explain this process in detail, aswell as give an example of the development of an applicationin order to show the simplicity of the process.

II. SYSTEM COMPONENTS

The uPart is an extremely low power sensor node whichoperates by taking sensory readings at set intervals and trans-mitting this information via a RF communication module.The nodes are quite efficient, being able to survive manymonths on a single button-cell battery. They are outfitted withlight, temperature and vibration sensors and are small andvery low cost. They are not capable of receiving data via RFcommunication, which improves their energy consumption, butrequires an additional heterogeneous network member actingas a bridge to form a fully functional network. The bridgeallows the user to interface with the wireless sensor networkand analyze the resulting data output of the sensor nodes,usually in conjunction with an application which presents thedata in a meaningful manner. The D-Bridge is such a devicewhich creates a connection between a uPart wireless sensornetwork and an Ethernet network.



Version: 1.0 of 64

Fig. 1. A Schematic of the D-Bridge

The D-Bridge implements a micro embedded web server,making a website available to all clients in the network. Thebridge consists of a PIC18F97J60 processor from Microchipcontrolling an Ethernet jack as well as an interface with a Cpartfor communication with the uPart network. The processor alsosupports a SD card slot for additional data storage. The deviceis powered by a USB adapter which delivers 5V of power,converted to 3.3V by a regulator as shown in figure 1.

The firmware is a combination of a modified version ofthe TCPStack software from Microchip which implements aTCP/IP stack as well as a basic web server and DHCP client.This enables the D-Bridge to host a website on the network andto automatically configure its IP address from a DHCP server.A FAT32 file system is implemented on the SD card using codepurchased from www.embedded-code.com, which allows thesystem to access the SD card using functions similar to thoseused for file stream operations in C. Communication with thewireless sensor network occurs over a Cpart programmed withthe firmware for the USBBridge.

III. FRAMEWORK

The goal of the D-Bridge platform is to reduce developmenttime for simple and cost-effective applications. The userinterface is embedded within the D-Bridge itself in the formof a website and is accessible via HTTP, through which theuser can interact with the wireless sensor network. The systemis constructed such that the uPart nodes in the sensor networkperiodically communicate with the D-Bridge over RF usinga simple protocol [1]. The bridge reacts to each packet fromthe uPart nodes in a way specified by the the application, andalso facilitates communication with the user over the networkas shown in figure 2. Communication on the network sidebetween the D-Bridge and the client can be configured to occurdirectly ad-hoc, over the local area network, or via the WWW,depending on what the current application calls for.

The HTTP protocol is specifically appropriate for the userbridge communication because it is well tested and almostuniversally implemented. It is also machine independent whicheliminates portability issues, and its intrinsic request andresponse architecture allows systems on both sides of the

Fig. 2. System Architecture

network bridge to function with minimal interdependence.As a further plus, one can assume that all clients usingthis product have had previous experience with the protocolthrough interaction with the WWW.

The D-Bridge provides a platform to create an applicationbased on HTML and provide access to this application tousers on the network. The website is composed of staticHTML with a proprietary method of creating dynamic content.Each .html file of the website is preprocessed by the webserver at request-time which searches for specific identifierstrings. Each string is linked to a function in the programmemory of the processor and, when a string is found, thefunction specified by that string is executed. These functionscan return data which replaces the special strings embeddedwithin the code, or it can be used to execute a command andcarry out a specific operation. The resulting bridge offers thedeveloper a platform with which to quickly and easily createapplications. The proprietary method was selected over theimplementation of a preexisting web development languagein order to maintain memory and processor usage within thelimits of the PIC18F97J60 because of its efficient nature andlow cost.

The website is stored on an external SD card which can alsobe used as data storage for items such as system or packet logs,configurations or context information. All sensory data packets



Version: 1.0 of 64

Fig. 3. The D-Bridge Prototype

from the sensor network are transfered to the application andcan be retransmitted on the network via TCP/UDP, logged onthe SD card, analyzed, discarded, or handled by any number ofcustom operations which can be created with minimal effort.A prototype of the D-Bridge has already been integrated intoa uPart network and can be seen in figure 3.

In order to demonstrate the simplicity of product creationusing this platform, the steps required to build a productwill be described. This example describes an application todisplay the temperature history of n different rooms, eachmonitored by a uPart. The components of the application andtheir interaction can be seen in figure 2. The first step is tocreate a function to log the temperature values from all packetsreceived from the uParts. This is accomplished by creating afile on the SD card using the functions provided by the FAT32system, and writing the data to that file, sorted by sensor nodeand chronological order. The next step is to write a functionget_data() in C which takes one parameter, i, extractsthe last 10 readings for the ith node and returns these in acomma delimited string. An identifier for this function is thenentered into the table of dynamic function identifiers with theinformation that the function takes one parameter: i. This tablecreates a dynamic link between the character string in theHTML text and the C function in program memory.

The application itself consists of a HTML web page con-taining a table with one column and n rows, where everyrow contains the results of the dynamic function, or thelast 10 temperature sensor readings for the ith node. Thisis accomplished by replacing the text in each cell with theidentifier for the C function as it appears in the identifier table,with the parameter i, for i = 1 to n. The result is a dynamic linkbetween the website and the data stored on the SD card. Whenthe user requests the web page over HTTP, the system searchesfor any identifiers embedded in the HTML and upon findingone, a pointer to that function is retrieved from the functionlist. The function get_data() is executed for each node,accessing the SD card each time, and returns the resultinghistory string to the website. The new website containing thedynamically generated content is then uploaded to the userover HTTP, allowing him or her to view the content

TABLE ID-BRIDGE DATA TRANSFER RATES

Type TCP kB/s UDP kB/s

Output 30.2 140Throughput 15 n/a

IV. OUTCOME

Embedding the application within the bridge has severalpositive effects on the system as a whole. The fact that theapplication is no longer dependent on the user’s hardware,operating system type and version reduces time spent makingapplications portable. A product developed on this platformcan be delivered with the application preinstalled, reducinginstallation effort for the user. Both of these factors reduce thetotal cost of ownership of the system, improving attractivenessfor the user.

The current design of the D-Bridge consists of only a fewlow cost components: the Ethernet plug (from Pulse Inc.,includes the operation LEDs and the transformer, 2e), the pro-cessor (includes CPU, Ethernet controller, dual-ported bufferRAM, periphery esp. SPI, 3,60e), the USB plug (0,20e), SD-Card slot (0,65e), oscillator (0,46e), voltage regulator (0,20e)and about 10 resistors and capacitors (1e). This leads to acomponent cost of less than 10 with PCB, and a possible salesprice after production of about 20-25e (assumed productionquantity: 50 pieces, without RF part). Together with the priceof about 20e per sensor node, a framework kit can start as lowas 60e for the hardware. The low cost of this platform allowsdevelopers to create solutions for problems which previouslycould not justify the expensive development of a wirelesssensor network solution.

Analysis of the data transfer rates of the D-Bridge showthat the system has the power necessary for small to mediumapplications. Table I shows the measured transfer rates, whereoutput is the rate at which the system can transfer data tothe network from RAM, and throughput is the rate at whichthe system can upload data from a file located on the SDcard to the network. The latter, which should also representthroughput from the wireless sensor network, was tested usingHTTP GET which explains why there is no result for UDP.The rates show that the system has a high enough throughputto support a moderately complex website.

V. CONCLUSION

The on-board application development environment reducestime and effort required for product creation, as well asinstallation. The affordability of the uParts and of the D-Bridge create a sensor network which is elegantly simple andinexpensive. The affordable nature of the hardware, as wellas the effort saved by the embedded application provides de-velopers with a platform to create extremely affordable WSNsolutions to solve problems of low to moderate complexity.These products will then be able to fill a niche previously leftempty by the preventatively expensive development costs ofwireless sensor network solutions.



Version: 1.0 of 64

VI. FUTURE WORK

The current D-Bridge is still a prototype, and not in a finaldesign stage. We are currently working on a small integratedsolution of about 30x40mm.

REFERENCES

[1] M. Beigl, A. Krohn, T. Zimmer, C. Decker, and P. Robinson, AwareCon:Situation Aware Context Communication, 5th International Conferenceon Ubiquitous Computing (Ubicomp) 2003

[2] M. Beigl, A. Krohn, T. Riedel, T. Zimmer, C. Decker, M. Isomura TheuPart experience: Building a wireless sensor network, IEEE/ACMConference on Information Processing in Sensor Networks (IPSN), 2006

[3] C. Decker, M. Berchtold, L. W. F. Chaves, M. Beigl, D. Roehr, T. Riedel,M. Beuster, T. Herzog, D. Herzig Cost-Benefit Model for Smart Items inthe Supply Chain Conference on The Internet of Things, Zurich, March2008

[4] J. Beutel, O. Kasten, F. Mattern, K. Rmer, F. Siegemund, L. ThieleProtoyping Wireless Sensor Network Applications with BTnodes 1stEuropean Workshop on Wireless Sensor Networks, January 2004

[5] J. Polastre, R. Szewcyk, A. Mainwaring, D. Culler, J. Anderson Analysisof Wireless Sensor Networks for Habitat Monitoring ACM InternationalWorkshop on Wireless Sensor Networks and Applications, September2002



Version: 1.0 of 64

A Study on the Use of Wireless Sensor Networks in a

Retail Store

Dawud Gordon, Michael Beigl and Masayuki Iwai

Workshop at Pervasive Computing 2009 (Pervasive09)

11.05.2009 Nara, Japan



Version: 1.0 of 64

A Study on the Use of WirelessSensor Networks in a Retail Store

Dawud Gordon, Michael BeiglDistributed and Ubiquitous Computing

Institute for Operating Systems and Computer NetworksTechnical University of Braunschweig

GermanyEmail: {gordon, beigl}@ibr.cs.tu-bs.de

Masayuki IwaiDepartment of Informatics and Electronics

Institute of Industrial ScienceUniversity of Tokyo

JapanEmail: [email protected]

Abstract—This paper presents the outcome of a formativestudy - experiences and requirements - on using wireless sensornetwork technology in retail stores. The study was carried outin several steps.

• First, a simple approach to implementing a wireless sensornetwork system was used by a developer for building a retailstore application. Here we collected experiences about theproblems in the application implementation process.

• Second, the system was deployed in a real retail store. Herewe collected feedback from customers and from retail storestaff about the system, its usefulness and integration intothe overall daily business workflow.

• Third, we analyzed requirements for the next generation ofimproved wireless sensor network systems by performing arequirements study.

We will report our initial results of the requirements analysisstudy. The findings indicate a lack of abstraction from thetechnical details of the system needed to enable a high-leveldeveloper to create an application for a retail scenario, and wewill list some of the important issues that need to be addressed.

I. INTRODUCTION AND RELATED WORK

Today, wireless sensor networks are more difficult to im-plement than PC or Web-based applications. There are threereasons for this that we found. First, the connection of com-puting to real world workflows makes such applications com-plex in the sense that current software development focuseson digital workflows. Second there is the lack of softwaresupport for distributed wireless sensor network systems. Third,programming and managing wireless sensor nodes are difficultand complex tasks. Some initial solution ideas have beenpublished for these problems. Complex integration of multiplewireless sensor networks has been addressed by Wielens etal [2], which focuses on the networking aspect. Anotherproposal named FLOW [3] focuses on the abstract softwaregeneration aspect. Both proposals have in common that theyexpect certain technical properties from their sensor nodes andthus show example implementations for one type of sensornetwork only. Also, both systems are complex in themselves,requiring a developer to learn a complex technical softwaresystem. Attempts to lower complexity in sensor networks byproviding more abstract approaches have been developed inthe context of TinyOS. In [4] for example, abstraction patterns

and interfaces were developed for the design of sensor nodesoftware, but this approach only focuses on one sensor node.

We believe that part of the problem of application im-plementation in sensor networks is that sensor nodes areseen as complex computing devices. Instead of using thesimplicity of sensor nodes to simplify development processes,we see a trend towards adding complexity to wireless sensorsystems using tools, frameworks and abstraction layers. TheuPart system [1] as seen in figure 2 was designed to abstractthe development process of wireless sensor network applica-tions from the technical details of the system by simplifyingdevelopment. The goal was to provide developers withoutengineering backgrounds with a platform for developmentof applications without requiring knowledge of the technicaldetails. Several applications have been built atop this platform[1][5][6]. In this paper, we focus on an application whichwas built for retail stores. Masayuki Iwai from the Universityof Tokyo designed a client behavior analysis application fora store in the Akihabara district of Tokyo, Japan, an areacontaining a multitude of consumer electronics vendors. Inthe following sections we will shortly explain the setup andthe requirements that we gathered.

II. SETUP

The application was deployed in one of Akihabara’s manyelectronic store-fronts. The store was outfitted with a demon-stration installation consisting of a counter-top with selectedcellular phones laid out on display as shown in figure 1. Behindthe counter top was a LCD display, showing an image of eachcell phone model on display as well as information about thatmodel. When a user approached the display and picked upone of the phones (a sign of interest in that model), the sensornodes detected fluctuations in light and vibration levels. Theimage of that phone was moved to the center of the displayand the information about that specific model was shown, aswell as the popularity ranking of that model compared to theother models on display.

The system functioned by analyzing the data generated bysensor nodes attached to each cell phone which reported onthe status of that phone. Each node reported how often eachphone was picked up and how long the passer-by held that



Version: 1.0 of 64

Fig. 1. A Display with Items and Monitor from the Akihabara Experiment

phone in their hand before placing it back on the display.This data transmitted by the nodes was gathered by a networkbridge between the sensor network and the in-house networkof the shop, which transmitted that data to a central unitto be analyzed for the ranking system. The resulting rankof a specific object was created measuring user interest inthe phone by analyzing the output of the vibration and lightsensors on the node and thereby deducing the amount of timethat users interacted with that phone as compared to others ondisplay.

III. THE REQUIREMENTS ANALYSIS PROCESS

This situation is somewhat special because the client is adeveloper with specific knowledge of all stakeholders in thescenario. Although he or she is not the end user of the finalproduct, he has direct contact with the end-users, both the end-client (the shop-keepers who would purchase such a systemin order to analyze the popularity of their products) and theend-users (passers-by, who interact with the system). What theend-clients require was discovered from direct interaction withthem on the part of the developer, and the end-client’s wisheswere obtained using a questionnaire after the fact.

In order to carry out the requirements analysis process ina scientific manner, it is necessary to select and adhere toa specific methodology. We selected the Volere [7] methodbecause it is a free framework for requirements analysis whichprovides so-called ”snow-cards” for individual requirements aswell as the outline of a document, which, along with the snow-cards, represents a requirements specification at the end of theprocess. Although useful, it is not necessary to use this or anyother commercial solution.

IV. REQUIREMENTS

The requirements gathered in the first round of communica-tion with the client were very technical in nature. The fact thatthe client was, in this case, a developer introduces a few newvariables into the development process which will be discussedhere as a side-note. Under usual circumstances, requirementsanalysis assumes that the user has a goal and the developer candecide how to best achieve this goal in the new system. In thiscase however, the developer-client also operates as a developerand therefore thinks somewhat technically when it comes tohis desires for the platform. What he or she may lack, however,

is the knowledge of surrounding situations, such as otherclients or stakeholders also involved in the process, or othereffects which could create the need for compromise withinthe system. This incongruence introduces an unnecessaryrigidity into the specification process, which could hinder thedeveloper when optimizing the system for multiple scenarios.One possible solution is for the requirements gatherer torecognize this situation and either attempt to extract the goalof the client’s technical requirements alone, which may bequite risky as an error here could be extremely expensive,or reopen discussion with the client on this requirement. Thisstep is crucial for the system engineer to create a system whichcan satisfy multiple scenarios and multiple clients at the sametime, by allowing the developer flexibility in his or her design.

The configuration of the individual nodes is an importantpart of the application. As was demonstrated by the study,this must be dynamically executable during system run-time.This requires over-the-air-configuration of the sensor nodes,which must be controllable by an application within the store,as well as be initiated from a server on the WWW. Thisallows the network to be able to adapt to dynamically changingconditions on the store floor, such as customer volume, or thelatest market analysis, and the store-owner himself does notwant to have to be aware of these adaptations. This meansthat the developer must account for the reconfigurations in hisapplication, and without some method for reconfiguring fromthe WWW, he or she will have to execute these reconfigu-rations on location. This would greatly increase maintenancecosts for all types of retail applications.

The system must also provide a configuration interfaceto reconfigure large amounts of nodes simultaneously. Thisis largely an ease-of-use issue for developers who oftenwork with large quantities of nodes during development andtesting stages, and need to reconfigure the entire applicationmany times over. These new methods of node configurationmust give immediate feedback to the administrator, signalingeither success or failure of the configuration actions. This isnecessary for the administrator to be able to weed out nodeswhich are still operating under old configurations in the retailapplication.

The system must also give instant feedback to the user aswell as the administrator. The system must instantly registerand display the actions of a user who is interacting with thesystem. If this does not occur, or if the delay is too long, theuser does not have the feeling of interaction with the system.A good example of this is that when a user picks up a cellphone on display, the display monitor must instantly reflectthis action.

The sensory attributes of the sensor nodes are also importantfor the development platform. It is vital to the scenario that thevibration sensor be accurate and sensitive enough to be ableto recognize human interaction with the sensor nodes, in thiscase if an object to which it is attached is being picked up orheld in the hand of the user. Also the light sensor must be ableto operate in indoor and outdoor environments, as the retailenvironment extends from the retail store interior, where there



Version: 1.0 of 64

Fig. 2. The uPart Wireless Sensor Node Used in the Akihabara Study

are low light conditions, to the store front in the street wherethere may be very high light levels including direct sunlight.Because of this it is important that the light sensor neithersaturate under normal day-light conditions, nor bottom out inlow-light environments.

Most retail environments have opening and closing hoursand in order to extend battery-powered network lifetimes andreduce maintenance costs it is important to take advantage ofthese phases. The system should provide a method for goinginto a dormant mode after closing time in order to reducepower consumption of the sensor nodes. In the same grain,the system should also support a wake function based onthese hours, as well as a manual wake-up override. In orderto keep the systems as low-maintenance as possible for theend-clients, they must be able to see the remaining energylevel as well as the time remaining in current modus of thenodes’ batteries. Based on this information, the shop-keepershould be notified 24 hours before a node will finally run out ofenergy. Also, the system should be able to provide some sort ofnode locating assistance. This will help the shop keeper carryout normal maintenance processes, such as battery changes ornode relocations.

The scenario of an Akihabara store-front is actually twoseparate scenarios with a large amount of overlap. The firstscenario is the one previously discussed, for which a rangeof at least 10 meters is necessary for the nodes. The otherscenario is that sensor nodes are attached to various objectsof the shop-keeper’s choosing throughout the store whichare then monitored by an application accessible only to theshop-keeper. This allows him to monitor the popularity of hisproducts among his clients with or without their knowledge.For this scenario, a range of 40 meters is necessary in orderto cover the floor area of the majority of the stores in theAkihabara district. The distinction between these two scenariosis important for retail scenarios as it defines a double networkrange requirement: one single network for an entire store, ormultiple applications/networks per retail store environment.

Continuing in the direction of multiple applications perenvironment, it is necessary to be able to group certainnodes together in order to create separate applications which

operate in the same environment. Also, not only intra-retail-store interference may occur, but inter-store collisions as wellbetween two separate retail stores operating the same product.For example, if the resulting product of this trial wouldbecome popular in the Akihabara district, it would rapidlybecome necessary to implement some sort of interferenceprotection for the case where two storefronts implement thesame application with a wireless network reception overlap.The resulting mechanism must create groups of nodes whichcan be configured together, and also provides a measure ofinterference protection between two applications running side-by-side.

V. CONCLUSION

The retail store application acted quite well as a methodfor gathering experience on implementing a wireless sensornetwork in a retail environment. Our overall impression is thatthere are still some areas of wireless sensor networks whichlack a certain level of abstraction from the underlying technicalprinciples. We have also presented a list of requirements whichare suggestions for improving these systems to allow high-level developers to design their own systems. We learned thatusers need to receive immediate feedback from the system inorder to validate their interaction. Also, store owners wantto have as little as possible to do with the technical sideof the network, and for this reason an acknowledged over-the-air-configuration method for one or multiple nodes frompoints inside and outside of the store’s network must be madeavailable. The nodes themselves must incorporate sensors andrange capabilities which can support the varying conditionsin a retail store. The nodes must also be able to adapt to theworking hours of such a store and be able to withstand pos-sible interference from neighboring wireless sensor networkapplications. We are already working on the next generationof sensor nodes, which with the help of these requirements,will be one step closer to enabling high-level developers tocreate their own wireless sensor network solutions.

REFERENCES

[1] M. Beigl, A. Krohn, T. Riedel, T. Zimmer, C. Decker, M. Isomura TheuPart Experience: Building a Wireless Sensor Network, IEEE/ACMConference on Information Processing in Sensor Networks (IPSN), 2006

[2] S. Wielens, M. Galetzka and P. Schneider, Design support for WirelessSensor Networks Based on the IEEE 802.15.4 Standard, Personal,Indoor and Mobile Radio Communications (PIMRC), 15-18 Sept. 2008

[3] T. Naumowicz. Managing Data Flows with Flow: A Software Factoryfor Wireless Sensor Networks., Poster. Microsoft Academic Days 2008,Berlin, Germany, November 2008

[4] D. Gay, P. Levis, and D. Culler, Software Design Patterns for TinyOS.In Proceedings of the 2005 ACM SIGPLAN/SIGBED Conference onLanguages, Compilers, and Tools For Embedded Systems (LCTES)Chicago, Illinois, June 2005

[5] J. Nakazawa and H. Tokuda, A Middleware Framework for SharingSensor Nodes among Smart Spaces. Fourth International Conferenceon Networked Sensing Systems, 2007. (INSS’07)

[6] M. Isomura, T. Riedel, C. Decker, M. Beigl, H. Horiuchi, Sharingsensor networks, Sixth International Workshop on Smart Appliances andWearable Computing, International Workshop on Smart Appliances andWearable Computing (IWSAWC) 2006, Lisbon, Portugal: Proceedings ofthe ICDCS 2006, IEEE Computer Society

[7] S. and J. Robertson, Mastering the Requirements Process, Addison-Wesley Professional, 1999, 2nd Edition



Version: 1.0 of 64

CHOSeN: Cooperative Hybrid Objects Sensor Networks

Thomas Herndl, Giuliana Zennaro, Jirka

Klaue, Pierre-Damien Berger, Álvaro Álvarez Vázquez, Stefan Mahlknecht, Miroslav

Konecny, Michael Beigl, Wolfgang Pribyl

Sixth Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks

(SECON 2009)

22.06.2009 Rome, Italy



Version: 1.0 of 64

Aeronautic Application:Structural Health Monitoring

Main Objectives

Thomas HerndlPrincipal Concept EngineeringIFAT DCGR

CHOSeN, while being application-driven, aims at providing scalable and adaptable technologies which allow the individual sensor nodes to work at operation points which are optimum in their specific, local application context.

• Generic Advanced RF Transceiver Platform• Self-organizing systems in a heterogeneous

environment• Low Power Scalable Protocol Processing Engine• Validation in highly challenging application environments

Analog Sensor

Digital Sensor Sensor

Gateway CAN

CAR Body

SensorCar Display

Sensor

Gateway Management

(Laptop) PDA

Temperature(break, road,..)

Humidity

Wear (Tyre, break pad,..)

Distance

Light levelTyre pressure

Water presence

(Relative)Speed

Acceleration

…..

Automotive Application: Collision Warning System

Technical Approach

Detect cracks (localisation, size) in supporting structure parts (aluminiumalloy, CFRP)• Very simple sensor (promising)• Embedded in structure• Very low data rate• Transmission on demand and/or event-based• Long lifetime (as long as airframe)• Maintenance-free and autonomous• Structure health assessment only possible withdata from sensors at different locations

• Data fusion algorithms

Monitor integrity of door surrounding

Hybrid Network Structure

• Dents caused by gangways/aerobridges

• Process data from groups of sensors to assess doorarea integrity

Heterogeneity Supporting Transceiver Platform

ApplicationAeronautics

ApplicationAutomotive

MACprotocolsMAC

protocolsMACprotocolsMAC

protocols

MACprotocolsMAC

protocolsMACprotocolsRouting

protocols

Sensor Node(Acorde, EADS, CRF)

Protocols(TUBS, IFAT, TUV,EADS, ADO, CRF)

Communication Middleware

ApplicationSoftware(TUBS, EADS, CRF)

RF, analog mixed signal

AD

1110digital (de)modulation

framing, scheduling,interfacing

Chip Design(IFAT, TUV, TUG)

Silicon Chip(IFAT, TUV, TUG)

Application Demonstrator(EADS, CRF, TUBS)

Components Systems

Analog FrontendAnalog

Frontend

PAPA ASK/FSKModulatorASK/FSKModulator

A/DA/D DSPRX

DSPRX

DSPTX

DSPTX

sampleschips,

clock, SOF

DFERX

DFERX

Fle

xib

le

Pro

toco

lP

roce

sso

r

Fle

xib

le

Pro

toco

lP

roce

sso

r

SysConSysCon

BBBB

DFETX

DFETX

bits,clock

System, Clock & Power ManagementSystem, Clock & Power Management

RC-osc.RC-osc.

cryst.osc.

cryst.osc.

LPreg.LP

reg.HPreg.HPreg.

ROMROMRAMRAM

data,control

SPI

/ G

PIO

s/

Deb

ug

SPI

/ G

PIO

s/

Deb

ug

Wake upReceiverWake upReceiver

• Ultra low power, scalable, reconfigurable for Multi-MAC support • Dedicated, always on Wake up Receiver for improved MAC

layer derivates• Increased responsiveness at low power consumption

• On demand• Moderate data rate (~100 kbit/s when measuring)• Synchronized measurements of several sensors must be processed in order to assess health status of structure part• Discovery/localization, auto-configuration• Wake-up when gangway approaches• Models for material & structure can beused to calculate damage

Improve ¡ Energy autonomy¡ Reliability and robustness of communication¡ Flexibility ¡ Responsiveness

¡ Capture and evaluate different physical parameters¡ Hybrid in network structure and sensor communication characteristics¡ Certain primary Wake-up nodes (e.g. radar) bring the system to high sampling and responsiveness state with more stringent parameter monitoring and communication demands¡ Multi-state WSN



Version: 1.0 of 64

initial dissemination & exploitation plan and activities · paper performance study of a video...

Documents