• No results found

Wireless Sensor Networks The design & implementation of a wireless sensor network, capable of ambient and body area sensing.

N/A
N/A
Protected

Academic year: 2021

Share "Wireless Sensor Networks The design & implementation of a wireless sensor network, capable of ambient and body area sensing."

Copied!
36
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

University of Amsterdam & Amsterdam University Of Applied Sciences

Wireless Sensor

Networks

The design & implementation of a wireless sensor network, capable of

ambient and body area sensing.

Sven-Erik Haitjema Studentnumber: 10002447

Organization: DigitalLifeCenter

Thesis supervisors: Ben Krose & Vadim Zaytsev

Master Software Engineering

(2)

Table of Contents

Glossary ... 3

Summary ... 4

1) Introduction ... 5

2) Related Work ... 7

3) Architecture ... 9

3.1 Stakeholders ... 9

3.2 Requirements ... 9

3.3 Architecture key decisions ... 10

3.4 Proposed Architecture ... 11

System Architecture view ... 11

Software Architecture ... 13

4) Implementation ... 19

Hardware & Protocols ... 19

Portable station ... 19

Ambient sensor hub ... 19

Server ... 20

Body area sensors ... 20

Ambient sensors ... 20

Software ... 20

Portable station ... 20

Ambient sensor hub ... 22

Server ... 23

5) Evaluation ... 24

Power consumption ... 24

Bandwidth ... 25

Network extension ... 25

User testing ... 26

Test 1 ... 26

Test 2 ... 27

6) Discussion ... 28

7) Conclusion ... 29

8) Future work ... 30

Smartphones as hub ... 31

9 )Bibliography ... 32

(3)

Generale introductie ... 34

Zorg op afstand ... 34

Informatie behoefte ... 34

Sensoren ... 34

Privacy ... 34

Doelgroep ... 35

(4)

Glossary

User A person, who is carrying the portable station. Client A person that is able to view the data generated by the sensor system. Portable Station The central hub used in the architecture to collect and transmit data Ambient sensor hub The secondary hub of the architecture that collects ambient sensor data ADL Activities of Daily Living IMU Inertial Measurement Unit Ambient The surrounding Sensor A device that can measure a physical property WAN Wide area network Zigbee Mesh network sensor protocol ZWave Mesh network sensor protocol with zero configuration and guaranteed interoperability between suppliers

(5)

Summary

This study proposes a location independent sensor network architecture. The system is composed of three systems, the portable station, the ambient sensor hub and a server. Attached to the portable station and ambient sensor hub are a variety of body and ambient sensors. The portable station is responsible for collection, storage of the sensor data and its transmission to the server. The ambient sensor hub is responsible for collecting and storing, of ambient sensor data, and its transmission to the portable station. The server serves to store all the data, and serve it real-time to a client interface, for example to a caregiver. By employing a battery powered portable station, the network can be carried around and be used for long-term monitoring. The study identifies common problems with (wireless) sensor networks. Tries to mitigate these problems with the design of a fitting architecture. And offers an insight in the usability and practical implementation risk of such an architecture.

(6)

1) Introduction

Technology has the potential to change the way healthcare works. With the introduction of X-ray scanners internal problems of the body could be made visible. After that, fMRI scanners gave insight into brain processes that form our thoughts and feelings. Recent advancements in cheap sensor hardware data interpretation algorithms, mobile computing and communication created the possibility to monitor health in daily life settings. The Digital Life Centre of the Amsterdam University of Applied Sciences has embraced the idea of sensor monitoring for various healthcare applications. An area of focus is elderly care. Since 2003 there is a strong decrease in the amount of subscriptions to care homes. Elderly living independently for a longer period of time in their life provides multiple challenges for healthcare professionals and the healthcare system as a whole. When they live in a care home, there are frequent health checks and close communication between elderly, and their caretaker. Living at home, independently and longer does not remove the need for care. The digital Life Centre has been developing systems that can measure the Activities of Daily Living(ADL) with non-invasive sensors. The used sensors can be mounted to the house and need no further attention of the user. Systems that are placed in the environment are called ambient systems. The developed systems are called ambient sensor systems. The Digital Life Centre has conducted several studies with ambient sensor systems and its data (Saskia Robben, 2012) (Krose, 2013) (Nait Aicha. Ahmed, 2013) Earlier experiments of the Digital Life Centre used the Salveo sensor system to monitor the ADL of elderly at home. The houses were set up with motion sensors to detect room occupation and movement. They also installed cabinet sensors to monitor kitchen cabinet and fridge use and a flush sensor to monitor toilet behavior. It was found that an individualized assessment over the collected data positively correlated with the functional health status of the elderly (Krose, 2013). The generated information could be used by healthcare professionals or for direct feedback. The used Salveo system is build upon a star topology, meaning it contains a central hub that collects the sensor data and relays it to a server. The sensors operated with a one-way signal. This means that there was no packet arrival verification or hopping. Problems with this setup included loss of data and difficult network deployment due to the use of repeaters. Its successor uses ZWave sensors with a base station. ZWave uses a two-way communication protocol, therefore, all messages send are acknowledged and sensors connected to a mains socket are automatically set up as repeaters. There are multiple challenges and limitations when deploying and working with ambient sensor systems. First there are connection problems that can occur between sensor and hub and between hub and server. Second is the need for a reliable WAN interface that can transport the data to a server. The limitations of ambient sensor systems lay in their method of operation. Measuring behavior or ADL is limited to an indoor setting because the sensors are mounted to their environment and rely on a stationary hub. Furthermore there is the possibility of ambiguity within the data when multiple living entities (people, pets) occupy the same measured physical space. The data delivered by ambient sensor systems provides a very abstracted view of the activities within a physical space. The Digital Life Centre would like to explore the possibility of including body sensor data to be able to measure activities in greater detail, but also introduce the possibility to measure in an outdoor setting.

(7)

