D2.3-A Network topology and communications architecture ...s15723044.onlinehome-server.info/artemise/documents/D23A_Network... · Network Topology and communications architecture

eDIANA Embedded Systems for Energy Efficient Buildings

Grant agreement no.: 100012

Dissemination level X PU = Public PP = Restricted to other programme participants (including the JU) RE = Restricted to a group specified by the consortium (including the JU) CO = Confidential, only for members of the consortium (including the JU)

Network topology and communications architecture definition

Author: Chiara Buratti UNIBO Contributors: Cengiz Gezer UNIBO

Roberto Verdone UNIBO Virginia Corvino UNIBO

Andrea Carniani UNIBO Gaia Maselli UoR

Bastiaan de Groot Apptech Julen Ugalde Garcia FAGOR

Aitor Arriola Ikerlan Xabier Bilbao Hernandez ZIV Ingolf Karls Infineon

Igor Rosenberg Atos Maria Josè Martinez I&IMS

Gert-Jan van Dijk QUINTOR Giampaolo Frugone ED Issue Date January 31 2010 (m12) Deliverable Number D2.3-A WP Number WP2: Design of architecture and middleware for effective

system composability Status Delivered

Network Topology and communications architecture definition eDIANA: GA no.: 100012D2.3-A

January 2010 Page 2

Disclaimer

The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

The document reflects only the author’s views and the Community is not liable for any use that may be made of the information contained therein.

Document history V Date Author Description

1 2009-13-03 UNIBO First ToC

2 2009-03-24 UNIBO Second ToC

3 2009-05-04 QUINTOR ToC of Chapter 2

4 2009-07-08 QUINTOR First draft of Chapter 2

5 2009-09-18 UNIBO

UoR

ToC of Chapter 4

ToC of Chapter 3

6 2009-10-18 INFINEON TOC of Chapter 1

7 2009-11-03 UNIBO First Draft of Chapters 1, 3 and 4

8 2009-15-12 UNIBO, INFINEON, UoR

Second draft Chapters 1, 3 and 4

9 2010-11-01 UNIBO, UoR

New version of Chapters 1, 3 and 4

10 2010-21-01 UNIBO Almost final version

11 2010-29-01 UNIBO Final version


January 2010 Page 3

Summary

D2.3-A is a public document delivered in the context of WP2, Task 2.3: Communication and Topology, with regard to the definition of the communication part of the eDIANA platform and the network topology. The aim of the Task is to identify the most promising and suitable solutions, techniques and network topologies able to allow a reliable and efficient communication of data among the different eDIANA platform elements.

This document is about network topologies and communication architecture. After the definition of the eDIANA reference scenario and applications, the network and communication architecture is defined. Follows an overview of possible solutions for wired and wireless networks to be used in the platform, and then the most promising and suitable are identified. For them, details about the communication protocols and the network topologies are introduced. Some numerical results related to the performance achieved when applying an IEEE 802.15.4/Zigbee network to energy efficient building scenarios, are provided. IEEE 802.15.4/Zigbee, in fact, seems to be the most suitable technology already available on the market, to be used. Both simulation and experimental measurement analyses have been carried out. Results demonstrate that such technology could fulfill the requirements set in the Project and are useful for the design of the wireless network in the eDIANA scenario.

Note that, owing to the presence in the document of some information about the standard Bluetooth Low Energy, which is still in an ongoing phase, these information have been removed for the sake of confidentiality since they are available only for Bluetooth SIG members. Another version of the Deliverable containing the whole content of the document, will be also delivered. This version will be confidential.


January 2010 Page 4

Contents

SUMMARY.....................................................................................................3

ABBREVIATIONS ..........................................................................................8

INTRODUCTION ........................................................................................ 17

1. REFERENCE ARCHITECTURE SCENARIOS AND SYSTEM REQUIREMENTS 20

1.1 REFERENCE ARCHITECTURE .............................................................................20 1.2 REFERENCE SCENARIOS ..................................................................................22 1.2.1 Single family house..................................................................................... 22 1.2.2 Apartment building ..................................................................................... 22 1.2.3 Office building ............................................................................................ 23

1.3 REFERENCE APPLICATIONS AND SERVICES ...........................................................24 1.4 SYSTEM REQUIREMENTS.................................................................................26 1.5 NETWORK ARCHITECTURE...............................................................................28 1.5.1 eDIANA devices .......................................................................................... 30 1.5.2 eDIANA intra-Cell network ........................................................................... 30 1.5.3 eDIANA inter-Cell network ........................................................................... 31

2. WIRELESS AND WIRED STANDARD INTERFACES ................................ 32

2.1 IDENTIFICATION OF WIRED TECHNIQUES .............................................................32 2.1.1 Standard Solutions...................................................................................... 34

2.1.1.1 ITU G.hn ........................................................................................................... 34 2.1.1.2 IEEE P1901........................................................................................................ 35 2.1.1.3 KNX .................................................................................................................. 36 2.1.1.4 PRIME ............................................................................................................... 38 2.1.1.5 Comparison between the different wired standard technologies ............................ 40

2.1.2 Proprietary Interfaces.................................................................................. 42 2.1.2.1 Universal Powerline Association (UPA)................................................................. 42 2.1.2.2 HomePlug.......................................................................................................... 42 2.1.2.3 CEPCA............................................................................................................... 43 2.1.2.4 X-10.................................................................................................................. 43 2.1.2.5 LonWorks .......................................................................................................... 44 2.1.2.6 FAGOR Home Automation Protocol...................................................................... 46

2.1.3 Other wired technologies............................................................................. 47 2.1.3.1 USB................................................................................................................... 47 2.1.3.2 FireWire ............................................................................................................ 48 2.1.3.3 Comparison between USB and FireWire............................................................... 48

2.2 IDENTIFICATION OF WIRELESS TECHNIQUES AND STANDARDS....................................49 2.2.1 Wi-Fi.......................................................................................................... 49

2.2.1.1 802.11 Physical Layer......................................................................................... 49 2.2.1.2 802.11 MAC Layer.............................................................................................. 50

2.2.2 IEEE 802.15.4 ............................................................................................ 51 2.2.2.1 Zigbee............................................................................................................... 51 2.2.2.2 6LowPAN........................................................................................................... 52 2.2.2.3 802.15.4/Zigbee application code size considerations ........................................... 52


January 2010 Page 5

2.2.2.4 IEEE 802.15.4 Energy consumption..................................................................... 54 2.2.2.5 IEEE 802.15.4 – Compliant Devices..................................................................... 56

2.2.2.5a TinyOS Based 802.15.4 Solutions ............................................................................... 56 2.2.2.5b 802.15.4 Standard-Based Stack Solution..................................................................... 58 2.2.2.5c Comparison between the different 802.15.4 devices..................................................... 59

2.2.3 Bluetooth ................................................................................................... 61 2.2.3.1 The Bluetooth Standard...................................................................................... 61

2.2.3.1a PHY......................................................................................................................... 61 2.2.3.1b Networking and traffic............................................................................................... 62 2.2.3.1c Security ................................................................................................................... 64 2.2.3.1d Profiles .................................................................................................................... 64 2.2.3.1e Power consumption .................................................................................................. 65

2.2.3.2 Upcoming releases ............................................................................................. 66 2.2.3.2a Bluetooth 3.0 ........................................................................................................... 66 2.2.3.2b Bluetooth Low Energy ............................................................................................... 66

2.2.3.3 Bluetooth Devices .............................................................................................. 67 2.2.4 UWB.......................................................................................................... 69 2.2.5 Other wireless solutions .............................................................................. 73

2.2.5.1 Wireless HART ................................................................................................... 73 2.2.5.2 ISA100 .............................................................................................................. 74

2.2.6 Comparison of Wireless Standards................................................................74 2.2.7 Energy usage of short range wireless networks ............................................. 76 2.2.8 Security considerations for wireless networks ................................................ 78

2.2.8.1 The main attacks ............................................................................................... 78 2.2.8.2 Four basic security services ................................................................................ 79 2.2.8.3 Wired Equivalent Privacy (WEP) .......................................................................... 80 2.2.8.4 Wi-Fi Protected Access (WPA)............................................................................. 81 2.2.8.5 WPA2................................................................................................................ 83

2.3 APPLICABILITY OF TECHNIQUES AND STANDARDS IN HIERARCHICAL ENERGY EFFICIENT ENVIRONMENTS .................................................................................................83 2.3.1 PLC technologies ........................................................................................ 83 2.3.2 Wireless technologies.................................................................................. 84

3. PROTOCOL ARCHITECTURE .................................................................. 87

3.1 COMMUNICATION PROTOCOLS FOR WIRED DEVICES ................................................87 3.1.1 ITU G.hn Protocol Architecture..................................................................... 87

3.1.1.1 PHY Layer ......................................................................................................... 88 3.1.1.2 Data Link Layer.................................................................................................. 89

3.1.2 IEEE P1901 ................................................................................................ 90 3.1.2.1 PHY Layer ......................................................................................................... 90 3.1.2.2 MAC Layer ......................................................................................................... 91

3.1.3 PRIME OFDM Powerline Communication ....................................................... 91 3.1.3.1 PHY Layer ......................................................................................................... 91 3.1.3.2 MAC Layer ......................................................................................................... 92 3.1.3.3 PRIME Convergence Layers ................................................................................ 96 3.1.3.4 Routing and Transport Layers ............................................................................. 98 3.1.3.5 Upper Layers (Session, Presentation and Application)........................................... 98 3.1.3.6 DLMS/COSEM data model................................................................................... 98

3.2 COMMUNICATION PROTOCOLS FOR WIRELESS DEVICES ............................................99 3.2.1 IEEE 802.15.4 ............................................................................................ 99

3.2.1.1 PHY Layer ......................................................................................................... 99


January 2010 Page 6

3.2.1.2 MAC Layer ........................................................................................................100 3.2.1.3 Upper Layers: Zigbee ........................................................................................102

3.2.2 Bluetooth Low Energy ............................................................................... 104 3.2.2.1 Overview..........................................................................................................104 3.2.2.2 PHY Layer ........................................................................................................104 3.2.2.3 MAC Layer ........................................................................................................105 3.2.2.4 Upper Layer......................................................................................................105

3.3 COMMUNICATION PROTOCOLS FOR MULTI-INTERFACE DEVICES ................................105 3.3.1 IP cameras............................................................................................... 105

3.3.1.1 ONVIF Protocol specifications ............................................................................106 3.3.1.2 Device Discovery...............................................................................................108 3.3.1.3 Device management .........................................................................................109 3.3.1.4 Device configuration..........................................................................................109 3.3.1.5 Real Time Streaming.........................................................................................111 3.3.1.6 Event handling..................................................................................................111 3.3.1.7 Video analytics..................................................................................................112

4. NETWORK TOPOLOGY......................................................................... 114

4.1 TOPOLOGIES FOR WIRED NETWORK ................................................................115 4.1.1 ITU G.hn.................................................................................................. 115 4.1.2 PRIME network topology ........................................................................... 117

4.2 TOPOLOGIES FOR THE WIRELESS NETWORK.......................................................119 4.2.1 IEEE 802.15.4/Zigbee Topologies ............................................................... 119

4.2.1.1 The IEEE 802.15.4 Topology Formation Procedure..............................................122 4.2.1.2 The Zigbee Tree-Based Topology.......................................................................123

4.2.2 Bluetooth LE Topologies ............................................................................ 124 4.3 ANALYSIS OF THE WIRELESS NETWORK TOPOLOGIES IN ENERGY EFFICIENT SCENARIOS 125 4.3.1 Simulation analysis of IEEE 802.15.4 in Star and Tree-based topologies ........ 125

4.3.1.1 How to compare different topologies..................................................................126 4.3.1.2 Evaluation scenario and application....................................................................128

4.3.1.2a Reference Scenario ..................................................................................................128 4.3.1.2b Reference applications .............................................................................................129 4.3.1.2c Channel Model.........................................................................................................129 4.3.1.2d Packet Capture Model ..............................................................................................130 4.3.1.2e The frequency allocation strategy..............................................................................134 4.3.1.2f System Parameters used in the simulator ...................................................................135

4.3.1.3 Star topology ....................................................................................................136 4.3.1.3a Monitoring Application..............................................................................................136 4.3.1.3b Monitoring and Controlling Applications .....................................................................145 4.3.1.3c Non beacon-enabled mode .......................................................................................147 4.3.1.3d Conclusions.............................................................................................................148

4.3.1.4 Tree-based topology .........................................................................................148 4.3.1.4a Examples of Numerical results ..................................................................................151 4.3.1.4b Monitoring Application..............................................................................................154 4.3.1.4c Monitoring and Controlling Applications......................................................................156 4.3.1.4d Conclusions.............................................................................................................158

4.3.2 Experimental Platform for IEEE 802.15.4 in a real Indoor environment .......... 158 4.3.2.1 Tree Topology ..................................................................................................160 4.3.2.2 Mesh Topology .................................................................................................164 4.3.2.3 Conclusions ......................................................................................................166

4.3.3 Experimental Platform for IEEE 802.15.4 in an Office Building ...................... 167 4.3.3.1 Communication details ......................................................................................169


January 2010 Page 7

4.3.3.2 Network uptime measurements .........................................................................171 4.3.3.2a Incident duration .....................................................................................................172 4.3.3.2b Incidents over time..................................................................................................173 4.3.3.2c Correlation with time of day......................................................................................175

4.3.3.3 Routing ............................................................................................................176 4.3.3.4 Link quality indicator test...................................................................................178 4.3.3.5 Quality indicators compared...............................................................................179

4.3.4 Interferences between IEEE 802.15.4 and IEEE 802.11b.............................. 180 4.3.5 Conclusions .............................................................................................. 183

CONCLUSION .......................................................................................... 185

ACKNOWLEDGEMENTS............................................................................ 187

REFERENCES ........................................................................................... 187


January 2010 Page 8

Abbreviations

3G Third Generation

4BOK Quaternary Bi-Orthogonal Keying

6LowPAN Pv6 over Low power Wireless Personal Area Networks

A/V Audio Video

A2DP Advanced Audio Distribution Profile

AC Alternating Current

ACL Asynchronous Connectionless Link

ACSE Association Control Service Element

AES Advanced Encryption Standard

AFH Adaptive Frequency Hopping

AMM Automatic Meter Management

AMR Automatic Meter Reading

AODV Ad Hoc On Demand Distance Vector

AP Access Point

APC Application Protocol Convergence

APDU Application Protocol Data Unit

ARQ Automatic Repeat Request

ATT Attribute protocol

BDR Basic Data Rate

BER Bit Error Rate

BI Beacon Interval

BO Beacon Order

BPL Broadband Over PowerLine


January 2010 Page 9

BPSK Binary Phase Shift Keying

BR Basic Rate

BT Bluetooth

BT LE Bluetooth Low Energy

c2MCCi Concentrator to Macro Cell Concentrator Interface

CA Collision Avoidance

CAP Contention Access Period

CBTXOP Contention-Based Transmission Opportunity

CCA Cell Control and Actuation

CCMP Counter Mode with Cipher Block Chaining Message Authentication Code Protocol

CD Collision Detection

CDC Cell Device Concentrator

CDMA Code Division Multiple Access

CFP Contention Free Period

CFTXOP Contention-Free Transmission Opportunity

CGS Cell Generation and Storage

CMM Cell Monitoring and Metering

CMOS Complementary Metal Oxide Semiconductor

CO Carbon Monoxide

COSEM Companion Specification for Energy Metering

CP Contention Period

CPCS Common Part Convergence Sublayer

CPU Central Processing Unit

CRC Cyclic Redundancy Check


January 2010 Page 10

CSMA Carrier Sense Multiple Access

CSMA/CA Carrier Sense Multiple Access with Collision Avoidance

CSMA/CD Carrier Sense Multiple Access with Collision Detection

CTC Convolutional Turbo Code

CTP Collection Tree Protocol

CTS Clear-To-Send

CUI Cell User Interface

DHCP Dynamic Host Configuration Protocol

DIFS Distributed Inter-Frame Space

DLMS Device Language Message specification

DM Domain Master

DP Discovery Proxy

DPSK Differential Phase Shift Keying

DQPSK Differential Quadrature Phase Shift Keying

DSL Digital Subscriber Line

DSSS Direct Sequence Spread Spectrum

DS-UWB Direct Sequence Ultra Wide Band

DVD Digital Versatile Disc

ED1 Event Detection

ED2 Event-Driven

eDIANA Embedded Systems for Energy Efficient Buildings

EDP eDIANA Platform

EDR Enhanced Data Rate

EHS European Home System



EIB European Installation Bus

EMC Electromagnetic Compatibility

EPC Enhanced Power Control

FCC Federal Communications Commission

FDMA Frequency Division Multiple Access

FEC Forward Error Correction

FFD Full Function Device

FFT Fast Fourier Transform

FHSS Frequency Hopping Spread Spectrum

FM Frequency Modulation

FSK Frequency Shift Keying

GAP Generic Access Profile

GATT Generic Attribute Profile

GFSK Gaussian Frequency-Shift Keying

GM Global Master

GTS Guaranteed Time Slot

HC Hop Count

HCI Host Controller Interface

HDLC High Level Data link Control

HD-PLC High Definition PowerLine Communication

HID Human Interface Device

HS High Speed

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol over Secure Socket Laye



HVAC Heating, Ventilation and Air Conditioning

I/O Input / Output

IDB Inter-Domain Bridge

IEEE Institute of Electrical and Electronics Engineers

iEi Intelligent Embedded Interface

IETF Internet Engineering Task Force

IETF Internet Engineering Task Force

IFFT Inverse Fast Fourier Transform

IPSO Internet Protocol for Smart Objects

IPTV Internet Protocol Television

IPv4 Internet Protocol Version 4

IPv6 Internet Protocol Version 6

ISA International Society of Automation

ISI Inter-Symbol Interference

ISM Industrial Scientific and Medical

ISO International Organization for Standardization

ITU International Telecommunications Union

L2CAP Logical Link Control and Adaption Layer Protocol

LAN Local Area Network

LC Link Controller

LDPC Low-Density Parity-Check

LE Low Energy

LL Link Layer

LLC Logical Link Control



LM Link Manager

LMP Link Management Protocol

LQ Link Quality

MAC Medium Access Control

MAP Media Access Plan

MBOA Multi-Band OFDM Alliance

MB-OFDM Multi-Band OFDM

MCC MacroCell Concentrator

MCU Micro Controller Unit

MD More Data

MIC Message Integrity Code

MITM Man-in-the-Middle

MPDU Media Access Control Data Unit

MTBF Mean Time Between Failures

NAT Network Address Translation

NCD Non-coherent Detection

NV Network Variable

NVC Network Video Client

NVT Network Video Transmitter

NWK Network

OFDM Orthogonal Frequency Division Multiplexing

ONVIF Open Network Video Interface Forum

O-QPSK Offset-Quadrature Phase Shift Keying

OSI Open Systems Interconnection



P2P Peer to Peer

PAM Pulse Amplitude Modulation

PAN Personal Area Network

PCS Physical Coding Sub-Layer

PDA Personal Digital Assistant

PDR Packet Delivery Ratio

PDU Protocol Data Unit

PER Packet Error Rate

PHY Physical

PLC PowerLine Communication

PMA Physical Medium Attachment

PMD Physical Medium Dependent

PRIME Powerline Related Intelligent Metering Evolution

PSIA Physical Security Interoperability Alliance

PTZ Pan-Tilt-and-Zoom

PwGRIDi Power Grid Interface

QAM Quadrature Amplitude Modulation

QB Query Based

QoS Quality of Service

QPSK Quadrature Phase Shift Keying

RAM Rapid Access Memory

RF Radio Frequency

RFCOMM Radio Frequency Communication

RFD Reduced Function Device



ROM Read Only Memory

RREP Route Reply

RREQ Route Request

RS Reed-Solomon

RS-CC Concatenated Reed–Solomon Convolutional Code

RTCP Real-time Transport Control Protocol

RTP Real-Time Transport Protocol

RTS Request-To-Send

RTSP Real Time Streaming Protocol

SCP Shared Contention Period

SD Superframe Duration

SDU Service Data Unit

SIG Special Interest Group

SMP Security Manager Protocol

SNR Signal-To-Noise Ratio

SO Superframe Order

SOAP Simple Object Access Protocol

SPP Serial Port Profile

SRAM Static Random Access Memory

SSCS Service Specific Convergence Sublayer

STXOP Shared Transmission Opportunity

TDES Triple Data Encryption Standard

TDMA Time Division Multiple Access

TKIP Temporal Key Integrity Protocol



TLS Transport Layer Security

TXOP Transmission Opportunity

UDP User Datagram Protocol

UPA Universal Powerline Association

USB Universal Serial Bus

UWB Ultra Wide Band

VoIP Voice Over Internet Protocol

WAP Wireless Application Protocol

WEP Wired Equivalent Privacy

Wi-Fi A synonym for 802.11 Technology

WLAN Wireless Local Area Network

WPA Wi-Fi Protected Access

WPAN Wireless Personal Area Network

WSDL Web Service Description Language

WSN Wireless Sensor Network

WWWi Internet Interface

XML Extensible Markup Language

ZC ZigBee Coordinator

ZDO ZigBee Device Object

ZED ZigBee End Device

ZR ZigBee Router



Introduction

This Deliverable is the first official report issued by Task 2.3; referring to the eDIANA platform, it deals with the design of the communication part. The document represents the baseline for the definition, development and engineering of the eDIANA platform elements. It aims at (i) identifying the wired/wireless solutions to be implemented in the eDIANA platform, and (ii) proving that the communication technologies identified fulfill the system requirements set in the Project in the context of the reference eDIANA scenarios. Deliverable D2.3-B, due by T0+18, will complete the design of the full stack of protocols, and will provide optimisation of the network parameters identified in this document.

The reference architecture developed in the framework of WP2 is briefly summarised here, with the goal of defining the communication network architecture both at the Cell and MacroCell level, and the role of the different devices from the communication viewpoint. Several wired and wireless technologies suitable for the eDIANA scenarios are analysed, and the most promising solutions are identified. For these technologies the possible communication protocols are described, and the different network topologies are analysed and compared.

At MacroCell level, the network links will be most probably realised implementing wired solutions based on powerline communication systems. Several available technologies are identified in Chapter 2, and the discussion within the Task brought to the identification of few options which should be considered as candidate technologies for the implementation of the demonstrators in the Project. Also wireless solutions based on IEEE 802.11b (Wi-Fi) could be used in such network.

Concerning the Cell level, it was decided to implement wireless solutions. After the consideration of the available options, IEEE 802.15.4/Zigbee has been selected within the Task as the most suitable technology, for reasons mainly related to the plethora of products already available on the market, and because of the fulfillment of the system requirements set by the applications, as is proven in Chapter 4.

For both the wired and wireless technologies identified, the communication protocols are described in Chapter 3, while performance characterisation in different scenarios is shown in Chapter 4.

Since wireless techniques in indoor environments can provide performance which are not easy to predict, the Cell level has received more attention within the Project, and network performance has been carefully characterised. Chapter 4 contains numerical results showing performance achievable in case of use of IEEE 802.15.4/Zigbee air interfaces for the communication among devices within the Cell. Results achieved through simulation analysis and experimental measurements made on the field, are reported. They demonstrate the applicability of such technology to the eDIANA



scenario, according to the application requirements set in the Project. The results included in this Deliverable represent a starting point for the design of the network itself and for the setting of parameters. In fact, more suitable and detailed analysis will be included in the second Deliverable of this Task (D2.3-B), dealing with communication protocol specifications.

The inputs received from WP1 and WP2 and used as a starting point in Task 2.3, are taken from the following Deliverables or documents circulated within the Project:

- D2.1-B: in this document the reference architecture, the functionalities and the possible interfaces between the different elements of the platform, are identified. This is briefly summarised in Chapter 1. Note that D2.1-B was not completed at the time of the delivery of this document and possible variations could be introduced before the final delivery.

- Task 1.4 documents related to the “single-family house”, “apartment building” and “office building” scenarios. These scenarios have been defined within WP1 and are summarised in Chapter 1; then, they are taken into consideration in the whole document as a reference for the evaluation and design phases. Performance results, in fact, refer to such scenarios. Also, the applications described in those documents have been taken into consideration for the preparation of this Deliverable: Chapter 2 will classify those applications from the communication viewpoint; the different categories will differ for the kind of data transmitted among the elements of the platform. Note that at the time of the delivery of this Deliverable, Task 1.4 documents were not completed. Possible variations could be introduced before the final editing and included in D1.4-A.

- D1.1-A (“Baseline Analysis results”): in this document an overview of different wired and wireless technologies to be used in the platform is included. Some of these technologies (e.g., IEEE 802.15.4, Zigbee, PRIME, KNX, etc..) are reconsidered here and described in much more detail in Chapter 2, where other possible solutions are also introduced.

Apart from the subsequent Deliverable D2.3-B, the outputs of this Deliverable will be used as inputs for the following Tasks and Deliverables.

Chapter 1 reports a list of application requirements. These requirements have been discussed and defined within this Task and are mainly related to the geometry of the scenario and to performance the platform is expected to provide to the user. This list will be included in Deliverable D1.3-A.

Moreover, the content of this Deliverable will represent the starting point for WP3, dealing with the engineering of Cell level devices; in particular, Task 3.6, devoted to the engineering of the communication part of Cell level devices, will take this



Deliverable as an input. Hence, the decisions taken within this Task will indeed affect the content of D3.6-A and D3.6-B.

The rest of the Deliverable is organised as follows: Chapter 1 deals with the reference scenarios, applications and network architecture. Chapter 2 is devoted to wired and wireless interfaces, their comparison and their applicability to the eDIANA platform. Chapter 3 deals with the communication protocols of the most promising technologies identified in Chapter 2. Finally, Chapter 4 treats the network topologies, and different solutions, some numerical results achieved when IEEE 802.15.4 is applied for the realisation of energy efficient buildings are reported and discussed.

Regarding partners contribution, almost all partners contributed to the first three Chapters (1, 2 and 3), that are description Chapters, whereas UNIBO, UoR and Apptech also provided numerical results to be included in the core part of the Deliverable (i.e., Chapter 4).

In particular, UNIBO edited almost all the Deliverable and provided the simulation results on IEEE 802.15.4. UNIBO has developed a simulator modelling IEEE 802.15.4 networks distributed over apartment or office buildings. Different topologies are studied and compared and some results are reported in this document. The simulator will be also used in D2.3-B for optimising parameters and communication protocols, in order to satisfy system requirements.

UoR was involved in the editing of Chapter 3 and provided some experimental results achieved through a test-bed composed of IEEE 802.15.4 devices. Another test-bed has been set up by Apptech, and some numerical results extracted from it are included in Chapter 4. Apptech also contributed to Chapter 2.

Ikerlan and Fagor mainly contributed to Chapters 1 on the definition of requirements, 2 and 3 on wired technologies description. ZIV contributed to Chapter 2, 3 and 4 with the description of the PRIME powerline communication technology.

Infineon was involved in the definition of the network architecture contained in Chapter 1, and provided some information related to the Bluetooth technology. Quintor defined the ToC of Chapter 2 and produced a first draft. I&IMS provided the description of the communication protocols of their cameras. Finally, ED contributed to the definition of the application requirements contained in Chapter 1.



1. Reference Architecture Scenarios and System Requirements

This Chapter summarises the reference architecture and scenarios contained in the documents of Task 2.1 (D2.1-B) and Task 1.4 (“single-family house”, “apartment building” and “office building”), with the perspective of emphasising the role played by the communication part of the eDIANA platform. Starting from such inputs, a list of application requirements, related to the reference scenarios and performance metrics, are introduced and used as a reference in the rest of the document. Finally, the network architecture and the role of the different devices in the communication network, are identified.

1.1 Reference Architecture

The eDIANA platform is organised in two levels, the MacroCell and the Cell level, with a 1:N correspondence among MacroCell and Cells. The Cell is a domain including the collection of devices operating in the different scenarios (e.g., house, office, etc.), whereas the MacroCell domain includes one or more Cells. The MacroCell also manages the connection to the grid, and holds the "contract" with the utility.

In terms of supervision and control, the eDIANA platform envisages a hierarchical structure where the MacroCell owns the most sophisticated energy-efficiency control algorithms and can determine energy-saving actions from information gathered from one or more connected Cells plus all the building-specific physical phenomena. The Cell, on the other hand, has dynamic control on the devices attached to its concentrator (plug&play, discovery, etc.).

While the eDIANA platform describes a number of logical devices and functions, these can be physically implemented in a variety of forms, as there is no one-size-fits-all physical architecture for all the envisioned scenarios. If required (i.e., in cases of “single family house”, to ensure interest in this market sector) the MacroCell will coincide with the Cell.

As shown in the Figure 1, the eDIANA platform is composed of the following entities:

- Cell Device Concentrator (CDC): Entity collecting data from and controlling Cell energy related devices (loads, m-generators, storage, etc.), also informing end users and collecting user specific needs and preferences.

- MacroCell Concentrator (MCC): Entity dealing with CDCs, in charge of knowing in every moment what is connected, what consumption, where, etc., and to



send CDC commands to achieve optimum behaviour, and interacting with utilities, by exchanging data with them and executing energy-efficiency and optimum usage algorithms. The MCC also informs building administrators and collects group needs or preferences.

- Cell User Interface (CUI): Simple display used to show the user the current active loads, the comfort status, the overall consumption/generation, etc.. This CUI will be integrated in the CDC.

- Cell Monitoring and Metering (CMM): Indoor temperature sensors, relative humidity sensors, lighting sensors, people presence sensors, energy generation sensors, smart meters (plugged devices), etc..

- Cell Control and Actuation (CCA): Light dimming actuators, blind actuators, smart appliances, etc..

- Cell Generation and Storage (CGS): Also generation devices should provide information of both consumed and generated energy.

-

Figure 1: eDIANA reference architecture

We refer to D2.1-B for a more detailed description of the functionalities of the different elements of the platform.



1.2 Reference scenarios

In the following the three reference scenarios identified in Task 1.4 are summarised. We refer to the “single-family house”, “apartment building” and “office buildings” documents for more details.

1.2.1 Single family house

In this case only one Cell (the home) is present and the MacroCell coincides with the Cell itself (1:1 correspondence between MacroCell and Cell).

Each Cell will contain: activity and presence sensors (CMM), solar cells that generate energy (CGS), actuators (CCA) and the CUI.

Figure 2: Single family house

1.2.2 Apartment building

Each apartment has a MacroCell that controls the Cell. Only one Cell exists in each MacroCell (1:1 correspondence between MacroCell and Cell, N times).

The communal area of the building belongs to a MacroCell that is connected to the different MacroCells present in each apartment.



Figure 3: Apartment building

1.2.3 Office building

In this scenario there exists only one MacroCell, controlling different Cells (1:N correspondence among MacroCell and Cells). Each Cell will be a single working unit.

Figure 4: Office Building



1.3 Reference Applications and Services

The reference applications that must be provided by the eDIANA platform are described in D1.4-A, in relation to the three identified scenarios.

According to such description, applications and services can be classified depending on the kind of data transmitted in the network. Different data should have different requirements in terms of delay, quality of service, etc.

In particular the following two applications have been identified:

1) Monitoring Application: It gathers data coming from sensors. These data are related to power consumption or ambient information (temperature, humidity, radiance, CO2, etc.) and are used by the CDC&MCC to take decisions.

2) Controlling Application: It gathers data coming from/going to "controllable devices": intelligent plugs, domestic appliances, brown goods, HVAC, lights..., which will be the target of the CDC&MCC decisions.

The “checking the status of sensors” and “checking of the energy use” applications identified in Task 1.4 belong to the Monitoring Application class belong. Therefore, all the applications that refer to the monitoring of the status of the devices belong to this class.

On the opposite, for example, “turning off non essential equipment”, “turning on devices according to user requirement” or “activity based energy saving”, belong to the second class. Therefore, in these applications the CDC sends a command to a controllable devices.

From the communication viewpoint, applications could be distinguished according to the kind of traffic and the flow of data generated (transmission from which to which devices, etc).

In particular, we can identify the following three kinds of application:

1) Event-Driven (ED): It is an event that generates a data transmission. The event could be something happening in the environment (in this case the traffic generated is aperiodic) or a clock indicating to the node that a packet must be transmitted at a given instant (in this case a periodic traffic is generated by each node).

