Networked Embedded Systems - Library Occupancy

Introduction

In the library at the Eindhoven University of Technology, it is regularly hard to find available workspaces. To assist students in locating available seats, we propose a wireless sensor network (WSN) with a node in every chair. This way, occupancy data of all seats can be collected and presented to students in order to assist them in finding an available workplace. This WSN has several requirements dictated by its applica-tion. We are looking for a network with low power usage by the nodes in the chairs, acceptable latency and little to no interference for other networks, like WiFi. Furthermore, the network should be able to deal with human behaviour, like short breaks, relocation of chairs and differing busyness (i.e. rush hour). We consider a public seating space of approximately 1000 seats and the network should be able to operate in an environment of any density. The goal is to design a WSN that is able to monitor seat oc- cupancy in a public space. This system should be constructed in such a way, that it can be reused in similar public seating environments with different sizes and densities.

Application Description

In the described system several challenges arise. A few of these challenges are related to human behaviour. Others are related to the environment. A major challenge is that user might relocate chairs. Unless handled properly, this will lead to a skew in the location of available seats. Therefore the WSN requires the ability to locate approximately every sensor. This information can be used to monitor and correct for moving chairs. Every public space has busier and less crowded times. It is rush hour when many people arrive or leave simultaneously. This might happen for example during a break or at the end of the day when the library closes. The network needs to be able to maintain acceptable latency levels even when a lot of communication is required. Furthermore, the system should allow students to take short breaks. The system should not immediately show to others that this workspace is available. However, eventually the system should allow others to use this space. This policymight be enforced by a centralized system or by all nodes separately.

Given the use case, it is not possible to recharge the sensors regularly. Nor is it possible to connect the sensors through cables. Hence, the network has to be constructed with low power sensors. This allows the WSN to operate without con-stant maintenance. This should be combined with a feature through which sensors can indicate low battery power. The system needs to operate inside a work environment. This means that there are other forms of wireless communication already present. Since our WSN will communicate over a2.4 GHz band, there should be minimal interference for WiFi and Bluetooth communication.Latency is not a main concern of this network. The WSN has to minimize the cases where someone picks a chair that has already been picked by another student in the meantime. This allows for several seconds of latency. Rather, as said before, it is more important to maintain this latency level when the WSN is under load. Finally, we are looking to design a networked embedded system that can be reused in similar public environments. This requires the resulting system to be versatile such that it can easily be adapted to similar situations.

Hardware Setup

This work is primarily focused on software implementation (simulation). Therefore, only the basic components of hard- ware setup have been taken into consideration. The sensor nodes (chairs) transmit occupancy data to the nearest clus- ter head (tables) through wireless communication. Further, various cluster heads form a mesh network along with the sink.Each sensor node consists of a low power micro-controller. There is a pressure sensor attached to the seat that sends data about occupancy to the micro-controller. A suitable 2.4 GHz RF transceiver module can be used to transfer data to the closest cluster head. These nodes have to be more energy efficient as compared to the cluster heads which can use powerful batteries.

Another problem are the many sources of distortion. Tables, chairs and for example laptops all contribute to distortion. This distortion may be for example caused by reflection, diffraction or scattering. In an attempt to minimize these problems we can use Direct Sequence Spread Spectrum modulated with offset quadrature phase-shift keying. Be-cause of the multiplication of the signal with a much shorter chipping sequence, redundancy is added to the sequence. Because of this redundancy the signal is more resilient to interference. Although the bandwidth usage is lower, the performance is often better than WiFi or Bluetooth transmitting the signal at the same power. For our application lower bandwidth usage is not a major concern since the nodes only need to transmit when a change in their state occurs.

There are two types of devices, full-function devices (FFD) and reduced-function devices (RFD) In our network we decided to have cluster heads and sensor nodes. The sensor nodes only need to communicate to the closest cluster head. Therefore the cluster heads are FFDs and nodes are RFDs. Since the sensor nodes only need to communicate event-based data, it would be the best choice to use unslotted CSMA/CA. As latency should generally be lower than 20s in our system, it is not necessary to include a timestamp in the events, therefore it is not necessary to synchronize nodes in the network. Beacons are thus not required.

Network Layer

In our situation the sensor nodes can communicate to their closest cluster head. For every area or table there is a cluster head available. By simply connecting to the cluster head with the strongest signal the nodes get some localization within the library as cluster heads are static. The cluster heads however need to form a network to transfer data to the sink. These cluster heads do not necessarily be energy efficient. In the next section different routing protocols are discussed.