There are architectures that provide a foundation for ambient sensor monitoring, usually consisting of a set of sensors that connect to a central data hub or data sink (Akyildiz, Su, Sankarasubramaniam, & Cayirci, 2002). While these types of architectures carry positive properties like reliability and availability, their sensing capabilities are limited to the environment where they are installed. Furthermore, as was also experienced at The Digital Life Centre, the process of getting a connection from a home to central server proves to be a challenge. Although a problem of current times, many elderly do not have a DSL internet connection in their home. Before any sensing can take place, efforts have to be put into getting an internet connection in the home. To overcome the challenges with ambient sensor monitoring on the area of connectivity, portability ,and to extend the range of possible metrics collected, body area sensor networks have been proposed. These networks rely on sensors that are placed on, or in near proximity of the body and can therefore be portable beyond the walls of a home. The data collection is usually done by a portable personal hub that is also responsible for relaying the data to a central server (Vasilakos·, 2011). Instead of indirect body metrics (movement /actions) collected through ambient sensors, body area sensors are able to measure direct metrics like heart rate, blood pressure, and limb movement. This level of detail can enhance clinical decision-making and improve feedback (Azeem Majeed, 2011). Because of the portable nature, transporting the data and managing the sensors is not as trivial as with ambient sensor networks. The sensors have limited battery capacity and are not always worn. As the data is more personal than with ambient sensors, security is also an important aspect of body area networks. An architecture that provides a combination of ambient and body area sensing could leverage the strong properties of ambient and body area sensor networks. It would allow healthcare professionals or researchers to collect data from activity level down to individual body metrics level. Managing a sensor network that is both portable and stationary poses presents challenges related to Network organization, energy consumption, signal routing, and signal bandwidth. The transition from using specialized medical devices, towards consumer electronics could help to speed up the process of healthcare transformation by reducing system cost. A physician could hand out a sensor to a patient, collect data for a period of time and then offer better feedback on the basis of continuous objective data, instead of incidental snapshots of a patient condition. Given the literature and the requirements by the stakeholders, what would be a fitting architecture for ambient and wearable sensor monitoring? On the basis of this question, we can formulate the following research questions: • What hardware architecture would facilitate the stakeholders’ requirements? • What software architecture would facilitate the stakeholders’ requirements? • What properties regarding network organization, energy consumption, signal routing and, signal bandwidth can be expected from this architecture? • What are the network organizational features of the implemented architecture? • What are the measured energy consumption features of the implemented architecture? • What are the measured signal coverage, routing and bandwidth properties of the implemented architecture? This study will try to answer these questions with the design of an architecture that integrates both ambient sensor networks, and body area sensor networks. First, the main system stakeholders will be identified. Then a requirements engineering phase follows. Here functional and non-functional

(8)

designed which tries to satisfy the majority of requirements and minimizes the conflicts between non-functional requirements. The parts of the architecture that contain implementation risk, or have not been proven by related work, will be implemented and tested against the requirements.

2) Related Work

Research has been performed on the subject of sensor networks and sensor networks applications in healthcare. One of the focus area’s, also of the Digital Life Centre is the collection of data about Activities of Daily Living (ADL). ADL are defined in this document as the activities a person undertakes that relate to daily self-care. Examples are bathing, eating and walking. Recently research towards body area sensor networks has gained traction. This section is divided into the related work regarding ambient sensor network architectures, body area sensor network architectures, and studies with mobile phones as data hubs. Ambient sensor networks predominantly consist of a set of wireless sensors that send their data to a base station using a variety of radio protocols. The base station is connected to a (local) server that stores and/or analyzes the data. Because of the need for remote management and access to the data, a stable connection to the internet is often required. In a home setting, it is this part of the architecture that carries a high risk. The connection to the server is a single point of failure if the hub is not equipped with a secondary WAN interface. If the used sensors and/or hub do not have a buffer with an adequate size to provide enough time to restore a failed connection, data will be lost. Managing the sensors also proves to be a tedious task, especially with larger deployments. Problems can occur per individual sensor and also during the communication between them. Varying energy consumption between different types of sensors and also between the same sensors in different physical locations requires careful battery level reporting and management. Moving furniture or opening/closing doors could also impede the signal of a sensor, preventing successful data transfer. The Hallym University of South Korea used a set of wireless motion sensors tot assess the ADL in nine homes (Kim & Jung, 2009). The sensors were equipped with a Zigbee radio and TinyOS software. They tried to reduce the complexity of the sensor management by introducing several agents on the server that acted on the collected sensor data. The sensors emitted heartbeat events and their battery levels. The agents on the server checked multiple times a day for irregular battery consumption, battery levels under threshold and missed heartbeat events, and summarized these in a status email to the administrator. To overcome the difficulty of ambient sensor network deployment, the Singapore Polytechnic proposed an architecture that uses a Zigbee sensors and a local server to collect the sensor data. The server can send SMS alert messages via GSM to caretakers or family. This architecture facilitates easier deployment of a system, but the use of SMS complicates remote management. Body area sensor networks have architectures that are designed with requirements that differ from ambient sensor network requirements. The sensors are portable and made to be worn on or carried with a body. They have to be designed unobtrusively in order to be accepted by the users (Vasilakos·, 2011). This requirement poses constraints on the design of the architecture. The sensors often have limited volume and thus limited available energy. In related work, proposed architectures introduced a portable hub with more energy capacity and computational power than the sensors. This hub stores the data and is sometimes also used to perform activity recognition and alert generation. Connectivity methods of the hub to a server differ per application. Some require real-time connectivity while others allow caching of the data on the hub.

(9)

The technical university of Braunschweig designed a body area network architecture that focuses on efficient management of data synchronization to reduce telecom costs (Sana Saadaoui, Jan. 2007). The architecture consists of a portable hub with sensors connected to it in a star network topology, and a base station that communicates with the portable hub through Wi-Fi. In outdoor environments, or the lack of a signal path to the base station, the central hub only collected data and provided alerts, resynchronization happened when the connection is restored. The sensors were connected by Zigbee radios. Researchers from the University of Alabama created the Actis activity sensor with support network, this was used to facilitate computer assisted physical rehabilitation. The Actis sensor accurately measured limb movement. The network consisted of body worn sensors, connected with a PDA in a star topology. The PDA was connected to the internet via GPRS or Bluetooth. There were multiple problem areas identified that all had to be addressed in order for body area networks to mature and be usable in a healthcare environment. Some of the identified problems were the power source and the size and weight of the sensors (Emil Jovanov, 2005). This finding is supported by a survey on body area networks (Vasilakos·, 2011). The University of Virginia describes a multi-tier sensor network that is capable of handling multiple clients (Virone, 2006). The ambient sensors are all two-way connected with a central hub in the network. The body area sensors can communicate hub with the ambient sensors through the portable hub, and all ambient sensors can relay that data to the central hub. The architecture focuses on being a facilitator for assisted-living communities, where multiple people carrying this network will be in proximity of each other. A small implementation with direct communication between portable hub and base station of the network showed that power consumption was an issue. The connectivity possibilities of smartphones make them very appropriate as a portable hub for body area networks. The dominant wireless technology for body area sensors (sometimes also called wearable’s) is Bluetooth low energy. This is also implemented in modern smartphones. The processing power of a smartphone allows it to analyze the data it receives. This opens up the possibility to create an intelligent portable hub, capable of generating warning messages or user feedback on its own. The Holst center in Eindhoven created a body area network with an Android smartphone as the data hub. This network can stream real time hart-rate data to a server, using the connectivity capabilities of a smartphone. The touch screen interface of the smartphone provided a convenient way to configure the network and configure alert thresholds (Marco Altini, 2010). To connect sensors to the smartphone, a circuit was designed that could hook into the sd-card slot of a phone, this provided the phone with an extra wireless transceiver. Phone operating system manufacturers also embrace the potential of using wearable sensors to track the health of a user. Both Apple, Google, and Microsoft have started to develop software platforms to facilitate the acquisition of body metrics through wearable sensors and internal phone sensors. Their phones utilize Bluetooth low energy to connect to a range of different body sensors, and then store it locally on the phone. The applications perform a basic sensor fusion in order to extract activity data. The focus on these systems is to inform the user about achievement of set nutritional, physical, and mental goals. This feedback happens through the phone´s screen. What these systems currently lack, is the ability to share this data in real time with a care taker and to generate alerts to external parties. Also the algorithms that extract the ADL data are proprietary.