2) Query-Based (QB): It is a query sent by the CDC in general that generates data transmissions. Queries are transmitted periodically, therefore the traffic generated by nodes is periodic.



3) Command: It is a command sent by the CDC to specific devices.

Monitoring Application could be seen as ED or QB, depending on the design choice made. We could impose that the CDC periodically sends queries to the devices, asking for the current data, or devices could be programmed for periodically sending such data to the CDC, without any need of request. In the first case, devices will be synchronized by the query coming from the CDC and the traffic generated by nodes will be periodic and synchronous (among different devices). In the second case, a periodic and asynchronous traffic is generated by devices. In Table 1 the main applications identified are characterised from the communication viewpoint, taking into consideration the flow of data generated in the network and the kind of traffic generated by devices. Note that the second and the third row are both belonging to the Controlling Application case.

Applications

Kind of

Application Traffic generated Flow of the data

Monitoring Application QB / ED Periodic traffic

With a given frequency the CDC sends queries to devices and waits replies (in the QB case), or for the devices directly transmit the data measured, with a given periodicity (in the case of ED)

The CDC sends commands to the devices (e.g., turning off non essential equipment, turning on devices according to user requirement) Command Aperiodic traffic

From the CDC to the interested devices

Data coming from controllable devices (e.g., turning on electrical appliances by a person, activity based energy saving)

ED (first phase)

Command (second phase) Aperiodic traffic

From the device that has detected the event to the CDC, which afterwards sends a command to the interested devices

Table 1: eDIANA reference applications

A comparison of performance achieved in case of Monitoring Applications, when both the gathering strategies, QB and ED, are applied, is provided in Chapter 4 for IEEE 802.15.4.



1.4 System Requirements

In Table 2 the list of system requirements defined in Task 2.3 and used as a reference in this Deliverable, is reported. This list will be included in D1.3-A and has been already included in the RequisitePro web-site.

Requirement nameRequirement descriptionValue

Apartment (working unit) size

Maximum apartment (working unit) size (in m2)

120 m2

Number of floors Maximum number of floors in a building 10

Number of apartments

Maximum number of apartments (working units) per building 40

Number of rooms per apartment

Maximum number of rooms per apartment (working unit) 10

Geometry of the scenario

Number of Cell devices

Maximum number of Cell devices per room 10

Data size from devices

Maximum size (in bytes) of the payload of the data transmitted by Cell devices 50 bytes Devices

Cost of sensor devices

Maximum cost of sensor devices 15 euros (iEi)

Performance Requirements

Delay between Cell devices and sensors and CDC

The maximum delay of data transmission from the sensors to the CDC

Monitoring Application --> non stringent (1 minute) Controlling Application --> stringent (few seconds)



Delay between CDC and MCC

The maximum delay of data transmission between CDC and MCC

Monitoring Application --> non stringent Controlling Application--> stringent

Throughput

Maximum number of bits/sec the network should be able to provide to the CDC

Monitoring Application --> non stringent Controlling Application --> stringent

Packet error rate (PER)

Maximum tolerable percentage of packets lost (owing to connectivity of MAC issues)

Monitoring Application --> non stringen Controlling Application --> stringent

Lifetime Minimum duration of the battery of sensor devices

1 year at a temperature of 20 degrees

Update frequency of devices data

Minimum frequency with which devices have to transmit their data to the CDC

1 minute between two successive queries from the CDC

Application

Offered Throughput

The maximum throughput (in bits/sec) offered by devices in the network toward the CDC

Monitoring Application --> large Controlling Application --> low

Table 2: System requirements

The first category of system requirements refers to the geometry of the scenario. Obviously the eDIANA platform will be installed in whatever building with whatever number of devices, rooms, floors, size, etc.. However, from the design viewpoint some limits have to be set. The other categories define requirements for the devices, communication links and network, and applications.



This Task (through this and the following Deliverable, D2.3-B) will provide guidelines for designing the communication network, achieving performance in agreement with those requirements. This means that, for example, the network will provide a Packet Error Rate (PER) in accordance with the requirement set, in case less than 10 devices per room will be distributed. In case, on the contrary, more than 10 devices are deployed, the PER could also increase and could not respect the requirement.

Note that performance requirements are more stringent for Controlling Application, with respect to Monitoring Application. In the latter case, in fact, it is important that the command coming from the CDC is received by the target device with large probability (PER near to zero) and with low delay (in the order of few seconds). In the case of monitoring, on the contrary, the application may tolerate some packet losses (the status will be updated at the following session, without causing serious problems at application layer) and with larger delays (in the order of minutes).

Finally, note that the constraint on the network lifetime is mainly related to devices that are not equipped with the intelligent Embedded interface (iEi), that is, devices not plugged. For those that are plugged to the electrical grid, in fact, the energy consumption issue is less stringent.

1.5 Network Architecture

The network architecture of the eDIANA platform includes the eDIANA devices and the eDIANA communication network. The latter, is divided into two parts: the intra-Cell network, that allows communication among devices within each Cell, and the inter-Cell network, that allows communication between the different Cells and the MacroCell.

The eDIANA network architecture is based on standards regarding the interfaces among devices, interfaces between the Cell and the MacroCell and its interfaces to the external environment. The networking standards used are considered on a requirement driven basis.

According to the applications described above, eDIANA devices must be able to reliably and securely communicate their data to the CDC, that will gather and process such data and send them to the MCC, connected to the external world. Considering the several environments and conditions where eDIANA network architecture elements will be implemented, there is no one-fits-all solution. Different hardware interfaces are used to inter-connect components and to interact with the external environment.

As shown in Figure 1, the MCC communicates with the external environment through two hardware interfaces:



1) Internet Interface (WWWi);

2) Power Grid Interface (PwGRIDi).

The former allows access to the eDIANA platform from internet. The physical interfaces expected to be used are:

1) IEEE®802.3, wired Ethernet;

2) IEEE®802.11, Wi-Fi.

PwGRIDi allows communication between MacroCell and utilities. The physical interfaces expected to be used are based on PLC (Powerline Communication) technologies.

The interface allowing the communication between the MCC and the Cell or the different Cells controlled by the same MCC (denoted as c2CMCi in Figure 1), could be:

1) IEEE®802.3, wired Ethernet;

2) IEEE®802.11, Wi-Fi;

3) PLC;

4) Software direct interface if MCC and CDC are on the same device.

Finally, the CDC will communicate with eDIANA devices (CMM, CAA, CGS) through the interface denoted as iEi. This interface consists of a PCS (Power Consumption Sensor) and an interface which connects to the CDC. Each iEi is able to acquire data from sensors and transmit the information to the CDC.

In case the device will be simply a sensor monitoring the environment, like a sensor of temperature, humidity, lighting, etc., the PCS will be not included in the iEi and the iEi will simply coincides with the interface used by the sensor to communicate the data to the CDC.

In this Deliverable we will mainly focus the attention on the definition of the interfaces for the iEi toward the CDC. Different standard interfaces will be analysed and compared. Both the options of using wireless and wired solutions will be considered.

The interface between the CUI and the CDC is not taken into account since, in general, the CUI will be directly integrated into the CDC.



In the following, the network architecture elements, that are the eDIANA devices, the intra-Cell and the inter-Cell networks, are briefly described.

1.5.1 eDIANA devices

The eDIANA devices are the CMM, the CAA and CGS devices. These devices could be equipped with the iEi, or could be simple sensors used for the environmental monitoring. In the first case, the device will be plugged in, since it will contain the PCS connected to the grid, whereas in the second case the device will be battery-charged and will not contain the PCS. Note that the energy consumption issue will be fundamental for the latter devices.

For the sake of simplicity, in the rest of the document we will simply denote as “device” each component that is distributed in the Cells that has to transmit and receive data to/from the CDC. Therefore, we will denote the CMM, CAA and CGS devices simply as “devices” (or “Cell level devices”).

From the network architecture viewpoint, the devices could act as:

- End Devices: They simply generate their data and transmit them toward the CDC directly, or passing through different Routers, if needed.

- Routers: They generate their data and transmit them toward the CDC, but they also act as routers, forwarding the data received from other routers, or end devices, toward the CDC.

Owing to the sake of energy efficiency for devices that are battery-charged, we must impose that these devices cannot act as Routers. Routers, in fact, because of their role of data forwarders, will consume much more energy. To solve such problem, we have to impose that only devices plugged in can act as Routers.

1.5.2 eDIANA intra-Cell network

The eDIANA intra-Cell network provides connectivity between eDIANA devices and the CDC. The CDC will act in the architecture as a concentrator of the data coming from eDIANA devices and will also act as gateway between the network inside the Cell and the one outside the Cell, that is toward the MCC (inter-Cell network described below).

Examples of technologies to be used in such network, that will be analysed in Chapter 2, are IEEE 802.15.4/Zigbee, Bluetooth Low Energy (BT LE) and PLCs.



1.5.3 eDIANA inter-Cell network

The eDIANA inter-Cell network provides connectivity between eDIANA CDCs (gateways of the architecture) and the MCC. In case more CDCs must be connected to the same MCC, it may happen that the CDC has to act as Router within the inter-Cell network, forwarding the data received by a CDC towards the MCC.

Examples of technologies to be used in such context are 802.11 (Wi-Fi), PLC and Ethernet.



2. Wireless and Wired Standard Interfaces

In this Chapter an overview of the possible wired and wireless technologies, to be used in the two cases of intra- and inter-Cell networks, are treated, with specific attention to the existence of standard technologies, and availability of devices on the market.

As stated in Chapter 1, even though both wireless and wired solutions could be used in both networks, wired links are more suitable in the inter-Cell case, whereas wireless solutions are a better option in the intra-Cell network.

The first part of the Chapter is devoted to wired technologies considering both standard and proprietary solutions, whereas the second part contains an overview of wireless standards. The latter part starts with a brief description of the IEEE 802.11 technology: this air interface could be used to connect the CDC to the MCC (inter-Cell network), but it does not represent an interested option for the intra-Cell communication. The description is included also because in Chapter 4 some studies on the interference caused by Wi-Fi over IEEE 802.15.4 networks, is provided.

The rest of the Chapter deals with a summary of the most suitable wireless technologies for the intra-Cell network, which are mainly IEEE 802.15.4 and Bluetooth Low Energy. A Comparison between these technologies is also provided. Then, the Chapter ends with some considerations about the applicability of the different technologies (both wired and wireless) to the eDIANA scenario, and some guidelines for the choice of the best solutions.

2.1 Identification of wired techniques

PowerLine Communications is a technology that uses existing electrical distribution lines, whether in-building (i.e., in-home) or out in the utility distribution system (i.e., access), for delivering communication services. In order to ensure a suited coexistence and separation between the power and communication signals, the frequency range used for communication is very far from the one used for power waves (50 Hz in Europe).

In particular, there exist low-speed and also high-speed solutions, respectively working on the [3–148.5] kHz band and the [1–30] MHz band. High-speed powerline systems operate with data rates up to 200 Mbps, which allow the transmission of several high-definition video channels. MAC protocols are also designed in order to guarantee the required Quality of Service (QoS) for multimedia contents. The types of service that can be provided using this kind of PLCs include in-premise multimedia services, broadband Internet services, telephony (Voice over Internet Protocol or “VoIP”), video services, and utility monitoring services. High data rates are achieved



through the use of Orthogonal Frequency Division Multiplexing (OFDM) techniques at the physical layer of the protocol stack, which divide the information to be transferred in several mutually orthogonal subcarriers. The primary advantage of OFDM over single-carrier schemes is its ability to cope with severe channel conditions without complex additional mechanisms. Channel equalization is simplified because OFDM may be viewed as using many slowly-modulated narrowband signals rather than one rapidly-modulated wideband signal. Additionally, OFDM makes use of a guard interval (or cyclic prefix) between symbols, making it possible to counteract time dispersion of the medium and to eliminate Inter-Symbol Interference (ISI).

Figure 5. Frequency occupation a) Conventional multi-carrier system b) OFDM

On the other hand, the powerline distribution network is a hostile environment for data transmission, as its signal propagation characteristics change drastically along time. Therefore, high-speed systems also include powerful adaptive coding and error correction methods in order to overcome this effect.

Currently, several industrial consortiums are involved in the use and promotion of high-speed powerline communications, despite some low-cost and low-complexity PLC solutions are also available.

In the following, a summary of some standard and proprietary solutions for both high-speed and low-speed PLCs are reported in the following, including also other wired standards like Universal Serial Bus (USB) and FireWire.



2.1.1 Standard Solutions

2.1.1.1 ITU G.hn

HomeGrid Forum (www.homegridforum.org) is a non-profit organization focused on the standardization process of G.hn by ITU (International Telecommunication Union) for the next generation of connectivity devices for the home environment. This standard covers Physical (PHY) and Medium Access Control (MAC) layers for three transmission media, namely coaxial cable, phone line and power-supply lines, and allows the deployment of a wide range of interoperable products. This standard defines an high-speed PLC.

It is foreseen that specific parameters can be optimized for each medium. In particular, in case of PL, which is a very demanding and noisy medium, the following techniques are implemented:

- Forward Error Correction (FEC): Low-Density Parity-Check (LDPC) codes are used, allowing the recovery in reception of corrupted bits. LDPC decoders are easy to implement at high data rates.

- Selective Automatic Repeat Request (ARQ): This allows the retransmission of data-frames affected by errors.

- Synchronization with the Alternating Current (AC) cycle: Noise in powerline systems is often synchronous with the AC frequency. The standard can use this information to predict the noise and schedule the transmissions accordingly.

Regarding MAC, G.hn is based on a master/slave Time Division Multiple Access (TDMA) architecture, in which a central device ("the domain master") allocates channel access to other "slave" nodes in a predictable manner. Slave nodes can request specific bandwidth allocations to the domain master, which can be implemented by assigning exclusive "contention-free" time slots to each slave. With this mechanism, G.hn can provide guaranteed bandwidth and latency to applications that have strict QoS requirements, such as Internet Protocol TeleVision (IPTV), Voice over Internet Protocol (VoIP) or on-line gaming.

Moreover, some additional features can be considered:

- Regarding network topologies, G.hn includes the possibility of extending the range of the network by message repetition, e.g., an intermediate node can send the data from a source node to a destination node.



- G.hn includes mechanisms that allow devices to go into "sleep state" in order to reduce energy consumption and to quickly get back to "active state" as soon as a device needs to send data.

- G.hn uses also Advanced Encryption Standard (AES)-128 as encryption algorithm and ITU Recommendation X.1035 as the protocol for authentication and key exchange.

Among the most significant members of this organization there are consumer-electronics companies, such as Intel, Panasonic and Infineon, and also companies specialized in PLC communications, such as DS2. The standard has been in development since 2006. On May 2009, a new draft of the G.hn Recommendation was approved. Sample quantities of G.hn-compatible chips are expected for the second half of 2010.

2.1.1.2 IEEE P1901

IEEE P1901 Group (http://grouper.ieee.org/groups/1901/), formed in June 2005, is working towards a standard for high-speed PLC, also called Broadband over PowerLine (BPL). This standard aims at covering several BPL devices, such as the ones used for broadband services on the first-mile/last-mile connection (< 1500 m), or the ones used inside buildings for Local Area Networks (LANs) (< 100 m between devices).

The standard will use transmission frequencies below 100 MHz, and its specification will be limited to PHY and MAC. In particular, it defines two PHY options. The first option, called "FFT PHY" is based on Fast Fourier Transform (FFT) OFDM modulation, with a FEC scheme based on Convolutional Turbo Codes (CTC). The second option, "Wavelet PHY", is based on Wavelet OFDM modulation, with a mandatory FEC based on concatenated Reed-Solomon (RS) and Convolutional codes, and an option to use LDPC code. P1901 also defines two different MAC layers, respectively designed to operate on top of the FFT PHY and the Wavelet PHY.

The main purpose of this standard is to offer a minimum implementation allowing the coexistence of different BPL devices. Nevertheless, a full implementation will provide interoperability between the BPL devices with other protocols. The focus is also on robustness, as this is a major issue in order to allow the massive deployment of powerline systems. EMC regulations will also be taken into account, in order to ensure the coexistence of the standard with other wireless and telecommunication systems. The standard will also address the necessary security issues to ensure the privacy of communications among users and allow the use of BPL for security-sensitive services.



The IEEE P1901 Group has more than 50 members, including corporations, government agencies, trade associations, universities, and standards developing organizations. The standard is currently under development. The P1901 baseline was approved on December 2008. On February 2009 a tentative table of contents of the Draft Standard was adopted and four Technical Subgroups were formed to merge the confirmed proposals and develop a unified document.

2.1.1.3 KNX

In 1999, nine electric equipment companies signed a collaboration agreement which was the starting point of the KONNEX Alliance. The KNX standard (http://www.knx.org/) brings together the previous works of three European associations (EIBA, BCI and EHSA) with the goal of joining the efforts of all the domotic system manufacturers in the European market, and the definition of a single European standard for home and office automation. This standard is about a low-speed PLC.

In June 2003, KNX became a European standard with the approval of CENELEC (European Committee for Electrotechnical Standardization), and is defined in a EN-50090 series of rule about: KNX application interface layer, application layer, network, transport and link layers, management procedures and specifications for the case of twisted pair media.

Version 1.0 of the standard has been recently finalized, showing the best of European Installation Bus (EIB), European Home System (EHS) and BatiBUS. More specifically, KNX is based on the EIB technology, and expands its functionalities adding new physical media to this standard and the configuration modes of BatiBUS and EHS. Currently, KNX is the only world-open standard for home and building control.

KNX is an application level standard which can be carried or implemented over different communication media, namely twisted pair, with two options based on its reference buses TP1 (9600 bps), making use of the equivalent EIB specifications, and TP0 (2400 bps), based on the BatiBUS specification using Carrier Sense Multiple Access with Collision Detection (CSMA/CD); powerline communications, also with two specifications PL110 (1200 bps), based on the equivalent EIB specification, and PL132 (2400 bps), based on EHS, and using carriers at 110 and 132 kHz, and Ethernet, based on the equivalent EHS and EIB.net rules.

Apart from specific media, KNX has solutions in order to integrate other technologies with IP support, such as Bluetooth, Wi-Fi/WLAN, FireWire (IEEE1394). The possibility of using different communication media allows installers to adapt the network to the conditions of the building and the required functions, increasing the likelihood of



satisfying the technical specifications and monetary constraints established by the users. The most common implementation, however, is the use of twisted pair, ad-hoc deployed.

About KNX specifications, KNX defines three configuration modes, which can be selected according to the installer’s level of competence (see Figure 6):

- S-Mode (System mode): This configuration follows the same philosophy of current EIB. Each device and node must be configured by an installer using a PC application. The installer needs specific formation and must make use of configuration tools.

- E-Mode (Easy mode): The devices are configured in production in order to achieve a specific task. However, the final functionality is tweaked using microswitches or through the residential gateway. This kind of devices supports different configuration modes.

- A-Mode (Automatic Mode): The automatic configuration follows a plug&play philosophy, that is, neither the installer nor the user have to configure the device. This is exactly the same behaviour of many consumer electronics products, as they allow a quick and easy installation, avoiding the final user to read complicated manuals.

Figure 6: KNX configuration modes (http://www.knx.org/)

About compatibility, KNX is based on the EIB core protocol stack, being compatible with the previously installed EIB products. Furthermore, the KNX A-mode is compatible with the EHS 1.3a standard, being feasible a transition from EIB products



to KNX devices. However no compatibility exists with the existing BatiBUS installations.

Finally, the feasibility of interacting with other networks is one of the main features of KNX from the point of view of installer and final user. ANubis (Advanced Network for Unified Building Integration & Services) is a coherent combination of protocols, programming interfaces, models and tools that the manufacturer or integrator/installer can use in order to develop the applications for enabling a KNX network in a Wide Area Network (WAN) or LAN environment.

Summing up, the main advantages of KNX are the following:

- Certification: The KNX/EIB certification guarantees a high level of product quality and interoperability.

- Interoperability: Between different products and different applications of different manufacturers.

- Product quality: The Association surveys regularly the production sites of the manufacturers.

- Standardised functionality: Profiles of Home & Building applications are integrated in the Standard.

2.1.1.4 PRIME

PRIME (Powerline Related Intelligent Metering Evolution) Alliance (http://www.prime-alliance.org/) was founded in 2009 by 8 members coming from industry and particularly manufacturers and utilities. The main target of PRIME Alliance is a new public, open and non-proprietary telecommunications architecture oriented to new Automatic Meter Management (AMM) functionalities and the electricity networks of the future, the so-called Smart Grids.

The main features of the architecture model are the following [1]. It is based on OFDM powerline communications, in the CENELEC-A band. The system is designed to reach raw transmission rates up to 130 kbps, using three different modulation schemes, with variable characteristics of robustness and performance, thus capable of transmitting and receiving data even over low quality physical links. It is a public, open and non-proprietary architecture, not depending on intellectual property rights and its focus is interoperability among equipments and systems from different manufacturers. Moreover, it defines the two lower layers of a PLC narrowband data transmission system over the electric grid, putting the focus on high performance and robustness of the system, and low cost devices.



The reference model is based on IEEE 802.16 [2] protocol layering, and the design is also based on IEC 61334 [3] and IEEE 802.15.4 [4] standards, with specific improvements and modifications to fit into the targeted physical environment.

The PRIME architecture involves three protocol layers, namely PHY, MAC and several Convergence Layers. PHY layer transmits and receives frames between neighbour PRIME nodes. MAC layer provides core MAC functionalities, as system access, bandwidth allocation, connection establishment and maintenance, and topology resolution. The Service Specific Convergence Layers classify traffic associating it with its proper MAC connection. It may also include payload header suppression functions. Various Convergence Layers are defined in order to accommodate different types of traffic on MAC frames.

PRIME system is composed of sub-networks, where each of them is a tree with two types of node, the Base Node and the Service Nodes. It is at the root of the tree and acts as a master node providing connectivity to the sub-network. It manages sub-network resources and connections. There is only one Base Node in a sub-network. It is initially the sub-network itself, and other nodes should follow a process of registering in order to enroll them to this sub-network. Any other node of the sub-network is a Service Node. Service Nodes are either leaves or branch points of the tree. These nodes start in a disconnected state and follow certain procedures to establish network connectivity. Each of these nodes is one point of the sub-network mesh. These nodes have two responsibilities: connecting themselves to the sub-network and switching the data of their neighbours in order to propagate connectivity. Service Nodes change their behaviour dynamically from “Terminal” functions to “Switch” functions and vice-versa. Changes of functional state occur based on certain predefined events in the network. The three functional states of a Service Node are:

1) Disconnected: Service Nodes start in a disconnected state. In this state a node is not capable of communicating or switching the traffic of another node. The primary function of a Service Node in this state is to search for an operational network in its proximity and to try to register itself to it.

2) Terminal: In this state a Service Node is capable of communicating its traffic by establishing connections, but is not capable of switching the traffic of any other node.

3) Switch: In this state a Service Node is capable of performing all Terminal functions. Additionally, it is capable of forwarding data to and from other devices in the sub-network. It is a branch point in the tree.

The PRIME Alliance is composed of members from the industry (ADD, Landis & Gyr, ZIV, Current, ST, Texas Instruments) and utilities (Iberdrola). At this time, some of the manufacturers have developed PRIME nodes, and the integration of the PHY and



MAC into a single chip is about to be finished. Here is a web link to the PRIME Alliance site: www.prime-alliance.org, for further reference.

2.1.1.5 Comparison between the different wired standard technologies

Table 3 summarizes the differences between the wired standard technologies discussed above.

Technology ITU G.hn IEEE P1901 KNX PRIME

Physical medium

Coaxial cable

Phone line

Grid (powerline)

Grid (powerline)

Twisted Pair

Grid (powerline)

Ethernet

Infrared

Wireless

Grid (powerline)

Transmission rates

Up to 843.75 Mbps (coaxial)

> 100 Mbps 2400 bps / 9600 bps (twisted pair)

1200 bps / 2400 bps (powerline)

10/100 Mbps (Ethernet)

From 21.4 to 128.6 kbps (raw, depending on the selected modulation schema)

Scope Home environment

Last-mile connection and inside buildings

Industrial Last-mile connection and inside buildings

Supporting organization

HomeGrid Forum

KNX Association PRIME Alliance

Licensing No No Free (no royalties) No

Standard ITU G.hn (under development)

IEEE 1901 EN 50090

ISO/IEC 14543

EN 50065,

IEC 61334,

IEEE 802.15.4, IEEE 802.16



Certification process

Compulsory KNX / EIB certification

Specification of OSI layers

PHY, MAC PHY, MAC EN-50090 series: PHY (twisted pair media); management procedures; network, transport and link layers; application layer; application interface layer

PHY, MAC, Several Convergence Layers (Ipv4, IEC 61334-4-32)

Application profiles

Yes No Yes (integrated in the standard)

No

Product portfolio

None None Slight shortage of products

Slight shortage of products, under development

Costs

~17 €/chip ~19 €/chip ~3 €/chip 4-6 €/chip

Base Node: 450 € approx.

Service Node: 95 € approx. (*)

Interfaces toward the host

-

-

UART,

Ethernet.

UART,

Ethernet (**)

Table 3: Comparison between wired standard solutions

(*) Prices by unit. Estimation done for a proportion of 1 Base Node / 10 Service Nodes, given the fact that the MCC should include one Base Node and each of CDC should include its own Service Node, as shown in the section related to topology.

(**) The interface between the modem PRIME itself and the device host. PRIME modem is expected to be a physically separated device at the first stage of the network development and deployment, but there is also the possibility of having built in PRIME devices, sharing the same packaging as the host device.



2.1.2 Proprietary Interfaces

2.1.2.1 Universal Powerline Association (UPA)

Universal Powerline Association (www.upaplc.org) is an international non-profit trade association working to harmonize global standards and regulations in the powerline communication market. It includes companies such as Schneider Electric, Ambient, Corinex, Current, DS2, EDF, Toyo Networks systems and Sumitomo Electric. It has two technology proposals:

- OPERA: It allows 200 Mbps transmission in powerline access, with guaranteed QoS. This specification comes from the IST OPERA project (www.ist-opera.org), and has been implemented by DS2.

- DHS: It provides 200 Mbps in-home communications, and pre-certified products are available. This generation is commonly known as PLC-2G.

Applications of this technology include medium voltage transport networks, last-mile low-voltage access distribution networks, in-building distribution networks, in-home multimedia networks, utility applications and automatic meter reading, automation, energy management, surveillance, etc..

2.1.2.2 HomePlug

HomePlug (www.homeplug.org) is an industry organization with the aim of creating technology proposals for powerline communications. Main contributors in HomePlug are Intel, Intellon, Sony and Current. The technology proposals of this association focus on in-home applications, and are the following ones:

- 1.0: It provides 14 Mbps with low QoS. This is the most extended technology for in-home PLC.

- Turbo: It provides 85 Mbps. This technology is used for in-home data and low-definition video transmissions.

- AV: It provides 200 Mbps with high QoS, and is used in domestic products for data and video transmissions.

- Command & Control: It's a low-speed, very low-cost technology intended to complement the alliance's higher-speed powerline communication technologies.

These proposals work in a frequency range from 2 MHz to 28 MHz, using OFDM with advanced FEC, channel estimation and adaptation. Recently, new specifications have



been published for infrastructure access and automation control. The technology providers are Intellon, Conexant and Arkados.

2.1.2.3 CEPCA

CEPCA (Consumer Electronics Powerline Communication Alliance: www.cepca.org) is an industrial association, mainly focused on the Asian market, which includes several consumer-electronics manufacturers, such as Mitsubishi, Panasonic and Sony. CEPCA promotes, together with UPA, a standard which allows the coexistence between the different technology proposals. Panasonic, main member of CEPCA, has presented an in-home solution with similar data-rate to HomePlug.

2.1.2.4 X-10

X-10 is a technology originally developed by Pico Electronics in Glenrothes (Scotland) in the mid 70s, with the goal of transmitting data through the low tension electric network at very low speed (60 bps in the USA and 50 bps in Europe) at low cost (www.x-10europe.com). It is one of the oldest protocols used in domotic applications. Originally developed only for powerline, X-10 currently supports radio-frequency as physical media.

The X-10 protocol is not proprietary itself, that is, any manufacturer can produce X-10 devices and offer them in its catalogue, but is forced to use the circuits of the Scottish manufacturer which designed this technology. X-10 products are especially attractive because of their price, maturity and performance. This technology has an important penetration in the residential market in America and Europe. On the other hand, it is a technology that allows quick installations without great automation knowledge.

Currently, three families of X-10 based products can be found in Europe, theoretically compatible among them: HomeSystems, Netzbus and Timac. However, X-10 is a technology which depends on the frequency of the electric signal, thus, devices designed for the American market are usually not compatible with European installations.

The X-10 protocol uses a relatively simple modulation, compared with the ones employed by other powerline control protocols: the X-10 transceiver is aware of the moment when the 50 Hz alternating current sinusoidal signal reaches a null power value. Immediately after this, a 1 ms burst is inserted, at a fixed frequency of 120 KHz and 0.5 W. The line codification uses two zeroes of the electric signal in order to send either a “1” or a “0”, and the signal is sent with redundancy (the bits are repeated) in order to guarantee the reception. A binary “1” is represented by a 120



kHz burst, and a binary “0”, is represented by the absence of this burst. Thus, in each full cycle of the electrical signal only a bit is sent, resulting in a binary speed of 50 bps. However, in a triphasic system, the 1 ms pulse is transmitted three times so it coincides with the zeroes of the three phases. Thus, the bit time coincides with the 20 ms of the signal cycle, so the 50 bps binary speed is imposed by the European network frequency, while in the USA it is 60 bps, since synchronizing the frame with the network frequency avoids increasing the complexity of the protocol.

About devices there are four kinds: those which can only send orders, those which can only receive, those which can simultaneously send and receive, and the wireless-compatible devices, called transmitters, receivers, 2-way transmitters/receivers, and wireless compatible, respectively. Each X-10 receiver is identified by a double code: a “home” identifier (letters from A to P) and a device identifier (numbers from 1 to 16), using two small knobs. Thus, the transmitters can address up to 256 receivers.

The portfolio of existing X-10 products includes most of the devices in the traditional residential market: switches, dimmers, touch panels, etc., and all kind of sensors and alarms.

The main advantages of the X-10 technology are:

- Cost effective designs and engineering;

- High quality, low cost manufacture;

- Rapid time-to-market.

From the end user’s point of vie, the advantages are the ease of installation, scalability, interoperability and the absence of additional installation.

2.1.2.5 LonWorks

LonWorks is a home automation technology introduced in 1992 by Echelon (www.echelon.com). It is a distributed, very robust and reliable technology, which comes from industrial automation world. LonWorks devices can communicate through several physical media, such as twisted pair, powerline, radiofrequency, fiber optics or infrared. In case of powerline, LonWorks transceivers are narrowband (low-speed) and support FEC techniques.

LonWorks technology is based on a Neuron Chip microcontroller, on LonTalk protocol, and on the control standard ANSI/EIA 709.1. In general each LonWorks node is composed of a transceiver, a Neuron Chip, ADC converters and sensors and/or actuators.



Channel Type

Medium Bit Rate Compatible Transceivers

Maximum Devices

Maximum Distance

TP/FT-10 Twisted pair, free or bus topology, opt. link power

78 kbps FTT-10,

FTT-10A,

LPT-10

64-128 500 m (free topology)

2200 m (bus topology)

TP/XF-1250 Twisted pair, bus topology

1.25 Mbps TPT/XF-1250 64 125 m

PL-20 Powerline 5.4 kbps PLT-20, PLT-21, PLT-22

Environment Dependent

Environment Dependent

IP-10 LonWorks over IP

Determined by IP network




Table 4: LonWorks physical media

Neuron is a system-on-a-chip developed by Echelon in 1990, whose production is made by Cypress Semiconductor, Motorola and Toshiba under agreement. It includes an operating system and an implementation of the LonWorks protocol in the Read Only Memory (ROM). Each Neuron chip gets a unique 48-bit address during manufacturing. Its structure is depicted in Figure 7.

Figure 7: Neuron chip (www.echelon.com)

Lontalk is the communication protocol of the LonWorks devices. This protocol implements all the levels of the OSI model. It is a Peer to Peer (P2P) protocol



adapted to a control systems and is integrated in the firmware of each Neuron. Neuron Chips communicate among themselves sending frames that contain target address, routing information, control and application data, and Cyclic Redundancy Check (CRC). The data exchange begins in a Neuron Chip, and only the nodes included in the same domain can exchange packets.

The MAC layer uses a variant of Carrier Sense Multiple Access (CSMA) called predictive p-persistent CSMA. When a collision is detected, each node tries to repeat the transmission after a random period of time but, as opposed to CSMA/CD, this period is adjusted dynamically on each device based on an estimation of the network load for that specific device. This access method shows excellent performance even in periods of high load in the network.

The LonTalk protocol implements a Network Variable (NV) system. Network variable is any element that the application program expects to receive from other devices or to make available to other system devices. To guarantee a real interoperability among devices, it is necessary that devices interpret in the same way all NVs. It should be noted that LonTalk can also be integrated with other network standards based on IP. This way, data and control networks can be integrated.

The LonMark Interoperability Association (www.lonmark.org), founded in 1994 and currently having more than 200 members, including manufacturers, distributors and developers, guarantees the interoperability among LonWorks devices.

Due to cost issues, LonWorks has not been massively deployed in Europe, specially due to the existence of similar cheaper technologies, such as X-10.

2.1.2.6 FAGOR Home Automation Protocol

FAGOR Electrodomésticos manufactures a range of home appliances and peripheral devices which communicate through the In-home electrical network using the proprietary FAGOR Home Automation Protocol (www.fagor.com).

FAGOR’s network consists of the following elements: a central node, which gathers all the information provided by the different nodes, home appliance nodes linked to the central node, where appliances include oven, washing machine, refrigerator, boiler and cooking-top, power and motor actuators, like light controls, electrical radiators, watering systems, etc., which can either work independently, linked among them by user indication, or linked with the central node, and gas/water sensors, which can either be linked to the central node or to their own shut-off actuators.

Several functional features are provided by this home automation protocol, such as security management, like between the water/gas detectors and their shut-off



actuator, communications management, for remote control of appliances and alarm transmission, or energy management. The energy management function allows for a rational use of energy by the following strategies: power or priority management, that is switching the loads of the network not to go over the total contracted power, programming of the start/stop and operation mode of appliances, management of the operation hours of the appliances, in order to take benefit from off-peak/low-price periods. This protocol uses 2400 bps PLCs with Frequency Shift Keying (FSK) modulation.

2.1.3 Other wired technologies

There are many other wired network technologies, which allow transferring information from one device to another, through wires. We present here two technologies which are currently relevant, especially in computer-centric scenarios, but which are not very often found on embedded devices. The first one is the USB standard, which was designed to replace the standards mentioned in the first sub-section. The second technology is FireWire, or IEEE 1394, which was designed for high throughput required by digital video or aeronautics applications.

2.1.3.1 USB

USB, first introduced in 1996 offering data transfer rate of 12 Mbps, was designed for personal computers, but has become commonplace on other devices such as PDAs and video game consoles. USB 2.0, standardized in 2001, offers 480 Mbps data rates, while USB 3.0, since 2008, promises 4 Gbps.

A USB system has an asymmetric design, consisting of a host and multiple peripheral devices connected in a tiered-star topology, allowing branching into a tree structure up to a maximum of 127 devices. Sharing hubs also permit sharing devices among several hosts. The host controller directs traffic flow to devices, so no USB 2.0 device can transfer any data on the bus without an explicit request from the host controller. In USB 2.0, the host controller polls the bus for traffic, and the slowest device connected to a controller sets the speed of the interface. For USB 3.0, connected devices can request service from the host.

The maximum length of a standard USB cable (for USB 2.0 or earlier) is 5 meters. Using hubs, the maximum distance between host and device is 30 meters. Optical fiber cable designs, likely to have a much longer maximum allowable length, are not known to be under development (http://en.wikipedia.org/wiki/Universal_Serial_Bus).



2.1.3.2 FireWire

The IEEE 1394 interface, initiated in 1986 and standardized in 1995, is a serial bus interface standard for high-speed communications and isochronous real-time data transfer, frequently used by personal computers, as well as in digital audio, digital video, automotive, and aeronautics applications. It is most commonly known under the brand name of FireWire and it is available in optical fiber and coaxial versions.

FireWire can connect up to 63 peripherals in a tree chain topology, and allows peer-to-peer device communication. It is designed to support plug&play and hot swapping. Its six-circuit or nine-circuit variations can supply up to 45 Watts of power per port at up to 30 volts, allowing moderate-consumption devices to operate without a separate power supply.

The original release of IEEE 1394-1995 specified what is now known as FireWire 400, offering transfer data rates at 100, 200, or 400 Mbps. Cable length is limited to 4.5 meters, although up to 16 cables can be daisy chained using active repeaters; external hubs, or internal hubs are often present in FireWire equipment. The S400 standard limits any maximum cable length to 72 meters. The IEEE 1394b-2002 is backwards compatible to the slower rates of FireWire 400, and supports data rates up to 3200 Mbps over beta-mode or optical connections up to 100 meters in length. S1600 and S3200 modes, will offer 1.6 Gbps and 3.2 Gbps rates, being compatible with S400 and S800 devices, and will compete with the new USB 3.0 (http://en.wikipedia.org/wiki/FireWire).

An interesting extension, provided by IEEE 1394c-2006, offers a port specification that provides 800 Mbps over 8P8C (RJ-45) connectors with Category 5e cable (standard Ethernet hardware), along with a corresponding automatic negotiation that allows the same port to connect to either IEEE Std 1394 or IEEE 802.3 (Ethernet) devices. Though the potential for a combined Ethernet and FireWire RJ45 port is intriguing, as since November 2008, there are no products or chipsets which include this capability.

2.1.3.3 Comparison between USB and FireWire

USB was designed for simplicity and low cost, while FireWire was designed for high performance, particularly in time-sensitive applications such as audio and video. The most significant technical differences between USB and FireWire include the following:

− USB networks use a tiered-star topology, while FireWire networks use a tree topology.



− USB 1.0, 1.1 and 2.0 use a "speak-when-spoken-to" protocol; peripherals cannot communicate with the host unless the host specifically requests communication. USB 3.0 is planned to allow for device-initiated communications towards the host (see USB 3.0 below). A FireWire device can communicate with any other node at any time, subject to network conditions.

− A USB network relies on a single host at the top of the tree to control the network. In a FireWire network, any capable node can control the network.

− USB runs with a 5 V powerline, while Firewire can supply up to 30 V. USB ports can provide up to 500 mA of current (2.5 Watts of power), while FireWire can in theory supply up to 60 Watts of power, although 10 to 20 Watts is more typical.

2.2 Identification of wireless techniques and standards

2.2.1 Wi-Fi

Wi-Fi indicates a set of standards unified in IEEE 802.11 used to allow computer communication using the wireless channel on frequencies from 2.4 GHz up to 5GHz depending on the adopted version, as reported in Table 5 [5].

Name Frequencies Data transfer speed

802.11a 5.1 – 5.8 GHz Up to 54 Mbps

802.11b 2.4 – 2.473 GHz in USA 2.4 – 2.485 GHz Asia-Europe

Up to 11 Mbps

802.11g Same as 802.11b Up to 54 Mbps

Table 5: Main versions of 802.11

Wireless stations (PCs, laptops, mobile phones) can access the wireless medium after the association with an Access Point (AP), responsible of managing the access to the medium. The protocol adopted for this purpose is Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) (see below).

2.2.1.1 802.11 Physical layer

802.11b and g uses 11 channels (13 in Europe and Asia, 14 in Japan), 22 MHz wide and separated by a guard band of 5 MHz each in the Industrial Scientific and Medical



(ISM) unlicensed frequency (2.4 GHz), while 802.11a uses 20 channels in the 5.1-5.8 GHz band.

Figure 8 Channels of 802.11 b and g in USA

In 802.11 b and g, channels 1, 6 and 11 are orthogonal in the sense that they are completely non overlapped, while partial overlapping happens with all other channels. 802.11 suffers from interference, in particular from micro-wave oven and/or cordless phones. On the other hand 802.11's transmissions cause interference to IEEE 802.15.4 and Bluetooth devices. 802.11a, being on different frequencies (far from 2.4GHz) suffers of lower interference, but the main problem with it is that the waves are extremely short, and thus they can easily be reflected or absorbed by walls, making them difficult to use for example in an apartment with a single AP. 802.11 can use alternatively Direct Sequence Spread Spectrum (DSSS), Frequency Hopping Spread Spectrum (FHSS) or Frequency Modulation (FM).

2.2.1.2 802.11 MAC layer

As said in the introduction, CSMA/CA is used by 802.11. Basically, the protocol works as follows:

- the station senses the channel for a short period of time called DIFS (Distributed Inter-Frame Space) and if the channel is found free, a transmission is started;

- if the channel is busy, a random back-off is chosen before re-trying;

- when a transmission is performed, the sender waits for an ACK; if it is received then the transmission was correct, otherwise a re-transmission is done.

To avoid the hidden terminal problem, 802.11 uses the so-called RTS/CTS mechanism. When a station must transmit something, it first transmits an RTS



packet (Request To Send) to the AP; then the AP broadcasts a CTS (Clear To Send) packets, to communicate to the sender that it is allowed to transmit, and to all the other stations that someone else is actually transmitting a data packet.

The main problem of 802.11b and g was the lack of security, partially solved by the introduction of 802.11i (or WPA2), a layer mainly introduced to grant a secure communications over the wireless medium.

2.2.2 IEEE 802.15.4

The IEEE 802.15.4 standard appeared in November 2003 and describes a low data rate Wireless Personal Area Network (WPAN) solution that can enable applications requiring multi-month to multi-year battery life with very low added complexity, operating in unlicensed, international frequency bands [4]. It describes physical and MAC layers, while the upper layers of the protocol (from network to application) are covered by ZigBee specification [6], [7].

The IEEE 802.15.4 physical layer uses spread spectrum techniques (DSSS), and it comes in two versions: one designed to operate in the 868 MHz (EU) and 915 MHz (US) ISM bands, and the other designed to operate in the 2.4 GHz global ISM band. The lower frequency band utilises Binary Phase Shift Keying (BPSK) modulation to achieve data rates of 20 kbps (EU) over a single channel, and 40 kbps (US) over 10 channels. The higher frequency band utilises Offset-Quadrature Phase Shift Keying (O-QPSK) modulation to achieve a data rate of 250 kbps over 16 channels.

The MAC layer defines two different access to the channel: beacon and non beacon-enabled. In both cases a contention-based protocol, based on CSMA/CA is implemented. IEEE 802.15.4 MAC supports star and peer-to-peer topologies, giving flexibility for the application. Each PAN has exactly one PAN coordinator and other devices may associate or disassociate at will. The 16-bits addressing mode allows the addressing of 65535 devices. At chip level, several vendors are offering 180 nm Complementary Metal Oxide Semiconductor (CMOS) chips that implement sensing/control radios (an overview of the products available on the market is provided in section 2.2.2.5).

Details about IEEE 802.15.4 PHY and MAC protocols can be found in Chapters 3 and 4.

2.2.2.1 Zigbee

The higher layers of the communication stack (from the network layer to the application) are addressed by ZigBee Alliance [6], [7]. This alliance is currently supported by more than 300 members. A detailed description is provided in Chapters



3 and 4. However, it is worth mentioning already that different ZigBee versions are available. The ZigBee 1.0 specification was ratified in December 2004 and is referred to as ZigBee 2004. In December 2006, the ZigBee 2006 specification was released, which was followed in October 2007 by the ZigBee 2007 and ZigBee PRO specifications. ZigBee 2007 and ZigBee PRO contain new features, such as group addressing, message fragmentation and interference detection/avoidance by frequency agility. Moreover, the PRO version allows centralized data collection (many-to-one routing), high-security mode, and network scalability in order to support thousands of nodes. Comparison of the different versions is provided in Table 20. Details about Zigbee protocols can be found in Chapters 3 and 4.

2.2.2.2 6LowPAN

In 2007 the Internet Engineering Task Force (IETF) has released an open standard called 6LowPAN (Pv6 over Low power Wireless Personal Area Networks) in order to use IPv6 over IEEE 802.15.4 [8]. The Abbreviation 6LowPAN stands for IPv6 over Low Power WPANs. IP for Smart Objects (IPSO) Alliance is promoting the use of 6LowPAN and embedded IP solutions in smart objects. 6LowPAN is built on top of the IEEE 802.15.4 PHY and MAC layers.

By defining an adaptation layer, 6LowPAN compresses the 60 bytes long headers of IPv6 to 7 bytes, and fragments the 1280 bytes long IPv6 packets to fit 127 bytes long 802.15.4 packets. The network layer protocol in 6LowPAN is compatible with any other IPv6 protocol. This determines interoperability with other IP networks.

The main difference between 6LowPAN and Zigbee is related to the IP interoperability of the former. 6LowPAN devices are capable of communication with other IP-enabled devices, whereas Zigbee nodes need an 802.15.4/IP gateway to interact with an IP network.

2.2.2.3 802.15.4/Zigbee application code size considerations

Besides offering PHY and MAC layers optimized for certain low power techniques, the chips in the ZigBee/802.15.4 application area tend to be highly programmable. This allows the building of e.g., a customized remote control system at a very low cost, with a single wireless chip containing maybe as little as 8-32 KBytes of custom microcontroller program code.

The ZigBee standard is available to build more general mesh networking control systems, hence several software implementations of ZigBee exist, on top of 802.15.4 hardware, with code sizes typically in the 64-128 KBytes order. This larger code size offers support not only for mesh networking, but also for certain levels of service



abstraction, allowing, for example, a light switch of vendor A to interoperate with a lamp of vendor B. Figure 9 and Figure 10 compare code sizes of ZigBee implementations to the code size of other (vendor-specific) networking stacks smaller than ZigBee.

Figure 9: Code and data sizes in Bytes for different network stacks on Jennic hardware. The ZigBee stacks shown are not of the ZigBee Pro type, but of earlier

ZigBee versions that require less code to implement.



Figure 10: Code and data sizes in Bytes for different network stacks on Microchip hardware. The ZigBee stacks shown are not of the ZigBee Pro type, but of earlier

ZigBee versions that require less code to implement.

2.2.2.4 IEEE 802.15.4 Energy consumption

In order to save energy, in many cases, sensors perform low duty cycling, i.e., they continuously alternate a short period of active state (0.1 sec.) with a longer period of sleep state (0.9 sec.).

Transmission over the wireless interface is obviously one of the most expensive tasks for a sensor node. To evaluate the cost of data transmission, we can consider the following sensor node energy model. Let us consider the set S of possible states (s1, … ,sk) where the node can be. These states are defined such that the energy consumption of the component is given by the sum of the energy consumptions within the states (s1, … ,sk) plus the energy needed to switch between the different states.

At each state sj, the amount of consumed energy can be measured using a simple index tj, (e.g., execution time or number of instruction). Furthermore, the energy needed to switch between the different states can be calculated through a state transition matrix st, where stij denotes the number of times the component has



switched from state si, to state sj. It should be noted that the consumption in switching from one state to another depends on the states themselves.

By denoting as Pj the power needed in the state sj and Eij the energy consumption of switching once from state si, to state sj, the total energy consumption of the component is given by:

∑ ∑≠

k

=j

k

ji=ji,

ijijjjconsumed Est+Pt=E1 1

Eq. 1

The energy consumption of a node depends on the activities of its several components: radio, processor, sensor, battery, external memory, and periphery (e.g. a voltage regulator or debugging equipment, periphery to drive an actuator). However, the radio constitutes the most consuming operation. Specifically, for the radio energy consumption, we need to distinguish at least four different states:

1) Sleep: The transceiver is not operational, nodes cannot receive or transmit information.

2) Idle: The transceiver is operational, even if there are no on-going transmissions or receptions. The receiver is active in the sense it is at any time able to detect an incoming PHY frame and trigger frame demodulation.

