Message routing for in-network processing in wireless mesh lighting control system in hospitality environment
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Message routing for in-network
processing in wireless mesh
lighting control system in
hospitality environment
Eero Prittinen
School of Electrical Engineering
Thesis submitted for examination for the degree of Master of
Science in Technology.
Espoo 24.5.2021
Supervisor
Prof. Mervi Paulasto-Kröckel
Advisor
MSc Jakub Järvenpää
Copyright © 2021 Eero Prittinen
Aalto University, P.O. BOX 11000, 00076 AALTO
www.aalto.fi
Abstract of the master’s thesis
Author Eero Prittinen
Title Message routing for in-network processing in wireless mesh lighting control
system in hospitality environment
Degree programme Automation and Electrical Engineering
Major Translational engineering Code of major ELEC0007
Supervisor Prof. Mervi Paulasto-Kröckel
Advisor MSc Jakub Järvenpää
Date 24.5.2021 Number of pages 44+8 Language English
Abstract
Smart light control systems are becoming increasingly popular in the hospitality
environment. However, legacy light control systems are not capable of coping with the
more demanding requirements of hospitality environments such as big public spaces
and large amounts of individual rooms under the same network. Employing wireless
mesh networks as a means of communication coupled with in-network processing
seem like a promising candidate for such networks.
This thesis analyses the suitability of wireless mesh networking as a means of
communication for large-scale lighting control system in hospitality environment.
From analysing mesh networking as technology and hospitality as an environment the
main requirements for light control system were determined to be minimal latency,
reliability, light control synchrony, minimal networking infrastructure, and capability
for large network size. The issues of typical wireless mesh based lighting control
systems were determined to be limited network size, centralized control, inducing
latencies, and flooding based routing.
Specifically the ability to route messages over multiple hops to large groups of
devices without flooding the whole network was not found in existing systems. This
thesis proposes a solution to message routing for large groups of devices without
flooding the whole network. The solution is based on configuring the devices into
groups within which the messages can propagate freely. By limiting the message
propagation into groups, unnecessary message leakage to the network is minimized.
Keywords lighting, mesh, hospitality, routing
Aalto-yliopisto, PL 11000, 00076 AALTO
www.aalto.fi
Diplomityön tiivistelmä
Tekijä Eero Prittinen
Työn nimi Viestien reititys in-network prosessoinnille langattomassa
valaistuksenohjausjärjestelmässä hotelliympäristössä
Koulutusohjelma Automation and Electrical Engineering
Pääaine Translaationaalinen tekniikka Pääaineen koodi ELEC0007
Työn valvoja Prof. Mervi Paulasto-Kröckel
Työn ohjaaja MSc Jakub Järvenpää
Päivämäärä 24.5.2021 Sivumäärä 44+8 Kieli Englanti
Tiivistelmä
Älykkäät valaistuksenohjausjärjestelmät ovat yleistyneet hotelleissa viime vuosien
aikana. Perinteiset valaistuksenohausjärjestelmät eivät kuitenkaan kykene täyttämään
hotelliympäristön asettamia erikoisvaamtimuksia, kuten suuria julkisia tiloja ja suurta
määrää yksittäisiä huoneita saman verkon alla. Langattomien mesh-verkkojen ja
in-network prosessoinnin käyttö vaikuttaa lupaavalta ratkaisulta kyseisiin ongelmiin.
Tämä työ analysoi mesh-verkkojen sopivuutta kommunikaatioalustaksi suuri-
kokoisille valaistuksenohjausjärjestelmille hotelliympäristössä. Analysoimalla mesh-
verkkoteknologiaa ja hotelliympäristön valaistuskäytäntöjä, järjestelmän tärkeim-
miksi ominaisuuksi saatiin valaistuksen ohjauksen viiveen minimointi, ohjauksen
luotettavuus, valojen synkroninen toiminta, verkkoinfrastruktuurin vähentäminen ja
soveltuvuus suurikokoisiin verkkoihin. Tyypillisten mesh-verkkoihin perustuvien va-
laistuksen ohjausjärjestelmän ongelmiksi todettiin rajoitettu verkon koko, keskitetty
ohjaus ja siihen liittyvä viive ja flood-tyyppinen viestien reititys.
Oleellisin olemassa olevien ratkaisujen puutteista on viestien reitittäminen suurille
laiteryhmille. Tämä diplomityö esittää mesh-verkoissa toimivan reititysratkaisun,
joka soveltuu käytettäväksi suurissa verkoissa ja vähentää tarpeettomia viestien
edelleenlähetyksiä. Ratkaisu perustuu jakamalla verkon laitteet ryhmiin, joiden sisällä
viestit saavat propagoida vapaasti. Rajoittamalla viestit ryhmien sisälle, tarpeeton
viestien välittäminen eteenpäin voidaan minimoida.
Avainsanat valaistus, mesh, hotellit
5
Preface
I want to thank my instructor Jakub Järvenpää for his sharp and on point comments
and Professor Mervi Paulasto-Kröckel for her undelayed feedback and responses to
my questions.
Otaniemi, 24.5.2021
Eero J. Prittinen6
Contents
Abstract 3
Abstract (in Finnish) 4
Preface 5
Contents 6
1 Introduction 8
1.1 Objective and scope of the thesis . . . . . . . . . . . . . . . . . . . . 8
1.2 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 About the graphics of this thesis . . . . . . . . . . . . . . . . . . . . . 9
2 Lighting control systems state of the art 9
2.1 Wired control systems . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 DALI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 KNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Evaluation of wired bus based networks . . . . . . . . . . . . . 12
2.2 Wireless control systems . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Bluetooth mesh . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Evaluation of wireless solutions . . . . . . . . . . . . . . . . . 14
3 Wireless mesh networking introduction 14
3.1 Mesh routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Types of routing . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Mesh network routing state of the art . . . . . . . . . . . . . . . . . . 16
3.3 Development of application specific routing . . . . . . . . . . . . . . . 17
4 Control system requirements 18
4.1 Hospitality environment as units of lighting control . . . . . . . . . . 18
4.2 User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 System costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Communication requirements . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1 Network size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 Network throughput . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.3 Network latency . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 No energy light switches . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 Centralized and decentralized logic . . . . . . . . . . . . . . . . . . . 21
4.6.1 Centralized logic . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6.2 Decentaliced logic . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 5 In network processing, from switch click to turning on lights 23 5.1 Determining light levels with switch configurations . . . . . . . . . . 24 5.2 Light control synchrony . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3 Tradeoff between synchrony and latency . . . . . . . . . . . . . . . . 27 6 Simulating mesh network routing 27 7 Message routing in large-scale lighting control system 29 7.1 Switch message propagation problems . . . . . . . . . . . . . . . . . . 30 7.2 Preventing multiple devices from broadcasting the switch message . . 30 7.3 Limiting the message propagation . . . . . . . . . . . . . . . . . . . . 32 7.4 Node grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.5 Limitations of group propagation . . . . . . . . . . . . . . . . . . . . 36 7.6 Light synchrony in large public spaces . . . . . . . . . . . . . . . . . 37 8 Conclusion 38 References 40 A Simulator source code 45 Abbreviations IoT Internet of things DALI Digital Addressable Lighting Interface
8
1 Introduction
Recently smart lighting control technologies have gained significant interest[1, 2].
They offer benefits such as enhanced user experience[3], easier maintenance, and
energy savings[4, 5, 6].
Despite the growth and technological advancements in lighting control, the
available solutions still rely on age-old technologies and legacy standards. This can
be seen in the popularity of wired bus-based systems, such as Digital Addressable
Lighting interface (DALI)[7] and KNX[8], even in recent installations. Moreover,
while these systems offer benefits such as proven technology and standardisation,
these legacy systems can not cope with the new requirements of modern illumination
control applications. Their drawbacks include reliance on wired communication,
limited network size, and redundant infrastructure.
Recently, advances in mesh networking have made it an attractive platform
also for illumination control. Mesh networking enables building wide networks and
decreased need for additional infrastructure. However, the existing solutions pose
various problems, as the protocols are typically accommodated to general purpose
mesh communication protocols. This overlooks the special needs of illumination
control for wireless communication, such as latencies and network size. Although
solutions have been developed for small-scale illumination control systems, these
solutions have failed to cope with the requirements for large-scale control systems
needed in the hospitality and hotel environment.
1.1 Objective and scope of the thesis
This thesis develops an application-specific, wireless mesh-network routing algorithm
for a large-scale illumination control system. Unlike the typical development approach,
that adapts the application to the mesh communication protocol, this thesis aims
to identify the communication requirements for illumination control. The technical
requirements set for communication will be derived by analysing lighting control in
the hospitality environment.
1.2 Structure of the thesis
The rest of the thesis is divided into 8 chapters. Chapter 2 examines the legacy
methods and standards currently used in lighting control. Chapter 3 introduces
mesh networking as a concept and provides a brief literature survey on the recent
development on the latest research in mesh networking routing. Chapter 4 analyses
the application and technical requirements set for lighting control in the hospitality
environment. Chapter 5 presents the small-scale in-network processing methodology
for lighting control. Chapter 6 briefly presents the simulation tool developed to
simulate the mesh routing protocol discussed in the thesis. Finally, Chapter 7
discusses the issues of message routing in large-scale lighting control systems, proposes
a solution to tackle these issues, and presents the simulated results. Chapter 8concludes the thesis by summarizing the main findings and identifying the needs for
future work.
1.3 About the graphics of this thesis
This thesis uses multiple graphical presentations to better deliver the ideas behind
the technological concepts. Explaining message propagation and connections in mesh
networks benefit greatly from visual aids. Here is a short guide to help the reader
better understand the visuals.
The mesh network is composed of single devices that can transmit and receive
data. These are called nodes. In the graphs nodes are presented as black, gray or
white circles. These shades may refer to different things, for example if the node
receives a message or not, or how many hops the message has propagated. If the
nodes are divided into separate groups, or a set of nodes needs to be highlighted,
the border of the node is highlighted with a color of the grouping. In graphs, which
also present non-routing nodes, the non-routing nodes are drawn as smaller circles
compared to the routing nodes.
Figure 1: Descriptions different graph styles
2 Lighting control systems state of the art
Most of us are familiar with the traditional method of light control, where the
luminaires are wired in series with the light switches. This provides simple on/off
control for a given luminaire, room or space, and is usually enough for home usage.
However, when considering more complex installations, like large public spaces,
offices, or hotels, the hard wired controls can not match the need for centralized
management, elevated user experience, and easy maintainability. For example, being
able to turn on and off all the lights with a single switch in an apartment with
multiple rooms still permitting individual switches to control each room turns out to
be impossible.10
In order to provide more varying control over lighting in a more sophisticated
manner, different control systems have been developed. Typically lighting control
systems allow for easy reconfiguration of controls, dimmable lights, lighting scenes,
and varying control methods such as scene switches and motion sensors. They can
also provide access through an external controller, which enables usage of external
user interfaces over the internet, mobile application, or voice commands. These
systems have previously been achieved through wired connections, but are gradually
transforming towards wireless solutions. Still, wired systems are widely applied even
in new installations due to them being proven, reliable, and widely available.
In this section control systems widely applied in the industry are discussed to
provide background information on how light control systems are typically built.
The goal is not to provide complete details of each system, but rather to give a brief
introduction to them focusing on the networking capabilities. The protocols here
have been selected based on findings in the literature, information about existing
products, and advice from experts on the field.
2.1 Wired control systems
Wired lighting control systems function by connecting the luminaires to a control
unit through physical data wiring. These kinds of control systems have been the
industry standard for decades and are thus well established and widely approved.
Standardisation has made these systems easy to build and manufacturers have been
able to make compatible components, creating an ecosystem around the protocol.
The topology of a wired control system is usually bus based. This means that
all the devices in a network connect to a single data bus, which is employed for the
exchange of control and configuration messages. In addition to input devices and
luminaires, the bus usually has a bus power source and a central controller, which
coordinates the communication in the bus, providing access to an external control
and configuration application.
Below is presented two most common control systems used for lighting control.
They are discussed in a detail that allows for comparison with other solutions in the
context of this thesis.
2.1.1 DALI
DALI, short for Digital Addressable Lighting Interface, is a standard communication
medium for light control. DALI is a bus based network, where the data is transmitted
over two wires. One dali network can accommodate up to 64 devices, as individual
devices are addressed with 6bit address. DALI supports sending messages to groups
and activating pre-defined scenes.[7]
Dali network requires a power source and network controller which is used to
configure and control the DALI devices. All the devices in a dali network connect
to the same bus, which can be laid in star topology, daisy chain or combination of
these. DALI control gear is required to be galvanically or optically isolated from the
bus, as DALI wiring is usually combined in the same cable with mains power going11
Figure 2: Wired data bus
to the DALI light. The DALI data line is rated to be maximum of 300 meters in
length. For longer distances, a specialised repeater device may be required.[7]
As the DALI bus is powered with a specialised power source, some low power
devices, like switches and motion sensors[9] can be bus powered.
2.1.2 KNX
KNX is another wired bus based automation standard that is widely applied in
illumination control. Like DALI, KNX is also based on a single data bus with its own
power source, where all the devices can be connected together. KNX network can
accommodate up to 64 devices. However this can be extended with line repeaters,
which can each handle additional 64 devices. The main line can operate up to three
additional line repeaters, which means the total number of devices in a bus can reach
up to 255. Alternatively the bus can be split into separate lines with line couplers,
15 of which can be operated from the main line. Each coupled line requires its own
power supply and can then operate additional 64 devices. Different main lines can
then be combined with area couplers which allow for up to 15 areas to work in the
same network.[8]
KNX communication medium is not limited only to using twisted pair cable data
bus. KNX supports also communication through power line, radio, or IP networks.
These topologies can also be mixed together in the installation. KNX network also
does not need a central control unit, as the devices can talk directly to each other.
For example, a light switch can send a signal directly to the luminaire driver to
turn on the lights. Still, in complex installations programming the rules devices will
operate with requires using dedicated tools and software.[8]12
2.1.3 Evaluation of wired bus based networks
As both KNX and DALI are well established industry standards, they are an easy
choice for an illumination automation system. However, they do have some short-
comings that make them inefficient, especially in very large installations.
First of, wired communication in general requires additional infrastructure to
operate. Data bus requires wiring both as physical material and as installation
labour. Both KNX and DALI data busses also require additional power sources.
Extending networks require repeaters and couplers, and in case of DALI, inter
controller communication outside the core specification. In a building wide installation
this means also providing networking infrastructure to all controllers. All the
additional infrastructure will add to the material and design costs of the automation
system.
The limited address spaces and cost of supporting infrastructure can also lead to
desire to optimize DALI and KNX installations. For example, instead of creating
an own network for each room in a building, it is tempting to span one network
over multiple spaces, thus reducing the amount of single networks needed. While
this reduces the amount of additional infrastructure, this can lead to multitudes of
problems. First of, designing and installing the wiring of such a system might be
challenging, as the network needs to span over large areas in the building. Secondly,
if all the networks host the maximum number of devices, installing additional devices
in the future is virtually impossible.
Having all the devices connected to a single bus makes the installation rather
simple, as there is a high degree of freedom in the wiring topology. However, this
creates a single point of failure, which can paralyse the operation of the whole bus,
with just one compromised device. For example in DALI, if a single device fails and
shorts the bus, communication to all the devices in the network will be compromised.
Finding the problem device can also be laborious, as parts of the network need to be
manually isolated to find the broken unit.
2.2 Wireless control systems
In addition to wired control systems, wireless alternatives are also emerging in the
industry. Most of these have not yet achieved as widespread adoption as DALI and
KNX, but are getting gradually more common.
The benefits of wireless connectivity over wired bus systems is the reduced
infrastructure in terms of wiring and power sources. Installations are easier to plan,
as network wiring is not required.
2.2.1 Zigbee
Zigbee is a wireless networking protocol. Zigbee is widely used in various applications
and backed by hundreds of companies participating in the Zigbee alliance. Zigbee is
expanding on IEEE 802.15.4 and supports various network topologies, such as star,
tree, and mesh[10, 11]. Out of these mesh is typical for automation systems, where
larger area networks are required.13
The theoretical amount of devices in a Zigbee network is up to 65 000, but in
practise this is usually much less, as larger network size increases latencies[12, 13]
and can cause network congestion[13].
Zigbee network consists of three types of devices. Each network has a central
coordinator device, which takes care of setting up the network. The mesh network
is constructed by router nodes, which relay the information in the network. End
devices are the actual payload devices in the network, providing inputs and outputs
such as sensor readings and light control. The end devices do not take part in the
message routing, to allow them to operate with lower power consumption.[11]
Figure 3: ZigBee mesh topology. Red: coordinator, Blue: routers, Green: devices
In addition to network operation Zigbee defines application profiles to allow
interoperability between manufacturers. This makes it easy to build automation
systems using Zigbee devices that follow this specification.[10]
2.2.2 Bluetooth mesh
Bluetooth mesh is the effort of Bluetooth SIG companies to provide mesh networking
based on bluetooth connectivity. The goal is to provide communication means for
smart building systems.[14]
Bluetooth mesh consists of nodes. Node is the basic unit with radio communication
capabilities, and can contain multiple devices, like sensors and actuators. Nodes can
be of different types. Routing nodes take care of creating the mesh network and
routing messages. Low power nodes are nodes with optimised battery conservation,
which is achieved by limiting their radio operation to minimum. This means that
low power nodes will only transmit data when necessary and query new data from
friend nodes nearby. Friend nodes are nodes that send messages to low power nodes14
whenever they are available for communication. In addition to these, Bluetooth mesh
can contain proxy nodes, that provide communication to non-mesh devices.[14]
Messages in the Bluetooth mesh network are of three types, unicast, group, or by
virtual addressing. Unicast messages are targeted from a single node to another single
node. Group messages are targeted to a group of nodes. Group addresses can be
assigned dynamically or be fixed. Fixed groups are the node types described above:
relay nodes, friend nodes, proxy nodes, and all nodes. Dynamic group addresses
are assigned during operations to group certain nodes together. Virtual addresses
are addresses assigned to devices. As node can contain multiple individual devices,
virtual addresses are used to address them instead of addressing the node.[14]
Message propagation in bluetooth mesh is conducted by controlled flooding.
Flooding refers to the propagation method, where each node retransmits the message
it receives to all the other nodes in its proximity. In bluetooth mesh this is constrained
with two methods. Message being transmitted contains a time to live(TTL) value,
which refers to the amount of hops the message is allowed to perform when propagating
through the network. Additionally, each node will keep a cache of all the messages it
has sent, and skip sending messages it has already sent.[14]
2.2.3 Evaluation of wireless solutions
Compared to the wired solutions, the main benefit of wireless systems is the lack
of wiring, which makes the system easier and cheaper to install. Being established
technologies on the market also enables device interoperability between manufacturers.
Still, the existing solutions are not perfect for advanced lighting control systems.
The main issues with existing systems are related to the network size. Even
if the address space permits thousands of devices, the practical operation limits
the network size. In Zigbee, large networks were concluded to induce latencies and
possible network congestion. The routing methods in bluetooth mesh also pose issues,
especially for large networks. The controlled flooding might not reach all intended
nodes, and broadcasting trough the whole network creates lots of unneccessary traffic.
3 Wireless mesh networking introduction
Mesh networking refers to means of wireless communication, where the messages
can perform multiple hops inside the network to reach their destination. Unlike in
traditional point-to-point wireless communication where the destination of a message
directly receives the very wireless signal transmitted by the source of a message,
mesh network is based on relaying messages to reach further coverage for the network.
This allows for messages to travel much further than would be allowed by only the
transmission reach of the message source.
Wireless mesh network consists of individual radio enabled devices usually referred
to as nodes. Nodes can perform different functions such as work as inputs and outputs
for an automation system. Nodes that take part in enabling communication in the
mesh network are called routing nodes or routers. Routers can receive transmissions
from other nodes and relay them forward to the nodes in the reach of their transmission15
power. This way a single message can be re-transmitted multiple times, and can
reach multiple, or even all nodes in the network.
3.1 Mesh routing
In mesh networking the process, which determines how the message proceeds in
the network is called routing. In essence routing is the decision to rebroadcast
or not the routing node makes when it receives a message from the network. By
applying different routing methods, the propagation of messages in the network
can be manipulated to achieve efficiency, reliability, decrease of latency and higher
network throughput.
If message retransmission is not constricted in any manner, the routing is con-
sidered as flooding. This means that the message will “flood” the network and
reach each device within it. In flooding networks, when a node receives a message it
rebroadcasts it. Retransmitting already transmitted messages is filtered to prevent
messages from looping in the network forever. Usually the flooding may also be
constrained with hop limit or time to live value, which determines how many times
the message is allowed to be retransmitted in the network.
3.1.1 Types of routing
Different applications require different methods of routing. Generally, three main
mechanisms can be generalised: one-to-one, one-to-many, and many-to-one. One-
to-one routing refers to the message having a known starting and destination node.
The goal in one-to-one routing is usually to find the most efficient route through the
network between two nodes. One-to-many routing is applicable when a single node
is sending a message to a selected group of nodes. Many-to-one routing refers to
situation when the messages from multiple nodes are wanted to be collected to a
single node in the network. This would be the case for example with large sensor
networks.16
Figure 4: examples of one-to-one, one-to-many, and many-to-one routing
The purpose of the mesh network is to provide the transport layer for communi-
cation. As mesh networks are not based on predefined point to point connections
but the routing is created by managing rebroadcasts, it is in theory possible for a
single mesh network to support multiple routing protocols simultaneously for multiple
applications. For example single mesh could provide both one-to-many routing for
luminaire control, and many-to-one routing for sensor data collection. In reality, the
ability to support multiple applications is limited by the physical resources, as node
memory and processing power and message relaying throughput capability.
3.2 Mesh network routing state of the art
Mesh networking as a technology has been around for decades[15]. Lately, there has
been an increasing interest in development due to increasing demand for more complex
and non hierarchical topologies for IoT and other connected applications[16, 17].
For this thesis, the most relevant field of research is development of mesh network
routing. As more and more demanding applications arise for mesh networking, more
reliable and efficient routing methods are needed. As different applications have
different routing needs, there is a demand for specialised routing protocols. In most
coarse division, routing protocols can be divided into one-to-one, one-to-many, and
many-to-one routing.
In one-to-one routing, the goal is to minimise the amount of unnecessary hops
by finding the most optimal path between the source and the target. The routing
methods can be divided coarsely to reactive routing, proactive routing, and hybrid
routing[18, 19]. The division is not strict, and routing protocols may contain features
from multiple routing methodologies.17
In reactive routing protocol, the route between two nodes is discovered on-
demand[16]. This means, that no prior knowledge of the network topology is required.
The route is discovered by flooding the network with discovery message[16]. The route
discovery protocol can also employ previously discovered routes[20]. The flooding
can also be optimized to reduce the network overhead thus reducing the network
traffic[21]. The nodes can also contain some routing information, like the next best
hop towards a destination node[22].
Contrary to the reactive routing where the route is discovered on-demand a
proactive routing protocol discovers the routes before they are needed. This is done
by storing information about the network topology in the nodes memory in form of
routing tables[16, 23]. Proactive routing works well in wireless mesh networks with
small amounts of nodes where the data rates are high[19].
Hybrid routing protocols combine the features from both reactive and proactive
routing[24]. Hybrid routing uses both stored information about the network and
route discovery[19]. Mesh networks with hybrid routing can for example organize
nodes in to clusters and use reactive routing inside the clusters and proactive routing
in communication between the clusters[25].
In many-to-one routing the goal is to route messages to a single node in the
network, for example in the purpose of data collection. These kind of networks are
usually built based on tree topology, as the messages are collected from “leaf nodes”
to intermediary nodes and towards the destination or root node [26, 27]. In addition
to routing data from network to the root node, the tree topology can also be used to
route data from root to the leaf nodes by special addressing[27].
One-to-many routing, or multicasting, aims to distribute a message from a single
source node to a selected set of nodes[28]. The approach to multicasting depends on
the application specific requirements, such as delay, energy efficiency and scalability
[28]. Some approaches create a multicast group similar to a tree topology, where
messages are transmitted through a root node[29].
3.3 Development of application specific routing
Although a lot of the research in mesh networking focuses on developing general
purpose mesh routing protocols, in some cases a more application specific approach
may be beneficial. Implementing specialized routing protocol usually aims to enhance
some of the routing metrics such as energy efficiency, latency, security, or reliability.
In [30] the mesh networking protocol is optimised to work in network of mobile
robots, which requires ability to react rapidly to network topology changes. This
is achieved by using multiple metrics for link quality, such as robot positions and
signal strength. Utilizing multiple link metrics can also be used to increase the
network reliability[31]. In [32] indoor robots use a mesh of dynamic nodes to find
mobile target nodes trough flooding the network and receiving the path to target as
a response.
Some applications require improved security. In [33]analyses the networks ability
to withstand denial of service attacks. In [34] a mechanism to increase the security
of a smart electic grid is presented.18
Improving energy efficiency of routing is one reason to develop more custom
routing protocols. In some cases the the aim is to extend the longevity of a network
of battery powered devices. In [35] this is considered in underwater acoustic sensor
deployment and approached by clustering nodes. In [36] analyses the requirements of
forest fire detection system aiming to achieve high fault tolerance and low response
times in addition to battery life maximation. In [37] the routing takes in to account
the individual battery levels of nodes while determining the most energy efficient
path trough the network. In [38] the lifetime of a wireless mesh network in coal mine
is extended alongside improved reliability trough route recovery.
4 Control system requirements
Diverging from other building illumination automation applications, hospitality
presents its own specialized requirements for automation systems. While the basic
technological infrastructure may be somewhat identical to any other light control
system, there are some key characteristics that span from the typical usage of hospi-
tality spaces. Analysis of these characteristics helps to understand the requirements
that are to be set for the light control application and technical layers.
4.1 Hospitality environment as units of lighting control
One way to characterize illumination control environments is to consider the instal-
lation as units of control. Unit of control is a set of lights that form an isolated
controllable entity, with its own inputs and outputs. For example, in a hotel, a single
hotel room would be one unit of control. In offices, this could be one office space or
a meeting room. The types and amounts of units of control affect the application
specific needs the system poses on lighting control.
Hotels typically have two types of units of control, hotel rooms and public spaces.
From a lighting control point of view typical characteristics for a single hotel room are
short distances between inputs and actuators, such as light switches and luminaires,
and vast amounts of the rooms. The public spaces on the other hand are larger,
possibly reaching all across the building without line of sight between the input and
luminaires, but there will be only a few of them in the building. Thus, hotels pose
two quite different environments for lighting control to work with.
4.2 User experience
In the hospitality industry, the income of an establishment is directly correlated
to the amount of booked visits by customers. From this it can be concluded that
hospitality has a high priority on user experience. Lighting in the hotels can be
considered as an important part of user satisfaction[39, 40]. Also, as individual
lighting preferences may vastly differ being able to adjust light levels contributes to
the positive user experience[41].
The most important feature of a lighting control is reliability. Poorly functioning
lights can in the worst case scenario completely ruin the user experience, For example,19
if the light control system breaks in the evening, the guest could be unable to turn
off the room lights and thus be unable to sleep.
To provide a feel of high quality user experience the light operation must be
responsive and smooth. In addition to good overall lighting design such as luminaire
types, light placement, brightness, and color, the light control should happen smoothly.
With light control, the quality can be quantized in two parameters, latency, and
concurrency or synchrony. Latency means the time that it takes from pressing a light
switch to the light reacting to the action. Synchrony refers to the time difference
between the reactions of single luminaires. High synchrony means that the lights
will turn on or off simultaneously.
4.3 System costs
Another important factor when selecting a light control system is the cost. Cost can
be divided into material and installation costs, and operational costs.
Material costs consist of all the materials involved in the communication medium
construction. In wired control networks, such as DALI and KNX this includes data bus
wiring, network controllers, network power sources and plausible network extenders
and repeaters. In wireless networks this includes central coordinators and network
routers. As all infrastructure also requires installation, it can be determined that
reducing the amount of infrastructure is one major way to decrease the installation
cost of the system.
During the operation of the system, the costs can be divided into maintenance
costs, and energy. As the energy used by the system is highly dependent on the
specific models of individual devices, and plausibly diminishes compared to other
expenses, evaluating it is outside the scope of this thesis. Costs for maintainability
come from two factors, the cost of maintenance labour and the cost of hotel room
downtime. Both of these can be minimized by increasing the reliability of the system,
having predictive maintenance capabilities, increasing the system resilience to failures,
and minimizing the time it takes to perform maintenance. One most important
feature of the network is to avoid single points of failure, which in case of a problem,
can cripple either large portions of the installation or even the complete system.
4.4 Communication requirements
To be able to fulfill the application requirements and provide the specified user
experience, the network must have certain capabilities and perform up to a certain
level. The main metrics are the network size, network throughput, and latency.
4.4.1 Network size
The network size is closely related to the infrastructure costs discussed earlier. Being
able to construct the whole system using only one network will reduce the need for
additional networking infrastructure and back end coordination between subnetworks.20
Hotel installations consist of thousands of devices, which means that the network
must be able to handle such a number of devices.
4.4.2 Network throughput
Network throughput capability refers to the amount of data the network is able to
handle. In lighting control, a single command is usually maximum of a few tens of
bytes in size, and they are transmitted quite sparsely. This means that the network
load is not very high in regular operation. Another parameter affecting the network
throughput capability is the bandwidth. In wired bus based systems, all the devices
use the same communication channel, which means only one message is allowed to
be sent at a time, and the devices themselves determine suitable collision detection.
In wireless networks the bandwidth may consist of multiple channels, which allows
more messages to be transmitted in the same wireless space without collisions.
Considering wireless mesh networks, the plausible network bottleneck is the central
coordinator device. In large networks, the messages arriving from multiple devices
may not cause problems in their proximity, but might lead to network congestion
in the central coordinator. This can lead to messages being delayed or completely
lost. To avoid this, three strategies can be taken. Either the network throughput
capacity needs to be higher on the central coordinator, the network must be split
into subsections and have multiple coordinators, or the communication to and from
the coordinator node must be decreased.
4.4.3 Network latency
Last network parameter to analyse is the network latency. Latency is especially
important for the user experience in time restricted real time applications, such as
light control. Too long latency between light switch press and the light turning on
may completely ruin the user experience for the hotel guests. In [42] the strict latency
requirements were also considered the main requirement for light control systems.
In application level, the latency refers to the time it takes from input event to
output action. In technical level this mainly consists of communications latency.
Some delay may be induced by executing the application logic in the devices, but this
is negligible compared to the communication and is not dependent on the network
technology.
In wired bus based networks, the latency consists of transmission time, and
network congestion. This refers to a situation where there are multiple messages sent
simultaneously in the network, and some messages need to wait to avoid collisions.
This is usually tackled by implementing device grouping and scenes, where multiple
devices are configured to be controlled by a single message.
In wireless mesh networks the transmission latency consists of the amount of
hops the message must take in order to reach its destination[12, 43, 44]. Also the
package size was show to have an effect on latencies[12, 43, 44].21
4.5 No energy light switches
Traditionally light witches have been either directly wired to control the luminaires,
or have been connected to the data bus of wired lighting control systems. In wireless
systems, battery powered light switches have also been used. However, recently there
has been development on no-energy light switches, which enable wireless operation
without the need to change batteries[45].
No energy switches function by harvesting the energy produced by the switch
motion in order to power the wireless transmission. This leads to completely wireless
and batteryless operation. Thus, no-energy switches contribute greatly in reducing
the costs by reducing infrastructure in the form of less wiring, installation, and
cutting the need for maintenance by omitting battery replacements. As no wires are
required, the installation can be reduced from having to drill a hole to a wall for the
switch body to using double sided adhesive to attach the switch to a wall.
As no-energy switches are not active devices, and only capable of transmitting
when activated, there is no method of two way communication with them. This
leads to few inconveniences, which will be discussed in the next chapter. Overall,
they pose clear benefits over the traditional wired light switches.
4.6 Centralized and decentralized logic
Unlike traditional directly wired control of lighting, in which the relation between
light switches and luminaires are hard wired, more complex lighting control systems
have cross connections between multiple inputs and outputs. As an example in a
hotel room a reading light might be controlled by direct on/off switch next to a bed,
by scene switch on the wall, and all off switch by the room door. In order to realize
the control, relational logic between inputs and outputs must be executed. This
logic can be processed either in a centralized manner, or in decentralized manner.
In centralized logic, all the relations of inputs and outputs are processed in a single
back end process running for example in a cloud service, In decentralized settings,
the logic is distributed into the network devices themselves. This can also be called
in-network processing.
4.6.1 Centralized logic
Having centralised logic really simplifies the configuration process, as all the logic
can be executed in a single process. Expanding such a system is also rather simple,
as no other device needs to be reconfigured if additional devices are added. This is
the typical approach of many home automation systems, which may even rely on
external cloud service to compute the logic.
When considering centralised processing of application logic there are three main
issues, latency, single point of failure[46], and network congestion[47]. If the message
needs to travel from the input device first to the central unit, and then the central unit
will send the commands to actuators, the message is usually travelling a longer route
it would have taken directly from input to output device. This becomes especially22
apparent with large networks, where the central unit might be tens of hops away,
and the light switch and the luminaire might be just one hop away from each other.
Having the application logic determined on a single process creates a single point
of failure for the whole network operation. If the central control unit is somehow
compromised, none of the lighting control will work. Also, in large networks when
there is a lot of activity, there is a possibility of network congestion near the central
unit[47].
4.6.2 Decentaliced logic
Relocating the application logic from the backend or edge service to the network solves
many of the issues related with centralized logic. First of, the operation no longer
relies on a single process getting rid of the single point of failure makin the system
more robust and reliable[46]. In addition it reduces the network communication, as
messages no longer have to route trough the central gateway, but only in their local
mesh area[48]. This further decreases the latencies drastically[49], especially in large
networks with multiple hops between the furthest nodes and the gateway.
Implementing in network processing however does come with its own requirements.
First off, the devices need to be able to receive, process, and execute the logic. There
are two approaches to apply the configuration logic, either in the transmitting end,
or in the receiving end. In standardised systems like DALI, both approaches are
utilized, as switches are configured to activate either groups or scenes, and luminaires
are configured to set a certain light level on a certain scene.
When utilizing low energy switches described in the previous section the applica-
tion logic is forced to be contained in the receiving device, as the switches can not
be configured to do any kind of preprocessing. This means that every device will
individually take care on how to react to different input signals it might receive. As
the transmitting end does not have any type of control over the message, and to
whom it is being sent, this requires some additional logic to be included, which will
be discussed in more detail in the next chapter of the thesis.
4.7 Conclusion
Above is the analysis of the application requirements from a technical point of view
containing analysis on network-, hardware-, and processing requirements. Decisions
made are justified based on the application requirements set above.
Minimal application latency Very important
Application reliability Very important
Infrastructure reduction Important
Light synchrony Important
Network size Moderately important
Reduced maintenance less important
Network throughput Less important23
The most important feature considering the user experience is the application
latency and reliability. This has the potential to completely ruin the user experience,
as if the lighting fails to operate expectedly it might require relocating the guest to
a completely new room. This would be the case for example if the system somehow
fails, and the guest is unable to switch off the lights when trying to sleep, or if the
lights in the bathroom will not turn on.
To increase reliability and decrease latency, in-network processing of application
logic is applied. This makes the luminaire controllers independent of the central
controller making them more robust to network and control gear failures.
As the next most important feature, the reduction of physical infrastructure
was selected. This is achieved by minimizing the amount of components to be
installed and relying on wireless solutions. By selecting wireless mesh network as the
communication medium the need for data wiring and network repeaters is removed.
Self powered light can be chosen to minimize the wiring needed. This also leads to
reduced maintenance as no battery changes are required.
Network throughput was selected as the least important feature. As light control
only requires fairly small packages of data to be transmitted, the throughput capabil-
ities pose no serious bottleneck for the system. In case of firmware or configuration
updates, larger portions of data might need to be transmitted over the network, but
considering this is outside of the scope of this thesis.
These design decisions lead to a very lean control system, as unnecessary compo-
nents such as network infrastructure and wiring are reduced to minimum. However,
this sets some technological challenges which will be discussed in the next chapter.
5 In network processing, from switch click to turn-
ing on lights
In traditional light control methods, latency has never been an issue, as the switch
directly controls the electricity to turn on the light. Even in lighting automation
systems like DALI the lights directly react to the signals coming from the switches in
the same data bus. However, in large-scale automation networks and IoT installations
the latencies may become longer. Especially in mesh networks, the multiphop nature
of communication adds to the latency in each retransmission.
In very large mesh based installations, round trip to central processing and back
may require multiple hops depending on the network size and the distance from the
gateway. As each hop increases the latency the most remote parts of the network
could experience intolerable latencies. This can be solved by processing the switch
events locally in the network without involvement from the central coordinator and
directly routing messages from the source to destination nodes. To implement this
the luminaries need to contain the ability to process locally broadcasted events from
the network and act accordingly.
As the system described in this thesis is designed to utilize no-energy switches,
any kind of pre-processing on the switch itself is not possible. The switch will simply
emit events that contain the information like switch ID, if the action was a press24
or a release, and which switch key or keys were pressed. For security and duplicate
detection purposes the switch does contain an event counter and authentication
signature. The parsing of suitable actions needs to be done in the actual actuators.
Switch ID Command Counter Verification hash
Table 1: Example switch transmission contents[45]
In the context of this thesis the counter and signature are irrelevant, as they
only contribute in detecting duplicates and preventing replay attack which is out
of the scope of this thesis. As the switch may contain multiple keys, the key flags
are used to identify which key or keys are currently being activated. To simplify
handling on the subject the switch can be assumed to be only one key with up and
down directions, and release to not have any effect on the lights. This allows to
replace the command with just up/down information and reduce the switch message
to minimum.
Switch ID Up/Down
Table 2: reduced switch transmission
The device to receive the transmission from the no-energy switch are the listening
nodes. As one switch message can potentially control tens or hundreds of luminaires,
each with potentially different light levels, the listening nodes can not resolve the
light level outcomes of the switch event. Instead, this node will simply filter out
plausible duplicate transmissions, and pass the switch event onwards to the network.
Each luminaire controller that receives the switch message will individually decide
how to react to it. As the switch message contains no instructions regarding the
expected outcome, the luminaire controller needs to determine the desired lighting
levels autonomically. This is achieved through switch configurations, which are stored
in the luminaire drivers and contain the information on how to react to certain switch
events.
5.1 Determining light levels with switch configurations
When a switch message is received at the luminaire controller it needs to determine
if and how it should react to the event. This information is stored in the luminaire
controllers memory in a form of switch configurations. Switch configuration contains
the information required to identify a switch by its ID, and how to react to various
events from the switch. If the incoming switch ID does not match with the ID in the
switch configuration, or the configuration is missing the lighting level for the given
switch event, the message is ignored and light levels are not altered.25
Figure 5: Lights react to switch event based on their configuration. White light turns
on, grey light does not react, and black light turns off.
5.2 Light control synchrony
To provide smooth user experience on the illumination control, the luminaires are
expected to operate in synchrony. This means that lights will turn on at the same
moment with each other. In traditional light control systems like DALI this has not
been an issue, as the command to turn on lights arrives simultaneously to all of the
luminaires. However, in control systems based on wireless mesh communication, the
message propagation is slightly delayed by each hop the message proceeds in the
network. This small delay causes the luminaires which receive the switch event first
to turn on earlier than the luminaires that receive it after multiple hops.
Figure 6: Switch message delay in the network
To counteract this delay caused by each hop the luminaires which receive the
message first need to wait until all of the other luminaires have received the message.26
To achieve this the luminaires needs to determine how long it needs to wait, until the
last luminaire to receive the message is ready to start the light level adjustment. The
time each luminaire needs to wait can be calculated using the remaining message
hop count and the time it takes to perform a single hop.
When a no-energy switch message is received by a listener node, it will broadcast
the message to the network with a certain hop count limit. From this hop count, it
can calculate an estimate the message will take to reach last node:
total_propagation_time = total_hop_count ∗ hop_delay (1)
This same formula applies to all of the nodes alongside the message propagation,
by only applying the remaining hops:
total_propagation_time = remaining_hop_count ∗ hop_delay (2)
From this, each node the message propagates through will be able to calculate
the needed delay to be in synchrony with the last node to receive the message.
Figure 7: Times nodes wait before turning on
This is a very simple method to achieve synchrony which assumes a constant
transmission time. Real world hardware would need to be analysed in order to
evaluate if this is really usable.
In order to be able to use this method at all, the time mean to perform a single hop
must be somewhat constant. This is of course dependent on the networking platform
being used, and the actual implementation of routing protocol. In [50] analysing
thread network the latencies per hop were measured to be somehow constant. In [51],
[12], and [44] the latencies were shown to be dependent on the transmitted packet
size. Analysing Bluetooth mesh [43] the payload size was shown to affect latency.
Also [52] did report variation in single hop latency.
Based on these experiments with real life latencies of such networking systems it
can be concluded that special care would need to be taken when selecting a mesh
networking platform for lighting control. Also further research should be conducted
in determining with empirical studies, what is the actual required synchrony level to
satisfy the user.27
5.3 Tradeoff between synchrony and latency
Implementing synchrony in the way described above includes inducing an artificial
delay to reacting to switch events. With the requirement for minimizing latency this
limits the hop count within which the synchrony can be reached. The maximum hop
count can be calculated as:
max_hop_count = max_latency/hop_delay (3)
In the literature, there is no clear definition for acceptable latency specifically
for lighting control. Some papers do speculate acceptable delay from switch press
to turning on the lights to be a few hundred milliseconds [53, 42, 54]. However no
original research is quoted.
If it is assumed for example that the acceptable latency of 200ms is the maximum
tolerated latency, and the single hop in the network requires 40ms of time, the
synchrony can be achieved in only 5 hop radius from the source.
6 Simulating mesh network routing
The next chapter of this thesis presents a method for message routing in large-scale
wireless mesh networks. In order to verify the results, a simple simulation tool
was developed using the Processing programming language. The tool consists of
simple user interface and logic to simulate mesh network operation, such as neighbour
discovery and routing based on the developed algorithm.
To simplify the visualisation of results, the tool was constrained to work with
mesh networks in two dimensional space. As the goal is not to research neighbour
discovery, the tool assumes an open space, where signal strength and distance between
nodes is directly correlated.
As the mesh network model, a simplest kind of neighbour forming has been
selected. Two nodes are considered a neighbour if they are in broadcast range from
each other. This means, whenever a node broadcasts a message, all of its neighbours
will receive that message and are capable of rebroadcasting it.
The simulation tool allows placement of nodes on a two dimensional test space.
When a new node is placed the distances from other nodes are calculated and nodes in
the ranges of each others form a connection. This is visualized with a line connecting
the nodes. Nodes can be placed manually one by one, or a randomized set of nodes
can be created.
In order to simulate message propagation, a single node is selected as the source
of broadcast. When selected, the source node will "broadcast" a message to it’s
neighbour nodes by looking trough its neighbour node list and calling their receiving
function. When a node receives a message, it will determine based on the routing
protocol being simulated if it should rebroadcast the message or not. The message can
contain information such as total permitted hop limit, current hop count, and node
group, like in the solution proposed in this thesis. By altering the routing algorithm
in the simulator different routing methods can be simulated, even concurrently.You can also read