(10)

3) Architecture

The architecture of the system was designed following lessons learned by related work and from requirements engineering performed with the stakeholders. The requirements engineering consisted of desk research and interviews with the system stakeholder. The desk research was done to gain a greater understanding of the stakeholders, their fields, and served as a basis for the interview questions. The interviews were constructed to elicit the systems functional and non-functional requirements, the real and perceived needs, and to identify possible biases. The fundamental parts of the architecture were then designed by testing known architectural design patterns (Len Bass, 2012) against the stakeholder requirements. In cases of contradiction a tradeoff between individuals stakeholder needs was made.

3.1 Stakeholders

The involved stakeholders of the system were identified in preliminary talks with the Digital Life Centre, also influenced by knowledge gained from early literature study. The Digital Life Centre, Initiator of the project. The Digital Life Centre is a research group that is a part of Create-IT and is affiliated to the Amsterdam University of Applied Sciences. Their research is partially focused on ambient living and Healthcare. Currently they operate multiple wireless sensor systems in different elderly homes. They have experience with data fusion and analysis. Their stake is to create and improve e-health solutions that can be used to support healthcare professionals, provide data for data fusion/ analysis researchers, and valorize knowledge developed within the research center or the Amsterdam University of Applied Sciences. Healthcare Professionals, represented by general practitioners and rehabilitation specialists Since the general practitioners and rehabilitation specialists are the people involved with the patient, and since this system will be designed to improve their insight in the health of this group, this group represents the main stake in the architectural design. They are professionals and know what kind of information drives their current work, and what missing information inhibits it. Their stake in this project is to form the architecture in such a way that it will support current and future information needs. The Elderly, represented by a group of people that are currently being monitored by the ambient sensor systems of Create-IT. The elderly people that are currently monitored by the Create-IT sensor systems are willing to participate in the testing of systems to monitor or improve their health. Since this group will receive the sensors in their home or on their body, it is of great importance that the architecture implementation is accepted by this group. Their abilities and needs will drive the physical and interface part of the architecture.

3.2 Requirements

From the requirements engineering phase and lessons learned by related work, the following key system requirements were formulated. 1) Ambient and body area monitoring The architecture should facilitate sensors that can be placed in the environment, or be worn on the body. 2) Continuous location independent subject monitoring

(11)

The resulting system should be able to take measurements of its subject regardless of the system’s physical location. This scenario should hold for both indoor and outdoor environments. 3) Location independent deployment The architecture should be designed to facilitate deployment with as little environmental or connectivity dependencies that is currently feasible. 4) Measurement Delivery & Frequency of transmission The architecture should support two types of messages, regular measurements, and critical vital sign measurements. The critical vital signs must be transmitted with as little latency currently feasible. The regular measurements can be synchronized at times where the environmental situation is best suited to transmit the data. 5) Sensor data acquisition interface The architecture should work with off the shelf sensors of different types and connectivity methods. An interface needs to be present that abstracts the data acquisition methods and sensor data type. 6) Energy Management The location independent deployment and measurement collection requirements introduce constraints on the physical properties of the sensor and its energy source. Therefore, it is a necessity to manage the network energy consumption.

3.3 Architecture key decisions

In order to develop an architecture that meets the stakeholder requirements, upfront key decisions had to be made. Data collection through a portable station In order to meet requirements 1 to 3 a location independent a portable station is needed that has its own connectivity, power and processing systems. Ambient sensor hub Ambient sensors have their own (non)internet connected base station called the ambient sensor hub that collects the sensor data and transmits it to a portable station . The introduction of the ambient sensor hub allows collection of data without the proximity of the portable station. The ambient sensor hub could send its data to a server directly through a WAN interface. The radio interface to the portable station could allow the sharing of sensor data with several portable stations in proximity. Two channel data transmission The architecture will support two data transmission systems to get all data to a central server. The first system consists of a database with synchronization capabilities. This will be used for data with a lower duty cycle, or non-safety critical information. The second system consists of a real-time connection from portable hub to server and to clients. This will make sure that the data is available to clients even before storage or analysis has taken place on the server. High bandwidth transmission IMU sensors consume a relatively large amount of bandwidth in comparison to ambient sensors. The architecture should support at least two IMU devices to allow validation of limb movement. Every data channel is a sensor The architecture must be compatible with a diverse set of physical sensors with output data formats

(12)

unknown upfront. To meet key requirement 5, an interface was introduced that abstracts any form of sensor data to individual data streams (e.g. x,y,z and battery for a motion sensor). Every data stream can be processed, stored and transmitted by the system in a generic fashion, thus reducing complexity.

3.4 Proposed Architecture

The proposed architecture was designed following the key decisions and further requirements. The architecture tries to integrate ambient and body area sensors in one location-independent sensor network. In both indoor and outdoor environments data can be transmitted and analyzed in real-time. The software architecture was designed to facilitate connections to sensors with various radio interfaces, protocols and output data types. To describe the architecture this chapter is divided in two sections. The first section describes the hardware, their connections, and function in the system. The second chapter describes the accompanying software architecture.

System Architecture view

Figure one shows the system level view of the architecture. It consists of a portable station with body area and ambient sensors connected to it in a star-topology, an ambient sensor hub with ambient sensors connected in a mesh-topology, and a server system to collect, store and analyze the data. Figure 1 – System level overview of the proposed architecture Body area sensors

(13)

All sensors that are capable of measuring properties of the human body and its context, and to achieve that, are placed on, or in proximity of the body. Body area sensors often have a limited transmission range because of their volume- and by extend energy constraints. For correct data reception, they rely on a receiver to be in physical proximity to gather their data, and transmit it to the server. The coverage area of a typical body area sensor with Bluetooth low energy is approximately 20 meters in an indoor setting. Ambient sensors The definition of ambient sensors in this document is: All sensors that are capable of measuring physical properties of an environment. Since ambient sensors are placed in an environment and not on/in proximity of a body, they have fewer constraints on their design than body area sensors. They can have a larger volume and therefore have more energy storage capabilities. If an ambient sensor is equipped with the proper radio interface a direct connection from portable station to ambient sensor could be made. Portable station A key component of the architecture is the portable station. The station is a connected device that contains various radio interfaces, a computer, energy storage, and optionally sensors. It is responsible for the acquisition, storage, and transmission of the system sensor data. Therefore it must contain at least one transceiver with a nation-wide coverage. If the device contains a (visual) interface for its users, feedback could also be served through it. In an outdoor environment the portable station must be carried in order to collect body area sensor data location independently. Ambient sensor hub