3) Receive: The receiver is operational, a packet is being received.

4) Transmit: The transmitter is operational, a packet is being transmitted.

In actual implementations of radios, however, many more modes are available to let the application implementer optimise the overall performance and power consumption. Typically, there are possibly several power down modes (sleep modes), and in a majority of cases these relate to the oscillator modes. This means tradeoffs are proposed between power consumption, switching time and, e.g., time drift between successive active (idle, transmit, receive) states.

An adequate use of those modes could strongly impact the network lifetime of synchronised network. For all of them, the energy consumption depends on the time the radio has been in a specific state. Thus, we need to memorize the times the radio has been in the four states and the 4x4 state transition matrix representing the number of times the radio has switched between the four states.

Differently from traditional medium-long range WLAN systems, in short range systems such as the ones based on IEEE 802.15.4 interface, the energy consumed in idle, transmit or receive states tend to have similar values. For example, Figure 11 shows the consumption values for a TmoteSky sensor node (with a CC2420 transceiver). Specifically, the left side of Figure 11 reports the consumption values



for the different states (e.g., reception, transmission, saving, etc.), while the right side of the figure shows the time and power consumption for switching from one state to the other (e.g., from reception to transmission).

Figure 11: TmoteSky energy model

2.2.2.5 IEEE 802.15.4 – Compliant Devices

IEEE 802.15.4 Standard has been supported by a large number of organizations including universities and companies. It has been envisioned as a strong candidate for home area networks. For instance, ZigBee and 6LowPAN Protocols are based on IEEE 802.15.4 Standard, and TinyOS is capable of communicating by using 802.15.4 compliant packets. In the literature, the research conducted in the field of wireless sensor networks and home area networks are mostly referred to IEEE 802.15.4. In the market there are various types of 802.15.4 compatible RF platforms. In general, IEEE 802.15.4 can be implemented in two relatively diverse methods: through TinyOS or through IEEE 802.15.4 Standard stack.

2.2.2.5a TinyOS Based 802.15.4 Solutions

TinyOS is an event driven open source operating system for embedded sensor networks developed by UC, Berkeley. Owing to its open source license it is possible to implement almost any kind of medium access and routing protocols through changes in the code. However this may need considerable effort in most of the cases.

In current TinyOS, the available MAC options are: B-MAC [9] and S-MAC [10]. Using B-MAC, 802.15.4-compliant packets can be generated in TinyOS. There is also an open-source implementation of IEEE 802.15.4/ZigBee for TinyOS [11]. A recent release of TinyOS supports hardware platforms, i.e., microcontroller and transceiver from Atmel and Texas Instruments. University of California, Berkeley has open source reference designs, called Mica2Dot Mica2 and Telos, which are based on the hardware platforms from the above mentioned two vendors.

The motes produced in Berkeley are available to the general public through a company called Crossbow [12]. Crossbow’s product family also consists of improved



versions of these motes called Micaz and Iris. All these motes are TinyOS-compatible. The well known TinyOS simulator TOSSIM can only emulate Mica2 and Mica2Dot motes. Support of the other motes is not currently available in the simulator. The two TinyOS-based devices are briefly described in the following.

Table 6: Atmel Platforms compatible with TinyOS [13]

2.2.2.5.a.1 Atmel Platforms compatible with TinyOS

8-bit ATMega128L microcontroller is used in Mica2Dot, Mica2 and Micaz motes, while Iris has 8-bit ATMega1281 microcontroller. These two different versions of ATMega microcontroller are from Atmel. All motes with Atmel microcontroller have 128 KByte program memory and 4KByte Static Random Access Memory (SRAM) (Iris has 8kByte). Among these motes only Iris has a transceiver from Atmel, namely RF230. RF230 works in the 2.4 GHz ISM band. In contrast to Iris, other devices have



transceivers from Texas Instruments (formerly Chipcon). Mica2Dot and Mica2 work around the 1 GHz band, having Texas Instruments CC1000 transceiver, whereas Micaz works in the 2.4 GHz ISM band, having Texas Instruments CC2420 transceiver. Iris is the latest TinyOS mote from Crossbow that has three times improved radio range and twice the program memory over previous Mica motes. Among the motes having Atmel MCU, next generation Iris is technically superior thanks to its 8 KByte SRAM and better radio performance. In Table 6, a summary of Atmel platforms compatible with TinyOs can be found.

2.2.2.5.a.2 Texas Instruments Platform compatible with TinyOS: TELOS

Telos mote has 16-bit Texas Instruments MSP430 microcontroller with 10 KByte RAM and 48 KByte program memory. It has Texas Instruments CC2420 transceiver like Micaz. When it is compared to all other TinyOS motes mentioned above, Telos platform delivers the lowest power consumption as well as the fastest MCU wake-up time from sleep state. In TinyOS-based solutions, Telos and Iris have better technical specifications compared to others. This would make Telos a good choice in the design of low power devices with TinyOS. But if coverage and connectivity are the main constraints, Iris would be a better choice. Unfortunately device emulation in bit-level is only available for Mica2 and Mica2Dot motes, since TOSSIM and many other emulators, like Atemu and Avrova, support these motes only.

2.2.2.5b 802.15.4 Standard-Based Stack Solution

On the other side of the medallion, there are international companies having 802.15.4-compatible software stack and devices. Since they are investing significant amount of money for the development of their stack and 802.15.4 compatible products, they provide high quality software and professional tools to the developers. The general trend among the producers is to make available the object codes of their 802.15.4 stacks to developers free of charge. Ember, Freescale, ST Microelectronics, and Texas Instruments are the only promoter partners in ZigBee Alliance that have been developing 802.15.4 compatible transceivers.

2.2.2.5.b.1 Ember & ST Microelectronics Platform

Ember and ST Microelectronics are strategic partners for ZigBee technology. ST denotes its transceiver as EM250 while Ember called it SN250. In practice both transceivers are compatible in terms of features and performance. The most significant specification of the transceivers is the -99 dBm receiver sensitivity. These transceivers have 802.15.4-compatible radios. Ember and ST provide EmberZNet ZigBee Stack, developed by Ember to the third party developers. In this stack 802.15.4 MAC should be implemented since ZigBee stands on top of PHY and MAC defined in 802.15.4, but Ember does not provide a standalone 802.15.4 MAC stack for developing custom applications using 802.15.4.



2.2.2.5.b.2 Freescale Platform

Freescale simply called its stack 802.15.4 MAC. Its object code is free of charge, in other words the use of this stack is free but its source code is not open. in June 2008 Freescale announced its next-generation 802.15.4 platform, namely MC13224V. This new platform has impressive specifications like 32-bit ARM7 Core, 22mA receive, 29mA transmit, 0.85 µA hibernate currents at 3.3V battery operation, -100 dBm receiver sensitivity in NCD mode, 96 KByte RAM and 80 KByte ROM. 80 KByte ROM contains bootcode, all device drivers and fully compliant 802.15.4 MAC including beaconing and Guaranteed Time Slots (GTSs).

2.2.2.5.b.3 Texas Instruments Platforms

Texas Instruments entered the ZigBee/802.15.4 market after the acquisition of Chipcon in 2006. Chipcon’s CC2420 was the industry’s first IEEE 802.15.4 compliant RF transceiver. System on chip solution CC2431 from Texas Instruments contains 8051 compliant MCU, CC2420 transceiver and a hardware location engine. Moreover, Texas Instruments has next generation CC2520 which is a significantly improved transceiver, having +5dBm transmit power and excellent channel rejection values (49dBm at ±5MHz, 54dBm at ±10MHz). TIMAC is Texas Instruments’ 802.15.4 stack. TIMAC is distributed as object code free of charge.

2.2.2.5.b.4 Jennic Platforms

Jennic is a fabless semiconductor company based in UK, which specializes in wireless microcontroller solutions. Jennic chipsets integrate a 32 bit RISC CPU (Central Processing Unit) with a 802.15.4 radio. This RISC CPU offers a somewhat higher compute power than the CPUs of other vendors, like TI integrate on their SoC solutions. The latest chip from Jennic, JN5148, offers radio based distance measurements based on a time-of-flight (light speed delay) engine. In addition to bare chipsets, Jennic also sells modules which integrate their chips with some passive and antenna components on a small printed circuit board. The module can be soldered onto a larger PCB, thus simplifying product design. Use of such modules is typically attractive when one has to realize products in series with volumes under 1-10K. Modules that integrate a radio power amplifier, boosting output to +19 dBm, are also available. Jennic offers 802.15.4 MAC, ZigBee, RF4CE, and 6LowPan stacks for their chipsets, and also a proprietary mesh networking protocol called JenNet.

2.2.2.5c Comparison between the different 802.15.4 devices

In the standard stack based 802.15.4 solutions, Texas Instruments and Freescale are strong actors while ST Microelectronics and Ember are only concentrating on ZigBee stack. In Table 7, a list of the 802.15.4 standard stack based solutions in comparison with TinyOS-based Iris and Telos can be found. Also the cost of these devices is reported. In particular, we provide the cost of the Integrated Circuit (IC) composed of the transceiver and microcontroller. These costs are those exposed by AVNET company and are related to the purchase of 1000 devices.



CC2520 from Texas Instruments and MC13224V from Freescale are state of art products, combining low power operations with high quality transceivers. Also Crossbow’s Iris, which has ATMega1281 MCU and RF230 transceiver from Atmel, is a high-end TinyOS-compatible device. The only drawback about Iris is its high sleep current. On the hardware side, Atmel Freescale and Texas Instruments have high technology transceivers which have some pros and cons although in the applications, their radio performance differences might not be notable. On the developer side, the choice could be done by having an open source software (e.g., TinyOS) or having a non-open but free of charge 802.15.4 stack (e.g., Freescale 802.15.4 MAC, TIMAC). Free 802.15.4 stack solutions would improve the development time whereas open source software could give more options.

ST SN250 (Ember EM250)

TI CC2431 TI CC2520 (Only Transceiver)

Freescale MC13224V

Telos/Tmote Sky B (Crossbow)

IRIS (Crossbow)

Jennic JN5139

MCU / Tranciever:

16 bit XAP2b / Custom

8 bit 32 MHz

Intel 8051 / CC2420

N/A / CC2520 32-bit TDMI ARM7 / Custom

TI 8 MHz 16-bit MSP430F1611/ CC2420

Atmel 8 bit 8.37 MHz Atmega 1281 MCU / AT86RF230 Tranciever

32 Bit Jennic RISC, Jennic 802.15.4 transceiver

Flash Memory (kByte):

128KB 128 KB N/A 128 KB 48KB 128 KB External

Other Memory (Kbyte):

5KB RAM 8 KB RAM N/A 96 KB SRAM80 KB ROM

10KB RAM 16KB EEPROM

8KB SRAM4KB EEPROM

96 KB

Max Transmit Power:

+5dBm in Boost Mode

+ 0 dBm +5 dBm +4 dBm +0 dBm +3 dBm +3 dBm

Rx Current:(MCU Active)

35.5 mA (Vdd=3V, MCU 12 MHz)

26.7 mA (Vdd=3V, MCU running at 32 MHz)

18.5 mA (Low Power Mode, Vdd=3V, No MCU)

22mA (Vdd=3.3 V, MCU running at 2 MHz)

24,8mA (MCU Active)

24 mA(Vdd=3V, MCU Active)

40 mA (Vdd=2.2-3.6V, MCU active)

Tx Current:(MCU Active)

32.8 mA (0dBm,Vdd=3V, MCU 12 MHz)

26.9 mA (0dBm,Vdd=3V, MCU 32 MHz)

25.8 mA (0dBm,Vdd=3V, No MCU)

29mA (0dBm,Vdd=3.3 V, MCU 2 MHz)

25 mA(+3dBm, Vdd=3V, MCU Active)

40 mA (Vdd=2.2-3.6V, MCU active)

Sleep Current:

1uA max (with sleep timer running)

0.3 µA(No clocks. RAM retention)

0.85 µA typical Hibernate (Retain 8 Kbyte SRAM contents)

6.1 µA

8 µA 3 µA typical – with RAM retain

Rx Sensitivity:

-98 dBm (Boost Mode)

-92 dBm -98 dBm -100 dBm (NCD mode)

-94 dBm -101 dBm -97 dBm

Channel Rejection: (Desired Signal -82 dbm)

35dBm(-5MHz) 35dBm(+5MHz) 40dBm(-10MHz) 40dBm(+10MHz)




38dBm(-5MHz) 47dBm(+5MHz)


31dBm(-5MHz) 33dBm(+5MHz)



IC Cost ($)

(1000+,

AVNET, 2009)

11.61 8.35 3.24 6.16 14.41 17.5 7.36 (100+, Farnell, Jan 2010)

Other: Hardware Location Engine

TinyOS, 6LoWPAN, Fast MCU Wake up Time

TinyOS, 6LoWPAN ZigBee, RF4CE, 6lowpan stacks

Table 7: Comparison of the Platforms

2.2.3 Bluetooth

2.2.3.1 The Bluetooth Standard

Bluetooth was initially developed by a Swedish mobile phone manufacturer as a cable replacement for accessory devices around the mobile phone and the office desk. Its standard (IEEE 802.15.1) is developed by coordination of Bluetooth Special Interest Group (BT SIG), which is also a US legal entity [14], [15]. At the time of writing, the BT SIG has approximately 12000 member companies ("adopters") worldwide. Standardization is driven by approximately 235 associate members. Many features of the specification are optional, allowing optimizations. First Bluetooth devices became available in 1999. Since then, more than 1 billion BT enabled devices have been sold. Laptops and mobile phones contribute to that figure with 100s of millions.

2.2.3.1a PHY

The 2.4 GHz ISM band was chosen to permit worldwide use of Bluetooth. Depending on the country, a spectrum of 60 to 80 MHz width is available. To comply with out-of-band regulations in several countries, a guard band is used at both lower and upper edges of the band. Since the BT RF spectrum width at any instant is 1 MHz, 79 channels are available in most countries. Since the 2.4 GHz band is shared with other services like cordless phones and appliances like microwave ovens, a fair amount of robustness is required. Another reason is the required coexistence with a transmitting mobile phone on the same circuit board and antennas close to each other.

Devices are categorized into three power classes, given as power levels at the antenna connector of the device, as shown in Table 8.



Transmit Power Class

Max. power [dBm]

Typical range [m]

3 0 1

2 4 10

1 20 (*) 100

Table 8: BT transmit power classes

(*) Class 1 devices shall have the ability to dynamically adjust their output power to lower values whenever the link quality permits. This is managed by the peer device. The effective range among devices of different power classes is determined by the weaker device. BT uses a pseudo-random frequency-hopping sequence for the purpose of robustness. The sequence will depend on the addresses of the devices involved. The hopping sequence is determined by the master, it is 1600 per second for single-slot packets, or less, when multi-slot packets are used. Frequency-hopping does also improve data security: channel quality is monitored, and those channels that do not deliver a satisfying quality (e.g. due to fading or interference) are excluded from the hopping sequence. This process is called Adaptive Frequency Hopping (AFH).

2.2.3.1b Networking and traffic

Up to 7 slave devices can be connected simultaneously to a master of a so-called piconet. Additionally, up to 248 slaves can be "parked" and only be activated when necessary. Master and slave roles are negotiated between devices when the piconet is set up. A slave can communicate directly only with the master. Each device can perform a role switch and thus become temporary member of more than one piconet ("scatternet").

Frequency hopping is used to avoid interferences among piconets and other external interferences: each piconet in the scatternet will have a different frequency hopping sequence (all nodes of a piconet will use the same channels at the same time).

Time is divided into slots and the medium access is managed by the master, though a polling strategy. The master queries slaves asking for data transmissions and slaves may transmit packets occupying one, three or five slots, immediately after the polling.

Various packet types are available for voice and data transmission. Data packets are acknowledged, the acknowledge credit is adjustable for isochronous connections. Full duplex is accomplished by the inherent time-division concept. Depending on packet type, simple FEC methods can be added to the basic error detection mechanism in each packet. This comes at the expense of increased air time (transmitter and receiver duty cycle), energy spent per bit of user data, and potentially reduced



throughput. Multi-slot packets can be used to increase throughput, since these packets have a better ratio of payload data to header information. Multi-slot packets also offer to trade downlink speed versus uplink speed, by assigning slots from one peer to the other. This allows some coarse adjustments, but not all conceivable combinations are legal, since the master starts transmitting its packets only on even slots, and the slave only on odd slots.

