In order to evaluate our approaches, we implemented a scenario with the use of a wireless sensor network in the context of smart buildings. Our argument is to find out which of the two approaches is more appropriate to use for implementing this scenario. Is IPv6-6LoWPAN along with CoAP more efficient than simpler solutions such as RIME ? A comparison of these two approaches after we implemented them in the simulator and in our testbed is presented in the next section. Problems such as feasibility of technology, efficiency in the embedded systems, relation with the Internet of Things, schemes for interoperability and others have been tackled. We have chosen the scenario of profiling because it comprises of general communication patterns and components required by most of the smart building scenarios. The technology, the protocols and the systems we are evaluating behind this scenario could be applied to several other scenarios in the smart buildings systems.
2.5.1 Description of Case Study
We implemented the profiling scenario with the above described approaches (with IPv6 and without IP) to evaluate the feasibility, energy consumption, memory footprint and latency of each one of them. The scenario consists of a profiling system in a WSN which is able to identify people, take decisions according to their profile and make the resources of the WSN available to the Web. Upon the arrival of a person in the proximity of an agent-node, the agent-node identifies the person (user) and it is transmitting a message to the profiling server through the gateway. The purpose of the agent-node is solely the identification of the users of the system. The message that is sent contains the profile ID of the person and the profile service decides whether to allow the access of the person in the room or not. In addition, it provides the agents and the node-actuators customized information based on the user’s profile.
According to the profile and the needs of each person, several actions take place such
2.5. Implementation of Approaches
Agent-node
Gateway
USB 6LoWPAN / RIME
6LoWPAN / RIME
Outdoors Sensor Indoors Sensor
Indoors Actuator
Server
Figure 2.2: Interconnections and communication pattern in the profiling scenario.
as switching on/off a light and turning on/off a fan. The interconnections and the communication pattern of the nodes of the scenario are shown in Figure 2.2
In a centralized version of the profiling scenario the agent-node is acting as a forwarder without taking any decisions or actions. It is the responsibility of the profiling server connected to the gateway to run the necessary services and drive the node-actuators.
A larger scale figure of the proposed scenario is shown in the Figure 2.3 where multiple nodes are placed in each of the four rooms in the premises of our a building comprising a wireless sensor network connected to the Web. The actuator nodes are placed in the corner of each room, driving the lights and the blinds of the windows. Next to each door of the building an agent-node is placed which is connected to the node-actuators and the gateway as well. The main gateway is handling all the received information by the agent-nodes and the Web while at the same time is able to drive the node-actuators.
Node-actuator Agent
Gateway
WEB
Control line 6LoWPAN / RIME
IPv6 / IPv4
Figure 2.3: WSN deployment of the profiling scenario in a smart building.
2.5.2 Experimental Setup
2.5.2.1 Hardware
For our implementation we used motes [25]. The TelosB motes are an open source platform designed to enable cutting-edge experimentation. The TPR2400[12] mote from Crossbow industries which our lab has and which we used in this work, bundles
2.5. Implementation of Approaches
all the essentials for our lab studies into a single platform including: USB programming capability, an IEEE 802.15.4 radio with integrated antenna, a low power MCU with extended memory and a build on sensor suite. The motes offer many features including: IEEE 802.15.4 / ZigBee compliant RF transceiver, 2.4 to 2.4835 GHz a globally compatible ISM band, 250kbps data rate, integrated onboard antenna, 8 MHz TI MSP430 microcontroller with 10kB RAM, Low current consumption, 1MB external flash for data logging, programming and data collection via USB, sensor suit including integrated light temperature and humidity sensor. It is powered by two AA batteries. If the mote is plugged into the USB port for programming or communication, power is provided from the host computer. If the mote is always attached to the USB port no battery pack is needed. The TPR2400 provides its users with the capability to interface with additional devices. The two expansion connectors and onboard jumpers may be configured to control analog sensors, digital peripherals and LCD displays. Figure 2.4 shows the TelosB platform. A TelosB apart from being either a sensor or an actuator, it offers the capability (with the appropriate software programming) to act as a gateway, i.e.acting as a border router between the web and the WSN or between two WSN (see Figure 2.1. In our work here, one TelosB was connected to a computer running an Ubuntu distribution of Linux. In the node-actuator, we used the General I/O pins of the TelosB motes to drive a table lamp and a fan. (More details on that are given in 3.4.
2.5.2.2 Software
To program our sensors we used the version 2.6 of Contiki OS. For the simulations, we used the Cooja simulator developed by the Contiki community. Cooja allows large and small networks of Contiki nodes to be simulated. Nodes can be simulated at the hardware level, which is slower but allows precise inspection of the system behaviour, or at a less detailed level, which is faster and allows simulation of larger networks. We used the Contiki’s CoAP API to implement a CoAP client and server in the agent-node and node-actuators. We used JSON as the message format with the JSON support of Contiki in both approaches.
(a) TelosB front size layout
(b) TelosB back size layout
Figure 2.4: TelosB Mote components