The ambient sensors have their own hub called the ambient sensor hub that is able to collect ambient sensor data. This collection takes place independently of the portable station. The ambient sensor hub acts as a sensor data buffer until the portable station is within radio communication range and able to receive the data. If an active internet connection is present, this hub could also be used to transmit the ambient sensor data to the server directly, thereby offloading the portable station. Server The server is used to collect, and store the data acquired by the portable station. It is equipped with a database and a set of software systems. The software running on the server is responsible for synchronizing the database between the portable station and server, analyzing the data, and presenting it to a client. Communication channels The system is equipped with two data communication channels. The first is a low bandwidth high latency connection between the portable station database and the server database. The synchronization between the two is managed by the databases themselves. The available bandwidth is determined by traffic on the other channel and by the available power in the portable station. This channel will be referred to as the synchronizing data channel. The second channel is a real-time two-way connection between portable station and server. This channel allows clients to view sensor data of a user in real-time. On the server, at the arrival of new

(14)

prior to any storage or analysis. This approach was chosen to offload the server in case of connected clients. If the data was first processes and then stored, a client interface would have to make calls to the data storage to retrieve the data. Introducing server load and latency. This channel will be referred to as the real-time data channel in the rest of the document. As with every architecture, this is a trade-off between conflicting requirements. The strong properties of the defined architecture are its location independence, modularity and low latency data availability. Power management There are three components in the architecture that have a limited energy supply. These components are the portable station, the body area sensors, and the ambient sensors. The server and ambient sensor hub are connected to the mains supply. In the portable station, power can be managed by turning off unused radio interfaces and processors when they are not in use. Utilizing the synchronizing data channel, also saves power over the real-time data channel, since data is transmitted in chunks rather than individual sensor data packets. With ambient and body area sensors, power management can be achieved by selecting sensors that use a power efficient radio protocol. If the sample rate is configurable, it is often beneficial to select a sample-rate that is a tradeoff between usability of the data against the usability, and acceptance of the sensor.

Software Architecture

Figure two illustrates the software components involved in the architecture. It consists of the software residing on the portable station, the ambient sensor hub, and the server with a client GUI. Figure 2 Abstracted software system view The designed system has similarities with the shared-data software design pattern. In this pattern, data producers and data consumers are decoupled, and there is no specific system part owner of the data. This means that development, testing and refactoring of data producing, and consuming modules can be separated from each other. The data that is shared between the system modules

(15)

consists of the sensor data (generated by the sensors) and the sensor configuration data (entered by clients). The pattern can also be used to save power in the portable station in the event of a connected client. Since the server sensor data storage contains the same data as the portable station sensor data storage, analysis can take place on the server. The decision to utilize this pattern came from its ability to keep software changes local. It allows for independent testing and could save power. Portable station The portable station software is designed to be able to include sensors in the system without recompilation or application redistribution. Figure 3 displays the module decomposition view of the portable station software. Figure 3 Portable station module decomposition view The software on the portable station allows sensors to be added to the system in a flexible way. Signals of a sensor are split by the acquisition module into individual data channels. Every data channel is treated as an individual sensor by the system. A physical sensor can therefore have multiple data channels, e.g. a data of a body area motion sensor will consist of an accelerometer and a battery status. The system would treat this physical sensor as four sensors containing an x,y,z, and battery level data stream. The abstraction from sensor specific data as early as possible in the system, allows the rest of the software to be build like generic components that can be chained in a pipe and filter manner. This step will reduce complexity of the system, and will reduce the complexity individual components. This setup is also beneficial for the maintainablility of the system since changes are often localized to a single module. If a new type of sensor is to be added with an unknown aquisistion method. A new acquisition module can be created. This module would setup, and manage the sensor connection, and transform it’s data into separate data channels. The same holds for the filters and detectors. These can be chained together to form complex filters or detectors. The other components can and should be made generic, and should only require one implementation.

(16)

Figure 3 illustrates the flow of data for a single sensor data packet. Figure 3 Sensor data flow inside the portable station The portable station and the server share a real time message bus. This bus can be used to transmit sensor data in realtime, but also dispatch configuration commands. Introducing the messaging bus in the system ensures that the system modules can all be build in a loosly coupled manner. All modules are attached to the bus, and listen for messages adressed to them, or messages that are of their concern (monitoring modules). This approach improves the ability to perfom unit testing and to localize code refactoring. In order to reason about the system properties of the portable station, three quality attribute scenario’s have been selected and put in table 1. Table 1, System Quality Attribute Scenario’s Scenario Source of

stimulus Stimulus Environment Artifact

Response Response Measure Modifiability Client Wants to add a

new sensor to the system with a known protocol The portable station Design time The system should use a ready present acquisition module to connect to the sensor and get its data The sensor is added to the system and becomes visible in the client interface sensor list on runtime. Its data is also accessible. Performance Sensor with real-time option enabled Generates a new data packet The portable station Runtime The system should decompose the packet in the acquisition module then it is directly transmitted over the real-time connection The data packet is available at the server, with a maximum latency, determined by sensor latency + thread scheduling latency +

(17)

connection latency

Usability User Wants to be monitored by the system, regardless of its location and without interaction with the system The portable station Runtime The portable station can be carried by the user. The portable station runs independent for at least 8 hours (regular working day).

Ambient sensor hub

The ambient sensor hub software is designed to have little dependencies on the types of sensors used or specific radio systems. It acts as an ambient sensor signal relay when the portable station is in radio transmission range. If the portable station is not in radio transmission range, the ambient sensor hub acts as a non-volatile data buffer. Configuration of the sensors will be performed by the portable station. The ambient sensor hub will transmit configuration commands to its connected ambient sensors. Figure 4 shows the module decomposition view of the ambient sensor hub software. The connection & sync controller is responsible for the creation and management of the wireless radio connection to the portable station. When a connection is established, the buffer is checked for data packets. If there are packets in the buffer, they will be transmitted to the portable station in a FIFO(First in, First out) manner. The acquisition module in the context of the ambient sensor hub is constructed differently from the portable station version. Instaid of breaking down a sensor packed into individual data streams, this aquistion module transforms a packet so that it can be transmitted over the radio link, and be read by an accompanying acquisition module on the portable station.

(18)

Figure 4 Ambient sensor hub module decomposition view In order to reason about the system properties of the ambient sensor hub, three quality attribute scenario’s have been selected and put in table 2. Table 2, Ambient sensor hub quality attribute scenario’s Scenario Source of stimulus Stimulus Artifact Environment Response Response Measure Perfomance Ambient

sensor Generates a new data