While the gross bit rate of classic Basic Data Rate (BDR) rate is 1 Mbps, the net bit rates available for data traffic depend on the chosen packet type, as shown in Table 9.

Type (#slots)

Symmetric [kbps]

Asymmetric –uplink

Asymmetric -downlink

Forward error correction

DM1 108.8 108.8 108.8 2/3 Hamming

DH1 172.8 172.8 172.8 -

DM3 256.0 384.0 54.4 2/3 Hamming

DH3 384.0 576.0 86.4 -

DM5 286.7 477.8 36.3 2/3 Hamming

DH5 432.6 721.0 57.6 -

Table 9: BDR net data rates

Only pure data packet types are shown here. The chosen packet type will also affect the latency of the link. DH5 packets will lead to 3.125 ms latency in case of first-time success, plus any SW processing.

Enhanced Data Rate (EDR) is an option in the standard that provides better throughput in data and multimedia use cases, and enhanced voice quality. Gross bit rates on air are 2 and 3 Mbps, using π/4-DQPSK (Differential Quadrature Phase Shift Keying) and 8-DPSK (Differential Phase Shift Keying) modulation schemes, respectively. The link budget suffers by 2 - 3 dB when these modulation types are used. The net data rates for various EDR packet types are sown in Table 10.

For backward compatibility, headers of EDR packets are transmitted in BDR, so that legacy receivers can still decode these packets and discern them from interference. EDR can also be used to reduce air time and power consumption for the same amount of payload data. This increases the maximum population density of



Bluetooth piconets, that is more piconets can coexist in the same area before congestion occurs.

Type (#slots)

Symmetric [kbps]

Asymmetric –uplink

Asymmetric -downlink

2-DH1 354.6 354.6 354.6

2-DH3 765.9 1152.0 172.8

2-DH5 863.9 1442.0 115.2

3-DH1 524.6 524.6 524.6

3-DH3 1149.9 1728.0 259.2

3-DH5 1297.8 2163.0 172.8

Table 10: EDR net bit rates

2.2.3.1c Security

Classic authentication (during initial pairing of new devices) is done by entering a PIN of up to 16 digits. Secure Simple Pairing is an advanced method that provides approximately 95-bit protection against passive eavesdropping and against man-in-the-middle attacks by public key cryptography based on the 20-bit entropy of a 6-digit PIN. Another association model is available for devices that have no display nor keyboard, but it does not protect against man-in-the-middle attacks. Encryption of data between two devices is based upon stream cipher with E0 algorithm. Key generation is done with E2-E3 algorithms. It provides link layer security between any two Bluetooth radios. Bluetooth uses encryption with a negotiated key length of up to 56 bits, in order to comply with export regulations.

2.2.3.1d Profiles

Any application needs to use one or more profiles for communication to other BT devices that implement the same type of profile. Each profile uses a set of certain protocol elements that are provided by the BT controller chip. Examples for profiles are:

- Headset: A headset uses a mobile phone as a long-distance voice modem gateway.

- Dial-up networking: A laptop uses a mobile phone as a data modem gateway to connect to the internet.



- Serial port: Two BT devices emulate a ‘wireless’ serial port cable.

More profiles are defined for connections between digital cameras and photo printers, A/V multimedia players and stereo headsets, handsfree car kits and SIM card access for mobile phones, and Human Interface Devices (HID) like mouse or keyboard. A sensor profile is in development. More information is only available to BT associate members at the time of writing.

2.2.3.1e Power consumption

With respect to power efficiency, we need to distinguish two variants of Bluetooth: normal Bluetooth with a PHY data rate up to 1 Mbps and Bluetooth EDR (Enhanced Data Rate) with PHY data rate up to 3 Mbps. The EDR version tends to be more power efficient per bit sent; this is also visible in the receiver power consumption graph above, where the rightmost point represents the use of EDR. Bluetooth is a somewhat complex protocol: it will for example automatically use more error correction (meaning more power usage per payload bit sent) if reception conditions are bad. An EDR link will automatically switch back to normal lower data rate packets if reception conditions are too bad for EDR.

Figure 12: Internals of a modern Bluetooth product – in this case the PCB and battery of a Bluetooth hands free phone headset. The PCB is 38 mm long and 15 mm

wide.

Current consumption from a 2.5 V supply for a Class 2 BDR & EDR chip in slave mode, using serial port profile SPP, is given in Table 11.



Mode Parameters Current [mA]

Sniff mode (scheduled break between rare data packets)

Sniff interval = 1.28 s, Sniff attempt = 3 0.112

Sniff mode Sniff interval = 5 s, Sniff attempt = 3 0.062

Sniff mode Sniff interval = 10 s, Sniff attempt = 3 0.053

Data transmission using EDR 68.2 kbps 16.7

Data transmission using BDR 62.8 kbps 20.0

Data transmission using EDR 356 kbps 25.7

Connectable Page interval = 1.28 s, page window = 11.25 ms

0.45

Table 11: BT Power consumption

The cost of a BT chip in high volumes should be in the range of 1$. LE devices can be expected to be slightly cheaper than BDR/EDR devices since LE uses less memory.

2.2.3.2 Upcoming releases

2.2.3.2a Bluetooth 3.0

A new process called Enhanced Power Control (EPC) ensures a faster and tighter control loop for transmit power control, and improves power consumption and interference. Bluetooth 3.0 introduces the option HS (High Speed), i.e. using another MAC/PHY. For the time being only 802.11/Wi-Fi is supported, but the architecture is generic, so adding e.g. Ultra Wideband (UWB) in the future is possible. Devices are still found and link establishment negotiated over BDR/EDR. The user payload is conveyed using the HS PHY.

2.2.3.2b Bluetooth Low Energy

Bluetooth Low Energy has been developed to address very low average data rates, where large latency is acceptable in favour of power savings [16]. It supports a star network topology. BT LE still does not support mesh networking, although it is being considered a future option. LE uses a different protocol built upon a similar RF. The RF uses more bandwidth and channel spacing which improves the link budget by



approximately 3 dB. The maximum output power is 10 dBm for a reliable range of 10 m and better. Figure 13 shows simulation results for receiver bit error rate (uncoded) and frame error rate as a function of the Signal to Noise Ratio (SNR) for BT BDR and BT LE.

The link budget of Class 2 devices for the usual corner Bit Error Rate (BER) of 1E-3 is thus approximately 91 dB (can be considered state of the art nowadays) for BT BDR and approximately 94,5 dB for BT LE.

BER/FER vs SNR

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

13 14 15 16 17 18 19 20

SNR [dB]

BE

R/F

ER BER (BDR)

BER (LE)

FER (BDR)

Figure 13: BER and FER for BT BDR and LE

The latency from non-connected state is less than 6 ms, which is same or better than ZigBee. Power consumption is on the same level as ZigBee, and 1% to 50% when compared to BDR/EDR. Version 1.0 of the standard is now expected to be adopted and released in 2010.

2.2.3.3 Bluetooth Devices

The BT devices available on the market are presented in Table 12. Note that LE devices are in development but not yet on the market.



Manufacturer Device Chip / Module

BT version Protocol / Profiles

Infineon PMB8753 Chip 2.0+EDR HCI

Infineon PMB8763 Chip 2.1+EDR HCI

Infineon PBA31308 Module 2.1+EDR HCI

Infineon PBA31308/2 Module 2.0+EDR SPP

Infineon PMB8762/2 Chip 2.0+EDR HID, RFCOMM

Cambridge Silicon Radio BlueCore4 Chip 2.0+EDR HCI, Headset

Cambridge Silicon Radio BlueCore5 Chip 2.0/2.1 HCI

Cambridge Silicon Radio BlueCore6 Chip 2.1+EDR HCI

Cambridge Silicon Radio BlueCore7 Chip 2.1+EDR+LE HCI

Broadcom BCM2045 Chip 2.0+EDR HCI

Broadcom BCM2042 Chip 2.0+EDR HID




Texas Instruments BRF6300 Chip 2.0+EDR HCI

Texas Instruments BRF6350 Chip 2.1+EDR HCI

Texas Instruments BL6450 Chip 2.1+EDR, HCI

NXP BGB210S Module 2.0+EDR HCI

ST-Ericsson STLC2500C Chip 2.0+EDR HCI

ST-Ericsson STLC2500D Chip 2.1+EDR HCI

ST-Ericsson STLC2690 Chip 2.1+EDR HCI, A2DP support

Atheros AR3011 Chip 2.1+EDR HCI-USB



Atheros AR3031 Chip 2.1+EDR Headset, Handsfree

Nordic Semiconductor nRF8000 µBlue single mode version

Chip LE Watch, Remote control, Sensor Devices

Nordic Semiconductor nRF8000 µBlue dual mode version

Chip BDR, LE Watch, Consumer, Terminals

Table 12: BT devices

2.2.4 UWB

In March 2007 the IEEE 802.15.4a was finalised [17], which proposes Impulse Radio UWB [18], [19] as an alternative to IEEE 802.15.4 and adds innovative features such as accurate ranging and variable bit rate. Early designs show the interest for such a technology especially when looking for ultra low power transmitters easy to handle, flexible bit rate and operation outside ISM bands, favoured by international regulation. In addition, the IEEE 802.15.4a standard proposes a Chirp Spread Spectrum mode operating in the 2.4 GHz band as promoted by NanoTron. Several companies (UbiSense, Time Domain, MSSI) commercialise proprietary UWB solutions which have no mass market penetration so far.

According to the American Federal Communications Commission (FCC), Ultra Wide Band (UWB) can be defined as the wireless communication system where short pulses are transmitted, which occupy a bandwidth which meets either of the two following requirements:

- The 10 dB bandwidth is larger than 500 MHz.

- The relative 10 dB bandwidth (central frequency divided by the occupied bandwidth) is larger than 20%.

In 2002, the FCC decided to review the use of the spectrum in the 3.1-10.6 GHz band, and the UWB technology gained considerable attention and industrial momentum.

The strengths of UWB include:

- High data rate, which allows transmission of multimedia content. The following picture shows a comparison with other wireless systems.



Figure 14. UWB data rate

- Robustness against multipath and interfering signals, due to the large occupied bandwidth and the transmission of power levels close to the noise floor (see Figure 15). In fact, the emission mask for the power density of UWB signals (-41.25 dBm/MHz in the operation band) is below the non-intentional signal emission levels for Electromagnetic Compatibility (EMC).

Figure 15. UWB frequency occupation

- Low power consumption, due to the low transmitted power and the possibility of using CMOS technology.



Figure 16. UWB power consumption

However, due to this low transmitted power and the use of high frequencies, the range of a UWB system is limited to a PAN (i.e., a few meters) This confines the application of this technology to a room-environment.

Figure 17. UWB range

Therefore, high data-rate and low communication range make UWB technology suitable for applications such as computer peripherals (Wireless USB), A/V transmission between devices (video cameras, DVD players, etc.) or entertainment (video on-demand, games, etc.).



Two standardization proposals have been made for UWB, which are not compatible to each other:

1) DS-UWB (Direct-Sequence UWB): Promoted by the UWB Forum, which consists of the transmission of short pulses (between 1 and 24, depending on the frequency expansion sequence), using BPSK and 4BOK (quaternary bi-orthogonal keying) modulation and FEC correction. The UWB Forum proposes the division of the 7.5-GHz UWB spectrum in two subbands (frequencies from 5 to 6 GHz are not used in order to avoid interference with 5-GHz WLAN systems):

a. Low band: from 3.1 GHz to 4.86 GHz (channels 1 to 6);

b. High band: from 6.2 GHz to 9.7 GHz (channels 7 to 12).

Figure 18. DS-UWB frequency allocation

2) MB-OFDM (Multi-Band OFDM): Proposed by the MBOA (Multi-Band OFDM Alliance), divides the 7.5-GHz UWB spectrum in 5 groups: the first four groups contain three channels, and the last one contains two (see Figure 19). Each channel is 528 MHz-wide and consists of 128 subcarriers, 4.125 MHz-wide each.



Figure 19. MB-OFDM frequency allocation (source: WiMedia Alliance)

These proposals were presented in January 2003 to the IEEE 802.15.3a Task Group as an alternative physical layer (see http://www.ieee802.org/15/pub/TG3a.html). After three years of discussion, supporters of both proposals decided the shutdown of the IEEE 802.15.3a task group without any conclusion. Nowadays, the MB-OFDM proposal is much better positioned in the market, as it was standardized as ECMA-368 in December 2005, and it is supported by the WiMedia Alliance. Moreover, MB-OFDM is being considered as a candidate technology for Bluetooth V3.

2.2.5 Other wireless solutions

2.2.5.1 Wireless HART

Wireless HART is the wireless extension of HART (one of the most known industrial protocols) and it is used in particular for process monitoring and control (see http://www.hartcomm.org/protocol/wihart/wireless_technology.html). Wireless HART operates in the 2.4 GHz ISM radio band. It is based on the 802.15.4 standard and it uses a packet by packet based frequency hopping. The protocol is completely based on mesh networking, and it is presented as a reliable wireless protocol (reliability of 99,9999998% according to the official documentation). Clear Channel Assessment is supported to ease the coexistence with other devices operating in the ISM band. The adopted PHY layer is the one of 802.15.4; it supports a maximum payload of 127 bytes and an adjustable transmit power with a maximum value of 10 dBm.



TDMA technology is used to coordinate the communication between network devices and TDMA link layer is thus used as link layer by Wireless HART. The bus arbitration is done by TDMA using timeslots organized in superframes (100 timeslots/second) and the network traffic is adjustable, mainly on the basis of bandwidth demand. Acknowledgement messages include timing information to maintain the synchronization of the network. 4 level-prioritization of messages is supported (command messages have the highest priority) to manage traffic flow.

It is a full wireless mesh network. All nodes can be sink, sources, or route messages on behalf of other nodes. Broadcast, unicast and multicast transmissions are supported. Security is granted in this protocol by the use of AES-128 block ciphers with symmetric keys.

2.2.5.2 ISA100

The first version of this standard (ISA100.11a [20]) has been released on September 2009, thus it is an extremely recent proposal. It is a standard mainly developed with the aim of monitoring processes in industrial environments using wireless devices. It is based on 802.15.4 standard at physical layer; it supports both mesh and star topologies and channel hopping is adopted to reduce the impact of interference. We describe shortly below the most interesting ISO/OSI layers of this proposal.

The standard is intended to offer the possibility of inter-network communication; the frame format is IP-based and the functionalities offered by this layer include aspects of quality of service. Transport layer supports reliable transport service, security, packets segmentation and flow control.

2.2.6 Comparison of Wireless Standards

As stated above, there exist a plethora of standards and technologies thought for low power and low complexity wireless networks. IEEE 802.15.4/Zigbee [4], [6], 6LowPAN [8], IEEE 802.15.4a (UWB) [19], Bluetooth Low Energy [16], are the most widely-recognized standards for this kind of networks.

A comparison between these different standards is shown in Table 13, where the main technical characteristics are provided.

All these standards, apart from Bluetooth, support mesh networking. On the contrary, Bluetooth Low Energy technology only allows point-to-point connections. ZigBee and 6LowPAN allows large scale mesh networks supporting 16 or 64 bit addresses.



ZigBee, 6LowPAN and Bluetooth use 2.4 GHz ISM band. Being this bandwidth used also by 802.11, the interoperability between the systems must be taken into account. Some experimental measurements related to interferences between IEEE 802.11 and 802.15.4 are shown in Chapter 4. Results show that if an proper choice of the 802.15.4 channels is done, 802.11 interference is not so dangerous. Note that Bluetooth uses frequency hopping against interference in 2.4 GHz ISM band.

For large scale mesh networks ZigBee and 6LowPAN are the only options. If interoperability with IP devices is required, implementing 6LowPAN would give a complete solution but if packet size is small and there is no real need for an IP interoperability, ZigBee can achieve better performance compared to 6LowPAN.

A recent release on April 27, 2009 from Zigbee Alliance stated that the Alliance planned further integration of internet protocol standards in collaboration with Internet Engineering Task Force (IETF), which released the 6LowPAN standard. The outcome of this collaboration would bring to a dominantly promoted and supported standard in the market, namely ZigBee.

Finally note that the main advantages of IEEE 802.15.4a (UWB) with respect to IEEE 802.15.4 are: larger bit rates and localisation capabilities. However, the eDIANA application doe not need such high bit rates, since the quantity of data that must be transmitted in the network is quite low. Moreover, locatisation functionalities are not required here. In addition, UWB is characterized by very low transmission ranges and the creation of networks covering large apartments is quite difficult. For these reasons this technology is not the best solution for the eDIANA platform.

802.15.4/ Zigbee

802.15.4/ 6LowPAN

802.15.4a (UWB)

Bluetooth Low Energy

Mesh Topology Support:

Yes

Yes

Yes No, Only Point-to-point

Max Data Rate: 250 kbps 250 kbps 1 Mbps 1 Mbps

Mesh Addressing:

64/16 bits 64/16 bits 64/16 bits -

Encryption: 128 bit AES 128 bit AES 128 bit AES 128 bit AES

Max Range: 300 meters (outdoor)

300 meters (outdoor)

30 meters (expected)

>10 meters (expected)

Bands: 2.4 GHz ISM 2.4 GHz ISM 249.6 MHz - 2.4 GHz ISM



900 MHz ISM 900 MHz ISM 10.6 GHz

Related Standard:

802.15.4 802.15.4 802.15.4 Bluetooth

Open Standard: For Non Commercial Purposes

Open Open Open to Bluetooth SIG

Promoters: Zigbee Alliance Ember, Freescale, Philips, Samsung, Schneider Electric, Siemens, ST Microelectronics, Texas Instruments, …

IPSO Alliance Atmel, Cisco, Ericsson, Freescale, National Instruments, SAP, Sensinode, Sun, Zensys, …

IEEE Bluetooth SIG Nokia, Motorola, Microsoft, Lenovo (IBM), Toshiba, Ericsson, Intel, …

Other: IP Interoperability

Ranging and Positioning

Table 13: Comparison of Low Power and Complexity Wireless Network Standards

2.2.7 Energy usage of short range wireless networks

With short range wireless, we mean a wireless technology that has a (typical) transmit range of less than 100 meters. Short range radios typically radiate only 1-40 mW of power, when they are transmitting. The processing steps needed to construct the radio signal to be transmitted usually consume more milliWatts of power than the antenna to transmit the constructed signal.

In short range radio technologies, the amplification and decoding of a received radio signal typically uses just as much power per bit, or even slightly more power, as the sending of the bit. This is illustrated in Table 14.

The power usage when the radio is off or in standby will depend significantly on the design goals for the device, Table 14 only gives typical values for typical devices. Highly optimized designs, with very low power usage in ‘deep sleep’ standby modes, are possible with all technologies above.

Figure 20 shows the receiver power consumption and bit rates for typical short range wireless technologies – each data point represents a measured value, with the measurement being the power consumption of the entire (wireless subsystem of) the device, covering processing in all protocol layers, i.e. all processing needed until the received and validated data can be read from memory by the receiving application.



The measurements are at device level, not at chipset level, so typical chipset leak currents, passive component power consumption, and other overheads are also taken into account in these measurements.

Technology Power usage, radio send

Power usage, radio receive

Typical power usage, radio off/standby

WiFi 1000 mW 1000m W Typically never switched off

Bluetooth 40-250 mW 40-250 mW <50 mW

802.15.4 and ZigBee 30-60 mW 40-70 mW <5 mW

Table 14: Typical power usage for short range wireless technologies

Figure 20: Receiver power consumption and bit rates for short-range wireless technologies

The data points are plotted on a log-log chart: this means that there are order-of-magnitude differences in the parameters of the technologies shown, in terms of both



bit rate supported and power consumption. Thus, when it comes to selecting the most power-efficient solution for a given bit rate, one size does definitely not fit all. Each of the three technologies Wi-Fi, Bluetooth, and ZigBee/802.15.4 have their own niche, in that they occupy a different range along the X axis. The green triangles for ZigBee/802.15.4 represent the maximum data rate for these technologies – at lower data rates the radio can be left switched off for some time. As shown by the green dotted lines, this leads to a drop in power consumption that is close to proportional to the bit rate, because these chips have been optimized to have very low leak currents in sleep mode.

2.2.8 Security considerations for wireless networks

Security is an important problem to be solved when talking about wireless networks. Nowadays those networks are quite common and practical, as now it is possible to enter a network while moving. Unfortunately, hackers have found wireless networks relatively easy to break into. Actually, many times wireless technology is used to crack into wired networks. Consequently, it is essential to protect wireless networks with effective security policies to ensure the security guarantees demanded.

2.2.8.1 The main attacks

There are a number of security risks associated with the current wireless protocols and encryption methods. Among the main attacks listed in the context of wireless networks, we could find:

- Intrusion: An external element connects itself to the operator AP and this way it will be able to penetrate the network (WLAN, WPAN, etc.). This attack could come either from the interior of the network or remotely.

- Data capture: It consists of recovering the contents of data which circulate on the wireless link. It can happen by using spy entities which are in the zone or remote with the help of a direct antenna.

- “Man-in-the-Middle” attack (MITM): In this case the attacker has the ability of reading, inserting and modifying the messages between two parts, while they are not able to know that their link has been violated. This attack is particularly easy to implement, it is enough to have an AP like Trojan horse.

- Intruding access point: It consists in connecting a false access point to the network. This attack lets any station access the wired network, as well as the Internet, if the local network is connected to it.



There are many free software applications used for attacking wireless networks, as the Auditor bundle. Furthermore, because of the context of wireless communications, the medium is very vulnerable. The radio channel is a broadcasting medium, that propagates in all directions and thus is interceptable by whoever is provided with a suitable device. Consequently, it could be said that it is quite easy to break into a wireless network, so if we want a secure network some measures must be taken.

2.2.8.2 Four basic security services

Currently there are no methods absolutely secure. The best strategy may be to combine a number of security measures, which means that all WLAN devices need to be secured, all users of the wireless network need to be educated in wireless network security, and all wireless networks need to be actively monitored for weaknesses and breaches.

Nevertheless, four basic security services provided by link layer security protocols can be identified, namely authentication, access control, data integrity and confidentiality.

The authentication service is for verifying the identities demanded by or for an entity. Those services could be divided into two groups, namely data origin authentication, which verifies the identity of a system that is claimed to be the original source of received data, and peer entity authentication, which provides corroboration between peer entities at the connection establishment or during the transfer of information between them.

Access control should prevent unauthorized nodes from participating in the network. Allowed ones should be able to detect messages from unauthorized nodes and reject them.

If an adversary modifies a message from an authorized node sender while the message is in transit, the receiver should be able to detect this tampering. To minimize this problem and to improve the access control, it is recommended to include a message authentication code through which each packet provides message authentication and integrity.

Finally, confidentiality guarantees keeping information secret from unauthorized nodes. The most usual method for achieving that objective is encryption. An encryption scheme should not only prevent message recovery, but also prevent adversaries from learning even partial information about the messages that have been encrypted. The data ciphering could be carried out using the WEP algorithm described below. This is known as semantic security.



Security mechanisms are processes provided by or within the system, which are used to implement a security service. They are divided into two groups, namely specific security mechanisms, possibly incorporated in a specific protocol layer, and enciphrement, which converts the original information into a form that is not intelligible. This way it can provide confidentiality of data flow.

2.2.8.3 Wired Equivalent Privacy (WEP)

Wired Equivalent Privacy (WEP) is the encrypt system used to secure IEEE 802.11 wireless networks (Wi-Fi) which allows to encode the information sent. It provides a level 2 encoding system, based in the RC4 algorithm which uses 64 bits or 128 bits keys. The main objective of WEP was to make the Wi-Fi networks as secure as the wired networks. WEP uses shared keys. To access a Wi-Fi network, a mobile client needs to have a WEP key that matches the one configured at its appropriate AP. Having checked this WEP key for validity, the AP grants the mobile client access to the network.

Figure 21: WEP

In 2001, some analyst detected deep weaknesses in the WEP protection. Consequently, nowadays this security can be violated quite easily and although WEP is still used for several networks, they implemented a new and more secure encrypt system: WPA.



2.2.8.4 Wi-Fi Protected Access (WPA)

WPA has been proposed by the Wi-Fi Alliance to replace the old WEP encrypt system. This protocol is a part of the IEEE 802.11i standard, which can work under two modes: WPA Enterprise (which uses 802.1X for authentication) and WPA personal (which uses a preshared key for authentication). Data encryption in WPA also uses an RC4 stream cipher, and it provides an algorithm called the temporal key integrity protocol (TKIP) for encryption and another algorithm called Michael for message integrity.

The WPA Enterprise mode. In this mode we are going to find mobile clients, an AP and an authentication server (RADIUS or LDAP). Those are the steps the process is going to follow:

- a mobile client wants to access a network;

- it contacts the appropriate AP for authentication;

- the client sends authentication information to the AP;

- this information is then forwarded to the authentication server for validation;

- after checking for valid credentials, the authentication server instructs the AP to allow the client to access the network. The server also sends an encryption key to the AP and the client.

The client uses this key to encrypt the information it exchanges with the AP.

The WPA Personal mode. It is used for home users or small offices where the deployment of an authentication server is not feasible. In this PSK mode, a password is manually entered at the AP as well as being given to the mobile client. When a client wants to join the network, the AP first checks if the password of the client matches its own. If so, the AP grants the client access to the network. It then delivers the encryption key to the mobile client and the information exchange starts.



Figure 22: WPA Enterprise mode

Figure 23: WPA Personal mode



2.2.8.5 WPA2

WPA2 was created to fix WPA vulnerabilities. It is also based in the standard 802.11i and in this case, it includes all the features of the standard. There are also two versions like in WPA with the same behaviour as in the last version: the WPA2 Enterprise mode and the WPA2 Personal mode. WPA2 uses the advanced encryption standard (AES) with a CCMP (counter mode with cipher block chaining message authentication code protocol) encryption mechanism, making the security stronger.

2.3 Applicability of techniques and standards in hierarchical energy efficient environments

2.3.1 PLC technologies

The decision about the proper PLC technology to be used within the eDIANA platform, is closely related with application requirements like bandwidth, cost, interoperability, latency, etc.. Furthermore, availability on the market, support from promoters, market penetration, and future roadmap of the technology, also have crucial importance. For instance, if a real demand for large data rates is missing in the application, low complexity and low cost solutions like LonWorks, HomePlug Command & Control, PRIME, KNX or X-10 could be proper options. On the other hand PRIME is only working in the licensed CENELEC-A band, therefore it is not an option for communications between CDC and MCC. Low Bandwidth High Bandwidth License Free Operation in EU LonWorks,

HomePlug C&C, KNX, X-10

IEEE P1901, ITU G.hn, HomePlug AV, OPERA

Licensed Operation for Utility Suppliers in EU (CENELEC-A)

LonWorks, PRIME, HomePlug C&C

Table 15: Licensed and licence free PLCs

Another aspect that must be taken into account in the choice of the powerline technology is connectivity. Some of the standards covered in this document natively support Ethernet, and generally these PLC modems/transceivers have a microcontroller equipped with UART, SPI or I2C interfaces, which are the de-facto standard de–facto used in microcontrollers. Examples of chips and related existing interfaces can be found in Table 17. Yitran ZeP is a single board solution that combines TI CC2430 and IT700, giving a ZigBee interface.



Technology /Standard Commercial Products Availability on MarketLonWorks Yes (i.e. Echelon Transceivers) KNX Yes (i.e. ADD1000B) HomePlug AV Yes (i.e. Atheros INT6400/INT1400) HomePlug Command & Control Yes (i.e. Yitran ZeP) PRIME Yes (i.e. ST 7590) ITU G.hn No (expected in second half of 2010) IEEE P1901 Yes (i.e. HomePlug compatible transceivers,

Panasonic HD-PLC) X-10 Yes (i.e. Micromint PLIX-10) OPERA Yes (i.e. DSS9010)

Table 16: PLCs availability on the market

Example Modem/Transceiver Existing Interfaces Echelon Neuron 5000 (LonWorks)

UART, SPI, I2C

ADD1000B (KNX)

UART, SPI

Atheros INT6400/INT1400 (HomePlug AV)

Ethernet, SPI

Yitran ZeP CC2430 + IT700 (HomePlug C&C)

ZigBee, UART, I2C, SPI

ST 7590 (PRIME)

UART, SPI, I2C

Panasonic MN1A92080L (P1901 wavelet-OFDM)

UART, GPIO

Atheros INT6400/INT1400 (P1901 FFT-OFDM)

Ethernet, SPI

Micromint PLIX-10 (X-10)

UART

DSS9010 (OPERA)

Ethernet, UART, SPI

Table 17: PLCs interfaces

2.3.2 Wireless technologies

Owing to cost and complexity issues, Wi-Fi should be used only in the inter-Cell network. In fact, as discussed in section 2.2.6, the most suitable wireless solutions for the intra-Cell network are IEEE 802.15.4 and Bluetooth in the Low Energy version.



In particular, the main advantages of IEEE 802.15.4a (UWB) with respect to IEEE 802.15.4 (larger bit rates and localisation capabilities) are not useful for the eDIANA scenarios and the transmission range is too low. About Bluetooth, the older versions are unsuitable for reasons related to energy inefficiency; on the contrary, LE version is thought for low energy applications and could be very suitable for the eDIANA application.

The main advantages of IEEE 802.15.4 and BT LE are the following: frequency band available worldwide, very low energy consumption, low-cost and low latencies. Despite the bit rate of BT LE is larger, the bit rate provided by 802.15.4 is sufficient for the eDIANA application (see Chapter 4 results). Another advantage of both technologies is that wide-spread interoperability with cell phones and laptops could be achieved in the next future. Either Zigbee or BT LE will be integrated into mobile phones in the next years.

The main disadvantages of both technologies is the presence of interference in the band, which is the ISM band, mainly due to Wi-Fi. This interference must be taken into account in the design of the platform, since the probability that one or more APs could be located in an apartment or an office building is very large. To this aim some studies on the interference caused by 802.11 over 802.15.4 networks are provided in Chapter 4. This issue will be studied also in the next Deliverable (D2.3-B).

The main advantage of IEEE 802.15.4 with respect to Bluetooth, is the possibility to realise mesh and tree-based topologies. This means that with IEEE 802.15.4/Zigbee, scalable networks could be realised and the covered area could be very large. In the case of IEEE 802.15.4/Zigbee networks, the simplest solution to be adopted is to realise a single PAN in each Cell, composed of a coordinator located at the CDC, and the different Cell level devices. These devices will transmit their data to the CDC through direct links, if it is possible, but in case the CDC cannot reach all the devices in the Cell directly, a mesh or a tree-based topology could be applied.

With the BT standard, instead, there is no provision for mesh connections; therefore, devices are not able to forward information to reach other devices or controllers. The improved modulation index of LE will then allow reliable communications within a rooms and the neighbouring room, but not within the whole apartment. Therefore, to cover large apartments some solutions should be found. For example, some communication routers could be included in each Cell to increase the connectivity of the network. However, a detailed analysis on how realising the different piconets and the communication between them is still an issue. On the other side, since the lack of mesh features in the BT standard makes the current eDIANA requirements challenging, Infineon will push Bluetooth SIG for including mesh topologies in the standard.

Finally, a part from the network topology problems of BT LE, that could be solved by an appropriate design of the network and by the possibility of including the definition



of mesh topologies in the next version of the standard, the most important problem on the applicability of BT LE to the eDIANA platform is the lack of availability of products on the market at the moment.



3. Protocol Architecture

This chapter presents the communication protocols that may be implemented on the devices composing the eDIANA platform. While the definition of the complete stack of protocols and their selection is left to Deliverable D2.3-B, in this document the main possible alternatives are discussed. The first section addresses the protocol stack for devices equipped with a wired electrical interface, using PLC. Then, the protocols enabling wireless communications for devices using IEEE 802.15.4, Zigbee, 6LowPAN or Bluetooth LE, are presented. Additionally, since the use of IP cameras is considered at Cell level for monitoring the presence of people and gather other data from the environment, the communication protocols to be used to connect such devices to the CDC are also described.

3.1 Communication protocols for wired devices

3.1.1 ITU G.hn Protocol Architecture

G.hn defines the physical layer and data link layer (see Figure 24), as stated in the G.9961 and G.9960 ITU recommendations, respectively [21].

The G.hn physical layer defines three sub-layers:

1) Physical Coding Sub-layer (PCS): It is responsible for generating physical layer headers.

2) Physical Medium Attachment (PMA): It is responsible for scrambling and forward error correction coding/decoding