Network Architecture Options

The possibilities for network architecture are somewhat limited by the setup of the problem. Because of energy constraints, sensor nodes cannot participate in routing (i.e. be an RFD). Due to the large surface area of a library we need more powerful, intermediate nodes that form a path to sink. The cluster heads fulfil this task. Because the space of the library might still be too large for every cluster head to communicate to the sink directly, we need a mesh network between the cluster heads and the sink. Alternatively, we can use the property that cluster heads have fixed positions. This would allow for a proactive routing pro- tocol, since the network is unlikely to change. Furthermore, because these cluster heads are not resource constrained, it is possible to store a routing table in memory. In this situation we would propose DSDV1. This technique is able to avoid low quality links and causes little interference because there are few changes in the network topology.For this particular application, we decided to use DSDV where distance vectors are based on link quality.

Implementation Prerequisitesa

Software Simulation platformThe wireless sensor network is realized by simulation using the Cooja simulator. Since the system of interest is a large- scale network and implementing the system in hardware is too expensive, it is efficient to first realize the system using software simulation and than observe the performance parameters such as latency, interference, collisions, etc. This will help drawing conclusions about the wireless sensor network and then can be extended to small-scale deployment or even full-scale deployment, which are out of scope of this project. For the software simulation purposes Cooja Simulator has been chosen on which the nodes will be running Contiki OS.B.

Contiki OSContiki operating system is one of the prerequisites for our system of interest. It is both open source and has a powerful powerful tool box for building wireless networked systems of high complexity. There are three classes of Contiki nodes: emulated nodes, in which the entire hardware of each node is emulated. Second one are the Cooja nodes, where the Contiki code for the node is compiled for and executed on the simulation host. The third one is the Java nodes, where the behavior of the node must be reimplemented as a Java class. Our system of interest makes use of the Cooja nodes. One Cooja simulation may also contain a mix of nodes from any of the three classes.

The applications in Contiki are written in Standard C and with the use of Cooja simulator Contiki networks can be emulated before actually implementing inthe hardware. Hence, for all the above mentioned advantages, we decided to use the Contiki operating system. C. Cooja SimulatorCooja Simulator is a network simulator specifically designed for Wireless Sensor Networks. It is an extensible Java-based network simulator for Contiki based applications. Moreover, it can simulate exact hardware behaviour. In this simulator we can add a number of nodes according to the system requirements and also include the feature of mobility of nodes. Hence, it is an appropriate choice of simulator for our system of interest.

Software Implementation Plan

Through the simulation, it is expected to measure the re- liability of the WSN and power consumption based on average result of simulation. Different parameters which can influence the result of the simulation are:

• The number of nodes
• The location of cluster heads
• Mobility
• Cluster size
• Randomness of user behaviour

Therefore, Various simulations need to be done based on multiple mobility files and different frequency of state change of the sensor to investigate the influence of the configuration parameters, and then calculate the average power consumption. In the simulation, sky platform is chosen because it is wildly used in the WSN research community and well documented in the Contiki tutorial.

Software im- plementation plan is as follows:

• Generate the initial location of nodes and cluster heads based on the seating map of the library
• Generate the position file to model the mobility of chairs
• Model the students behaviour in sequence and classify them into different scenarios
• Select the appropriate sensor in the Contiki
• Program Contiki application C file
• Simulate radio interference such as WiFi and Bluetooth to check the reliability
• Calculate the average power consumption.

References:

1. R. Priyadarshini, S. Reddy, and R. Mehra, “Occupancy-based energy management and campus monitoring using wireless sensor network,” vol. 15, 03 2015.
2. C. Torres and P. Glsektter, “Reliable and energy optimized WSN design for a train application,” Journal of Systems Architecture, vol. 57, pp. 896–904, Nov 2011.
3. S. Vidyasagaran, S. Devi, A. Varma, A. Rajesh, and H. Charan, “A low cost iot based crowd management system for public transport,” in Proceedings of the International Conference on Inventive Computing and Informatics, Nov. 2017.
4. S. Poovizhi, M. Premalatha, and C. Nivetha, “Automatic water level monitoring and seat availability details in train using wireless sensor network,” in International Conference on Computation of Power, Energy Information and Commuincation, Mar. 2017.
5. A. Atayero, O. Ilori, and M. Adedokun, “Development of seatsense: A wireless sensor network based seat detection system,” in Proceedings of the World Congress on Engineering and Computer Science, Oct. 2015.