packet sensor hub Ambient Runtime + Portable station connected The packet is send to the portable station The data packet is available at the portable station with a maximum latency of: sensor latency+thread scheduling latency+radio latency Availability Ambient

sensor Generates a new data packet Ambient sensor hub Runtime The packet is put in the packet buffer The data packet is available at the portable station when it becomes in radio range of the portable station, with a maximum latency of: (thread scheduling latency+radio

(19)

latency)*amount of data packets in buffer before this one.

Usabilty User Wants to be monitored by the systems ambient sensors without any interaction. Ambient sensor hub Runtime The user can plug the portable station in a mains outlet for the period of measurement. The ambient sensor hub will collect ambient sensor data autonomously. The portable station is used to manage the network. Server The server software is a composition of storage, analysis, and presentation modules. To be able to scale the system at a later stage, loads on the server(s) have to be minimized. Realtime sensor data can be accessed by the user interface directly, and does not need to be stored first. This ensures that the presented data has the least ammount of latency. At the same time by directy presenting it, an extra call and query on the database can be avoided. To be able to access the data from any location or time, the server provides the user interface as a website. Figure 5 shows the module decomposition view of the server software. Figure 5 Server software module decomposition view Communication in the server is achieved by means of a central communication bus where multiple module can hook into and listen for messages of interrest of publish information. Employing this structure will keep the system modules manageble in complexity, and there does not need to be a communication planning. Every module can listen/ publish messages. It is important that the imput/output operations are performed non blocking. The quality attribute scenario’s relevant for the server are put in table 3. Table 3, Server quality attribute scenario’s

(20)

stimulus Environment

Availabilty Client Wants to view the historical data of a

sensor The server Runtime

The server queries the database and generates a result set The server responds with the required data set, while not impeding new write operations due to its non-blocking IO.

Performance Client Wants to view real-time data of a sensor The server Runtime The server opens a real-time socket to the client web browser and connects the socket to the one available for the portable station The maximum latency of a data packet coming from the portable station is: Connection latency(portable station to server) + Connection latency (server to browser)

4) Implementation

Hardware & Protocols

In order to test and evaluate properties of the architecture, an experimental implementation was made. This implementation tries to stay close to the architecture, both structurally and technically. The architecture was implemented using mostly of the shelf components. As the focus of this sensor network is on healthcare, the total cost of the system is an important factor for successful implementation. It is a continuous tradeoff between cost and functionality, therefore, components were chosen that would just fit the use-case.

Portable station

A low-end Android smartphone is used as the hardware platform for the portable station software (Motorola MOTO G 2014). A model was chosen that featured a Bluetooth & Bluetooth LE radio to provide connectivity for the body area sensors. Android was chosen, because it allows great control over the behavior of the device, and provides access to its internal sensors and storage resources. Because of the sensors embedded in the phone, the phone itself can acquire data about person carrying it. The phone provides an accelerometer, compass, GPS, light, sound and proximity sensing capabilities that can be employed to build fall-detectors, sound based distress detectors, and location detection on macro and micro level (through Bluetooth beacons radio).

Ambient sensor hub

The ambient sensor hub was implemented by using an off the shelf low cost embedded Linux computer, equipped with a ZWave transceiver and Bluetooth low energy transceiver. The Bluetooth low energy transceiver is used to connect to the portable station. The ZWave module will receive the ambient sensor signals.

(21)

Figure 6 Ambient sensor hub hardware

Server

The server is a regular desktop computer, running Windows 7 as operating system, and is connected to a permanently available network connection. All systems are interconnected over VPN.

Body area sensors

The sensors come from a variety of suppliers, and utilize multiple types of connectivity. Bluetooth low energy was the protocol of preference for the body area sensors since its power demands are four times lower in comparison with traditional Bluetooth radios in the same use-case. It is becoming the standard for interfacing low power sensors with smartphones. Shimmer sensors with Bluetooth 2.0 were added later.

Ambient sensors

The ambient sensors can be arbitrarily picked as long as there is a possibility to gain access to the raw sensor data. For this test, ZWave was used because of the zero configuration setup, compatibility across different suppliers and familiarity in the host organization. Three types of sensors were connected to the ambient sensor hub: • Motion sensors, set to a 10 second timeout, • Magnetic switch sensors, 3 second timeout, • Energy monitor wall socket, 10 second timeout.

Software

There are three software systems in this architecture. The software on the portable station, ambient sensor hub, and server.

Portable station

The software on the portable station is written to closely reflect the portable station software design of the architecture. It is implemented in Java for Android API 19. A version of couch base database was also compiled to work on the Android platform. The real time socket was set up with an Android compiled version of Socket.IO. Figure 7 shows the portable station hardware and software layers.

(22)

Figure 7 Portable station hardware and software layer view For the configuration of the system, it was chosen that all sensor related settings would be managed through an external JSON configuration file. Upon start of the software, the configuration file is read, ,and for every sensor listed, an appropriate acquisition interface is instantiated together with a new instance of the configured detector, filter and storage system. As an example, a typical entry has the layout of figure 8.

"name": "BLE Heart rate monitor",

"body-location": "wrist",

"sensors": [ {

"name": "Heart Rate",

"acquisition-strategy": { "name": "dataAquisitionBLEConnection", "hardware-address": "C3:4D:F2:BD:3B:63", "uuid": "00002a37-0000-1000-8000-00805f9b34fb", "enable-notifications": "true" }, "transmission-strategy": "realtime", "measurement-unit": "bpm" }, { "name": "Battery", "acquisition-strategy": { "name": "dataAquisitionBLEConnection", "hardware-address": "C3:4D:F2:BD:3B:63", "uuid": "00002a38-0000-1000-8000-00805f9b34fb", "interval": "60000" }, "measurement-unit": "%" },

(23)

]

Figure 8 Example sensor configuration entry

The example entry of figure 8 would set up the system with two data channels. The heart rate, that is automatically updated, transmitted in real-time, and has a unit bpm. The second channel is the battery, this channel is updated every minute and stored. It reports its value in %. The acquisition strategy dataAquisitionBLEConnection is a generic acquisition interface implementation for

setting up a Bluetooth low energy connection, read/write its characteristics, and it also transforms the received data into data channels that can be used by the rest of the system. The available properties differ per acquisition interface. If a new acquisition interface is built, it should be build generic. The configuration can be supplied through properties added in the sensor entry. The interfaces currently available are: Bluetooth Low energy, ZWave, and internal phone sensors.

Ambient sensor hub

The ambient sensor hub software is written in NodeJS. This programming platform was chosen because it is independent of hardware and operating system. Interaction with hardware components is achieved through the use of separate NodeJS modules. The modules are platform dependent. The software written for the ambient sensor hub acts as a non-volatile data buffer for sensor data. ZWave module For the evaluation of the system ZWave ambient sensors were used. To receive the signals from the sensors, an off the shelf ZWave module was used from ‘Razberry’. This module comes with a software package for the raspberry pi board. The data coming from the sensors can be read by polling a web-interface provided by the razberry software. The data is offered in JSON format.