3) Physical Medium Dependent (PMD): It is responsible for the modulation.

The G.hn data link layer defines three sub-layers:

1) Application Protocol Convergence (APC): It accepts frames from upper layers and encapsulates them into G.hn Application Protocol Data Units (APDUs). Upper layer frames can be in Ethernet format.

2) Logical Link Control (LLC): It is responsible for encryption, segmentation, and aggregation. This sub-layer is also responsible for relaying the APDUs.

3) Medium Access Control layer: It determines the way of channel access strategy.



Figure 24: G.hn Protocol Stack

3.1.1.1 PHY Layer

G.hn uses OFDM with programmable set of parameters to address different types of medium. There are three different frequency bands defined in the standard, namely Baseband, Passband and RF band, which are shown Figure 25.

In each band plan, there are 50 MHz and/or 100 MHz bands. A transceiver could select one of the three bands according to the noise level. The number of sub-carriers in the OFDM modulation depends on the bandwidth (Table 18).



Figure 25: G.hn Band Plans for different media (Powerline, Phone Line, Coax)

Bandwidth Powerline Phone Line Coax

100 MHz 4096 2048 512

50 MHz 2048 1024 256

Table 18: Number of Sub-carriers in Different Bandwidths

3.1.1.2 Data Link Layer

Transmissions happen in a domain and are managed by a master, denoted as Domain Master (DM) (see Chapter 4) through MAC cycles, and a MAC cycle is divided into intervals of time, called Transmission Opportunities (TXOPs). The DM assigns at least one TXOP to each node for transmitting its Media Access Plan (MAP) frame, which describes the boundaries of the TXOPs assigned for one or more successive MAC cycles. All nodes in the domain are synchronised with the MAC cycle, read and interpret the MAP, and transmit only during the TXOPs the DM has been assigned with.

To address different applications, three types of TXOP are defined:



- Contention-free TXOP (CFTXOP): It implements pure TDMA, hence only one node can transmit during this TXOP. It is used for target services with fixed bandwidth and strict QoS (e.g., video).

- Shared TXOP with managed time slots (STXOP): It implements a managed CSMA/CA protocol, similar to the one defined in ITU-T G.9954. It is used for services with flexible bandwidth where QoS is an issue (e.g., VoIP, games, interactive video).

- Contention-based TXOP (CBTXOP): It is a shared TXOP, where assigned nodes contend for transmitting packets and contention is based on frame priority, similarly to HomePlug AV. It is used for best effort services with several priority levels.

3.1.2 IEEE P1901

P1901 is a draft standard for broadband over powerline networks. It defines medium access and physical layer specifications and includes two physical layer options. The first is based on HomePlug Alliance’s OFDM modulation, and the second on Panasonic’s wavelet-based OFDM technology.

Even though the standard is not completed, there are already commercial off-the-shelf products on the market. For example, HomePlug AV compliant integrated circuits (ICs) is migrating to the IEEE 1901 powerline standard [22]. Another example is represented by Panasonic's Wavelet-OFDM technology [23].

3.1.2.1 PHY Layer

The OFDM-based PHY uses a maximum of 1893 carriers in the 1.8 to 48 MHz band for maximum data rates up to 400 Mbps. Frequencies above 30 MHz are optional.

The Wavelet-OFDM PHY uses 512 carriers form direct current to 30 MHz and 338 of these carriers are used to carry information. With the use of an optional band above 30 MHz, data rates in the order of 0.5 Gbps can be achieved.

A comparison of the above PHY can be found in Table 19.



FFT-OFDM PHY Wavelet-OFDM PHY

Communication Method FFT-OFDM Wavelet OFDM

Subcarrier Modulation BPSK, QPSK, 8-, 16-, 64-, 256-, 1024-, and 4096-QAM

BPSK, 4-, 8-, 16-, 32-PAM

Frequency Band (MHz) 2–30 (optional bands: 2–48 and 2–60)

2–28 (optional band: 2–60)

Maximum Throughput (Mb/s) 545 544

Error Correction Turbo convolutional coding RS, RS-CC; LDPC (optional)

Table 19: Comparison of PHY in P1901 versions

3.1.2.2 MAC Layer

Medium access layer is based on a master/slave relationship among network stations. The master authorizes and authenticates slave stations in the network and may assign time slots for transmissions. In particular, time is organised in superframes: after beacons transmitted by master, Contention Free Periods (CFP) and Contention Periods (CP) follow. CFPs are reserved by the master to stations requiring low latency and reserved bandwidth. Each network station can communicate directly with all the other stations in the domain.

3.1.3 PRIME OFDM Powerline Communication

PRIME is a recently developed powerline technology for SmartGrids, based on OFDM transmission at PHY layer. In the following, some details of the PRIME OFDM PLC protocol stack are given [1].

3.1.3.1 PHY Layer

This layer provides the interface between the equipment and the transmission medium. The main features as follows:

- This layer allows the exchange of data between neighbour nodes, and the management of signalling for upper layers to inform, them abut the status of the transmission or the arrival/delivery of data.



- It manages control primitives and services, allowing the setting of the automatic gain mode, management of quality data (frame quality, SNR, floor noise level, etc.), etc..

- The layer includes management primitives and services to reset the PHY to a well known initial status, to enter or leave an energy saving mode, to test the PHY layer itself and to retrieve the values of several PHY parameters to be sent to upper layers.

The PRIME reference model is based on IEEE 802.16 protocol layering. This physical layer allows transmission and reception of MPDUs between neighbour nodes. The PRIME PHY consists on an OFDM system using the CENELEC A-band as defined in EN50065-1 [24]. The latter comprises a band from 3 kHz up to 95 kHz, whose usage is restricted to electricity suppliers and their licenses. PRIME OFDM signal uses a reduced frequency bandwidth of 47.363 kHz located on the higher frequencies of the CENELEC A-Band.

Convolutional encoding is performed: the selected encoder is ½ rate binary non-recursive, non-systematic convolutional, with constraint length k=7 and a free distance of 10. Additionally, interleaving is used; because of frequency fading characterizing typical powerline channels, separate OFDM subcarriers at the receiver generally show different amplitudes. Deep fades in the spectrum may cause groups of subcarriers to be less reliable than others, thereby causing bit errors to occur in bursts rather than be randomly scattered. Interleaving is applied along with convolutional encoding to randomize the occurrence of bit errors before to decoding. At the transmitter, the coded bits are permuted in a certain way, which makes sure that adjacent bits are separated by several bits after interleaving. PRIME uses three different interleaving schemes depending on the symbol constellation.

Finally, an additive scrambler is used to avoid the occurrence of long sequences of identical bits. By randomizing the bit stream, crest factor at the output of the IFFT is reduced. This is a cheap but helpful mechanism to decrease the Peak-to-Average-Power-Ratio of the OFDM signal, which may cause problems in the presence of non linear amplifiers. The PRIME PHY uses three different digital modulations: differential BPSK, QPSK and 8PSK.

3.1.3.2 MAC Layer

The MAC layer addresses several issues such as:

- Address resolution and broadcast/multicast addressing. - CSMA/CA algorithm implementation. - Service Nodes functionality as Switches: promotion, demotion.



- Capability of establishing direct connections from one Service Node to another.

- Packet aggregation. - Security issues, such as encryption and security keys management. - PHY robustness management in order to select the best modulation scheme

for a given channel situation. - ARQ mechanisms to recover lost frames.

As stated in section 2.1.1.4, a PRIME system is composed of sub-networks, using tree topologies, where the root is a Base Node, while the intermediate nodes and the leaves are Service Nodes. Each node has a universal MAC address of 48 bits (the EUI-48; IEEE Std 802-2001). Each manufacturer assigns this address during manufacturing process and is used to globally identify a node during network registration process.

Each sub-network has only one Base Node, so the EUI-48 of the Base Node identifies its sub-network uniquely. The Switch Identifier is a unique identifier of 10 bits for each Switch Node inside a sub-network. The sub-network Base Node assigns this identifier during the promotion process.

During registering process, a node receives its own identifier, which is 16 bits long. During connection establishment, a local 6 bits long connection identifier is reserved. Additionally, multicast and broadcast addresses are used for transmission of data and control information. There are several broadcast and multicast address types, depending on the context associated with traffic flow.

Each Service Node has a level in the topology. The nodes connected directly to the Base Node have level 0. The level of any Service Node not directly connected to Base Node is the level of its Switch Node plus one.

The main role of a Base Node is primarily setting up and maintaining a sub-network. In order to execute its goal, the Base Node performs the following tasks:

- Beacon transmission. The Base Node and all Switch Nodes in the sub-network broadcast beacons at fixed intervals of time. The Base Node always transmits exactly one beacon per frame. Switch Nodes transmit beacons with a frequency prescribed by the Base Node at the time of their promotion.

- Promotion and demotion of terminals and switches. All promotion requests, generated by Terminal Nodes, are directed to the Base Node. The Base Node maintains a table of all Switch Nodes in the sub-network. Also, the Base Node is responsible for demoting any registered Switch Nodes. The demotion may either be initiated by the Base or be requested by the Switch Node itself.



- Device registration management. The Base Node receives registration requests from all new devices trying to be part of its managed sub-net. Base Nodes process each received registration request and respond with an Accept or Reject message. Likewise, the Base Node is responsible for the deregistration of any registered Service Node. Deregistration may either be initiated by the Base or be requested by the Switch Node itself.

- Connection setup and management. MAC layer is connection oriented, implying that data exchange is necessarily preceded by connection establishment. The Base Node is always required for all connections in the sub-net, either as an end-point of the connection or as a facilitator of the connection.

- Channel access arbitration. The usage of channel by devices conforming to this specification may be controlled at certain times and open at others. The Base Node prescribes which usage mechanism shall be in force at what time and for what duration.

- Distribution of random sequences for deriving encryption keys. All control messages in the MAC specification are required to be encrypted before transmission. Besides control messages, data transfers may be optionally encrypted as well. The encryption key is derived from a 128 bit random sequence. The Base Node periodically generates a new random sequence and distributes it to the entire sub-network.

- Multicast group management. The Base Node maintains all multicast groups in the sub-network. This implies processing of all join and leave requests from any of the Service Nodes.

Channel access in PRIME sub-networks is performed through both CSMA/CA and Time Division Multiplexing (TDM). Time is divided into composite units of abstraction for channel usage, called frames. Base Node and Service Nodes in a sub-network can access the channel during the Shared Contention Period (SCP) or they may request for dedicated Contention Free Periods (CFPs).

Access to channel in CFP needs devices to make allocation requests to the Base Node. The Base Node, depending on present status of channel usage, may grant access to the requesting device for a specific duration or may deny the request.

Access of channel in SCP does not require any arbitration. The transmitting devices however need to respect the timing boundaries of the SCP within a frame. The composition of a frame in terms of SCP and CFP is communicated in every frame as part of the beacon. A frame is comprised of one or more Beacons, one Shared Contention Period and zero or one Contention Free Periods (CFP).



In a sub-network, the Base Node cannot communicate with every node directly. That is the reason why the switching function is defined as part of the MAC layer. As mentioned earlier, devices that forward traffic are called Switch Nodes. All Service Nodes in a sub-network are capable of acting as Switch Nodes, thus enabling full coverage over the low voltage network.

Switch Nodes do not necessarily need to connect directly to the Base Node. They may attach to other Switch Nodes and form a cascaded chain. There is no limitation to the number of Switch Nodes that may connect to a Switch Node down the cascaded chain, contributing significantly to range extension and scalability.

Switch Nodes are primarily responsible for transmitting Beacon PDUs at fixed intervals to help relaying data and control packets to/from the devices in their domain from/to the Base Node.

Switch nodes do not perform any control functions except for transmitting Beacons. They repeat traffic to/from the Base Node such that every node in the sub-network is effectively able to communicate with the Base Node. Switch Nodes selectively forward traffic that originates from, or is addressed to, one of the Service Nodes in its control hierarchy.

In order to enable better application layer efficiency, a retransmission scheme is specified within the MAC. Implementing ARQ functions is not mandatory for conformance to PRIME specifications. Thus, there is provision for low cost Switch Nodes that choose to not implement any ARQ mechanism at all. Intermediate Switch Nodes that do not implement ARQ are required to transparently bridge traffic. For the others, the ARQ mechanism is Selective Repeat, which provides an efficient performance as compared to other commonly used ARQ schemes.

The security functionality provides privacy, authentication and data integrity to the MAC layer through a secure connection method and a key management policy. While devices may choose not to encrypt data traffic, it is mandatory for all MAC control messages to be encrypted with a specific security profile.

Several security profiles are provided to manage different security needs, which can arise in different network environments. The current version of the specification enumerates two security profiles and leaves scope for adding up to two new security profiles in future versions. In particular, communications having Security Profile 0 are based on the transmission of MAC SDUs without any encryption. This profile shall be used by communications that do not have strict requirements on privacy, authentication or data integrity. Security Profile 1 is based on 128 bit AES encryption of data and its associated CRC. This profile is specified with the aim of fulfilling all security requirements.



3.1.3.3 PRIME Convergence layers

The PRIME specification states that there must be a Convergence Layer, which is part of MAC layer, having the role of adapting the PDUs coming from, or being delivered to, upper layers, to, or from, the common PRIME MAC layer.

The Convergence Layer is separated into two sublayers. The Common Part Convergence Sublayer (CPCS) provides a set of generic services. The Service Specific Convergence Sublayer (SSCS) contains services that are specific of one application layer. There are several SSCS, typically one per application, but only one common part. The use of common part services is optional in the sense that a specific service sublayer will configure into its protocol stack services which are required from the common part, and omit services that are not required. At this moment, CPCS provides the following service to the different SSCS: segmentation and reassembly.

Finally, PRIME provides two different, separate, SSCSs to connect MAC layer to upper layers: the IEC 61334-4-32 LLC Convergence Layer and the IPv4 Convergence Layer. The IEC 61334-4-32 LLC Convergence Sublayer (SSCS) supports the same primitives as the IEC 61334-4-32 standard [25]. The document IEC 61334-4-1 [26] should also be referenced for definitions of the destination address. 4-32 SSCS provides convergence functions for applications that use IEC 61334-4-32 services. Implementations conforming to this SSCS shall offer all LLC services specified in IEC 61334-4-32 (1996-09 Edition) specification. Additionally, PRIME 4-32 SSCS specified in this section provides extra services that help mapping this connection-less protocol to the connection-oriented nature of PRIME MAC.

Its main features are:

- A Service Node can only exchange data with the Base Node and not to other Service Nodes. This meets all the requirements of IEC 61334-4-32, which has similar restrictions.

- Each 4-32 SSCS session establishes a dedicated PRIME MAC connection for exchanging unicast data with the Base Node.

- The Service Node SSCS session is responsible for initiating this connection to the Base Node. Base Node SSCS cannot initiate a connection to a Service Node. However, once the SSCS session has been established, the Base Node will always initiate all data transfers with the Service Nodes SSCS session. This meets all the requirements of IEC 61334-4-32.

- Each 4-32 SSCS listens to a PRIME broadcast MAC connection dedicated to the transfer of 4-32 broadcast data from the Base Node to the Service Nodes. This broadcast connection is used when the 4-32 application on the Base Node makes a transmission request with the destination address used for broadcast



or the broadcast SAP functions are used. When there are multiple SSCS sessions within a Service Node, one PRIME broadcast MAC connection is shared by all the SSCS sessions.

See IEC 61334-4-32 and PRIME specification for 4-32 Convergence Layer for further details on addressing issues and the establishment of data sessions.

On the other hand, the IPv4 Convergence Sublayer (SSCS) provides an efficient method for transferring IPv4 packets over the PRIME network. Its main features are:

- A Service Node can pass IPv4 packets to the Base Node or to other Service Nodes.

- It is assumed that the Base Node acts as a router between the PRIME sub-net and the backbone network. The Base Node could also act as a Network Address Translation (NAT).

- In order to keep the implementation simple, only one single route is supported per local IPv4 address.

- The Service Nodes may use statically configured IPv4 addresses or DHCP to obtain IPv4 addresses.

- The Base Node performs IPv4 to EUI-48 MAC address resolution. Each Service Node registers its IPv4 and EUI-48 MAC address with the Base Node. Other Service Nodes can then query the Base Node to resolve an IPv4 address into an EUI-48 MAC address. This requires the establishment of a dedicated connection to the Base Node for address resolution.

- The convergence layer performs the routing of IPv4 packets. In other words, the convergence layer will decide whether the packet should be sent directly to another Service Node or forwarded to the configured gateway.

- Although IPv4 is a connectionless protocol, the IPv4 convergence layer is connection-oriented. Once address resolution has been performed, a connection is established between the source and destination Service Node for the transfer of IP packets. This connection is maintained while traffic is being transferred and may be removed after a period of inactivity.

- Optionally TCP/IPv4 headers may be compressed. Compression is negotiated as part of the connection establishment phase.

- The broadcasting of IPv4 packets is supported using the MAC broadcast mechanism.



- The multicasting of IPv4 packets is supported using the MAC multicast mechanism.

The convergence layer has a number of connection types. For address resolution there is a connection to the Base Node. For IPv4 data transfer there is one connection per destination node: the Base Node acts as the IPv4 gateway to the outside world or to another node in the same sub-network.

3.1.3.4 Routing and Transport Layers

Standard IP network layer and TCP/UDP transport layer are used for the IPv4-based profile over PRIME to transport DLMS / COSEM (Companion Specification for Energy Metering) APDUs. See [27], [28] and [29] for further details. IEC 62056-47 [30] defines a TCP/IP wrapper for DLMS/COSEM when using the IPv4-based profile. No network neither transport layers are used for a 4-32 based profile over PRIME.

3.1.3.5 Upper Layers (Session, Presentation and Application)

The application layer is the COSEM application layer. It provides services to the COSEM application process and uses the services of the connectionless or the HDLC based LLC sublayer.

The application layer contains two main Application Service elements, namely the Association Control Service Element (ACSE), and the xDLMS ASE. The task of ACSE is to establish, maintain, and release application associations. For the purposes of DLMS/COSEM connection oriented communication profiles, the Connection Oriented ACSE. The task of the xDLMS_ASE is to provide data transfer services between COSEM application processes. It is based on the DLMS standard and it has been extended for DLMS/COSEM. The main objective of the DLMS/COSEM approach is to provide a business domain oriented interface object model for systems while keeping backward compatibility to the DLMS standard. To meet these objectives, DLMS/COSEM includes an evolution of DLMS.

3.1.3.6 DLMS/COSEM data model

On the server side, the COSEM device and object model, are specified in [31] (the Blue Book), in [32] and in [33] applies. Each logical device represents an application process.



The client side application processes make use of the resources of the server side application process. A physical device may host one or more client application processes.

The DLMS/COSEM data model profile depends on the projected functionality for the device. The standard data model can be extended with country-specific or manufacturer-specific classes and objects, not necessarily related only to metering functions.

3.2 Communication protocols for wireless devices

3.2.1 IEEE 802.15.4

As stated in Chapter 2, IEEE 802.15.4 represents a short-range wireless technology intended for applications with relaxed throughput and latency requirements [4]. According to the key features of this technology (low complexity, low cost, low power consumption, low data rate), this standard is particularly suitable for Wireless Sensor Networks (WSNs).

In the following, some technical details related to PHY and MAC sublayers protocols are given, even if we let the reader refer to the standard for a more detailed description.

3.2.1.1 PHY Layer

The 802.15.4 physical layer operates in three different unlicensed bands (and with different modalities). However, DSSS is wherever mandatory to reduce the interference level in shared unlicensed bands.

TPHY provides the interface with the physical medium. It is in charge of radio transceiver activation and deactivation, energy detection, link quality, clear channel assessment, channel selection, and transmission/reception of message packets. Moreover, it is responsible for establishment of the RF link between two devices, bit modulation and demodulation, synchronization between transmitter and the receiver, and, finally, for packet level synchronization.

IEEE 802.15.4 specifies a total of 27 half-duplex channels across the three frequency bands, and is organized as follows:

- The 868 MHz band, ranging from 868.0 and 868.6 MHz and used in the European area, implements a raised-cosine-shaped BPSK modulation format, with DSSS at chip-rate 300 kchip/s (a pseudo-random sequence of 15 chips



transmitted in a 25 µs symbol period). Only a single channel with data rate 20 kbps is available and, with a required minimum -92 dBm RF sensitivity, the ideal transmission range (i.e., without considering wave reflection, diffraction and scattering) is approximately 1 km;

- The 915 MHz band, ranging between 902 and 928 MHz and used in the North American and Pacific area, implements a raised-cosine-shaped BPSK modulation format, with DSSS at chip-rate 600 kchip/s (a pseudo-random sequence of 15 chips is transmitted in a 50 µs symbol period). Ten channels with rate 40 kbps are available and, with a minimum required –92 dBm RF sensitivity, the ideal transmission range is approximately 1 Km;

- The 2.4 GHz ISM band, which extends from 2400 to 2483.5 MHz and is used worldwide, implements a half-sine-shaped O-QPSK modulation format, with DSSS at 2 Mchip/s (a pseudo-random sequence of 32 chips is transmitted in a 16 µs symbol period). Sixteen channels with data rate 250 kbps are available and, with minimum –85 dBm RF sensitivity required, the ideal transmission range is approximately 200 m.

The ideal transmission ranges mentioned above are computed considering a transmit power set at –3 dBm, which any IEEE 802.15.4 compliant device should be able to support. However, real transmission ranges are significantly shorter in real conditions owing to obstacles and multipath propagation. In particular, in indoor environments like those of interest to eDIANA scenarios, wall absorption can provide transmission ranges shorter than 20-40 meters in some cases.

Power consumption is a primary concern, so, to achieve long battery life, energy must be taken continuously at an extremely low rate, or in small amounts at a low power duty cycle: this means that IEEE 802.15.4-compliant devices are active only during a short time. The standard allows some devices to operate with both the transmitter and the receiver inactive for over 99% of time. As a result, the instantaneous link data rates supported (i.e., 20 kbps, 40 kbps, and 250 kbps) are higher with respect to the data throughput in order to minimize device duty cycle.

3.2.1.2 MAC Layer

MAC layer provides access control to a shared channel and reliable data delivery. In particular, IEEE 802.15.4 uses a protocol based on the CSMA/CA algorithm, which requires listening to the channel before transmitting to reduce the probability of collisions with other ongoing transmissions. The main functions performed by MAC are: association and disassociation, security control, optional star network topology functions (such as beacon generation and GTS management), generation of ACK



frames (if used), and finally to provide application support for the two possible network topologies described in the standard.

IEEE 802.15.4 defines two different operational modes, namely the beacon-enabled and non beacon-enabled, which correspond to two different channel access mechanisms. In the non beacon-enabled mode, nodes use an unslotted CSMA/CA protocol to access the channel and transmit their packets. The algorithm is implemented using units of time called backoff periods. In the beacon-enabled mode, on the contrary, the access to the channel is managed through a superframe, starting with a packet, called beacon, transmitted by the WPAN coordinator. The superframe may contain an inactive part, allowing nodes to enter in sleeping mode, whereas the active part is divided into two parts: the Contention Access Period (CAP) and the Contention Free Period (CFP), composed of GTSs, that can be allocated by the coordinator to specific nodes. The use of GTSs is optional.

The duration of the active part and of the whole superframe, depend on the value of two integer parameters ranging from 0 to 14, that are, respectively, the Superframe Order (SO), and the Beacon Order (BO), with BO larger than or equal to SO. BO defines the interval of time between two successive beacons, namely the Beacon Interval, denoted as BI, which is equal to:

s

BO TBI ⋅⋅⋅= 26016 Eq. 2

where Ts is the symbol time equal to 16 µs in case the 2.4 GHz band is used.

The duration of the active part of the superframe, containing CAP and CFP, namely the Superframe Duration, denoted as SD, is equal to:

s

SO TSD ⋅⋅⋅= 26016 Eq. 3

In the beacon-enabled mode a device wishing to send data to the WPAN coordinator needs to listen for a beacon, then it will use the CAP portion of the superframe if it does not have a GTS assigned. If the device has a GTS assigned, it waits for the appropriate one to transmit its data frame. Afterwards, the WPAN coordinator sends back an acknowledgement to the device. When the WPAN coordinator has data for a device, it may use the beacon payload, or it may set a special flag in its beacon. Once the appropriate network device detects that the coordinator has pending data for it, it sends back a “data request” message. The coordinator responds with an acknowledgment followed by the data frame.

In non beacon-enabled mode, a network device wishing to transfer data sends a data frame to the coordinator using CSMA/CA and the coordinator responds sending an acknowledgement. When a WPAN coordinator requires making a data transfer to a device, it shall keep the data until the network device sends a “data request” message.



3.2.1.3 Upper Layers: Zigbee

The purpose of ZigBee Alliance is to univocally describe a protocol stack on top of the PHY/MAC IEEE 802.15.4 standard. In such a way, interoperability among devices produced by different companies, implementing the ZigBee protocol stack, is guaranteed.

The ZigBee stack architecture is composed of a set of blocks called layers. Each layer performs a specific set of services for the layer above. The ZigBee stack architecture is depicted in detail in Figure 26. Given the IEEE 802.15.4 specifications on PHY and MAC, ZigBee Alliance provides the network layer and the framework for the application layer.

The responsibilities of the ZigBee network layer include: mechanisms to join and leave a network, frame security, routing, path discovery, one-hop neighbors discovery, neighbor information storage.

The ZigBee application layer consists of the application support sublayer, the application framework, the ZigBee device objects and the manufacturer-defined application objects. The responsibilities of the application support sublayer include: maintaining tables for binding (defined as the ability to match two devices together based on their services and their needs), and forwarding messages between bound devices. The responsibilities of the ZigBee device objects include: defining the role of the device within the network (e.g., WPAN coordinator or end device), initiating and/or responding to binding requests, establishing secure relationships between network devices, discovering devices in the network, and determining which application services they provide.

More details about the different profiles defined at the application layer, security and commissioning issues, will be included in D2.3-B. Here we only report a comparison between the different versions of Zigbee (see Table 20).



Figure 26: Zigbee protocol stack [6]

2004 2006 2007 PRO

Switching to another channel during the network operation

� � � �

Stochastic address assignment � � � �

Group addressing � � � �

Many-to-one routing � � � �

Source routing � � � �

Trust Center can be any device in the network � � � �

High security mode � � � �

Fragmentation and reassembly of messages � � � �



Standardized commissioning � � � �

Improved reliability and robustness in mesh. � � � �

Cluster Library Support � � � �

Table 20: Zigbee versions comparison

3.2.2 Bluetooth Low Energy

3.2.2.1 Overview

Not shown for confidentiality issues.

Figure 27: Advertising Events [16] (omissing)

Figure 28 : Connection Events [16] (omissing)

Figure 29 : LE Architecture (omissing)

3.2.2.2 PHY Layer


Table 21 : Operating frequency bands (omissing)

Table 22 :Transmission power (omissing)



3.2.2.3 MAC Layer


Figure 30 : State diagram of the Link Layer state machine [16] (omissing)

3.2.2.4 Upper Layer


3.3 Communication protocols for multi-interface devices

3.3.1 IP cameras

IP cameras are involved at Cell level in the eDIANA platform. IP cameras support the general goal of the Project by providing information on the environment, such as human presence, light intensity, and others.

Figure 31: Direct connection between IP cameras and the CDC



The IP cameras can be integrated in both wired and wireless (WiFi 802.11g) networks using different protocols. Until now, these protocols have been proprietary, developed by different manufacturers. However, recently, several initiatives on protocol standardization for cameras have been launched. As a result of these initiatives, two protocols, ONVIF and PSIA have been defined.

ONVIF is an open industry forum for the development of a global standard for the interface of network video products. ONVIF is committed to the adoption of network video in the security market. The ONVIF specification aims at ensuring interoperability between network video products regardless of manufacturer. The ONVIF specification defines a common protocol for the exchange of information among network video devices including automatic device discovery, video streaming and intelligence metadata. Some commercial cameras implementing ONVIF protocols are already available while, until now, there are no devices implementing PSIA protocol in the market.

In the following, ONVIF protocols will be described as preferred option to be used within the eDIANA platform. A selection of the ONVIF applicable functionalities and capabilities in this Project has been extracted from the complete specification; however, all the ONVIF protocol capabilities and characteristics briefly defined in the next sections are exhaustively described in the documentation published by ONVIF organization.

3.3.1.1 ONVIF Protocol specifications

The ONVIF complete specifications define standardized procedures for communication between network video clients and video transmitter devices. This new set of specifications make it possible to build network video systems with video transmitters from different manufacturers using common and well defined interfaces. These interfaces cover functions such as device management, real-time streaming of audio and video, event handling, Pan-Tilt-and-Zoom (PTZ) control and video analytics.

The management and control interfaces defined in this specification are described as Web Services. The ONVIF complete specification also contains full XML schema and Web Service Description Language (WSDL) definitions for the network video services.

In order to offer full plug-and-play interoperability, the specification defines procedures for device discovery. The device discovery mechanisms in the specification are based on the WS-Discovery specification with extensions. These extensions have been introduced in order to cover the specific network video discovery needs.

The specification is not limited to discovery, configuration and control functions, but defines precise formats for media and metadata streaming in IP networks using



suitable profiling of IETF standards. Furthermore, appropriate protocol extensions have been introduced in order to make it possible for network video manufacturers to offer a fully standardized network video transfer solution to its customers and integrators.

The ONVIF core specifications are based on network video use cases covering both local and wide area network scenarios. The ONVIF specification framework covers procedures from the network video transmitter deployment and the configuration phase to the real time streaming phase for these different network scenarios. The framework starts from a core set of interface functions, and it shall be easy to extend and enhance the specifications as future versions are released.

The main focus of the specification is the interface between a Network Video Transmitter (NVT) and a Network Video Client (NVC). The specification covers device discovery, device configuration, events, PTZ control, video analytics and real time streaming functions.

The core specification defines the ONVIF framework, commands and requirements. The different services are defined in the relevant service WSDL document (WSDL is used for describing the services).

The ONVIF specification framework is built upon Web Service standards. All configuration services defined in the specification are expressed as Web Service operations and defined in WSDL with HTTP as the underlying transport mechanism.

Figure 32: WEB Services based developed principles.

Figure 32 gives an overview of the basic principles for development based on Web Services. The service provider (NVT) implements the ONVIF service or services. The service is described using the XML-based WSDL. Then, the WSDL is used as the basis



for the service requester (NVC) implementation/integration. Client-side integration is simplified through the use of WSDL compiler tools that generate platform specific code that can be used by the client side developer to integrate the Web Service into an application.

The Web Service provider and requester communicate using the SOAP message exchange protocol. SOAP is a lightweight, XML-based messaging protocol used to encode the information in a Web Service request and in a response message before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols. This ONVIF specification defines conformant transport protocols for the SOAP messages for the described Web Services.

3.3.1.2 Device Discovery

One of the most interesting characteristics of this protocol to be used onto the eDIANA platform is the Device Discovery service. This functionality provides a seamless component architecture.

ONVIF-defined configuration interfaces are Web Services interfaces that are based on the WS-Discovery standard. This use of this standard makes it possible to reuse a suitable existing Web Service discovery framework, instead of requiring a completely new service or service addressing definition.

The specification defines ONVIF-specific discovery behaviour. For example, a fully interoperable discovery requires a well defined service definition and a service searching criteria. The specification covers device type and scope definitions in order to achieve this.

All NVTs must include the service address of the device service. Once the NVC has the NVT device service address, it can receive detailed NVT device information through the device service.

In addition, a new optional remote Discovery Proxy (DP) role is introduced in this specification. The remote DP, allows NVTs to register the remote DP and NVCs to find registered NVTs through the remote DP even if NVC and NVT reside in different administrative network domains.



3.3.1.3 Device management

Device management functions are handled through the device service. This is the entry point to all other services provided by NVT. Device management interfaces consist of several commands that can be grouped as follows.