Bluetooth Low Energy Module

The connection between portable station and ambient sensor hub is made with a Bluetooth 4.0 Low Energy(BLE) module. The low latency, low bandwidth BLE connection consumes little power on the portable station side. If there is no connection present, the Bluetooth module will switch to ‘advertising mode’. In this mode an advertisement signal is send every second. The portable station is periodically searching for this advertisement signal. This signal contains unique identifiers, so the portable station can identify it among other Bluetooth devices. The Bluetooth module is set up to only allow a connection from the first device is has ever connected to (in our case the portable station). This setting can be reset if necessary. When the signal is detected by the portable station, a connection is made and the buffered sensor data is transmitted. Figure 9 shows portable station program flow.

(24)

Figure 9 Ambient sensor hub program control flow

Server

For the software on the server, a platform was chosen that facilitate speed and scalability. NodeJS was used because of its event driven and non-blocking IO model and has the possibility to work with Couchbase database and Socket.IO. Couchbase was selected as the database type because it features a zero configuration style synchronization procedure. The socket.IO real-time socket was introduced to facilitate real-time messaging between portable station, server and client interface. Client interface The client interface is a website server through NodeJS on the server. The website has a real-time socket connection to the server. In the client interface, data channels from sensors can be viewed in real-time. Multiple data channels can be combined and viewed in (real-time) graphs. Figure 10 Server software

(25)

5) Evaluation

To evaluate the architecture and implementation, focus is put on the areas where other researchers and surveys found the most problems to occur. From literature study and requirements engineering followed that energy consumption, bandwidth and network organization posed a risk for other sensor network implementations. For this study part of the implementation success lays with the used hardware. Since metrics like power consumption and connectivity bandwidth are partially device specific, it is assumed that, because of the low-end characteristic of the smartphone, these results can be extrapolated to the majority of other Android smartphone systems. In order to verify the systems usability in a real-life setting user testing has also been performed.

Power consumption

The power consumption of the architecture can be evaluated by assessing the power consumption of the individual devices. Since the ambient sensor hub is mains connected and the battery life of the ZWave sensors already determined (1 year, dependent on use-case) by the Digital Life Center, it was decided to exclude this part of the system from energy consumption testing. We encountered a device limitation when implementing the portable station software. The hardware does not allow event-based accelerometer reading delivery to the application when the CPU is turned off. We overcame this shortcoming by implementing a wake lock that keeps the CPU awake. This unfortunately comes with a severe energy consumption penalty, shortening usable system time from days to hours. The power consumption of the portable station was evaluated experimentally with the following steps: 1. Fully charge the portable station, 2. Stop all running apps, 3. Start the portable station app, 4. Detach the portable station charger, 5. Start a stopwatch, 6. Turn the screen of, 7. Wait until the portable station delivers a low battery audio warning, 8. Stop stopwatch and record time. Two tests were performed to evaluate two possible use-cases of the portable station. The first test consisted of the portable station without any sensors enabled and can be considered the base case, this setup yielded a battery life of 2 days. The second test consisted of the portable station with accelerometer sensor enabled. This test was performed to measure the energy penalty of the wake-lock. The yielded battery life was 8 hours. From the two tests it was determined that accelerometers and their accompanying wake-lock are by far the greatest power consumers in the smartphone. This consumption cannot be attributed to the accelerometer itself. It is the central processor that has to be woken/kept awake and operate at high speed in order to catch and store all measurements. A later test showed that with a wake-lock both internal and external accelerometer consume roughly the sample power from the portable station. So dependent on the amount and type of sensors that are connected, the maximum usable time will

(26)

Bandwidth While the bandwidth requirements of the system changes with the type of sensors used, the system was designed to provide real-time data to a receiver. Devices requiring a high bandwidth are internal and externally attached accelerometers/gyroscopes/IMU units. The system was successfully tested with three simultaneously connected accelerometers, all transmitting their x,y,z measurements at a rate of 25 Hz. Because GSM/3G was used, bandwidth was a property of the location and time. The 3G infrastructures bandwidth is highly dependent on the amount of traffic and de degree of propagation possibilities. To measure the overall time that the portable station was connected to the server the following steps were taken: 1. The portable station was fully charged and then rebooted to reset the ‘connected time’ percentage of the Android OS, 2. Stop all running apps, 3. Start the portable station app, 4. Detach the portable station charger, 5. Start a stopwatch, 6. Turn the screen of, 7. Wait until the portable station delivers a low battery audio warning, 8. Note the ‘connected time’ percentage of the Android OS The system had and overall connected state of 96% in an urban environment. Another bandwidth limitation of the system was observed during several software tests. When enabling more that two accelerometers and synchronization it was observed that the database buffer kept growing. This implies that the bandwidth limitation of the database and Android file system has been reached. The area where bandwidth limitations became most prominently apparent was Bluetooth connectivity. While the Bluetooth 4.0 standard prescribes no limit to the amount of connected devices, it does not mean the underlying hardware supports an ‘unlimited’ amount of devices. When the radio is in a connected state while simultaneously scanning for new devices to connect to, existing connections can become unstable. We observed missing data points and the disconnection of already present Bluetooth connections. This issue could be related to the Bluetooth low energy radio implemented in the portable station, although some literature speaks of this shortcoming of BLE*

Network extension

In order to test the flexibility of the network, three sensors where added to the system after it was initially developed. The key component in adding sensors is the structure of the data acquisition system. Every data stream from a sensor device can be seen as an individual sensor itself. By treating these data streams equally, the internal structure of the architecture only has to account for a single data stream after the point of entry The first sensor that was chosen to be added to the network was a Bluetooth 2.0 shimmer sensor. Shimmer sensors are used by researchers to track the motion of body parts. They connect through Bluetooth 2.0. There was no acquisition interface designed for this type of Bluetooth, so this had to be developed.

(27)

In order to achieve connectivity with the sensor, a manufacturer supplied library had to be added to the acquisition module. The module itself was written generically, so it would be able to connect to multiple shimmer sensors.

In the sensor configuration file, an entry was added that described shimmer sensors. Figure 11 shows the addition

"name": "Shimmer Sensor 1",

"body-location": "heel", "sensors": [ { "name": "X", "acquisition-strategy": { "name": "dataAquisitionShimmer", "hardware-address": "00:06:66:A0:3B:33", "sampling-rate": "low", "axis": "x" }, "transmission-strategy": "realtime", "measurement-unit": "m/s" }

] * For the y and z axis and the battery level an entry also had to be made Figure 11 Sensor configuration file addition Integrating this sensor into the system required only the addition of an acquisition interface and the addition to the sensor configuration file. No components, nor database entries had to be altered. The architecture prescribes that the sensor configuration can be performed through the client interface of the server. In our test case the sensor configuration was provided by an external JSON file.

User testing

The main stakeholder(HvA) evaluated the architecture implementation on the precision of the sensor data and overall functioning of the system. Two separate tests were performed.

Test 1

The first test consisted of an evaluation of the entire architecture. The sensor system was deployed from 2 April 2015 to 5 April 2015. The deployed hardware consisted of: • 1x Portable station, implemented as Android application on a Motorola Moto G(2014 edition), • 1x MIO Link optical heart rate monitor, • 1x Ambient sensor hub, implemented as Node.js application on a Raspberry Pi 1 model B+, • 2x Benext MOLITE ZWave motion sensor, with a trigger timeout of 30 seconds, • 1x Benext ZWave Door sensor, • 1x Benext ZWave energy meter & switch.

(28)

The software on the portable station was configured to measure: • Heart rate once per second, • Location every 10 minutes, through the portable station’s internal GPS, • Ambient sensor data in real-time. Severe connection problems prevented successful exploration of the real-time functionality of the sensor system. There was no possibility within the host organization to create a server with a public IP Address, therefore, al traffic had to be routed through an external VPN server. This added latency and connection drops. A total of 280000 data points were collected in the first test that had a duration of four days. Analysis of the heart rate monitor data showed that if the sensor was turned on, readings were stored every second. There were no missing seconds during the sensor operation. The first test was a success in the sense that there was no data loss. All the collected data was stored on the portable station and partially synchronized to the server. Full synchronization was performed when the test ended. The data was analyzed together with the main stakeholder and proven correct. Direct feedback on the first user test focused foremost on the maintenance of the system. The charging of the hub and sensors proved to be a hassle. The ambient sensors measured unobtrusively and are almost maintenance free. While the high power consumption and thus low battery life of the hub can be attributed to non-optimal implementation of the architecture, the charging of the sensors cannot be overcome by this architecture. The heart rate sensor uses an optical system (LED with a sensitive photo detector) perform its measurements. With the current consumer available battery energy density it is not possible to measure for extended periods of time(in the test case case longer than 8 hours) while keeping the physical volume of the sensor within limits of usability. From a later evaluation of the test through a questionnaire, it was found that the user experienced management of the energy levels in the sensors and portable station to be a hassle.

Test 2

The second test was set up to test the eventual consistency of the system. The sensor system was deployed from 8 May 2015 to 12 May 2015. The deployed hardware was identical to the first test. The software configuration differed. The software on the portable station was configured to measure: • Heart rate once per second, • Location every minute, through the portable station’s internal GPS, fused with location data from the mobile network and surrounding Wi-Fi access points, • Ambient sensor data in real-time. • Steps in real-time The step sensor was chosen to continuously transmit its data to the real-time channel. The server stored the measurements. The portable station stored the measurements of the sensor if there was too little bandwidth available to transmit the data.

(29)

A total of 220000 data points were collected in the second test that had a duration of five days, where the total on-time for the portable station was 3 days. The test was a success for validation of the real-time channel and eventual consistency. When observing the database after the test, it was found that all data points were collected and stored in the right order. Only single packet drops could be observed when switching from the real-time channel to the synchronized database. This problem was identified by gaps in the sensor data timestamps. This could be overcome by a proper software implementation. We found that although the system conforms to the requirements, its usage is less convenient as expected. The maintenance of the devices proves to require too much attention from the user. The main goal of measuring with sensors is unobtrusive monitoring. That could not be achieved with the sensors used. Figure 12 shows a graph of with heart rate measurements collected over two hours. Figure 12, user heart rate data ( 2 hour sample)

6) Discussion

A couple of lessons have been learned regarding the Android as a platform for sensor system software. While the Android platform offers freedom in software development, there are some challenges that have to be overcome in order for Android be a stable platform for sensor systems. The biggest challenge to overcome is guaranteeing that the application stays alive, and is not shutdown or put in the background by the Android scheduler. On Android 4.3 we found that the most reliable method is implementing a wake lock. Unfortunately this comes with a severe energy consumption penalty, since the CPU will not be put in sleep mode. This study found that a mechanism could be implemented that would restart the app if it was shut down by the scheduler. This mechanism worked for events where the system shut down the app. In case of an exception in the software, the app is shut down and is not automatically restarted. This makes exception handling a very important aspect of the software. When a system is implemented outside of the lab environment, little to no interaction can be expected from the users. Therefore the system has to perform autonomous for extended periods of time.

(30)

The implementation was done on a consumer Android device. Effort was put into selecting a device that could be considered a low-end device. It can assumed that the majority of consumer brought Android smartphones exceed the performance of this device. While a sensor network implemented with this architecture features autonomy and needs little user interaction, it does introduce a responsibility that might complicate successful measurements. A user is responsible for maintaining the necessary energy level in the portable station and sensors. This means that in practice, the portable station and sensors have to be charged on a regular interval. During testing with users it was found that this responsibility poses the biggest thread to the success of a measurement trial using this sensor system. Even when tested with healthy people gaps in the data exist because they forgot to charge either the phone or the sensors. The developed architecture, when implemented properly, provides a system for objective gathering of medical information using consumer grade electronics. The transition from using specialized medical devices, towards consumer electronics could help to speed up the process of healthcare transformation by reducing system cost. A physician could hand out a sensor to a patient, collect data for a period of time and then offer better feedback on the basis of continuous objective data, instead of incidental snapshots of a patient condition. • What hardware architecture would facilitate the stakeholders’ requirements? • What software architecture would facilitate the stakeholders’ requirements? • What properties regarding network organization, energy consumption, signal routing and, signal bandwidth can be expected from this architecture? • What are the network organizational features of the implemented architecture? • What are the measured energy consumption features of the implemented architecture? • What are the measured signal coverage, routing and bandwidth properties of the implemented architecture?

7) Conclusion

This study was performed in order to design a hardware and software architecture that would facilitate (real-time) location independent sensor monitoring of both ambient and body area sensors. It was evaluated in a lab setting and through user testing. The literature identifies power consumption, bandwidth and network organization are threads to successful implementation of sensor networks. The designed hardware and software architecture tries to mitigate the identified threads through architecture design choices. The designed architecture is a system that features both body area and ambient sensor network properties. The architecture is equipped with On the area of network organization, this architecture performed according to the expected organizational features. The network can be expanded with any type of sensor that has a compatible physical & data link layer. By utilizing the start topology around the portable station the wearer literally becomes the center of the network. The network travels with the wearer and always tries to connect to as many sensors as possible given the current location.

(31)