- Capabilities: The capability command allows an NVC to ask for the services provided by an NVT and to determine which ONVIF services, as well as brand specific services, are offered by the NVT.

- Network: Network commands allow standardized management of functions, such as Get and set of hostname, network interface configurations, etc..

- System: System commands are used to manage NVT system settings such as device information, system backups, system log, service discovery parameters, etc..

- Security: Security operations are used to manage the NVT security configurations, such as access security policy, HTTPS server certificates, etc..

- Input/Output: Input/Output (I/O) commands are used to control the state or observe the status of the I/O ports.

3.3.1.4 Device configuration

Regarding Image Configuration, the imaging service provides configuration and control data for imaging specific properties. The service includes operations to get and set imaging configurations (e.g., exposure time, gain and white balance), get imaging configuration options (valid ranges for imaging parameters), move focus lens, etc..

Real-time video and audio streaming configurations are controlled using media profiles. A media profile maps a video and/or audio source to a video and/or an audio encoder, PTZ and analytics configurations. The NVT presents different available profiles depending on its capabilities (the set of available profiles might change dynamically though).



Figure 33: A media profile.

An NVT must provide at least one media profile at boot. An NVT should provide “ready to use” profiles for the most common media configurations that the device offers. A profile consists of a set of interconnected configuration entities (e.g., video or audio source configuration). Configurations are provided by NVT and can be either static or created dynamically by NVT. For example, the dynamic configurations can be created by the NVT depending on current available encoding resources. All NVTs must support a fixed or dynamic profile with at least a video source and a video encoder configuration. A complete profile configuration is illustrated in Figure 34. A complete media profile defines how and what to present to the NVC in a media stream as well as how to handle PTZ input and Analytics.

Figure 34 : Complete profile configuration



3.3.1.5 Real Time Streaming

The ONVIF specification defines media streaming options and formats. A distinction is made between media plane and control plane, as illustrated in the Figure 35. ONVIF defines a set of media streaming (audio, video and metadata) options all based on RTP in order to provide interoperable media streaming services.

The metadata streaming container format allows well-defined, real-time streaming of analytics, PTZ status and notification data. Media configuration is done over SOAP/HTTP and is covered by the media configuration service. Media control is accomplished over RTSP. ONVIF defines RTP, RTCP and RTSP profiling, as well as JPEG over RTP extensions and multicast control mechanisms.

Figure 35: ONVIF layer structure.

3.3.1.6 Event handling

Event handling is based on the OASIS WS-BaseNotification and WS-Topics specifications. These specifications allow the reuse of a rich notification framework without the need of redefining event handling principles, basic formats and communication patterns. Firewall traversal, according to WS-BaseNotification, is handled through a PullPoint notification pattern. This pattern, however, does not allow real-time notifications. Hence, this specification defines an alternative PullPoint communication pattern and service interface. The PullPoint pattern allows a client



residing behind a firewall to receive real-time notifications while utilizing the WS-BaseNotification framework.

A fully standardized event requires standardized notifications. However, the notification topics will, to a large extent, depend on the application needs. Consequently, this specification does not require particular notification topics, instead it defines a set of basic notification topics that an NVT is recommended to support.

3.3.1.7 Video analytics

Video analytic applications are divided into image analysis and application-specific parts. The interface between these two parts produces an abstraction that describes the scene based on the present objects. Video analytic applications are reduced to a comparison of the scene descriptions and of the scene rules (such as virtual lines that are prohibited to cross, or polygons that define a protected area). Other rules may represent intra-object behaviour such as objects following other objects (to form a tailgating detection). There are also object-oriented rules to describe prohibited object motion, which may be used to establish a speed limit.

These two separate parts, referred to the video analytics engine and as the rule engine, together with the events and actions, form the video analytics architecture according to this specification, as illustrated in Figure 36. The video analytics architecture consists of elements and interfaces. Each element provides a functionality corresponding to a semantically unique entity of the complete video analytics solution. Interfaces are unidirectional and define an information entity with a unique content. Only the interfaces are subject to this specification. It is central to this architecture the ability to distribute any element or set of adjacent elements to any device in the network.

The following interfaces are within the scope of the current ONVIF specification: Analytics Configuration Interface, Scene Description, Rule Configuration Interface, Event Interface.

The specification defines a configuration framework for the Video Analytics Engine. This framework enables an NVC to ask the NVT for supported analytics modules responsible for their configurations. Configurations of such modules can be dynamically added, removed or modified by a client, allowing an NVC to run multiple Video Analytics Modules in parallel if supported by the NVT.



Figure 36 : Video analytics architecture.

The output from the Video Analytics Engine is called a Scene Description. The Scene Description represents the abstraction of the scene in terms of the objects, either static or dynamic, that are part of the scene. This specification defines an XML-based Scene Description Interface including data types and data transport mechanisms.

Rules describe how the scene description is interpreted and how to react based on that information. The specification defines standard rule syntax and methods to communicate these rules from the application to the NVT.

An event signals the state of the analysis of the scene description and the associated rules. The event interface is both the input and the output of the event engine element. The event interface is handled through the general notification and topics framework. All other interfaces in the architecture are included for completeness only, but are outside the scope of the current specification.

An NVT supporting analytics must implement the Scene Description and Event Interface, as well as the Configuration of Analytics by the Media Service. If the NVT additionally supports a rule engine, responsible for analytics engine as defined by ONVIF, then it must implement the Rules Analytics Modules Interface.



4. Network Topology

As stated in Chapter 1, two different networks will be present in the architecture: the intra-Cell network, devoted to the communication among the Cell level devices and CDC, and the inter-Cell network, devoted to the communication among the MCC and one or more CDCs. Both wireless and wired technology solutions could be used in both networks.

Regarding the inter-Cell network, wired solutions represent the best option. The topology defined by the most suitable wired technologies are reported here. In the case of use of wireless options in such network, Wi-Fi links could be established.

As far as the intra-Cell network is concerned, the use of a wireless technology represents the best option, owing to the need to connect also devices that are not attached to the electric network. Given this, the use of only wireless links within the Cell seems to be the best and cheapest solution. However, also heterogeneous solutions, using both wired and wireless technologies, could be possible. In the latter case, a suitable definition of when and in which cases the two different solutions should be used, must be provided. As an example, devices attached to the grid could use wired links after discovering that their packets are not correctly received by the CDC. In case acknowledge messages are used in the wireless network, in fact, the node could decide to use wired links, once it does not receive any acknowledge (this means in fact, that some connectivity or congestion problems are present in the wireless network). An other possibility is to use wired links for transmissions of commands coming from the CDC, since they have an high priority. However, even though such solution appears more flexible, it brings to a large increase of complexity and costs, since all the iEis should be equipped with two interfaces, one toward the wireless medium (air-interface) and another toward the wired network.

Owing to these issues, Task 2.3 partners retain that the use of only wireless within the Cell is the most suitable solution. However, for the sake of completeness this Chapter shortly deals also with topologies for PLCs to be used within the Cell, since also such solution is possible.

Most of the Chapter will be dedicated to the identification of the possible topologies of the two most promising wireless technologies selected: IEEE 802.15.4 and Bluetooth LE. Note that, owing to the lack of BT LE devices available on the market at the moment and also to the lack of scalability of BT networks, the attention will be mainly focused on IEEE 802.15.4. For this technology, different studies realized through simulation analysis and experimental measurements will be reported, to show examples of performance metric that could be achieved with such networks. In particular, a suitable comparison of performance achieved in the case of star and tree-based topologies, considering a building composed of one or more apartments/working units, will be reported. This study has been performed through



simulations at UNIBO. Finally, some experimental measurements realised in office buildings by Apptech and UoR, will be treated.

4.1 Topologies for Wired Network

In this section the topologies of some of the most promising PLC technologies are presented. These technologies could be applied to both the intra- and the inter-Cell networks.

4.1.1 ITU G.hn

G.hn allows to connect up to 250 nodes operating in the network. It defines several profiles to address applications that need different levels of complexity. A G.hn network consists of one or more domains. A domain is a group of G.hn nodes that can communicate with each other. Each domain is managed by a Domain Master (DM), which is in charge of adding nodes to the domain, performing bandwidth reservations, etc.. Different domains in the same network are connected with Inter-Domain Bridges (IDB), allowing nodes of separate domains to communicate among them. IDBs can also connect domains with wired or wireless alien networks (e.g., DSL, WLAN, etc.). Nodes in a domain can communicate with other nodes directly or through one or more relays. The maximum number of hops is still under study.

Domains may require mutual coordination against interference of other technologies coexisting in the same medium. Therefore a node, denoted as Global Master (GM) node, could be present for coordinating domains. The GM collects statistics from domains, derives appropriate parameters for each domain and sends them to the DMs. Each DM imposes these parameters to all the nodes of its domain. Figure 37 shows a G.hn network model [21].

An example of G.hn residential network is presented in Figure 38 [21]. This network includes three domains, having its own DM: coaxial, phone line and powerline domains. In this example, the alien networks are WLAN, USB2, Ethernet and a residential access network. A residential gateway bridges among powerline and coaxial domains, and also among the G.hn and alien networks.



Figure 37. G.hn network model

Figure 38. Example of home network topology [21]



4.1.2 PRIME network topology

The topology defined by the standard, is basically a tree, where three different types of nodes can be found: a Base Node, which is the root of the tree, and a variable number of Service Nodes (up to several hundreds of devices, the top limit is considered far beyond the needs of a normal Cell level or MacroCell level structure). The Service Nodes can represent two different roles in the network: as branches or Switch Nodes, and as leaves or Terminal Nodes. Terminal Nodes can be directly connected to the Base Node, or can be connected to it through one or more Switch Nodes. Depending on the Convergence Layer applied, direct communications between Terminal Nodes could be allowed or not. Anyway, the communication flow between the Base Node and the rest of the nodes and vice-versa is the most frequent case.

The PRIME topology could be applied to both the inter- and the intra-Cell networks. In the first case, the role of the Base Node should be implemented by the MCC, while each CDC should include a Service Node. In case a CDC is too far from the MCC, to make impossible direct connection, other CDCs could act as Switch Nodes, extending the physical range of the network. In the intra-Cell case, instead, the role of the Base Node should be implemented by the CDC, letting the rest of the devices in the Cell be Service Nodes, some of which might act as Switch Nodes to extend the physical range of the network.

The dynamic behavior of a PRIME network is described in the following.

First of all, the presence of a PRIME node acting as Base Node is needed. The Base Node functionalities include: solving addressing issues for all the network, routing messages between nodes, registration of new nodes, deregistration of old nodes, etc..

Any Service Node starts its operation looking for a Base Node or a Switch Node to be registered to. If a Base Node is detected, the Base Node registers the new Service Node and from this time on, the new Service Node can start its normal operation as communication interface for the device to which it is attached. If another Service Node is detected, a promotion request can be delivered from the latter node to the Base Node, in order to be promoted to a Switch Node. If this procedure is successfully performed, the new Switch Node can then register the new Service Node, allowing it to start its normal operation as communication interface for the device to which it is attached. Only the Base Node has the ability to promote (or demote, that is the inverse procedure) a Service Node from the status of Terminal to Switch. All these procedures are automatically executed, thus there is no need for an operator to realise the complete network topology manually. The Base Node contains all the information needed to solve the addressing and routing issues for all the



nodes in the network. The Figures below illustrate the dynamic construction of a PRIME network.

First stage: An active Base Node alone, sending beacons periodically.

Next stage: A Service Node active, but not yet connected to the network, detects the presence of the Base Node and asks for joining the network. After being registered by the Base Node, a link level connection is established and the Service Node is now capable of exchanging information with the Base Node.

Next stage: The Figure above represents three registered Service Nodes that could individually detect the signal sent by the Base Node (i.e., no need of a Switch Node). After being registered by the Base Node, a link level connection is established for each of the Service Nodes, and all of them are now capable of exchanging information with the Base Node.

Base node

Base node

Service node

Base node

Service node Service node Service node

Base node

Switch node Terminal node Terminal node

Terminal node



Next stage: A new Service Node claims for registration in the network. The signal of the Base Node cannot be detected by the candidate, but there is a Service Node attached to the network in the range. Thus, a promotion request is delivered from this node to the Base Node, and when accepted, the Terminal Node turns its operation mode to Switch, and the candidate node can then be joined to the network via the new Switch Node. The Switch Node adds to its normal functions as Service Node another one: it starts acting as a router for the Service Nodes connected to the network through it.

4.2 Topologies for the Wireless Network

Wireless sensors have the intrinsic ability to easily connect to their physical neighbors, which generates local fully-connected topologies. But the energy required to maintain this network connectivity is high. An improvement lies in partially disabling some of the sensors communication capabilities. For example, by disabling reception and limiting transmissions of data: some sensors can act as senders only, while other sensors can have a central role as repeaters of the signal. This optimization reduces the energy consumption, and generates different network topologies. One efficient solution (called “clustering”) is to group sensors into local clusters, choosing one device as repeater of the whole cluster data. This requires auto-organization capabilities: implementing algorithms for a fair division of the roles in the network (e.g., rotation of the role of repeaters among the nodes), and fault-compensation to solve problems created by the “death” of repeaters. The topology of the wireless network will impact the energy consumption of devices, which is related to the role they assume in the organization.

In the eDIANA scenarios, the Cell level devices equipped with the iEi, will be plugged in (since they include the PCS), but the sensors used for monitoring the environmental will be battery charged and their energy supply will be limited. Therefore, the study of the energy efficiency of the different topologies is fundamental.

Finally, note that also connectivity issues must be accounted for. In case of large Cells, in fact, devices cannot reach the CDC through direct links, therefore a star topology cannot be applied and tree-based or mesh topologies are needed.

4.2.1 IEEE 802.15.4/Zigbee Topologies

The IEEE 802.15.4 standard defines two types of device: Full Function Device (FFD) and Reduced Function Device (RFD). The FFD contains the complete set of MAC



services and can operate either as coordinator, or as simple network device. The RFD contains a reduced set of MAC services and can operate only as a network device.

IEEE 802.15.4 networks may be organised in two topologies: star and peer-to-peer topologies. In the first case, the star is formed around a FFD, acting as PAN coordinator, which is the only node allowed to establish links with more than one device. In peer-to-peer topology, instead, each device is able to form multiple links to reach other devices and redundant paths between two nodes could be available.

Star topology is preferable in case the coverage area is small and low latency is required by the application. In this topology, communication is controlled by the WPAN coordinator that acts as network master, sending packets, named beacons for synchronization and managing device association. Network devices are allowed to communicate only with the WPAN coordinator and any FFD may establish its own network by becoming a WPAN coordinator according to a predefined policy. A network device wishing to join a star network listens for a beacon message and, after receiving it, the network device can send an association request back to the WPAN coordinator, which allows the association or not. Star networks support also a non beacon-enabled mode. In this case, beacons are used for association purpose only, whereas synchronization is achieved by polling the WPAN coordinator for data on a periodic basis. Star networks operate independently from their neighboring networks.

Peer-to-peer topology is preferable in case a large area should be covered and latency is not a critical issue. This topology allows the formation of more complex networks and permits any FFD to communicate with any other FFD behind its transmission range via multiple hops. Each device in a peer-to-peer structure needs to proactively search for other network devices. Once a device is found, the two devices can exchange parameters to recognize the type of services and features each supports. However, the introduction of the multi-hop feature requires additional device memory for routing tables.

IEEE 802.15.4 can also support other network topologies, such as mesh and tree-based. These topologies are not described in the IEEE 802.15.4 standard (dealing only with PHY and MAY), but they are described in the ZigBee Alliance specifications.

ZigBee uses slightly different terminology: the 802.15.4 coordinator is denoted as ZigBee Coordinator (ZC); the routers in the topology are denoted as ZigBee Routers (ZR) and they are 802.15.4 FFDs; the leaves of the topology (i.e., devices that are neither coordinator and routers), are called ZigBee End Devices (ZED), and they are 802.15.4 RDFs. A simple star topology is shown in Figure 39.



Figure 39: Star Topology

Figure 40 shows a tree-based topology, where the tree is rooted at the ZC and ZRs forward the data coming from ZEDs toward the ZR. In this topology, only one path between whatever two devices in the tree, exists.

Figure 40: Tree Topology

Finally, in Figure 41 an example of mesh topology is illustrated. In this topology, multiple paths between two devices are present, therefore in case of failure in one of these alternative paths, the message can still reach the destination. However, this comes at the expense of potential high message latency and energy consumption.



Figure 41: Mesh Topology

ZigBee mesh networks usually implement the Ad hoc On Demand Distance Vector (AODV) algorithm in order to meet objectives such as cost-effictiveness and path robustness [34], [35]. The route discovery in a ZigBee network is similar to the AODV routing protocol [36]. The source node broadcasts a Route Request (RREQ) packet and then intermediate nodes rebroadcast RREQ if they have routing discovery table capacities. Once the destination node receives the RREQ, it responds by unicasting a route reply (RREP) packet to its neighbor from which it received the RREQ. The destination will choose the routing path with the lowest cost and then will send a route reply.

4.2.1.1 The IEEE 802.15.4 Topology Formation Procedure

The IEEE 802.15.4 Group defined a mechanism to support a WPAN coordinator in channel selection when starting a new WPAN, and a procedure, called association procedure, which allows other devices to join the WPAN. A WPAN coordinator wishing to establish a new WPAN needs to find a channel which is free from interference that would render the channel unsuitable (e.g., in a multi-sink network, a channel may be already occupied by other WPANs). The channel selection is performed by the WPAN coordinator through the energy detection scan which returns the measure of the peak energy in each channel. It must be noticed that the standard only provides the energy detection mechanism but it does not specify the channel-selection logic.

The operations accomplished by a device to discover an existing WPAN and to join it can be summarised as follows: i) search for available WPANs; ii) select the WPAN to join; iii) start the association procedure with the WPAN coordinator or with another FFD device, which has already joined the WPAN. The discovery of available WPANs is



performed by scanning beacon frames broadcasted by the coordinators. Two different types of scan that can be used in the association phase are proposed:

- passive scan: In beacon-enabled networks the associated devices periodically transmit beacon frames hence the information on the available WPAN can be derived by eavesdropping the wireless channels;

- active scan: In non beacon-enabled networks the beacon frames are not periodically transmitted but shall be explicitly requested by the device by means of beacon request command frame.

After the scan of the channels, a list of available WPANs is used by the device to choose the network to try to connect with. In the standard, no specific procedure to select a WPAN is provided and so, this selection among potential parents is open for different implementations. Hence, the device sends an association request frame to the coordinator device by means of which the selected network was discovered. The association phase ends with a successful association response command frame to the requesting device. This procedure basically results in a set of MAC association relationships between devices, named in the following parent-child relationship.

4.2.1.2 The Zigbee Tree-Based Topology

The topology formation procedure is started by the WPAN coordinator, which broadcasts beacon packets to neighbour nodes. A candidate node receiving the beacon may request to join the network at the WPAN coordinator. If the WPAN coordinator allows the node to join, it will begin transmitting periodic beacons so that other candidate nodes may join the network.

Nodes must be in beacon-enabled mode: each child node tracks the beacon of its parent (see Figure 42, where the tracking period is outlined as a dashed rectangle). A core concept of this tree topology is that the child node may transmit its own beacon at a predefined offset with respect to the beginning of its parent beacon: the offset must always be larger than the parent superframe duration and smaller than beacon interval. This implies that the beacon and the active part of child superframe reside in the inactive period of the parent superframe; therefore, there is no overlap at all between the active portions of the superframes of child and parent. This concept can be expanded to cover more than two nodes: the selected offset must not result in beacon collisions with neighbouring nodes. This implies that the node must record the time stamp of all neighbouring nodes and selects a free time slot for its own beacon. Obviously a child will transmit a beacon packet only in case it is a router in the tree; if the child is a leaf it has only to transmit the packet to its parent. Each child will transmit its packet to the parent in the active part (CAP or CFP) of the parent superframe.



Therefore, each router in the tree, after the reception of the beacon coming from the parent, will select the instant in which transmits its beacon. Beacon scheduling is necessary to prevent the beacon frames of one device from colliding with either the beacon frames or data transmissions of its neighboring devices.

Figure 42: Beacon Tracking

4.2.2 Bluetooth LE Topologies

As stated above, the only topology made available by BT LE is the star topology.

Bluetooth LE networks, in fact, are organised in piconets. A piconet consists of a master node, managing the communication, and some slave nodes, directly connected to the master. The maximum number of devices that could be simultaneously attached to the same master is seven. This limits the scalability of the network. Moreover, no direct communication between slaves in the piconet is allowed.

Different and independent piconets may exist in the environment, forming a scatternet. The piconets in a scatternet could also be partially overlapped, since one or more nodes may belong to different piconets and have different roles in different piconets. The following state and role restrictions inside the same piconet must be applied: i) a node cannot operate as master and slave at the same time; ii) each slave can be connected only to one node (i.e., the master); ii) each master can have multiple connections.

In Figure 43 an example of a possible piconet implementation is shown.



Figure 43: Example of Bluetooth LE topology [16]

In order to create more complex network topologies, it is possible to use BDR and LE combined core configuration. This configuration combines classic and LE version on a single chip. Using dual mode devices creation of a star-bus network topology is possible, with no limit on the number of active slaves.

The dual mode devices act as Hubs and the single mode devices acts as nodes. The connection between Hub and Node is realised through LE technology, while the backbone connection between different Hubs use the BDR.

Through this implementation we could cover an apartment: each Hub can be the master of a network that manages LE devices in a room. Properly positioning the hubs, it is possible to manage a large number of nodes that provide efficient coverage for large areas.

4.3 Analysis of the Wireless Network Topologies in Energy Efficient Scenarios

4.3.1 Simulation analysis of IEEE 802.15.4 in Star and Tree-based topologies

The study reported in this section has been performed through simulations developed at the University of Bologna.



A simulator written in C++ has been used. The simulator implements the MAC layer as described in the standard, takes into consideration the PHY layer and implements star and tree-based topologies, based on the Zigbee specifications.

As stated in Chapter 2, the simplest way to apply IEEE 802.15.4 to the eDIANA scenario, is to realise a PAN in each apartment/working unit. The PAN coordinator will be located at the CDC and will manage all the IEEE 802.15.4 devices distributed over the Cell. In the case of apartment or office building scenarios, a multi-PAN network, with different coordinators (CDCs) working at different frequencies, will be realised. According to the standard, each coordinator selects a given channel to be used by the devices in the PAN. The standard defines the algorithm used by the coordinator to measure the level of interference of each of the 16 channels, but does not specify how to properly select the channel to be used. An example of strategy to be used is proposed here.

Star and tree-based topologies are fairly compared in the following by considering both the data gathering strategies: QB and ED. Also, considerations about the design of the network parameter to realize both Monitoring and Controlling Applications will be included.

4.3.1.1 How to compare different topologies

Being comparison of topologies one of the aims of this study, it is important to define the criteria that allow to realise a fair comparison. These criteria follows.

1) Definition of a common reference scenario:

a. map of the building to be studied;

b. number and position of devices in the different rooms;

c. packet size.

2) Performance metrics:

a. Average energy spent by a device in a given interval of time (e.g., for QB application this interval will be equal to the query interval);

b. Average energy spent by a device per packet correctly received, in a given interval of time;

c. Average normalized energy spent by a device in a given interval of time;



d. Lifetime: average duration of the battery of a device;

e. PER for MAC failures: average number of packets lost due to MAC failures (e.g., collisions);

f. PER for connectivity: average number of packets lost due to connectivity issues (i.e., nodes that are not connected to the network);

g. Throughput: average number of bits per second correctly received by the CDC;

h. Offered Traffic: average number of bits per second the network was deployed to transmit toward the CDC (that could be offered to the network if all nodes could access the channel);

i. Average delays:

1. QB applications: average delay between the transmission of the query from the CDC and the instant in which the CDC receives the data (the last bit of the packet) coming from the device;

2. ED applications: average delay between the event itself (that is the instant in which the packet is generated by the device) and the instant in which the data (the last bit) is received by the CDC.

A part from the performance metrics defined above, other issues will be taken into account for the comparison of the different topologies:

- Tolerance to sensor loss: it should be evaluated if a topology is capable of self-reorganizing when some of its members are lost. This requires the evaluation of when a loss is considered fatal (due to too great dispersion, insufficient sensor data, unrecoverable hierarchy, etc.).

- Heterogeneity of the sensors: different sensors may support different communication hardware, giving them different energy-consumption behavior. This plays a crucial part when choosing the role the device takes in the organization; it is often beneficial to select, when possible, long or infinite battery-life sensors for communication-intensive roles.

- Device energy loss: devices can be switched to low consumption mode (hibernate), or on emission-only, or full emission-reception. This will affect the energy spent over time. The emission of a message should be measured in terms of energy spent.



4.3.1.2 Evaluation scenario and application

4.3.1.2a Reference Scenario

We consider a building composed of N apartments located in l floors (N/l apartments per floor).

The “single family house” scenario is achieved by simply setting N=1, whereas the cases N>1 are related to both “office” and “apartments” building, where multi-Cells exist. The following two cases will be accounted for: N=1 and N=16 with l=4 (4 apartments per floor). Note that only the communication between the Cell level devices and the CDC is accounted for also in the case N=16 (i.e., the communication between the CDC and the MCC is not considered).

Each apartment has an area of 120 m2 and is composed of 6 rooms. The map of an apartment is shown in Figure 44. One CDC per apartment is present and n nodes are distributed in the apartment. Six different scenarios, characterized by a different number of devices per Cell, are considered: n=18, 24, 36, 48 and 60. These scenarios are characterized by fixed positions of devices in the Cell. From Figure 44 to Figure 49 the six different scenarios with the relative devices position, are shown. Results shown below are achieved by averaging over 10.000 superframes (beacon intervals), without varying devices position. Because of this, some metrics could show a non-linear behavior by varying the number of devices in the Cell.

Devices that are attached to the walls, are located in the plugs, therefore, they are set at an height of 0.4 m from the floor. Devices that are in the centre of the rooms are located on the ceiling, at an height of 2.70 m. Finally, the CDC is assumed to be located in the electrical panel, at a height of 1.5 m.

Note that the apartment size and the maximum number of devices per room (10 nodes) have been set according to the requirements (see Table 2).

In the case N=16, we have 16 Cells having all the same map shown in Figure 44 and they are deployed over 4 floors (4 apartments per floor), see Figure 50.

Regarding the number of floors and Cells per building a lower number with respect to requirements is considered here. However, the evaluation of networks with N>1 is important for understanding the impact of the interference on a given Cell coming from the other Cells. To this aim, the case N=16 is sufficient, since we could assume that in case of more apartments they will not interfere being at large distances.



4.3.1.2b Reference applications

The following applications and data gathering strategies will be accounted:

1) Monitoring Application with QB traffic: The CDC periodically sends queries to devices and waits for the data. In this case data are generated at the devices at the same time (synchronous generation of the data at devices) and devices will start the CSMA/CA protocol at the same time.

2) Monitoring Application with ED traffic: The devices periodically transmit their data. In this case, the event that triggers the generation of the data is simply a clock. The data are generated at the devices at different instants (asynchronous generation of the data at devices) and devices will start the CSMA/CA protocol in different instant with large probability.

The two above cases will be studied and compared in detail for both the topologies (star and tree-based); by the way a discussion about results achievable also in case of Controlling Applications is included. The eDIANA application, in fact, foresees the possibility of have both the kinds of traffic contemporaneously.

4.3.1.2c Channel Model

Two different kind of walls are considered: thin (0.1 m) and thick (0.3 m). The multi-wall channel model described in [37] is used in the simulator. According to this model, the loss in dB between two nodes at a distance d, is given by:

ccwlwlwtwt LNLNLNdkkL ⋅+⋅++⋅+= )ln(10 Eq. 4

where )/2(log20 100 cfk π⋅= , where f is the frequency and c=3 108 m/s. Whereas

k1=β∗10 /ln(10). We set β=3.

Lwt, Lwl and Lc are the losses introduced by the thin and large walls and the ceiling, respectively. Nwt, Nwl and Nc are the number of thin and large walls, and the number of ceilings between the two communicating nodes, respectively.

We set Lwt = 5.9 dB and Lwl = 14 dB and Lc = 20 dB; these values have been achieved from experimental measurements performed inside the Telecommunication Laboratory at the University of Bologna. The measurements have been performed by using Freescale IEEE 802.15.4-compliant devices.



4.3.1.2d Packet Capture Model

For what concerns the packet capture model, we use a threshold model. We assume that a packet is correctly received when both the following conditions are satisfied:

• Pr > Prmin, where Prmin is the receiver sensitivity and Pr is the received power

given by: ][][][ dBLdBmPdBmP tr −= , where Pt is the transmit power and L is

given by Eq. (4);

• C/I > C/Imin, where C is the power received from the useful signal and I is the sum of the interference powers. We distinguish between co-channel (Ico), adjacent (Iad) and alternate channel (Ial) interferences. I is given by:

alaladadco IwIwII ⋅+⋅+= , Eq. 5

where the two weights and the capture ratio C/Imin will be fixed according to the standard or technology used.

Figure 44: the apartment in the case of 18 devices distributed














Figure 50: The building map (N=16)

4.3.1.2e The frequency allocation strategy

When dealing with multiple Cells (N>1) N different PANs will be formed. According to the standard, each PAN coordinator (and all devices belonging to its Cell) will work at a different frequency channels. As stated above, during the formation phase each coordinator will scan the 16 channels for selecting the channel to be used. However the standard does not define how to select the channel.

In the UNIBO simulator the following channel selection strategy has been implemented. Since interferences are generated by co-channel, adiacent and alternate channel interferences, and since the number of channels is limited, one of the following strategies will be used, according to the possibility to implement it (the first option is the best one, but in case it cannot be applied according to channel measurement results, the coordinator will use the second option and so on):



1) selection of a channel having a “distance” (in terms of number of channels) larger than 2 from all the channels already occupied (in which the received power is larger than the receiver sensitivity);

2) selection of a channel having a “distance” equal to 2 from all the channels already occupied;

3) selection of a channel having a “distance” equal to 1 from all the channels already occupied;

4) if all the 16 channels are already used, the less interfered channel will be selected.

If the first case can be applied (we have less than 6 PANs), by assuming that all the PAN coordinators can “hear” each other, no inter-Cell interferences will be present. In the second and third cases only alternate and adiacent channel interferences will be present, while in the last case also co-channel interferences could be present.

4.3.1.2f System Parameters used in the simulator

We assume that nodes work in beacon-enabled mode (some consideration about results achievable in the case of non beacon-enabled mode are also included). Therefore, in the case of QB applications the query will coincide with the beacon packet and the query interval coincides with the beacon interval, BI, given by Eq. (2).

An acknowledge mechanisms is used: each node waits for 0.864 ms (as required by the standard) the acknowledge packet, in case it is not received the data packet is retransmitted.

Results are achieved by averaging over 10.000 beacon intervals.

The following parameters are set in the simulator:

- Prmin = -96 dBm;

- Packet size: 42 bytes (25 bytes of payload) and 67 bytes (50 bytes of payload);

- Beacon size: 20 bytes;

- wad = 0,44 and wal = 0,44 10-3 (set according to the standard);



- C/Imin=1.3 dB (achieved through experimental measurements realized with 802.15.4 Freescale devices, see below);

- Pt=3.6 dBm transmitted by the CDC and Pt=0 dBm transmitted by devices;

- The MAC parameters are set to the defaults values: BEmin=3, BEmax=5, NBmax=4;

- Bit rate = 250 kbps;

- Frequency, f= 2.4 GHz;

- Maximum number of retransmissions=3;

- No GTSs are considered.

We assume that each node consumes energy when it is in idle state, receives data, or transmits data. The above power consumptions are taken from data sheet of IEEE 802.15.4 Freescale devices [38]: power consumed during transmission (at 0 dBm)= 95.7 mW; power consumed during reception and sensing = 72.6 mW; power consumed during idle or backoff state = 10.9 mW. We set to zero the energy spent in sleeping state.

4.3.1.3 Star topology

In the case of star topology all the devices distributed in the apartment will try to transmit their packets to the CDC through a direct link.

The CDC will transmit beacons trying to connect devices to the PAN. In case a device cannot receive correctly the beacon packet (Pr<Prmin) the device will be isolated and its data packets will be considered lost (connectivity losses).