It is very difficult to get an objective measurement of the available bandwidth of the total system, as this is a function of time and place. Also the bandwidth demand is completely dependent on the amount and type of sensors that are connected to the system. The architecture tries to mitigate the problem of bandwidth limitations and unknown upfront demand by introducing a real-time and buffered data path. If bandwidth limitations cannot be met, either temporarily of permanently, the system will decide to settle for eventual consistency. While this approach guarantees the preservation of all data, even in case of a low bandwidth situation, it does not solve the situation where there is demand for real-time high bandwidth data in a situation where there is little bandwidth available. At our design and testing location in the center of Amsterdam 3g bandwidth was sufficient to transmit the data of three accelerometers at 25 Hz in real time. Testing the power consumption of the designed architecture independent of its implementation is possible by comparing the concept with other architecture designs and then reason about properties that influence power consumption. This type of examination is beyond the scope of this study. The implementation of the architecture on the portable station consumed a lot of energy because of platform limitations. This was reflected very strongly in the user feedback. However when looking at the hypothetical scenario where these platform limitations are solved, users report that wearing this sensor system would not impede them in their daily lives. The connected sensors have their own energy source and energy management. The architecture can do little to improve that, except for using a push structure instead of a pull structure for acquisition of data. The overall conclusion that can be drawn from this study is that the architecture satisfies the need for real-time and location independent sensor monitoring but hardware limitations in the area of energy density prevent this system from being as unobtrusive as expected.

8) Future work

There is a lot of practical work and theoretical research necessary before this system could have serious impact in way medicine does measurements. Foremost there is still lack of technology with the ideal properties for this use-case.

Sensors

The sensors that were used during the user test did not have their own storage capabilities, meaning that in case of (Bluetooth) connectivity problems or software crashes, precious data was lost. Sensors should ideally have their own local storage, capable of storing all data until the connectivity problems are resolved. The eventual consistency of the storage system could merge the stored data with actual data. The data transmitted from most sensors was unencrypted. While the rest of the systems communication is encrypted and encrypted again through the use of a VPN, the data of the sensors was transmitted freely through air. Creating a very secure backend has little use when the sensors themselves do not encrypt their data. It would be preferred that a sensor transmits its data encrypted end-to-end. That means encryption on the sensor and decryption when the data packet is put in the server’s database. This prevents that the operating system, rogue apps or software faults lead to the unintentional ‘sharing’ of data. Another problem that was encountered with the wearable sensors is that in some cases it is very difficult to differentiate between measurements where the sensor was worn but not moved by the wearer, and measurements where the sensor was not worn at all. For successful monitoring, the sensor needs to be equipped with a sensor that can detect human presence. It is not enough to look

(32)

at movement data (accelerometer, gyroscope) because the environment of the sensor could be moving (bag, car, etc). Future sensors that are going to be used by this system should ideally have the following properties: - Local storage that gets synchronized upon connection with the smartphone. - Encryption - User wear detection.

Smartphones as hub

Smartphones can reliably act as central nodes of a sensor system. The current state of the Android operating system prevents reliable utilization for our use case. The operating system has too much control over the applications running on top of it. As talked about in the discussion, the app can be closed at will by the OS for various reasons (low memory, low battery, demand for processing power). For the future there needs to be a separate category of apps that are exempt from OS control of the level that current apps are. That means no force closes because of memory needs, no bandwidth throttling. It must be noted however, that the required functionality must not impede the user from using their phone as an actual phone. Care must be put into making the right tradeoff between reliability and usability. During our testing, it was found that 3G provided enough bandwidth for real-time measurement reporting, however, the area where improvements can be made is in the area of latency. The current latency sat between 200ms and 500ms depending on location and time of day. This could be improved to less than 20ms when using 4G technologies.

(33)

9 )Bibliography

Akyildiz, I., Su, W., Sankarasubramaniam, Y., & Cayirci, E. (2002, 8). A survey on sensor networks. Communications Magazine , 102-114. Azeem Majeed, A. B. (2011, 1). The Impact of eHealth on the Quality and Safety of Healthcare. PLoS Med. Emil Jovanov, A. M. (2005). A wireless body area network of intelligent motion sensors for computer assisted physical rehabilitation. Journal of NeuroEngineering and Rehabilitation , 2-6. Kim, Y.-J., & Jung, K.-K. (2009). Design and Verification using Energy Consumption Model of Low Power Sensor Network for Monitoring System for Elderly Living Alone. Journal of IKEEE , 13 (3), 39-46. Krose, S. R. (2013). Longitudinal residential ambient monitoring: Correlating sensor data to functional health status. Pervasive Health. Venice, Italy. Len Bass, P. C. (2012). Software Architecture in Practice (3rd ed.). Marco Altini, J. P. (2010). An Android-Based Body Area Network Gateway for Mobile Health Applications. WH '10 Wireless Health , (pp. 188-189). Nait Aicha. Ahmed, G. E. (2013). How lonely is your grandma? Detecting the visits to assisted living elderly from wireless sensor network data. Adjunct proceedings of UbiComp . Sana Saadaoui, L. W. (Jan. 2007). Architecture Concept of a Wireless Body Area Sensor Network for Health Monitoring of Elderly People. Consumer Communications and Networking Conference, 2007. CCNC 2007. 4th IEEE (pp. 722 - 726). Las Vegas, NV, USA: IEEE. Saskia Robben, G. E. (2012). How is grandma doing? Predicting functional health status from binary ambient sensor data. Proceedings of Artificial Intelligence for Gerontechnology . Vasilakos·, M. C. (2011). Body Area Networks: A Survey. Mobile Netw Applications , 171–193. Virone, G. W. (2006). An advanced wireless sensor network for health monitoring. Transdisciplinary Conference on Distributed Diagnosis and Home Healthcare , (pp. 2-4).

(34)

APPENDIX A: Desk research APPENDIX B: In order to elicit the requirements of the system from the stakeholders, a questionnaire was set up. The questions are constructed in a way that will clearly show eventual biases against or for the subject.

Referenties

GERELATEERDE DOCUMENTEN

We used seed-based functional corre- lation analyses to calculate partial correlations of all voxels in the hippocampus relative to characteristic re- gional signal changes in

Semi/porous materials such as polymeric fabrics will be multi-functionalized by the multifunctional formulations including nanoparticles (NPs) with specific

Dat ik Mark Rutte wel of niet charismatisch vind, heeft te maken met dat ik bij de volgende verkiezingen wel of niet vrienden zou aanmoedigen om op Mark Rutte te stemmen1. Dat ik

The average flow throughput performance for the inter-operator CoMP degrades only in the case of non co-azimuth antenna orientation (it is even worse than intra-operator

Een stookkuil is wel aangetroffen tijdens de opgraving, maar een verband tussen deze stookkuil en één van de ovens kon niet worden gelegd door recente(re) verstoringen.

These are set out in a separate document and, amongst all, include the promise of Samsung not to seek injunctive relief for a period of five years before any court for

In this study, we chose to focus on the interaction of research and practice in design projects as evidenced through study of: the instructional solutions created

Comparison of all degradation products in units per mPEG 113 at different reaction temperatures (RT, 50 ◦ C, 70 ◦ C), Figure S9: SEC traces of the degradation study of mPEG 113