In case a node does not succeed in accessing the channel (NB reaches its maximum value) or in transmitting the packet correctly (i.e., without collisions) after three attempts, the packet is lost.

4.3.1.3a Monitoring Application

By assuming that only Monitoring Application is needed, meaning that no controllable devices (like actuators) are present, the two gathering strategies (QB and ED) are compared.



In the QB case, the query coincides with the beacon, BI is the interval of time between two successive packets generated and each nodes will have only one packet to be transmitted in each BI. Nodes will start the CSMA/CA protocol at the same time, since they will receive the query at the same time (no propagation delays). We assume that, since each node has to transmit only one packet for query, it enters in sleeping mode (i.e., it doesn’t spend energy) once the packet is correctly transmitted, that is once the acknowledge coming from the CDC, is received.

In the ED case, instead, devices in the Cell transmit a data with a given periodicity. We assume that the period is equal to BI and that the instant in which each node generates the first packet is uniformly and randomly distributed over BI. However, according to the standard, the node must start the CSMA/CA at the beginning of a backoff period, therefore after the generation of the packet the node will wait the beginning of the following backoff period. In this case nodes receive the beacon, then they enter in sleeping state till the data is generated. Finally they return in sleeping state after the correct transmission of the data.

According to the Monitoring Application requirements, devices have to transmit their data every minute. Therefore we set SO=BO=12 (i.e., BI=62.9 s).

Results, in terms of PER, average delays and average energy consumed by a generic node in the network for the transmission of one packet (i.e., in each BI), as a function of the number of nodes in the Cell, are shown.

From Figure 51 to Figure 61 we consider a single apartment (N=1) and nodes transmitting packets of 42 or 67 Bytes.

Note that the PER is due only to MAC issues, since for the scenario considered here, all the nodes can reach directly the sink. Therefore, no connectivity losses are present in our scenario. In particular packets are lost when NB reaches its maximum value, or the packet collides more than 3 times.

PER in the ED case is null (see Figure 51), since the traffic is almost uniformly distributed over BI, that is very large. In the QB case, instead, the PER is quite large and does not satisfy the requirement, even if this application may tolerate some losses.

Figure 52 reports the behavior of the throughput by varying the offered traffic (both defined in section 4.3.1.1). As expected the case ED achieves the largest throughput, that has a linear increase by increasing n, since the PER is always null.

Average delays are shown in Figure 53. QB strategy brings to larger delays, since nodes compete for the channel at the same time, therefore they have larger probability to find the channel busy and collide (i.e., they perform sensing and transmissions more times). Average delays in the ED case, instead, are on the order



of 5 ms, that definitively satisfies the requirement. Note that in the ED case, there is not an increasing of delays when n increases, since few contemporaneous competitions for the channel are present also in case of dense networks.

In Figure 54 the average energy spent by a node in the network per BI, as a function of the number of nodes in the Cell, is shown. Note that ED allows to achieve notable decrease of consumptions. This metric does not increase when n gets larger, since even though nodes spend more energy in backoff and sensing, they will have a lower probability to transmit their packets.

To have a more realistic indication about the average energy spent by the network per BI, we evaluate the average energy spent by a node per packet correctly received at the CDC (see Figure 55). Such energy increases when n gets larger, since the number of packets received decreases.

Figure 56 shows the average normalized energy spent by a node in a BI. The normalization is done by considering the average energy spent by a node when it is alone in the network (ideal conditions from the MAC viewpoint), denoted as E. The Fig. shows how much the network differs from the optimum case, in which the normalized energy is equal to one.

The normalizing factor will be equal to:

ackrxborxdatatxboidBrx TETETETETEE ⋅+⋅⋅+⋅+⋅⋅+⋅= 22/7 , Eq. 6

where Erx is the energy spent in reception per sec, Etx is the energy spent in transmission per sec, Eid is the energy spent in idle state (backoff) per sec. Whereas TB, Tdata, Tack are the beacon, data and acknowledge transmission time, respectively. Tbo is the duration of one backoff period. The duration must be in seconds. Note that 7/2 is the average number of backoff periods a node will wait before sensing the channel. Given the values provided above, E=0,258 mJ in the case of 42 Bytes packets and 0,334 mJ in the case of 67 Bytes packets.

Finally, Figure 57 shows the lifetime, that is the average duration of the battery of a node, expressed in number of hours. A battery of 1 Joule is considered here as a reference case. Note that in the model used here, the energy spent for transitions between the different states is not accounted for. However it could be simply evaluated for the case of ED, where the probability to find the channel free at the first attempt and to transmit the packet correctly at the first time is large. In this case we will have the following transitions:

1) Beacon reception: from sleeping to reception (12.48 µJ at 3.3 V) 2) Backoff: from reception to idle/backoff (12.48 µJ at 3.3 V))



3) Sensing: from idle/backoff to sensing (RX) (12.48 µJ at 3.3 V) 4) Transmission: from sensing to transmission (11 µJ at 3.3 V) 5) Idle: from transmission to idle (11 µJ at 3.3 V) 6) Reception of ack: from idle to reception (12.48 µJ at 3.3 V)

By using the energy consumption data provided in section 2.2.2.4, we can derive (assuming to have 3.3 V as in the Freescale devices case) the energy spent in transitions, that is equal to 71.92 µJ. If we consider that in general batteries are charged with more than 1000 Joules, devices can remain active much more than one year (the requirement), also taking into account the energy spent for transitions between the states.

Figure 51: PER for a node, when N=1 and BO=SO=12



Figure 52: Throughput as a function of the Offered Traffic, when N=1 and BO=SO=12

Figure 53: Average Delays, when N=1 and BO=SO=12



Figure 54: Average energy per BI, when N=1 and BO=SO=12

Figure 55: Average energy per BI per packet correctly received, when N=1 and BO=SO=12



Figure 56: Average normalised energy per BI, when N=1 and BO=SO=12

Figure 57: Average lifetime in number of hours for a node with a battery of 1 Joule

The following Figures are devoted to the case N=16. The aim here is just to show the impact of the presence of more Cells. Therefore only the case of QB data



gathering strategy when SO=BO=12, is considered. It is reasonable to state that the impact of inter-Cell interferences will be the same also in the ED case.

The frequency allocation strategy described in section 4.3.1.2e is used. As expected, by comparing Figure 51 and Figure 58 we can note that the increasing of the PER in the multi-Cell case is quite small. As an example, in the case n=18, we pass from 0.3 to 0.35 for PER. Also the increase of the average delays (see Figure 53 and Figure 59) is negligible (in the case n=18 the increase is of 1 ms).

The increase of the average energy consumed by a node in a superframe, instead, changes by changing the packet size (0.03 mJ for the case n=18 and 42 Bytes packets and 0.07 mJ for the case n=18 and 67 Bytes packet). Note that here there is a slight decrease of the energy spent by increasing n in the case of 67 Bytes, due again to the increase of the probability that the node cannot transmit its packet and will not consume energy for transmission.

Note that all the above results are achieved without the use of GTSs that strongly improves performance in terms of PER [39].

Figure 58: PER in the case of 16 Cells, when SO=BO=12



Figure 59: Average Delay in ms, in the case of 16 Cells, when SO=BO=12

Figure 60: Average energy spent per BI



Figure 61: Average energy spent per BI per received packet

4.3.1.3b Monitoring and Controlling Applications

In case both applications, Monitoring and Controlling, are present, we have to take into consideration the following issues: i) the CDC should be able to send a command that must be received with low delay (few seconds) and high probability; ii) once a particular event happens in the Cell, a device should be able to transmit a packet that must be received by the CDC with low delay and high probability.

The second issue does not affects performance so much. If we consider results shown in the previous section, in fact, we can see that when ED strategy is used, PER and delays are largely far from the limits fixed by requirements also when the network is dense. This means that, even if the traffic increases a bit (one or two nodes transmit two packets instead of one per BI) performance will still satisfy the requirements. Have in mind, in fact, that in general it is expected that few events might happen during the day, meaning no more than one event in a minute.

On the other hand, instead, the first issue needs to be taken into account. In the beacon-enabled mode the command could be contained into the beacon packet and BI should be equal to the maximum tolerable delay.

As an example, if the maximum delay for the reception of a command is equal to 1 second, we need to set BO=SO=6 (i.e., BI=0,98 s). In this way, in fact, the CDC is able to transmit the command within 1 second and the command will be immediately received by devices since no propagation delay is present and no collisions of beacons are possible (also in the case of multiple Cells the probability that two CDCs



transmit at the same time the beacon by using the same channel is very small and could be neglected).

The majority of the traffic generated by devices will be still represented by the monitoring packets, transmitted every minute. Since nodes will generate data every minute, whereas beacons are transmitted every second (to satisfy the Controlling Application requirements), monitoring data will be gathered through an ED strategy. Therefore, nodes will receive the beacon and will take actions in case of need, then they will enter in sleeping state till when they will have a packet to be transmitted or till the reception of the following beacon. This means that, in each superframe the number of packets transmitted will be much smaller than the number of nodes in the Cell.

As an example, in the worst case of 60 nodes in the Cell, if they are transmitting a packet every minute and we set BO=SO=6, in each superframe the number of packets transmitted is, on average, equal to one.

For the sake of completeness we show in Table 23 results achieved when 2, 3, 4 and 5 packets of 42 Bytes are transmitted in a superframe when BO=SO=6. According to the ED strategy, the instant of generation of the packets is uniformly distributed over BI. The position of nodes transmitting these packets are randomly and uniformly distributed over the Cell represented in Figure 44 and results are achieved by averaging over 100 different nodes distributions (100 BIs per scenario are simulated).

Number of packets transmitted in the Cells in a BI

PER Average Energy spent by a node in a BI [mJ]

Average delay [msec]

2 0 0.257 3.1

3 0 0.257 3.1

4 0 0.257 3.1

5 0 0.258 3.1

Table 23: Results in the case BO=SO=6

Note that the average energy spent is equal to the optimum value of the energy, E, given by Eq. (6).



From the results in the table we can state that all the application requirements are satisfied.

4.3.1.3c Non beacon-enabled mode

A final consideration should be related to the non beacon-enabled mode. In such modality since a superframe does not exist and nodes are generally in sleeping mode, the coordinator may transmit a data toward a node only after receiving from it a data request (see section 3.2.1.2). Owing to this, QB data gathering strategies should be avoided.

The different applications could be realized as follows:

1) Only Monitoring Application: Nodes wake up every minute and transmit directly their data to the CDC. No important data are expected from the CDC, therefore, after the reception of the acknowledge they will return in sleeping mode.

2) Both Monitoring and Controlling Applications are present: The duty cycle of nodes must be set according to the maximum delay tolerable for reception of commands from the CDC. Let us assume to set this delay to 1 second. In this case, nodes wake up every second and stay on for a small amount of few time (some ms), for receiving the command from the CDC. Then, in case they receive a command they take the action needed, otherwise they return in sleeping state, till the end of the duty cycle, or the generation of a packet to be transmitted. On the other hand, when the CDC has to send a command, it needs to transmit it continuously for the entire duration of the duty cycle. In this way it is ensured that all the interested nodes will receive the command.

Regarding performance, note that this modality differs from the beacon-enabled mode for:

1) According to the standard, only one sensing phase instead of two are performed before a node can access the channel;

2) GTSs cannot be allocated;

3) According to the standard, the CSMA/CA is not slotted, therefore there is no need of alignment with the backoff periods.

As shown in [39] and [40], if no GTSs are used in the beacon-enabled mode the PER achieved with the two modalities is approx. the same. What makes the difference is the allocation of GTSs, that strongly improves performance (in terms of PER). In



terms of average delays, since only one sensing phase is present (instead of two) the non beacon-enabled mode is a little bit better than the beacon-enabled mode.

4.3.1.3d Conclusions

In conclusion, we can derive the following:

1) In case only Monitoring Application is required and star topologies are sufficient to cover the area (i.e., each node can reach directly the CDC), we can set BI equal to the interval of observation (BO=SO=12) and use ED gathering strategy. In this way all requirements of performance are satisfied.

2) In case both, Monitoring and Controlling Applications, are present, we could set BO=SO=6 such that BI is equal to the maximum tolerable delay of commands and use the ED gathering strategy for monitoring data. In this way all requirements of performance are satisfied.

3) The issue of having multiple Cells interfering may be solved by using appropriate channel selection strategies. The solution proposed here brings to good results since it introduces little worsening with respect to the mono-Cell case, so that requirements could be satisfied also when large buildings are present.

4.3.1.4 Tree-based topology

When the number of nodes in the PAN or the size of the apartment get larger, star topologies are not suitable and peer-to-peer or tree-based topologies should be used A three-level tree, rooted at the CDC (namely, at level zero) is considered. Level i nodes receive data from level i+1 nodes and forward them to level i-1 nodes, toward the coordinator (see Figure 62). The tree-based topology defined by the Zigbee Alliance is accounted for and the topology formation procedure described in section 4.2.1.2 is implemented.

Recall that, according to the standard, nodes must be in beacon-enabled mode, therefore no considerations about the non beacon-enabled mode will be introduced here.

The superframe is divided in different non overlapped parts, allocated to the different parent nodes (i.e., ZRs). Each child will transmit its packet to the parent in the active part of the parent superframe (see Figure 63).



Figure 62: The three-level tree-based topology

Figure 63: The access to the channel in the tree-based topology



We set the duration of all the active parts of the superframes generated by the ZRs and by the coordinator at the same value (i.e., we set a unique value of SO). In these conditions, once we set the BO value, the number of ZRs that will have a portion of superframe available for receiving data from their children, will be equal to 2BO-SO-1 (see Figure 63). Note that the first part of the superframe will be always allocated to level 1 nodes (ZRs and ZEDs) for their transmissions toward the coordinator. If the number of ZRs is larger than 2BO-SO-1 some routers will not have a portion of superframe available and their children cannot access the channel and their packets will be lost. Therefore an adequate setting of BO and SO is necessary.

Finally, note that we assume that a data aggregation strategy, without loss of information, is performed at the ZRs, so that the packet generated by them (after aggregation) has the same size of those received from the children.

The tree is formed according to the following procedure: the CDC (coordinator) sends beacons, nodes that receive this beacon will be at level 1. Level 1, that are routers will start transmitting beacons for generating the second level of the tree. In case a level 2 node will receive more than one beacon it will select as parent, the level 1 node from which it receives the largest received power.

Since in our scenario all nodes may receive the beacon from CDC (i.e., all nodes will be ay level 1 and a star will be formed), we impose a maximum number of nodes at level 1 and we select such nodes as those receiving the largest power from the CDC. The remaing nodes will be at level 2. Note that the constraint of having a maximum number of children per parent is included also in the Zigbee specifications [6]. In Zigbee-compliant devices such parameter could be set.

Some clarifications about the evaluation of performance metrics in the case of trees follow.

As in the case of star topologies, a packet coming from a level 1 node is correctly received when no problems (connectivity or MAC failures) occur in the link toward the CDC. Whereas a packet coming from a level 2 node is considered received when both the transmissions, from the level 2 to level 1 and from the parent to the CDC, are correct (i.e., without collisions).

Regarding energy consumption, each level 2 node will consume energy when: receives the beacon of the parent, performs backoff and sensing for the transmission of its packet, transmits its packet, receives the ack. Each router at level 1 will consume energy when: receives the beacon from the CDC, performs backoff and sensing for the transmission of its packet, transmits its packet toward the CDC, receives the ack from the CDC, transmits its beacon and, finally, it will remain on during all the active part of its superframe for the reception of the packets of its children. Level 1 nodes that are not routers, instead, have not to transmit beacon and to receive data from children.



Concerning the average delays, these are evaluated in a different way depending on the data gathering strategy used. In QB applications, being the delay the interval of time between the query and the packet reception at the CDC, level 1 nodes will have the same delay they have in the star topology case (since they use the first part of the superframe for their transmissions). Whereas packets coming from level 2 nodes, need two BIs to reach the CDC, therefore this delay will be given by BI plus the delay of the parent in its transmission toward the CDC.

In the case of ED traffic generation, instead, the average delay will be the interval of time between the generation of the packet at the node and the instant in which the packet is received by the CDC. We denote as tg the instant in BI in which the packet is generated (with respect to the beginning of the superframe) and x is the interval of time between the beginning of the superframe and the end of the correct transmission of a level 1 node.

A level 1 node has a delay, D1, equal to d when the packet is generated during the first part of the superframe and given by: D1=BI-tg + x, otherwise.

A level 2 node has a delay, D2, given by:

- D2=BI-tg +x, if the data is generated before or during the superframe of the parent;

- D2=2*BI-tg + x, otherwise.

Note that x in this case is the delay of the parent at level 1.

4.3.1.4a Examples of Numerical results

In this section some examples of numerical results achievable with trees are shown. The aim is to show how much different distributions of nodes from level 1 and 2 affect performance and to provide some guidelines for the optimum design of trees. In the following we denote as p the maximum percentage of nodes that can be at level 1.

In Figure 64 we show the PER as a function of the number of nodes in the Cell, when p=0.1 and p=0.3, BO=7, SO=2 and packets of 42 Bytes are transmitted. Performance is strongly affected by the value of p and the value of p maximizing the PER varies by changing n. In particular, when n is small, having 30% of level 1 nodes brings to have approx. the same number of children per parent at each level. The latter situation is the best one, since SO is equal for all superframes. When n is large, instead, when p=0.3 the number of level 1 nodes competing for the channel is too large. In D2.3-B the design of the optimum split of nodes between levels 1 and 2



will be dealt with. The different curves in Figure 64 are related to QB and ED data gathering strategies. Note that, in tree topologies, there is not a notable difference between the two strategies. The reason is that when ED is applied, all nodes that select an instant of generation of the data outside the part of the superframe devoted to their transmissions, will start the CSMA/CA protocol at the beginning of the superframe (after the beacon) as in the QB case. Therefore, even though the data is generated in a random instant within BI, in most of the cases nodes start the access to the channel at the same time. Obviously, this effect decreases by increasing BO and the difference between BO and SO.

In Figure 65 we show the average delays. In the ED case, after the generation of the packet nodes have to wait the beginning of the superframe dedicated to them and this increases delays. Moreover by increasing the number of level 2 nodes (i.e., decreasing p), delays increases since level 2 nodes need two BIs to reach the CDC.

Figure 64: The PER for a tree when BO=7, SO=2, packets of 42 Bytes



Figure 65: The average Delay (in s)

Number of devices in the Cell

QB, p=0.1 ED, p=0.1 QB, p=0.3 ED, p=0.3

18 4,77 4,76 2,63 2,62

24 4,80 4,79 3,22 3,21

30 4,80 4,80 2,92 2,91

36 3,71 3,70 3,30 3,29

48 4,84 4,84 2,28 2,27

60 4,12 4,11 2,50 2,49

Table 24: Average energy (in mJ) spent by a level 1 node per BI

Regarding the energy consumption, in Table 24 and Table 25, we show the average energy consumed at level 1 and level 2, respectively. On average, level 1 nodes spend 10 times more than level 2 nodes. This implies that the better solution is to impose that routers must be plugged in.




QB, p=0.1 ED, p=0.1 QB, p=0.3 ED, p=0.3

18 0.44 0.436 0.358 0.353

24 0.42 0.415 0.381 0.376

30 0.46 0.450 0.383 0.378

36 0.48 0.473 0.408 0.402

48 0.47 0.464 0.435 0.428

60 0.493 0.484 0.435 0.431

Table 25: Average energy spent (in mJ) by a level 2 node per BI

4.3.1.4b Monitoring Application

For a fair comparison between star and tree-based topologies, we consider here the same application described in section 4.3.1.3a. We set BO=12 (1 minute between the generation of two successive packets from nodes) and we set SO such that all the possible routers in the network may have a part of the superfarme allocated. Since the case of p=0.3 is considered and being 60 the maximum number of nodes in the Cell, we set SO=7. We also assume that nodes transmit packets of 42 Bytes. Both QB and ED strategies are considered. In the QB case, the query will be again the beacon coming from the CDC, for level 1 nodes and coming from the level 1 parent, for level 2 nodes. By comparing Figure 51 and Figure 66 we can note that, in QB case the tree performs better, thanks to the presence of time division among children of different parents (i.e., less nodes compete for the channel at the same time). When, instead, ED is used, the tree does not allow to reach a PER equal to zero as in the star case, for the reason explained in the above section. Moreover, delays in the tree topology are larger than in the star. They are, in fact, on the order of ms for the star, and around one minute for the tree.



Figure 66. PER for tree-based topologies, when BO=12 and SO=7

Figure 67. Average Delay [s] for tree-based topologies, when BO=12, SO=7




QB level 1 node

ED level 1 node

QB level 2 node

ED level 2 node

18 71.6 71.68 0.357 0.351

24 89.5 89 0.381 0.374

30 79.6 79.6 0.383 0.377

36 91.1 68.26 0.407 0.401

48 57 57.5 0.434 0.426

60 63.8 63.8 0.435 0.427

Table 26: Average energy spent (in mJ) by level 1 and 2 nodes per BI

Finally, in Table 26 we show the average energy spent per BI by level 1 and 2 nodes. Note that in case level 1 nodes are equipped with a battery of 1000 J they will have a duration of approx. 11 days (note that in general devices are equipped with batteries of 10000 J). This results brings again to impose the connection to the electrical network of level 1 nodes. Level 2 nodes, instead, do not have problems and may live for more than one year, according to the requirements.

4.3.1.4c Monitoring and Controlling Applications

In the case both, Monitoring and Controlling Applications, are present, the CDC needs to send commands with a delay of few seconds to all nodes. Since the target of the command could be a node at level 2, we need to set BO, such that BI is the half of the maximum delay allowed for commands. The command, in fact, could need two BIs for reaching the destination. Once BO is fixed, SO should be fixed again allowing all the possible routers to have a part of the superframe allocated. Let us assume (as in the case of star topologies) that the maximum delay is equal to 1 sec. We need to set BO=5 such that the command will arrive to all devices in 1 second. Then, the values to be used for SO will vary by changing p and n. These values are provides in Table 27. As in the case of star topologies, nodes will receive the beacon (command in some cases) every second, but they will generate one packet every minute according to the Monitoring Application requirement, plus some packets generated after events. Therefore, in each BI, a maximum number of 5 nodes will have a packet to be transmitted.



To prove that, in such conditions of traffic, requirements in terms of PER are satisfied, we show in Table 28 the PER for a star, being SO=0, 1 and 2, when a maximum number of 5 nodes are transmitting. The reason why we are showing here results achieved in the star topology case, is that, according to the strategy used to access the channel, each cluster in the tree (formed by the parent and its child), can be seen as a star topology and the different clusters are not interfering among them. Results are achieved in the same way described in section 4.3.1.3b. As we can see, the requirement is satisfied. Finally, regarding the maximum delay of data coming from a device, it will be equal to BI+SD (i.e., 0.5 s, 0.52 s, 0.55 s for SO=0, 1 and 2, respectively), for a level 1 node and equal to 2*BI+SD (i.e., 0.99 s, 1.01 s, 1.04 s for SO=0, 1 and 2, respectively), for a level 2 node. In addition, level 2 nodes will consume approx. the same energy consumed in the star topology (meaning requirement satisfied), whereas routers at level 1 will consume much more.

Number of devices in the Cell (n) p=0.1 p=0.3

18 2 2

24 2 2

30 2 1

36 2 1

48 2 1

60 2 0

Table 27: The values of SO to be used by varying p and n


SO=0 SO=1 SO=2

2 0 0 0

3 0 0 0

4 0.03 0 0

5 0.1 0 0

Table 28: the PER in the case of star topology, by varying SO and setting BO=SO



4.3.1.4d Conclusions

In conclusion, we can state the following:

1) When only Monitoring Application is present, we could set BI equal to the interval of time between two successive measurements and SO such that all the routers have a portion of superframe allocated.

2) When both Monitoring and Controlling Applications are present, we need to set BO, such that BI is equal to the half of the maximum tolerable delay for commands and SO as described at point 1). Requirements in terms of PER are satisfied, delays are larger than in the star but are still reasonable.

3) In ED case, star topologies performs better in terms of PER and average delays. Therefore, if a star is sufficient for covering the apartment, star with ED provides the best performance.

4) In the QB case, trees are better than stars in terms of PER but introduce larger delays.

5) In case trees are needed it would be reasonable to locate routers attached to the electrical grid.

A final consideration should be related to the re-configurability of tree-based topologies. The lack of self-reorganisation capabilities of trees when some nodes in the topology die, is an issue. In mesh topologies, in fact, the path between the transmitter and the receiver is generated at each transmission; the death of some nodes in the network, does not cause the loss of other packets. In trees, instead, if a router dies, all the packets of its children are lost. To solve this problem, suitable solutions must be implemented. As an example, a node at level 2 not receiving beacons from the parent for a given interval of time, could starts searching for another router to connect to. This could be simply done imposing the level 2 node to start a new association procedure.

4.3.2 Experimental Platform for IEEE 802.15.4 in a real Indoor environment

In order to evaluate the behaviour of real WSNs, UoR ran some experiments on a set of real devices, using the Motelab permanent test-bed [41], [42]. The test-bed is composed of 180 Tmote sky sensor nodes deployed on three floors of an (81 x 30) meters building at Harvard University, which can be programmed through a web interface.



The whole third floor of the building (see Figure 68), composed of 35 nodes have been used to evaluate the Packet Delivery Ratio (PDR), that is the number of packets correctly received by a sink (that represents the CDC), over the total number of packets generated by packet generator nodes.

Different conditions of traffic load, communication channel used, transmit power and selected packet generators, will be accounted for.

In all the experiments the network will be composed of a total of 35 nodes, of which only a subset (namely, 5 nodes) will generate packets. The selection of which nodes generate packets brings to different results, as we will see in the following.

Tmote sky sensor nodes use the Tiny OS CC2420 radio stack, that does not support the full IEEE 802.15.4 standard (http://webs.cs.berkeley.edu/tos/faq.html). Tmote sky sensor nodes, in fact, transmit according to the B-MAC [5] MAC layer protocol and standard TinyOS routing protocols. B-MAC does not ensure reliable communication. The following clear channel access mechanism is used: before transmitting a packet, the channel is sensed; if it is found free, the packet is transmitted after a small random backoff interval (named Initial Backoff); if the channel is sensed busy, a Congestion Backoff interval is used. In Tmote sky sensor nodes both the backoff values are chosen randomly in the interval 0.3ms – 10ms. Transmissions between Tmote sky sensor nodes using B-MAC doesn't use any acknowledgement mechanism.

Two different topologies have been evaluated: tree-based and mesh topologies. We assumed no sleep/wake up cycle; in other words, in this first set of experiments, all the nodes are always turned on. Details on the topologies are given in the following.

We now explain why we chose to vary load, communication channel, output power and packet sources:

1) Traffic Load. Varying the data generation rate, the network load increases or decreases; obviously, the higher the traffic, the higher the interferences between different communications. We are interested in evaluating the impact of different loads on the PDR at the sink. The selected transmitting nodes generate a traffic of 0,96 kbps in the first case (one packet of 12 bytes every 100 ms) and of 9,6 kbps in the second case (one packet of 12 bytes every 10 ms). All the transmitting nodes generate the packets at the same time (synchronous transmissions). The MAC protocol (as described above) uses a random backoff interval to avoid collisions of packets (contemporaneous transmissions). We assume that in each experiment the generating nodes transmit 1000 packets, for a total of 5000 packets (5 generating nodes are selected). It is important to underline that both loads studied are extremely heavy; we decided to explore these solutions to evaluate the behaviour of the WSN under stressing conditions (i.e., a burst of traffic). We have also



investigated what happens at a lower rate. This aspect will be discussed in the following.

2) Selected Generators . The selection of different generators can impact on the PDR at the sink, in particular when selected generators have different distances from the sink. The following two cases are considered: 5 leaves of the tree are selected as generators; 3 leaves plus 2 routers generate packets (denoted as 3+2 generators in the following). The total number of generators is always 5, and 5000 packets are generated in all the experiments. We obviously expect a higher PDR when routers nodes (i.e. nodes nearer to the sink) are considered.

3) Communication Channel. Tmote nodes can use one of 16 different channels; it is well known that since they work on the 2.4 GHz ISM band, they suffer interferences from 802.11 Wi-Fi networks. We used two different channels (after a preliminary experiment we noticed that channel 26 is the less interfered, while channel 20 is the worst performing channel) to evaluate what is the impact of a right channel selection on the overall PDR. It is expected that different settings and deployments may experience difference performance over the same channel. Our objective was to identify whether the channel over which packets are transmitted makes the difference.

4) Output Power. The transmission power of the nodes can be set; a lower value implies both a lower energy consumption and a lower number of in-network interferences (i.e., interferences coming from other nodes of the network). A lower output power however also implies a smaller transmission range (implying lower connectivity of the network) and a higher sensitivity to interferences. We are interested in evaluating what is the behaviour of PDR when the transmission power varies. We tested our solution using 3 different values of transmit power, according to CC2420 datasheet [43] (CC2420 is the radio transmitter used by Tmote sky sensor nodes):

31 – corresponding to a power of 0 dBm and a current drain of about 17.4 mA

23 - corresponding to a power of -3 dBm and a current drain of about 15.2 mA

19 - corresponding to a power of -5 dBm and a current drain of about 13.9 mA

4.3.2.1 Tree Topology

To set up a topology, we used CTP (Collection Tree Protocol), a standard interface of TinyOS. Details on CTP can be found on Tinyos website, in TEP 123 [44]. The CTP protocol allows the realization of a tree rooted at the sink. When a node has a data to be transmitted, it sends it to its parent in the tree; therefore the communication in



this case is unicast (this is the standard implementation of CTP). A single sink collecting data from sensors is considered in the experiments. The topology built is shown in Figure 68 and Figure 69, where the 3+2 generators and 5 leaves cases are shown, respectively. In the Figures, the blue dot represents the sink node; black dots are generators and the other dots represent non-generator nodes. Purple lines are the connection between nodes (the route followed by generated packets), while the other lines must be ignored (unfortunately they were included in the original image taken from Motelab map).

Figure 68: Motelab deployment and route of packets when having 3 + 2 generators



Figure 69: Motelab deployment and route of packets when having 5 leaves

Results of the experiments are reported in the Figure 70 and Figure 71. The lower lines represent channel 20, while the upper lines represent channel 26. Fig.s clearly show the impact of the selected channel on the PDR.

Figure 70: 3+2 generators with 100 ms (left) and 10 ms (right)



Figure 71: 5 leaves generators with 100 ms (left) and 10 ms (right)

The PDR tends to be quite low in all the considered scenarios (only in Figure 70 we achieve a data rate of about 0.93, which is however low). We want to underline that the low PDR is due to the fast generation rate we decided to adopt. Generating one packet every 10 ms (or even every 100ms, which is always extremely faster than usual WSN protocols), the traffic flowing in the network at the same time is very high, and thus each transmitted packet experiences an high number of collisions.

In fact, the number of wrong packet sending is negligible (if node A receives 1000 packets from node B, A re-transmits more or less all of the 1000 packets) and all the losses are due to collisions. Recall that here no acknowledge mechanism and retransmissions are used.

If we consider reduce the traffic load (e.g., one packet every second), the PDR could reach the 100%. This is confirmed by the fact that when passing from 10 ms to 100 ms of generation rate, the PDR strongly increases. We remark that the adopted generation rates are not necessary for the vast majority of real applications (sending a temperature reading every 100ms or even worst every 10 ms is not necessary, in most cases), but they give us an indication on the behaviour of an IEEE 802.15.4 network in application scenarios in which a burst of traffic may need to be sent.

By looking at the Fig.s above, we can notice that the PDR tends to be higher when 3 leaves generators + 2 routers are used. This can be explained by the fact that routers are closer to the sink, and thus their transmissions have a lower probability of getting lost. This is true for both data rates.

Another interesting aspect is that in all cases (except power 31 for channel 26 in Figure 70 on the right, which can be due to a coincidence) the lower PDR is obtained when using an output power of 23 (-3 dBm) rather than 31 (0 dBm). This can be explained by the fact that even if a lower transmission power implies more



connectivity losses and larger susceptibility to external interferences (i.e., Wi-Fi), high transmission power increases the transmission range of nodes and in-network interferences (i.e. interferences coming from 802.15.4 nodes.

From our results, it seems that using a transmission power of –3 dBm ensures the best PDR in the specific setting we are considering and that in general optimizing the transmission power is an important design choice for a test-bed.

The results depicted in the figures show how critical the selection of the channel is to grant a good overall performance. UoR is currently working at protocols to grant the best channel selection and these studies will be included in D2.3-B.

In conclusion, the experiments for the tree topology show that accurately selecting the communication channel and tuning the output power to reduce interferences among nodes (not from external devices, like Wi-Fi APs) may significantly increase the PDR, so that the requirements could be satisfied.

4.3.2.2 Mesh Topology

In this case, to set-up the topology, rather than using a standard Tinyos interface, the following simple algorithm has been used in the test-bed:

1) the sink sends in broadcast 10 messages, containing an Hop Counter (HC, namely the distance from the sink) value;

2) all the nodes which receive this packet are set to HC = 1, and they send 10 messages advertising HC = 2;

3) nodes receiving a packet with hop count h-1 send 10 messages advertising HC=h.

At the end of this simple procedure we will have a situation similar to the one depicted in Figure 72 (the node in “Hopcount=0” is the sink).



Figure 72: The mesh topology

Nodes are organized in different levels. After the topology is set, the generator nodes start sending their messages in broadcast. The message will be received and re-transmitted toward the sink if and only if the HC of the receiver is lower than the HC of the transmitter (and obviously if the same message has not been re-transmitted before, to avoid duplicates). After some hops (typically 1 or 2 in our experiments), the data reaches the sink.

In the following we report the results achieved with the mesh topology.

Figure 73: Mesh: 3+2 generators with 100 ms (left) and 10 ms (right)



Figure 74: Mesh: 5 leaves generators with 100 ms (left) and 10 ms (right)

A significantly lower PDR with respect to the tree topology case, is obtained. This is an expected result, if we consider that the number of transmissions is significantly higher in this topology when compared to CTP. Recall that CTP builds up a routing tree, in which each node knows its own parent and sends its data only to it (in unicast). In the mesh topology, instead, a generator node broadcasts its packet and all the nodes which receive this packet for the first time, will re-transmit it toward the sink.

It should be pointed out, however, that also in this case, if a lower generation rate is adopted, the PDR largely increases (100% when nodes generate one packet per second).

What’s important to underline is that the consideration we made in the tree topology case are confirmed in the mesh one: there is a strong dependency between channel selection and PDR (recall that from a previous analysis, we selected channel 26 as the best and channel 20 as the worst); when increasing the data rate, the PDR decreases and setting the output power to 23 grants the best results, as the number of in-network collisions is reduced.

4.3.2.3 Conclusions

We presented here a set of experiments executed on a real test-bed, with 35 nodes deployed in an indoor environment. We made our experiments on different situations in terms of network traffic, transmission power, selected packet generator nodes and communication channel, using two different methods to build a topology. In the first case, a tree topology using CTP (a standard Tinyos protocol) has been produced,



while, in the second case, a mesh topology (organizing the nodes in different levels on the basis of their distance from the sink) has been tested.

Results show that in both cases the PDR is quite low, and this is due to the extremely high generation rate we selected and the fact we used widely adopted but unreliable communication protocols; our interest was in testing the behaviour of the WSN under stressing conditions (results obtained sending one packet every second show in both topology a PDR near to 100%). Also at this step we didn’t test protocols developed within eDiana but we were analysing the performance of widely used basic solutions adopted in the literature.

The overall performance of CTP outperforms that of mesh topology and this is mainly due to the different kind of transmissions adopted (unicast in CTP, broadcast in the Mesh). The main advantage of adopting a mesh topology, however, lies in the fact that it is more reliable in case of failure of nodes, since packets can reach the sink following different paths, while in CTP they are forced to follow a single path until a route update process is started.

4.3.3 Experimental Platform for IEEE 802.15.4 in an Office Building

Many tests of 802.15.4 (and ZigBee) radio reception quality known in literature (and internally to Apptech) are tests that measure the influence of specific interference sources, like WiFi interference, people standing between two radio antennas, etc.. We could not find a test of how reliable the radio reception is over a long period of time (i.e., many days), in a situation with low interference. Therefore we did duration tests in the Philips building at High Tech Campus 5 in Eindhoven (HTC5), a ‘regular’ office building, with people moving around, doors and metal window shades opening and closing, etc. Every building is different of course, but these tests do provide at least one baseline data point for office buildings.

A driving question we had was: how reliable can we expect a link to be: does it work 99% of the time or 99.9%? A related question was: if a link is (temporarily) unavailable, do mitigation actions like routing via a different node work? What are the properties of the radio environment, and how do these inform mitigation actions and the general question of how to pick the most reliable routes?

We placed 5 Jennic-based 802.15.4 radio nodes at HTC5 as shown in Figure 75. The nodes ran software called the ‘wireless home platform’ that was developed in and tuned for this particular test.

We used Jennic development boards to create the nodes, with JN5139 modules. The node shown has batteries on it, but we used mains power adapters for the tests. The JN5139 modules are state-of-the-art 802.15.4 radios in 2009. Datasheets and other information about the Jennic modules can be found at http://www.jennic.com/.



As can be seen in the map, nodes are located as follows:

- Node 0 was the coordinator, placed on top of a PC on a table.

- Node 1 was placed on a table in the same room, with a metal bookcase next to node 1 blocking direct radio line of sight between 0 and 1.

- Node 2 was placed on a desk, with a metal closet in the middle of the room blocking direct radio line of sight between 0 and 2.

- Node 3 was placed on a window shelf, in such a way that direct radio line of sight (through 2 windows) existed to node 1. Both windows had metal window shades which could be lowered.

- Node 4 was placed next to a printer in a hallway.

The internal walls between the office spaces in the building are not brick walls, but made of plastic/wood/gypsum panels and glass panels.

Figure 75: The map of the office building



4.3.3.1 Communication details

In the main test, nodes 1-4 are configured as sensors, which send a value to the coordinator (node 0) every 5 seconds on average. The 5 second reporting interval is not deterministically defined, a random number generator in each node is used to put a random component in each wait time.

Each node can act as a router for any other node. Routes are dynamically configured as follows

- When it needs to find a route, a node sends a beacon request in broadcast. A single broadcast is done on all 802.15.4 channels, so the entire procedure of broadcasting on a channel and listening for responses takes about 2 seconds.

- The coordinator, and every node having a working connection to the coordinator, is configured to answer the beacon request.

- Among the answering nodes, the node selects preferably the coordinator as the router: it always selects the coordinator if it is found in the list of received beacon responses. If the coordinator is not in the list, the node selects that responding node that has the best link quality indicator. In this case, the complete route is made up of the hop to the chosen node and the route of that node to the coordinator.

Regular message traffic between the nodes is done using CDMA (Code Division Multiple Access) or non beacon-enabled mode, in which a node will send a packet as soon as it detects a clear channel.

Each sensor report is sent in a single packet along the chosen route to the coordinator; each hop is a unicast, acknowledged, message. When the coordinator receives the report it sends an end-to-end acknowledge packet back – if the node does not get an end-to-end acknowledge it retries 3 times; if this still fails it assumes that the connection is lost, and will do the route-finding algorithm above every 7 seconds in order to re-establish the connection.ì

The packet sniffer picture below shows (in dark) the 4 messages involved in a measurement report from node 1 to node 0.



The longer packet sniffer picture below shows (in dark) the resend attempts that node 1 will do when node 0 is temporarily unreachable – in this case we made it unreachable by switching node 0 off entirely. Packet numbers 1-12 show regular reporting traffic, node 0 is switched off between packet 12 and 13. In packets 13-16, we see 4 attempts, which fail because no acknowledgement is received. The node then tries the single-hop unicast again, about 100 ms later (there is a random component to the retry interval), and gives up after the 3rd retry. So in total, 16 packets have to go un-acknowledged over a period of about 325 ms, for the node to determine that it has been disconnected.

Packet numbers 29-32 are the beacon requests sent by node 1 (on the monitored channel) for a period of disconnection. After packet 31, the coordinator node was on again, so beacon request 32 gets a response, leading to traffic that re-establishes the connection.



4.3.3.2 Network uptime measurements

We have done two duration tests: one on channel 25 for 5 days, and one on cannel 23, overlapping with WiFi, for 7 days.

During the test, node 0 receives measurements from the other nodes, with each node reporting a measurement every 5 seconds. If a node fails to deliver the measurement message, and has to re-establish the connection, we define this as an ‘interruption incident’. We define the duration of the interruption incident as the time between the last successfully received measurement from the node and the next successfully received measurement.

Node number

Total number of interruption incidents

Incidents/day Average incident duration (seconds)

Downtime (time spent in incidents as % of total time)

Average number of messages between incidents

1 61 12.23 8.0 0.114 1413

2 3 0.60 7.7 0.0054 28724

3 4 0.80 7.7 0.0072 21543

Test 1: channel 25 for 5 days

4 27 5.41 6.9 0.043 3192

1 160 22.85 7.4 0.196 756

2 40 5.71 6.8 0.045 3024

3 15 2.14 8.6 0.021 8065

Test 2: channel 23 (overlap with WiFi) for 7 days

4 17 2.42 6.6 0.018 7116

Table 29: Number of incidents in Test 1 and Test 2

Overall we see that the network is fairly reliable: the interruption incidents might be missed entirely in a shorter test. Also, node 1 has the overall link quality, even though it is in the same room as node 0.

We can see that the number of incidents/day is higher in test 2, when there is overlap with WiFi. Summed over all 4 nodes, we have 19 incidents/day in test 1 and 33 incidents/day in test 3.



4.3.3.2a Incident duration

Most often, the incident duration is about 7.5 seconds. In the first 5 seconds of the incident, the node is just waiting until it is time to send the next status message. At the 5th second, it tries to send the status message but fails after trying for 325 ms, causing it to go to the disconnected state. The next 2 seconds are spent doing beacon requests on all channels, which usually leads to getting a successful beacon response and a re-establishing of the connection.

Some incidents take only about 2.5 seconds: in this case, the status message is received by node 0, but the end-to-end acknowledge message never makes it back to the sending node. Therefore the sending node immediately detects a disconnect, and tries to re-establish the connection; the 5 second waiting period at the start of the incident is not present. Very long incidents are rare, which is good. If we would have defined an incident as a failure to report a sensor reading for more than 30 seconds, there would have no incidents at all in the entire tests. Table 30 shows how many incidents with a certain duration happened.

Incident duration (rounded to nearest integer) in seconds

Occurrences in test 1

Occurrences in test 2

Total occurrences, test 1 and test 2 combined

2 0 2 2

3 0 26 26

8 82 196 278

10 1 2 3

15 0 6 6

21 3 0 3

Table 30: Incidents duration

If an incident took 15 seconds, we cannot conclude that the radio spectum was blocked for 15 seconds. We can only conclude that

1. 16 attempts to send the message (or 16 attempts to send an end-to-end acknowledgement ) all failed.

2. About 7 seconds later, a single beacon request in the right channel failed to receive a response from any of the other nodes.

3. About 15 seconds later, a single beacon request did get a response.

So we expect that with a more aggressive reconnection strategy it would be possible to shorten the incident durations significantly.



4.3.3.2b Incidents over time

Figure 76 shows how the incidents are distributed over the running time of test 1, running from a Friday till a Wednesday. The X axis is the time axis (in seconds). The dark line plots the hour of the day, so it shows the progression of each day. Each mark in the plot is an interruption event, the Y position of the mark indicates the duration of the event in seconds. The days of the week have been indicated for convenience.

We see here that the incidents are not evenly spread: during some periods there are no incidents at all. Moreover, different nodes seem to have incidents at different times in the test: there seem to be suggestions of an underlying structure (maybe due to changing routing topologies), but it is difficult to see from these graphs what kind of ordering mechanism would be at play.

Figure 76: Test 1 incidents over time



Figure 77: Test 2 incidents over time

Incidents seem to be somewhat evenly spread over time in Test 2. In the graphs above, incidents that are very close to each other in time are not easily visible. Table 31 shows some detail not visible in Figure 77. A ‘previous incident’ is an incident for any participating node in the test, not just the same node. If node A is using B as a router, and B is disconnected, then A might experience an interruption in routing service from B. However, with A sending a message every 5 seconds, such an interruption is not guaranteed: typically the reconnection attempt by B will only take 2 seconds, so it may be invisible to A altogether.

Number of incidents occurring

In test 1 In test 2 In test 1 and test 2 combined

In entire test 85 231 316

Within 10 minutes of the previous incident

16 74 90

Within 60 seconds of the previous incident

5 21 26




5 19 24


5 14 19

Table 31: Number of incidents in different tests

4.3.3.2c Correlation with time of day

Figure 78 plots, for test 2, on the X axis the hour of the day and on the Y axis the number of incidents that happened for a particular node in that hour. The line is the total, computed over all nodes. We see a suggestive peak inside office hours, but if we take out the data from node 1, we do not see a peak in office hours anymore. Overall it looks like the occurrence of incidents is not strongly correlated with the time of day, or at least we do not have enough statistics to see a strong correlation in the data we have. This is somewhat surprising: definitely during the day there will be somewhat more WiFi usage, but this does not show up in the data.

Figure 78: Test 2 number of incidents per hour (the line is total of all nodes)



4.3.3.3 Routing

During the test, for most of the time the nodes routed their message directly to node 0, without an intermediate hop. Routes with more than 1 hop never occurred.

Table 32 and Table 33 show how often a certain route was used during the tests. When we look at the physical location of the nodes on the map, there are some surprises. In test 1, node 1 often routes via node 4, less often via 2 which is much closer.

Percent of time that a certain route is used, per node, test 1

Route For messages from node

Direct to 0 Via 1 Via 2 Via 3 Via 4

1 85.6 - 0.6 0 13.7

2 100 0 - 0 0

3 53.6 46.4 0 - 0

4 77.3 21.5 1.2 0 -

Table 32: Percentage of time a certain route is used (test 1)

Percent of time that a certain route is used, per node, test 2



1 83.8 - 14.6 0 1.6

2 89.4 8.3 - 0 2.3

3 11.4 88.6 0 - 0

4 96.5 3.5 0 0 -

Table 33: Percentage of time a certain route is used (test 2)



Figure 79: Locations of nodes

The amount of time that a certain route is used says something about our route selection algorithm, which has a preference for routing directly to node 0, but says less about the ‘quality’ of this route.

The ‘wireless home platform’ used in the test uses source routing. This means that the route that a packet should take is embedded inside the packet headers by the initial sender of the packet, that is in our case the node originating the status message. Routers do not decide on a hop-by-hop basis where to send a packet, they simply follow the instructions inside the packet. The route chosen by the originating node is the route that was the outcome of the last successful (re)connection attempt of that node. This source routing can have some counter-intuitive effects, which are also visible in the statistics of test 2. During test 2, at one time node 3 was routing its messages via node 1 to node 0, with node 1 routing its messages directly to 0. Then, node 1 got an incident, and re-connected to the network by finding a route for its messages via node 2 to node 0. Node 3 did not notice the incident happening in node 1 however, so it kept sending its own messages to node 1, telling node 1 to route directly to node 0, which node 1 managed to do successfully for a long time. At the same time, messages originating at node 1 were routed via node 2.

We could define the quality of the route as the average time that the route is used before an interruption event occurs, that is the mean time between failures (MTBF) of the route. For many routes in our network, we cannot compute this time with any statistical certainty, either because the route was not used at all or because it was used only a few times. In Table 34 we only show the routes that are used 4 times or more.

In the table we can see that for node 1, the indirect route via node 2 to node 0 seems to be more reliable (longer-lasting) than the direct route toward node 0. Therefore, in this case the route selection algorithm, preferring the shortest, direct route, does not result in a situation where the number of interruption events is minimized.



For node 3, we see that the indirect route via node 1 is also more reliable than the direct route to node 0.

Route quality: Average time, in minutes, that a route lasts before an interruption event, in minutes, during both test 1 and 2.



1 62 - 374 no statistics no statistics

2 157 131 - no statistics no statistics

3 408 862 no statistics - no statistics

4 243 229 no statistics no statistics -

Table 34: Route quality

4.3.3.4 Link quality indicator test

In another test, we tested the 802.15.4 ‘active scan’ or ‘beacon request’ mechanism. We measured the link quality indicator values with these responses. Table 35 plots the average values of the quality indicator over a duration test, test 3.

Responding node

Requesting node

0 1 2 3 4

1 131 - 100 43 52

2 142 105 - 28 45

3 54 43 25 - 13

4 83 53 42 14 -

Table 35: Response quality indicator for different node combinations, average over entire duration of test 3.



4.3.3.5 Quality indicators compared

It is interesting to compare this table with the incidents per day and the route quality values shown earlier: we see that link quality is only a very poor predictor of actual route performance. Table 36 compares the MTBF and hop-by-hop link qualities for the different routes of test 3.

Route route MTBF (minutes)

link quality hop 1

link quality hop 2

Lowest link quality in route

1->0 62 131 n/a 131

2->0 157 142 n/a 142

3->0 408 54 n/a 54

4->0 243 83 n/a 83

1->2->0 374 100 142 100

2->1->0 131 105 131 105

3->1->0 862 43 131 43

4->1->0 229 53 131 53

Table 36: Route MTBF versus and hop link qualities, test 3

If we plot the correlation between MTBF and the lowest link quality in the route, we get the results shown in Figure 80.

Figure 80: Correlation between MTBF (X axis) and the lowest link quality in the route (Y axis) in test 3.



If the two were correlated, one would expect the points to line up on a straight line that runs diagonally, and upward in the left-right direction. We see almost the opposite. So we can conclude that in our tests, link quality was a very bad predictor of long-term route quality. This is interesting because many routing algorithms use the link quality indicator to construct optimal routes.

4.3.4 Interferences between IEEE 802.15.4 and IEEE 802.11b

In this section some results of experimental measurements made on the field with IEEE 802.15.4 devices, in the presence of APs WiFi, are provided. The aim of the tests was the evaluation of the interference generated by IEEE 802.11b APs on an 802.15.4 network The MC13192 sensor devices produced by Freescale were used and the experiments were performed in the telecommunication laboratory of the University of Bologna. In Figure 82 the map of the laboratory is shown. We located two 802.15.4 sensor devices in a room of the laboratory, at a distance of 3 meters, and two APs in other two rooms (see Figure 82). The APs were transmitting by using the channels 4 and 11. In Figure 81 the channels used by the APs and 802.15.4 are shown. As we can see, the 802.15.4 channels interfered by the APs were the channels number 4, 5, 6, 7 and 11, 12, 13 and 14. However, the most interfered channels are the numbers 5, 6, 12 and 13.

The experiments were performed as follows. One of the two 802.15.4 devices sent to the other 1000 packets in each 802.15.4 channel and waited for the acknowledge packet. Then the role of transmitter and receiver was exchanged and the same tests repeated. The non beacon enabled mode was used and packets with a payload of 20 bytes were transmitted, by using three different power levels: -16.6 dBm, 0 dBm and 3.6 dBm.

In Figure 83 and Figure 84 the PER and the average Link Quality (LQ), as a function of the different channels used, are shown. As can be seen, in the channels 5 and 6 PER increases only when the minimum power is used. In the channels 12 and 13, instead, there is a relevant increasing of the PER also at nominal power and at –16.6 dBm a PER of 100% is reached. This is due to the fact that the AP working in the channel 11 is nearer to the 802.15.4 nodes than the one using channel 4. It could be also noted that there is an increasing worsening of LQ from channel 11 to channel 16. This is due to the possible presence of other external interferences, working in a frequency band adjacent to the ISM band.



Figure 81: the IEEE 802.11 and IEEE 802.15.4 channels

Figure 82: the environment used for the experiments



Figure 83: Packet error rate

Figure 84: Average Link Quality



4.3.5 Conclusions

Chapter 4 presents the first numerical results achieved within the Project when IEEE 802.15.4 air interfaces are applied to the eDIANA scenarios.

A simulation framework has been developed at UNIBO, for the sake of studying 802.15.4-based networks deployed in buildings, composed of different apartments/working units and having different floors. The PHY and MAC layers defined by the standard were implemented and star and tree-based topologies (based on Zigbee specifications) were considered.

The geometry of the scenario, the data payload, the number of nodes and their spatial distribution, and the traffic generated in the network, were all fixed according to the requirements of the Project (defined in Task 2.3). The two applications defined within the Project, i.e., Monitoring and Controlling, have been accounted for, and guidelines for the design of network parameters setting are provided. In particular, the two possible data gathering strategies, ED and QB, have been addressed and compared.

Results show that star topologies using ED gathering strategy allow achievement of the best performance. In this case, in fact, all requirements in terms of PER, latency and network lifetime can be satisfied. On the other hand, star topologies are not applicable in all environments, and multiple hops are needed when apartment size gets larger. In the latter case, tree-based topologies can be considered. The simulation study of UNIBO shows that, if optimally designed, trees allow the satisfaction of requirements in terms of PER. However, latency may increase with respect to star topologies, and also the energy consumed by router nodes can become quite large. This requires that nodes acting as routers are connected to the electrical grid; this also requires appropriate strategies for network self-healing have to be implemented, in case of failures or damages of routers.

On the other hand, when a multi-hop network needs to be established, mesh topologies are an other option; they have been studied through experimental measurements by Apptech and UoR.

Apptech developed a (small) test-bed composed of IEEE 802.15.4-compliant Jennic devices, distributed over an office building and communicating their data to the coordinator. A mesh topology, using a routing algorithm simpler than AODV, is established. The traffic generated is similar to the one defined by the eDIANA application and interesting results on the behavior of a real network are provided.

The number of incidents (packet failures) occurred over time, by observing the network for days, and the average duration of such incidents, are shown. Also results about the routes chosen by devices at different times, are provided. Results show that the losses are negligible. Even though these results refer to a network composed only of 5 nodes, we can state that the routing protocol proposed here can provide good results when a two-hop communication network is built. According to



the maximum size of the Cells fixed by the application, a two-hop communication network should be sufficient to cover the apartment in most, if not all, cases.

Finally, UoR provided some experimental results based on a test-bed composed of Tmote sky devices (based on TinyOS radio stack). Both trees and mesh topologies, based on AODV routing protocol, have been addressed. Results show that the tree outperforms the mesh topology, owing to the complexity of AODV.

In conclusion, the above numerical investigations demonstrate that IEEE 802.15.4/Zigbee is a suitable technology to be applied to the eDIANA platform and that, if opportunely designed, the network is able to satisfy all the requirements set within the Project.

As a consequence, the above mentioned studies will continue in the next months and final results, with all parameters set for each scenario, will be included in the next Deliverable (D2.3-B).



Conclusion

The D2.3-A is the first official report issued by Task 2.3, and it is also the first official document within the Project, dealing with the design of the communication part of the eDIANA platform. The document represents the baseline for the definition, development and engineering of the eDIANA platform elements.

The main outcomes of this Deliverable are described below.

First, a list of requirements that the communication network must be able to fulfill, has been defined; a useful classification of the eDIANA applications, taking into account the data traffic generated within the network, has been introduced for the purpose of allowing clear and simple comparison of performance levels between separate technical solutions.

Then, the communication architecture and the role of the different eDIANA devices, from a communication perspective, have been discussed. A proper functional separation between the inter-Cell network, for the communication among the MCC and different CDCs, and the intra-Cell network, for the transmission of data from the Cell level devices to the CDC, has been identified. The two sub-networks clearly show separate characteristics, and this drove the selection of different communication techniques. Several wired and wireless suitable technologies have been analysed, providing details about the communication protocols and network topologies they implement.

The inter-Cell network will be most probably realised implementing wired solutions based on PLC systems. Several technologies have been identified in Chapter 2 and compared in terms of availability of products on the market, costs, bandwidth and interfaces. The choice will be based on cost issues and on the compatibility with the device/devices that will be used as CDC and MCC (e.g., the ST Spear platform). Based on the selection of a specific technology, the inter-Cell network topology might be different (e.g., a star or tree if PRIME is used and an office building is considered, etc.).

Concerning the Cell level, which received most of the attention within the Task owing to its larger potential complexity (many nodes per Cell might be developed, and their deployment is subject to many degrees of randomness), it was decided to implement wireless solutions. After the consideration of the available options, IEEE 802.15.4/Zigbee has been selected within the Task as the most suitable technology, for reasons mainly related to the plethora of products already available on the market, and because of the fulfillment of the system requirements set by the applications, as is proven in Chapter 4.

Different topologies for IEEE 802.15.4/Zigbee networks have been considered by means of numerical results achieved through simulations and experimental



measurements. Results show that if a star topology can be used, depending on the physical and geometrical characteristics of the scenario, IEEE 802.15.4/Zigbee can fulfill all requirements defined in the Project, whatever the application (Monitoring or Controlling) considered. On the other hand, if the scenario requires multi-hop capabilities and the network topology becomes more complex, fulfillment of the requirements can be achieved provided that some guidelines are followed, and depending on the fine tuning of the network parameters (e.g., SO and BO at MAC layer, etc.).

Having proven that IEEE 802.15.4/Zigbee is a suitable technology for the eDIANA platform is thus the most important result of this Deliverable; all considerations discussed in Chapter 4 will be used in the next six months to perform the fine tuning of all network parameters. The next Deliverable of this Task (D2.3-B) will be mainly focused on the design of the IEEE 802.15.4 intra-Cell network, while also a final decision about the technology to be used within the inter-Cell network will be provided.

Finally, the content of this Deliverable will represent the starting point for WP3, for the engineering of Cell level devices and for the realisation of the demonstrator.



Acknowledgements

The eDIANA Consortium would like to acknowledge the financial support of the European Commission and National Public Authorities from Spain, Netherlands, Germany, Finland and Italy under the ARTEMIS Joint Technology Initiative.

References

[1] Draft Standard for Powerline Related Intelligent Metering Evolution, 1.3A, October 2009.

[2] IEEE 802.16-2004, IEEE Standard for local and Metropolitan Area Networks-Part 16: Air Interface for Fixed Broadband wireless Access Systems.

[3] IEC 61334-4-1:1996: Distribution automation using Distribution Line Carrier Systems – Part 4: Data communication protocols.

[4] IEEE 802.15.4 Standard, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low- Rate Wireless Personal Area Networks (LR-WPANs). Piscataway, New Jersey, 08855-1331: IEEE, 2006. [Online]. Available: http://standards.ieee.org/getieee802/802.15.html.

[5] IEEE Standard for Information Technology-Telecommunications and Information Exchange Between Systems-Local and Metropolitan Area Networks-Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Std 802.11-2007 (Revision of IEEE Std 802.11-1999). June 12 2007. Page(s): C1 – 1184.

[6] Z. Alliance, “Zigbee Specifications”. Zigbee Standard Organisation, 2008. [7] The ZigBee Alliance web site: http://www.zigbee.org/en/index.asp [8] IPv6 over Low power WPAN Working Group web site:

http://www.ietf.org/html.charters/6lowpan-charter.html [9] J. Polastre, H. Jason, D. Culler, “Versatile Low Power Media Access

for Wireless Sensor Networks”. SenSys’04, November 3–5, 2004, Baltimore, Maryland, USA.

[10] http://www.isi.edu/ilense/software/smac/index.html [11] A. Cunha, A. Koubaa, R. Severino, and M. Alves, “Open-ZB: an open-source

implementation of the IEEE 802.15. 4/ZigBee protocol stack on TinyOS”. Mobile Adhoc and Sensor Systems, 2007. MASS 2007. IEEE Internatonal Conference on, pages 1–12, 2007.

[12] www.xbow.com

[13] Crossbow, “MPR-MIB Users Manual”, Revision A, June 2007.

[14] IEEE Std 802.15.1 - 2002 IEEE Standard for Information technology-Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements. - Part 15.1: Wireless



medium access control (MAC) and physical layer (PHY) specifications for wireless personal area networks (WPANs).

[15] Bluetooth SIG, Inc: Specification of the Bluetooth System - Covered Core Package Version: Tokyo.

[16] Bluetooth Low Energy Technology web site: http://www.bluetooth.com/Bluetooth/Products/Low_Energy.htm.

[17] IEEE Std 802.15.4a-2007: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs) - Amendment 1: Add Alternate PHYs

[18] Huilin Xu and Liuqing Yang, “Ultra-Wideband Technology: Yesterday, Today, and Tomorrow”, Proceedings of IEEE Radio and Wireless Symposium, 2008.

[19] M.G. Di Benedetto, et al., “UWB Communication Systems. A Comprehensive Overview”, Hindawi Publishing Corporation, 2006.

[20] ISA-100.11a-2009 Wireless systems for industrial automation: Process control and related applications.

[21] V. Oksman and S. Galli, “G.hn: The New ITU-T Home Networking Standard”. IEEE Communications Magazine. October 2009.

[22] Press Release: HomePlug® AV Technology Enables IEEE 1901 Draft Standard, Portland, Ore., July 28, 2009.

[23] Panasonic Technology Incorporated into IEEE P1901 Draft 2.0 Standard for Broadband-Over-Powerline Networks, Osaka, Jan 7, 2010.

[24] EN50065-1:2001: Signalling on low voltage electrical installations in the frequency range 3 kHz to 148.5 kHz – Part 1: general requirements, frequency bands and electromagnetic disturbances.

[25] IEC 61334-4-32:1996: Distribution automation using Distribution Line Carrier Systems – Part 4: Data communication protocols – Section 32: Data Link Layer – Logical Link Control(LLC).

[26] IEC 61334-4-1:1996: Distribution automation using Distribution Line Carrier Systems – Part 4: Data communication protocols – Section 1: Reference model of the communication system.

[27] RFC 791: Internet Protocol Specification, 1981.

[28] RFC 793: Transmission Control Protocol, 1981.

[29] RFC 768: User Datagram Protocol, 1980.

[30] IEC 62056-47:2006: Electricity metering – Data exchange for meter reading, tariff and load control – Part 47: COSEM transport layers for IPv4 networks.

[31] DLMS UA 1000-1: Blue Book: COSEM identification system and interface objects, 8th edition, 2007.



[32] IEC 62056-61: 2006: Electricity metering – Data exchange for meter reading, tariff and load control – Part 61: object identification system (OBIS).

[33] IEC 62056-62:2006: Electricity metering – Data exchange for meter reading, tariff and load control – Part 62: interface classes.

[34] P. Ran, M. Sun and Y. Zou, ”ZigBee Routing Selection Strategy Based on Data Services and Energy-Balanced ZigBee Routing,” Proc. IEEE Asia-Pacific. On Services Computing 2006,pp.400-404, Dec. 2006.

[35] K. Lee, S. Kim, Y. Choi, H. Park, “A Mesh Routing Portocol using Cluster Label in the ZigBee Network”, Proc IEEE Mobile Ad hoc and Sensor Systems 2006, pp.801-806, Oct. 2006.

[36] Charles E. Perkins and Elizabeth M. Royer, “Ad hoc On-Demand Distance Vector Routing”, Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, February 1999, pp. 90-100.

[37] S. Zvanovec, P. Pechac, M. Klepal, “Wireless LAN Networks Design: Site Surve or Propagation Modelling?”, Radioengineering, Vol. 12, n. 4, december 2003.

[38] Freescale MC13224V Data Sheet, Rev. 1.2, 02/2009.

[39] C. Buratti, F. Fabbri and R. Verdone, “Area Throughput of an IEEE 802.15.4 Based Wireless Sensor Network”, Proc. of European Conference on Wireless Sensor Networks, EWSN 2009, Feb. 2009, Cork, Ireland.

[40] C. Buratti, “A Mathematical Model for Performance of IEEE 802.15.4 Beacon-Enabled Mode”, Proc. of ACM IWCMC 2009, Leipzig, Germany, June 22-25.

[41] http://motelab.eecs.harvard.edu.

[42] G.W.Allen et al., “Motelab: A wireless sensor network testbed”.

[43] CC2420 Transceiver Datasheet.

[44] Tinyos TEP123 - http://www.tinyos.net/tinyos-2.x/doc/txt/tep123.txt

Documents

D2.3-A Network topology and communications architecture ...s15723044.onlinehome-server.info/artemise/documents/D23A_Network... · Network Topology and communications architecture