You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Electronics
Download PDF
  • Article
  • Open Access

31 December 2020

SmartWalk BAN: Using Body Area Networks to Encourage Older Adults to Perform Physical Activity

,
,
,
,
,
,
,
and
1
Computer Science and Communications Research Centre, School of Technology and Management, Polytechnic Institute of Leiria, 2411-901 Leiria, Portugal
2
Institute of Electronics and Telematics Engineering of Aveiro, Higher School of Technology and Management of Águeda, University of Aveiro, 3810-193 Aveiro, Portugal
3
Center for Health Technology and Services Research, School of Health Sciences, University of Aveiro, 3810-193 Aveiro, Portugal
4
Institute of Electronics and Telematics Engineering of Aveiro, School of Health Sciences, University of Aveiro, 3810-193 Aveiro, Portugal
Electronics2021, 10(1), 56;https://doi.org/10.3390/electronics10010056
This article belongs to the Special Issue Ambient Assisted Living Technologies
Version Notes
Order Reprints

Abstract

Due to the demographic ageing of the world’s population and the respective consequences, it is necessary to guarantee that older adults can be active and maintain their independence and autonomy for longer. The aim of the SmartWalk system is to promote walks in the city in order to stimulate physically active lifestyles. Body area networks are used to aggregate data collected by different type of sensors, which are transmitted to a server to support informed decisions of caregivers when planning physical activities for their care receivers. This article presents the SmartWalk system and reports an experimental setup that was developed to assess the performance of the current implementation and the respective critical components. According to the results, the SmartWalk system presents good performance in terms of battery usage, data upload, capacity to recover from connectivity failures and wireless coverage of its body area network.

1. Introduction

Over the last few decades and throughout the world, due to a significant increase of life expectancy [1], the mean age of the population has been increasing. Moreover, there has been a generalized decrease in the birth rate. As a consequence of these trends, older adults nowadays compose a larger segment of the world population than ever before, which is expected to continue in the future [2].
In historical times, when people got older and had more difficulties caring for themselves, their families took up that responsibility; when that was not possible, many older adults were forced to fend for themselves. In modern times, alternative options are for older adults to be institutionalized and have formal caregivers take care of them or, alternatively, stay in their domiciles and contract external support (e.g., domiciliary support services).
However, because of the changing demographics, i.e., with increasing numbers of older adults to care for and fewer young people to take care of them, these possibilities are becoming scarce and expensive. The concept of Ambient Assisted Living (AAL) [3] emerged to help assuage this problem. AAL makes use of information technologies to, among other things, remotely monitor older adults’ health conditions and thus facilitate the extension of life in which they remain independent and autonomous, while diminishing the human resources needed to care for them [4,5].
The SmartWalk system [6,7] was designed to make use of the AAL concept to encourage older adults to perform physical activities while under the remote supervision of caregivers, namely clinicians such as physiotherapists.
Caregivers can plan different routes for walking in the city according to the profiles of the older adults. Then, older adults using a smartphone application (i.e., the SmartWalk App) can follow the planned routes. Moreover, during the walk, data are collected so that caregivers can verify walkers’ performances and adjust future routes accordingly. For example, if the data reveal that an individual had difficulty in completing the routes that were provided, the respective caregiver might change these routes (e.g., by reducing the distance or by selecting an easier road to walk on); conversely, for good performances, more challenging routes might be provided.
In this study, a Body Area Network (BAN) (i.e., a network of sensors placed on a person’s body or clothing to collect multiples types of data [8]) was implemented to collect data on users’ heart rate, blood oxygen level, and for how long they had been walking. The data collected by this SmartWalk BAN were sent to a server (the SmartWalk Server) where they were consolidated into information that could then be consulted by caregivers so that they could supervise and make informed decisions about the physical activities of their care receivers.
An important requirement for the implementation of the SmartWalk BAN was that multiple instances had to be controllable by a single smartphone. The SmartWalk App had to be able to collect different sets of data related to various SmartWalk BANs, each one associated with a specific user. This was considered to take advantage of the SmartWalk system to promote socialization by allowing a group of walkers to undertake a specific itinerary together by using the orientations provided by a single smartphone. This specific feature was a technological challenge in terms of development, but could minimize the impact of low digital literacy, since older adults with low digital skills could take full advantage of the SmartWalk system without the need to interact with a smartphone application, it being only necessary to wear the SmartWalk BAN.
The present article describes the SmartWalk system and presents details of the respective implementation. In this implementation, a significant engineering effort was made to develop an unobtrusive and energy efficient SmartWalk BAN [9], as well as to guarantee connectivity between multiple BANs and a smartphone hosting the SmartWalk App. An experimental setup was developed to assess the performances of critical components of the current implementation considering four different dimensions (battery life, data upload, impact of connectivity failures, and wireless coverage). The respective results are also presented and discussed.
The following sections briefly present the research work that influenced this study, the proposed SmartWalk system, the respective components, and the results of the experimental setup. Finally, the last section draws some conclusions and presents future plans.

3. Proposed System

The main goal of the SmartWalk system [6,7] is to encourage older adults to perform physical activity (i.e., walking in the city) while under the remote supervision of caregivers, such as physiotherapists.
As can be seen in Figure 1, a SmartWalk user wears a BAN composed of various sensors that collect different types of data and communicate these data to a smartphone. The smartphone acts as temporary data storage and as a relay to a remote server where the collected data is permanently stored to be accessed by authorized entities. Moreover, a single smartphone can be connected to several BANs and, consequently, can aggregate and communicate to the server data from different users.
Figure 1. Architecture of the SmartWalk system.
A smartphone application (i.e., the SmartWalk App) was developed for older adults’ interactions that allowed users to see the planned routes and the actual routes walked, respectively presented in blue and red in Figure 2. The users could also access complementary information, such as their heart rates, blood oxygen levels, distances walked and how long they had been walking.
Figure 2. Route screen.
For the optimization of the routes, the SmartWalk App makes use of context awareness. This means that the application characterizes its surrounding conditions, including itself and its user, to create a context and can then act on that context intelligently to provide the user with relevant information or services [55]; this is something that must be continually adjusted to adapt to changing conditions in a mobile environment and must take into account the limited resources present in a smartphone (e.g., limited battery, uncertainty of network availability, and fewer computational resources) [56].
An important feature of the SmartWalk system is that it enables the caregiver to create a fitness regimen for each user by scheduling walks on various routes in the city. Moreover, the caregivers are able to analyze users’ performances, since the SmartWalk App is able to gather and transmit to the SmartWalk server different types of data to complement the clinical information already stored in a user’s clinical file, including routes the user walked or not, physiological parameters collected by different sensing devices, or patient reported outcomes measures [57], such as pain levels. This allows the caregiver to make well-informed decisions when planning the walking routes and possibly to notice early signs of performance deterioration.
With regard to the physiological parameters, there is a need for a set of different sensors. Therefore, a BAN (i.e., the SmartWalk BAN) was implemented to aggregate this set of sensors together with the capability to either analyze or communicate the data produced by them.
Although the SmartWalk implementation was supported by existing internet communication infrastructures and was thought to take advantage of the relatively easy access of the majority of the population to smartphones [58,59], leveraging the infrastructure provided by a smart city was also considered. This could facilitate not only the connectivity with other smart city services aiming at the wellness of citizens, but also the secondary use of collected data that might be invaluable for the city itself, in terms of the planning of its infrastructures; for example, by providing better information on where people concentrate or whether the public spaces in a city are adequate for citizens’ needs [6].

3.1. SmartWalk App

The SmartWalk App (Figure 1) makes use of the several sensors already present in a typical smartphone (e.g., accelerometer, Global Positioning System (GPS)) and connects to the external sensors of the BAN using Bluetooth Low Energy (BLE).
In terms of implementation, the SmartWalk App was designed to be installed on Android smartphones. The earliest version of Android compatible with the SmartWalk App is version 5.0 (Application Programming Interface (API) level 21), which means that the application is compatible with almost 90% of Android smartphones, according to data from 2019 [60].
Moreover, BLE was chosen instead of regular Bluetooth because, while it has a lower data throughput, it also has a much lower power consumption, making it much more suited to transmitting small amounts of data in bursts, as required; minimizing energy consumption is also extremely important (i.e., the sensors and the smartphone itself are all restrained by batteries with limited charge). Additionally, BLE is advantageous when compared with other possible protocols (e.g., ZigBee [61]), since most smartphones already come with the required BLE hardware, which is not the case for other possible protocols.
Once the routes have been created (e.g., using the My Maps service from Google or the geojson.io website), the generated Keyhole Markup Language (KML) files can be downloaded by the SmartWalk App, which makes them available as new routes to experience.
To know whether the user is walking, running or at rest, the SmartWalk App makes use of the accelerometer sensor that all modern smartphones possess. It is mainly used so that a smartphone can detect its own orientation and thus know how to correctly show images on the screen. While this is the most common use of an accelerometer in smartphones, an accelerometer can also be used for many other purposes, but the one that interests us is how it can be used to detect motion. A good accelerometer with the correct software can detect what type of activity the person carrying it is doing with a high degree of precision, including the difference between walking and running, different types of sports, whether the user is moving in a vehicle and the number of steps taken when moving. To be able to recognize all these activities, a sturdy algorithm must be created with several reference points for all types of motion [62].
The SmartWalk App also tracks the users by recording their positions at set intervals, so that visual representation of a user’s progress can be presented, or their performance later analyzed. Moreover, if during a walk the user strays too far from the planned route, the application will emit an alarm to inform the user. Tracking is achieved by making use of either the smartphone’s own GPS or by triangulating the user’s position using Wi-Fi networks. Triangulation is faster and thus uses less battery power, but its accuracy is heavily impacted by how many access points it can connect to, as the accuracy is directly correlated with the number of access points that can be connected to and whether those access points are present in a location database. Thus, when outdoors, Wi-Fi-based triangulation is still less reliable than GPS. Therefore, it was decided to give preference to GPS (i.e., more accurate data even at the cost of lower battery performance), with Wi-Fi only being used when GPS was unavailable.
Readily available frameworks with proven effectiveness were used for the implementation of the SmartWalk App. Google’s Awareness API [63] was used to register whether the users were moving or not and, when moving, whether their movement conformed with the planned routes. In turn, the Google Fit API was used to record the different types of activity during the walk (i.e., walking, running, or resting). Moreover, the Snapshot API was used when an active read of the current context was needed (e.g., to check for the user’s current locations, whether they are running or whether their headphones are plugged in). Finally, the Fences API was used to implement geofences, by which a geographical area is defined and the application receives a callback when the smartphone enters or exits that area, which can be expanded by enabling the creation of fences from other context types. It also allows for different fences to be combined using the Boolean operators.

3.2. SmartWalk Server

All the data collected by the SmartWalk App is sent to the SmartWalk Server, which is responsible for their storage. The structure of the data being stored conforms to the FHIR [53], a healthcare interoperability standard to guarantee the integration of disparate healthcare systems and the interchange of clinical information between different healthcare providers and organizations.
The data are collected into different types of JavaScript Object Notation (JSON) files, depending on which data are to be sent. However, this is a sensitive process with private information, and thus security mechanisms must be included. In light of this, it was decided to use Rivest–Shamir–Adleman (RSA) encryption [64], a type of public key cryptography system, to encrypt the data. However, while this type of encryption is very secure, it presents an important limitation: the maximum amount of data that can be encrypted is only 256 bytes. This is patently insufficient, as even a small walk can generate a volume of data that far surpasses this limit. To get around this problem, the application uses the Advanced Encryption Standard (AES) [65] to generate a secret key, which is then used to encrypt the data. However, the server requires the generated key to be able to decrypt the information, but transmitting the generated key is in itself a security risk. So, RSA is used to encrypt the AES-generated key to be sent to the server. On the server side, the RSA private key is used to decrypt the AES-generated key and the respective result used to decrypt the received data.
The SmartWalk Server also provides several web services coded in Hypertext Preprocessor (PHP) to its clients, allowing for data sharing and communication between the end users of SmartWalk (e.g., caregivers).

3.3. SmartWalk BAN

At the beginning of the development of the SmartWalk BAN, it was planned that the system should allow for quick familiarization and should be easy to use, easy to wear, and cheap to fabricate. The data collected by the BAN sensors are aggregated by the SmartWalk App [66], which is responsible for the communication with the SmartWalk Server.
A permanent data connection was not considered. Although it would have permitted real-time monitoring, it would also have an impact on the battery life and the communication costs, since the users are walking around and will not always be in range of a Wi-Fi connection, thus entailing the use of costlier means of maintaining the connection. Therefore, the data communication channel is established according to a predetermined frequency.
As previously stated, BLE was selected for the SmartWalk implementation because most smartphones already come with the prerequisite hardware installed. Another important factor in choosing BLE was that it supports the Generic Attribute Profile (GATT) [67], which defines the profile and what services a device provides when communicating with other BLE devices. This means that for specific types of sensors (e.g., a heart rate sensor), one only needs to implement the correct profile on the device and any other BLE devices will automatically recognize it and know what the communicated data means. It is important to note that, in this context, a sensor and a BAN device are not the same thing.
As can be seen in Figure 3, the SmartWalk implementation was designed such that any type of device or sensor supporting BLE, and thus GATT, whether commercially available or not, would be able to seamlessly connect with the application and share data with it. This allows users to make use of devices that they may already possess (e.g., Fitbit or Mi Band).
Figure 3. SmartWalk Body Area Network (BAN).
However, when designing the SmartWalk BAN, the possibility was considered that different BANs might be controlled by the same smartphone. The rationale of this approach was that although some potential users might live alone, others might live with their spouses, who most likely are also older adults and would also benefit from the physical activity. Moreover, since walking around might be an activity that facilitates socialization, the possibility of having a group of walkers performing a specific itinerary together was foreseen. In such cases, with regard to orientation uses, one instance of the smartphone application can be shared as long as the gathering of data from the various individuals is guaranteed (i.e., different BANs can be connected to the same instance of the SmartWalk App). This feature allows older adults with low digital literacy, when with a group of friends, to take full advantage of the SmartWalk system without the need to interact with the respective smartphone application, it being only necessary to wear the SmartWalk BAN. In turn, the disadvantage of a more complex implementation should be pointed out: it requires defining the number of BANs in the SmartWalk App and assigning a user identifier to each BAN, as well as to the respective BLE devices from the set of visible BLE devices. Furthermore, this implementation requires the synchronous collection of different sets of data from multiple devices and the guaranteed connectivity of a greater number of communicating parties. In this respect, as the number of BANs increases, the number of devices per BAN decreases due to connectivity limitations. In such cases, it is necessary to prioritize the importance of each BAN sensor. It is reasonable to assume that the device running the SmartWalk App can hold 8+ BLE connections simultaneously.
For the SmartWalk App to be associated with a specific BAN, it must identify the respective BLE device. To do that, the application checks for devices and if it finds one or more new devices, it questions the SmartWalk Server whether the devices that were identified are already associated with the current users. If the answer is positive, the SmartWalk App seamlessly maps the devices to the users’ BANs, if they are already active, or creates new pairs composed of the BANs and the respective BLE devices (Figure 4).
Figure 4. Algorithm to associate a BLE with a BAN.
If, however, the device is known but not associated, the user is prompted for an authentication, which requires establishing a connection to the SmartWalk Server. When the authentication is concluded a new pair of BAN and BLE devices is created. If the response from the server is negative, the application ignores the device and continues to the next one on the list. This process is repeated until there are no more new devices.
The implemented SmartWalk BAN includes a heart rate/pulse oximeter sensor that registers both the number of beats of the heart per minute and the level of oxygen saturation in a person’s blood. For this purpose, it makes use of a MAX30100 sensor that uses two Light-Emitting Diodes (LEDs), one of which emits red light and the other infrared light. The infrared light is used to obtain a Photoplethysmogram (PPG) that detects changes in the volume of blood in the skin, and from those changes it calculates the heart rate of the user. To obtain the level of oxygen in the blood, it makes use of both LEDs, as oxygenated blood absorbs more infrared light and allows more red light to pass through, while deoxygenated blood is the reverse, absorbing more red light and allowing more infrared light to pass through. The amount of each type of light that is not absorbed is measured and the ratio between the red light and infrared light indicates the level of oxygen in the person’s blood.
The MAX30100 sensor was chosen because it combines both a pulse oximeter and a heart rate sensor in an affordable package and would serve as good testing platform for its more recent siblings, the MAX30101 and MAX30102, if the need for change arose. It was connected to an ESP32 microcontroller, which provides wireless communication, is an easily programmed microcontroller and has programming libraries and plentiful documentation.
Figure 5 shows the diagram of the ESP32 microcontroller along with the MAX30100 sensor used in this project, with each colored line signifying how they were connected. The serial clock (SCL) synchronized the data transfer between the sensor and the microcontroller using serial data carrying (SDA). Figure 5 also shows the voltage input (VIN) and the ground of the circuit (GND).
Figure 5. Pin connections of the ESP32 microcontroller.
The microcontroller was programmed to be a BLE server that makes available for any other BLE device listening two specific services in accordance with the GATT profile: a heart rate service (Universally Unique Identifier—UUID—0×180D) and a pulse oximeter service (UUID 0×1822) [68]. Each service is composed of several characteristics, namely attribute types that contain a single value and are used to store the data collected by the sensor for transmission. During the initialization, the microcontroller starts advertising its services and when a client is connected, the sensor updates its values every ten milliseconds and transmits them to the client. This cycle is maintained until the client is disconnected. At that point, the microcontroller tries to connect to another client, but no data is transmitted until a connection is made.
Since it was envisaged that a single smartphone might control different BANs, the SmartWalk BAN also provides an alarm to notify its user that they are too far from the connecting node.
The design for the device intended it to be like a glove, with the sensor in one of the fingertips, in an enclosed cover to keep any light from disrupting the readings, with a battery pack attached either at the wrist or on the back of the hand.

4. Performance Evaluation

During the development of the SmartWalk project, real-life pilot study were planned to assess the impact of the proposed solution for the minimization of sedentarism among older adults. Therefore, as preparation for this pilot study, the SmartWalk system prototype was made the object of several assessments, including assessments of the usability of the SmartWalk App, the conformance level of the FHIR implementation, and the adequacy of the security mechanisms.
Considering the focus of this study, an experimental setup was developed to ascertain the performance of the SmartWalk critical components in terms of battery life and data upload. Moreover, since a single smartphone might control multiple SmartWalk BANs and the users of different BANs are walking and, therefore, it is not possible to maintain a constant distance between each BAN and the smartphone hosting the SmartWalk App, experimental tests were also performed to determine the impact of connectivity failures in the transmission of the data collected by the sensors of the BAN, as well as the wireless coverage.
For the experimental setup two Android smartphones were used: a BQ Aquaris M5 with Android version 7.1.2 and Bluetooth 4.0 and a Samsung Galaxy A40 with Android version 9.0 and Bluetooth 5.0. In terms of BLE communications, the SmartWalk BAN requires versions that are supported by Android version 4.3 (API level 18) and up.

4.1. Battery Usage

To assess the battery life the application was repeatedly used in a use case scenario that consisted of walking a predefined route, both while using and not using the heart rate sensor, at the end of which a report of the data collected by the sensor was sent to the server via the Internet. The Batterystats tool and the Battery Historian script [68] from Google were used to collect the assessment data, along with Docker Desktop [69] for data viewing and analysis.
As can be seen in Table 1, the most significant drains were the screen, which was always on, the GPS, which was used to record the location, and the BLE radio for the connection to transmit the data collected by the heart rate sensor. Over longer periods, the usage of the heart rate sensor led to a vastly increased energy consumption due to the constant use of the BLE radio. However, even in light of this the application’s energy consumption was not excessive, with the tests showing that it was capable of remaining active for multiple hours of constant activity, far more than expected for normal usage.
Table 1. Battery usage.

4.2. Data Upload

To assess the performance of the upload of data collected by the SmartWalk BAN, a test consisting of sending both single and multiple files of different sizes to the server was performed. It is important to note that it was assumed that while this operation was being performed the user should be able to continue to make use of the application as normal without suffering any usage lag or interruptions.
The test files were conformed to the JSON files generated by the application, storing dummy data of progressively longer walks for each of them.
Figure 6, Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11 show the testing smartphone’s usage of its Central Processing Unit (CPU), memory, and network bandwidth as each test was performed in order to ascertain performance, displaying the various values over time. Figure 6, Figure 7 and Figure 8 show the data for single file uploads of 2.5, 7.5, and 15 MB, respectively, and Figure 9, Figure 10 and Figure 11 show five consecutive file uploads of 2.5, 7.5, and 15 MB, respectively. In each figure, it can be seen that CPU usage spiked at the beginning as the files were encrypted, and then dropped as the file was being sent. It can also be observed, for multiple files, that memory usage increased during the entire process of file uploading and then dropped off, before increasing again when the next file started to be uploaded.
Figure 6. Single file uploads of 2.5 MB.
Figure 7. Single file uploads of 7.5 MB.
Figure 8. Single file uploads of 15 MB.
Figure 9. Multiple 2.5 MB file uploads.
Figure 10. Multiple 7.5 MB file uploads.
Figure 11. Multiple 15 MB file uploads.
In the presence of larger file sizes more system resources were required, but the resources being used were only a small part of all the resources available to most Android smartphones, and within the tolerances established by the SmartWalk requirements.

4.3. Impact of Connectivity Failures

The SmartWalk App was designed to be used in the context of a smart city, and thus was expected to be capable of always being connected to the Internet when in use. However, outages, user errors, or any number of other occurrences can happen that may preclude a connection. For such cases, the application functions normally but when the user decides to end its walk it stores all the data collected in the smartphone. It can do this indefinitely with the only limitation being the storage space of the smartphone itself.
When the application reconnects to the Internet it then transmits the stored data until all are sent or the connection is lost again. This was designed this way so that even in low bandwidth conditions the data can be transmitted, even if slowly or over several distinct time periods. Furthermore, since maps have to be loaded from the Internet, if a connection does not exist and if the map is not cached from a previous walk of that route, the route will be presented on a blank map. Considering this issue, the SmartWalk App was assessed with regard to five different scenarios that might occur when a user goes for a walk: I—the Internet connection is always active; II—the Internet connection is established at the beginning of the walk, but it is unstable throughout the rest of the walk; III—the Internet connection is not available in the beginning of the walk, but it is established before the end of the walk; IV—the Internet connection is available at the beginning of the walk, but it is lost during the walk and a reconnection is not possible; and V—the Internet connection is not available throughout the whole walk.
The results (Table 2) show that when the connectivity was reestablished the SmartWalk system could recover all data collected by the BAN, which was then transmitted to the SmartWalk Server.
Table 2. Impact of connectivity failures.

4.4. Wireless Coverage

The SmartWalk BANs must always be in contact with their users when they are walking a route; this, however, is not true for the smartphone. A single smartphone can control and receive data from multiple BANs, so that there is no need for all walkers to carry a smartphone and interact with the respective SmartWalk App. However, during a walk, the distance between the smartphone and the different BANs varies continuously and it is dependent on the dynamic of each group of walkers.
Interferences might result when WSNs are used by several people in close proximity. These interferences are caused when different sensor nodes send their data at the same time, particularly if they use the same communication bands [70], and result in possible communication failures and the expense of more power to resend the data. Using the SmartWalk strategy of allowing multiple BANs to communicate with a single coordinating node, this issue can be ameliorated, as each sensor node communicates only during its assigned time slot.
The limitation on the number of devices is defined by the implementation of the smartphones and at the time of writing it is assumed that the latest smartphones can support at least eight devices, with this number expected to increase. The supported BLE devices can be distributed to distinct users, as appropriate. The limit of application throughput of 1.37 Mbit/s, as defined for BLE [67], is more than sufficient for the SmartWalk BAN data transmission, given that the sampling of the heart rate or the blood oxygen level is highly spaced over time.
It should be noted, however, that the theoretical limit of the wireless coverage of BLE is less than 100 m [67], but in real conditions we can expect the distance to be reduced due to interferences such as other signals, terrain, or buildings.
Therefore, the experimental setup was also used to determine at what ranges the SmartWalk BAN could communicate with the smartphone and what effect obstructions, such as walls, exhibited. The results are presented on Table 3.
Table 3. BLE coverage.
As expected, the range at which the devices were able to communicate was much larger when no obstructions were present, but they were still able to communicate up to ten meters even with two walls between them. The two versions of BLE showed a significant difference in the range, with version 4.2 having almost two meters of additional range when compared to version 4.0.
To assess the recovery capability when the BLE signal was lost, a test was performed that consisted of turning off the heart rate sensor and turning it on again, and taking the smartphone out of range until it lost the connection and then reentering range and letting it reconnect. As the two smartphones used in the experimental setup had different versions of BLE, the lowest version was used to create the connection. As can be seen in Table 3, if the sensor shut down and had to be restarted, it could take up to twenty seconds for the sensor to reconnect with the application and only then could data collection be resumed. This period was much smaller when the sensor was taken out of range of the smartphone, taking up to five seconds to reconnect and resume data collection. This was due to the sensor dropping out completely from the list of devices the application was connected to and thus forcing the application to search and connect with what was for it a new device, as opposed to simply reconnecting with a device already on its list. There were no measurable differences in time between the two versions of BLE. However, since the SmartWalk BAN has the capability of data storage, this does not impact the quality of the data sent to the SmartWalk Server.

5. Conclusions

This article presents the SmartWalk system as a means for promoting physical activity among older adults under the supervision of their respective caregivers, and reports some details related to the current implementation and the performance assessment of critical components.
For the implementation of the SmartWalk App, Android smartphones were selected. Moreover, available developing frameworks were also selected, including Google’s Awareness and Fit APIs, as well as the Fences and Snapshot APIs.
An important component of the SmartWalk system is the BAN, since it is through it that all data collection and forwarding is achieved. By using computational hardware, different sensors, BLE, and a smartphone as the gateway node, the SmartWalk BAN provides a way to collect and transmit data related to the performances of the respective users that can inform the decisions of caregivers when planning physical activities for their care receivers.
To promote socialization and to minimize the impact of low digital skills, it was foreseen that a single smartphone might interact with several BANs. Therefore, the performance evaluation consisted not only of the assessment of the battery life and data upload throughput, but also sought to determine the impact of connectivity failures and wireless coverage. The results showed that the battery usage did not inhibit long city walks (e.g., around 8% of battery drain for one hour). Moreover, the upload of the data acquired was efficient, even when multiple data uploads were required, and the system had the capacity of recover from the connectivity failures that were expected when using the wireless communication of a smart city. Finally, in terms of wireless coverage, the results showed that the maximum coverage varied from 10 m to 17 m. The experiment also showed that when the coverage limits were surpassed, the system was able to recover.
Due to the COVID-19 pandemic, a real-world pilot study involving older adults was delayed. However, this pilot is still planned to be conducted in the future. This will be invaluable to collect evidence related to the real impact of the SmartWalk system in terms of the physical activity of older adults supervised by formal caregivers. This could be an important contribution, since the SmartWalk system addresses an opportunity that it has not been sufficiently explored, i.e., the use of the smart city paradigm to minimize the sedentarism of older adults together with the optimization of the opportunities for socialization. Moreover, it is also important to assess the acceptability of the SmartWalk system by formal caregivers.
Moreover, future work is also planned to improve the connectivity of multiple BANs to a single smartphone. Since some operating systems limit the number of BLE devices that can communicate, an approach that consists of linking multiple BANs is being studied. Using a contention protocol, a virtual structure can be created so that the BANs communicate with each other to minimize the number of interactions with the smartphone. In this approach, each SmartWalk BAN could use other BANs as relays to communicate with the smartphone. This optimization might also extend the wireless coverage and the reliability of the SmartWalk BAN, which is essential to provide older adults with different types of solutions and mobile devices.

Author Contributions

Conceptualization, A.P., J.R., F.S., M.R., A.G.S., A.Q., N.P.R.; Methodology, A.P., J.R., F.S., M.R., A.G.S., A.Q., N.P.R.; software, D.B.; Validation, A.P., J.R., F.S., M.R., A.G.S., A.Q., N.P.R.; Formal analysis, D.B.; Investigation, D.B.; Resources, A.P., J.R., F.S., M.R., A.G.S., A.Q., N.P.R.; Data curation, D.B.; Writing—original draft preparation, D.B.; Writing—review and editing, A.P., J.R., F.S., M.R., A.G.S., A.Q., A.F.-C., N.P.R.; Visualization, D.B.; Supervision, A.P., J.R., F.S.; Project administration, A.P., J.R., F.S.; Funding acquisition, A.P., J.R., F.S., M.R., A.G.S., A.Q., N.P.R. All authors have read and agreed to the published version of the manuscript.

Funding

Research funded by CENTRO-01-0145-FEDER-024293. Project Smart-Walk: Smart Cities for Active Seniors lead by ESTGA/ESSUA/ISCA—University of Aveiro, by ESTG—Polytechnic Institute of Leiria, by ESE—Polytechnic Institute of Coimbra, by Águeda Municipality, and by Globaltronic S.A. This work was partially financed by national funds through FITEC—Programa Interface, with reference CIT “INOV-INESC Inovação-Financiamento Base” and by FCT—Foundation for Science and Technology, I.P., in the scope of the projects UID/CEC/04524/2020 and UID/CEC/ 00127/2020.

Institutional Review Board Statement

Non applicable.

Data Availability Statement

No new data were created or analyzed in this study. Data sharing is not applicable to this article.

Conflicts of Interest

The authors declare no conflict of interest.

Abbreviations

The following abbreviations are used in this manuscript:
AALAmbient Assisted Living
AESAdvanced Encryption Standard
APIApplication Programming Interface
BANBody Area Network
BLEBluetooth Low Energy
CABANContext Aware Body Area Network
CPUCentral Processing Unit
CoCaMAALCloud-oriented Context-aware Middleware in Ambient Assisted Living
Fit4AllFit for All
FHIRFast Healthcare Interoperability Resources
GATTGeneric Attribute Profile
GPSGlobal Positioning System
GNDGround
HELPHome-based Empowered Living for Parkinson Disease Patients
HOMERHome Event Recognition System
HOPESmart Home for Elderly People
IoTInternet of Things
JSONJavaScript Object Notation
KMLKeyhole Markup Language
LEDLight-Emitting diode
PHPHypertext Preprocessor
PPGPhotoplethysmogram
ReAALMake it ReAAL
RSARivest–Shamir–Adleman
SCLSerial Clock
SDASerial Data Carrying
UAVUnmanned Aerial Vehicles
UniversAALUniversal Open Platform and Reference Architecture for Ambient Assisted Living
UUIDUniversally Unique Identifier
VINVoltage Input
WHOWorld Health Organization
WiFiWireless Fidelity
WSNWireless Sensor Network
WWSWearable Wellness System
ZAAS-DTZaragoza Ambient Assisted Services Description Tool

References

  1. Kontis, V.; Bennett, J.E.; Mathers, C.D.; Li, G.; Foreman, K.; Ezzati, M. Future life expectancy in 35 industrialised countries: Projections with a Bayesian model ensemble. Lancet 2017, 389, 1323–1335. [Google Scholar] [CrossRef]
  2. United Nations. World Population Ageing 2017; Department of Economic and Social Affairs, Population Division: New York, NY, USA, 2017. [Google Scholar]
  3. van den Broek, G.; Cavallo, F.; Wehrmann, C. AALIANCE Ambient Assisted Living Roadmap; IOS Press: Amesterdam, The Netherlands, 2010; Volume 6. [Google Scholar]
  4. Blackman, S.; Matlo, C.; Bobrovitskiy, C.; Waldoch, A.; Fang, M.L.; Jackson, P.; Mihailidis, A.; Nygård, L.; Astell, A.; Sixsmith, A. Ambient assisted living technologies for aging well: A scoping review. J. Intell. Syst. 2016, 25, 55–69. [Google Scholar] [CrossRef]
  5. Calvaresi, D.; Cesarini, D.; Sernani, P.; Marinoni, M.; Dragoni, A.F.; Sturm, A. Exploring the ambient assisted living domain: A systematic review. J. Ambient Intell. Humaniz. Comput. 2017, 8, 239–257. [Google Scholar] [CrossRef]
  6. Queirós, A.; Silva, A.G.; Simões, P.; Santos, C.; Martins, C.; Pacheco da Rocha, N.; Rodrigues, M. SmartWalk: Personas and scenarios definition and functional requirements. In Proceedings of the TISHW 2018—The 2nd International Conference on Technology and Innovation in Sports, Health and Wellbeing, Thessaloniki, Greece, 20–22 June 2018. [Google Scholar]
  7. Rodrigues, M.; Santos, R.; Queirós, A.; Silva, A.G.; Amaral, J.; Jorge Gonçalves, L.; Pereira, A.; Pacheco da Rocha, N. Meet SmartWalk, Smart Cities for Active Seniors. In Proceedings of the TISHW 2018—The 2nd International Conference on Technology and Innovation in Sports, Health and Wellbeing, Thessaloniki, Greece, 20–22 June 2018. [Google Scholar]
  8. Chen, M.; Gonzalez, S.; Vasilakos, A.; Cao, H.; Leung, V.C. Body Area Networks: A Survey. Mob. Netw. Appl. 2011, 16, 171–193. [Google Scholar] [CrossRef]
  9. Aarmidor, J. How Embedded Sensors will Transform Workplace Performance, Employee Engagement, and Facility Management; CoWorkr and Haworth AP: Holland, MI, USA, 2017. [Google Scholar]
  10. Wilson, C.; Hargreaves, T.; Hauxwell-Baldwin, R. Benefits and risks of smart home technologies. Energy Policy 2017, 103, 72–83. [Google Scholar] [CrossRef]
  11. Sargano, A.B.; Angelov, P.; Habib, Z. A Comprehensive Review on Handcrafted and Learning-Based Action Representation Approaches for Human Activity Recognition. Appl. Sci. 2017, 7, 110. [Google Scholar] [CrossRef]
  12. Queirós, A.; Silva, A.; Alvarelhão, J.; Rocha, N.P.; Teixeira, A. Usability, accessibility and ambient-assisted living: A systematic literature review. Univ. Access Inf. Soc. 2015, 14, 57–66. [Google Scholar] [CrossRef]
  13. HOMER-HOMe Event Recognition System. Available online: http://homer.aaloa.org/ (accessed on 2 July 2020).
  14. Fuxreiter, T.; Mayer, C.; Hanke, S.; Gira, M.; Sili, M.; Kropf, J. A modular platform for event recognition in smart homes. In Proceedings of the The 12th IEEE International Conference on e-Health Networking, Applications and Services, Lyon, France, 1–3 July 2010; pp. 1–6. [Google Scholar]
  15. Austria, A.A.L. fit4AAL Pilot Region. Available online: http://www.aal.at/fit4aal/ (accessed on 2 July 2020).
  16. Research, S. Fit Mit ILSE. Available online: https://www.fit-mit-ilse.at/fragen-antworten/ (accessed on 2 July 2020).
  17. Blasco, R.; Marco, Á.; Casas, R.; Cirujano, D.; Picking, R. A Smart Kitchen for Ambient Assisted Living. Sensors 2014, 14, 1629–1653. [Google Scholar] [CrossRef]
  18. WHO. Ageing and Health. Available online: https://www.who.int/news-room/fact-sheets/detail/ageing-and-health (accessed on 2 July 2020).
  19. WHO. Dementia. Available online: https://www.who.int/news-room/fact-sheets/detail/dementia (accessed on 2 July 2020).
  20. Schneider, C.; Willner, V.; Feichtenschlager, M.; Andrushevich, A.; Spiru, L. Collecting User Requirements for Electronic Assistance for People with Dementia: A Case Study in Three Countries. In Proceedings of the eHealth 2013, Vienna, Austria, 23–24 May 2013. [Google Scholar]
  21. Project, H. Smart Home for Elderly People (HOPE). Available online: http://www.hope-project.eu/ (accessed on 2 July 2020).
  22. Consortium, H.P. HELP. Available online: http://www.aal-europe.eu/projects/help/ (accessed on 2 July 2020).
  23. WHO. Global Action Plan on the Public Health Response to Dementia 2017–2025. Available online: http://www.who.int/mental_health/neurology/dementia/action_plan_2017_2025/en/ (accessed on 2 December 2020).
  24. Ngandu, T.; Lehtisalo, J.; Solomon, A.; Levälahti, E.; Ahtiluoto, S.; Antikainen, R.; Bäckman, L.; Hänninen, T.; Jula, A.; Laatikainen, T.; et al. A 2 year multidomain intervention of diet, exercise, cognitive training, and vascular risk monitoring versus control to prevent cognitive decline in at-risk elderly people (FINGER): A randomised controlled trial. Lancet 2015, 385. [Google Scholar] [CrossRef]
  25. Coronato, A. Uranus: A middleware architecture for dependable AAL and vital signs monitoring applications. Sensors 2012, 12, 3145–3161. [Google Scholar] [CrossRef]
  26. Forkan, A.; Khalil, I.; Tari, Z. CoCaMAAL: A cloud-oriented context-aware middleware in ambient assisted living. Future Gener. Comput. Syst. 2014, 35, 114–127. [Google Scholar] [CrossRef]
  27. Ottoboni, G.; Gallelli, T.; Mariani, E.; Rebecca Soluri, V.; Nunziata, S.; Tessari, A.; Savary, J.P.; Chattat, R. Remote home physical training for seniors: Guidelines from the AAL-supported MOTION project. Eur. J. Ageing 2019, 16, 25–37. [Google Scholar] [CrossRef] [PubMed]
  28. Ganesan, B.; Gowda, T.; Al-Jumaily, A.; Fong, K.N.K.; Meena, S.K.; Tong, R.K.Y. Ambient assisted living technologies for older adults with cognitive and physical impairments: A review. Eur. Rev. Med. Pharmacol. Sci. 2019, 23, 10470–10481. [Google Scholar] [PubMed]
  29. Zschippig, C.; Kluss, T. Gardening in Ambient Assisted Living. Urban For. Urban Green. 2015, 15. [Google Scholar] [CrossRef]
  30. Casino, F.; Patsakis, C.; Batista, E.; Borras, F.; Ballesté, A. Healthy Routes in the Smart City: A Context-Aware Mobile Recommender. IEEE Softw. 2017, 34, 42–47. [Google Scholar] [CrossRef]
  31. Stocklöw, C.; Medrano, A.; Fides, A. UniversAAL Wiki. Available online: https://github.com/universAAL/platform/wiki (accessed on 2 July 2020).
  32. Ram, R.; Furfari, F.; Girolami, M.; Ibañez-Sánchez, G.; Lázaro-Ramos, J.P.; Mayer, C.; Prazak-Aram, B.; Zentek, T. UniversAAL: Provisioning platform for AAL services. In Ambient Intelligence-Software and Applications; Springer: Berlin/Heidelberg, Germany, 2013; pp. 105–112. [Google Scholar]
  33. Falcó, J.L.; Vaquerizo, E.; Artigas, J.I. A Multi-Collaborative Ambient Assisted Living Service Description Tool. Sensors 2014, 14, 9776–9812. [Google Scholar] [CrossRef]
  34. Kantoch, E.; Augustyniak, P.; Markiewicz, M.; Prusak, D. Monitoring activities of daily living based on wearable wireless body sensor network. In Proceedings of the 2014 36th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, Chicago, IL, USA, 26–30 August 2014; pp. 586–589. [Google Scholar]
  35. Siren Temperature Monitoring for Better Foot Care. Available online: https://siren.care/ (accessed on 2 July 2020).
  36. GmbH, Ambiotex Ambiotex Smart Shirt. Available online: https://www.ambiotex.com/ (accessed on 2 July 2020).
  37. Should You Trust Apple’s New Blood Oxygen Sensor? Available online: https://spectrum.ieee.org/view-from-the-valley/biomedical/devices/should-you-trust-apples-new-blood-oxygen-sensor (accessed on 16 December 2020).
  38. SpO2 and pulse ox Wearables: Why Blood Oxygen is the Big New Health Metric. Available online: https://www.wareable.com/wearable-tech/pulse-oximeter-explained-fitbit-garmin-wearables-340 (accessed on 16 December 2020).
  39. Fuller, D.; Colwell, E.; Low, J.; Orychock, K.; Tobin, M.A.; Simango, B.; Buote, R.; Van Heerden, D.; Luan, H.; Cullen, K.; et al. Reliability and validity of commercially available wearable devices for measuring steps, energy expenditure, and heart rate: Systematic review. JMIR mHealth uHealth 2020, 8, e18694. [Google Scholar] [CrossRef]
  40. Bender, C.G.; Hoffstot, J.C.; Combs, B.T.; Hooshangi, S.; Cappos, J. Measuring the fitness of fitness trackers. In Proceedings of the IEEE Sensors Applications Symposium (SAS 2017), Glassboro, NJ, USA, 13–15 March 2017; pp. 1–6. [Google Scholar] [CrossRef]
  41. Smartex Smartex Wearable Wellness System. Available online: http://www.smartex.it/en/our-products/232-wearable-wellness-system-wws (accessed on 2 July 2020).
  42. Piwek, L.; Ellis, D.A.; Andrews, S.; Joinson, A. The Rise of Consumer Health Wearables: Promises and Barriers. PLoS Med. 2016, 13, e1001953. [Google Scholar] [CrossRef]
  43. O’Donovan, T.; O’Donoghue, J.; Sreenan, C.; Sammon, D.; O’Reilly, P.; O’Connor, K.A. A context aware wireless body area network (BAN). In Proceedings of the 2009 3rd International Conference on Pervasive Computing Technologies for Healthcare, London, UK, 1–3 April 2009; pp. 1–8. [Google Scholar]
  44. Aguirre, E.; Led, S.; Lopez-Iturri, P.; Azpilicueta, L.; Serrano, L.; Falcone, F. Implementation of Context Aware e-Health Environments Based on Social Sensor Networks. Sensors 2016, 16, 310. [Google Scholar] [CrossRef]
  45. Khan, M.; Din, S.; Jabbar, S.; Gohar, M.; Ghayvat, H.; Mukhopadhyay, S.C. Context-aware low power intelligent SmartHome based on the Internet of things. Comput. Electr. Eng. 2016, 52, 208–222. [Google Scholar] [CrossRef]
  46. Li, A.; Liu, W.; Zhang, S.; Xi, M. Fast Multicast with Adjusting Transmission Power and Active Slots in Software Define IoT. IEEE Access 2020. [Google Scholar] [CrossRef]
  47. Sui, D.; Hu, F.; Zhou, W.; Shao, M.; Chen, M. Relay selection for radio frequency energy-harvesting wireless body area network with buffer. IEEE Internet Things J. 2017, 5, 1100–1107. [Google Scholar] [CrossRef]
  48. Liu, X.; Song, H.; Liu, A. Intelligent UAVs trajectory optimization from space-time for data collection in social networks. IEEE Trans. Netw. Sci. Eng. 2020. [Google Scholar] [CrossRef]
  49. Rajesh, M.; Gnanasekar, J.M. Path observation based physical routing protocol for wireless ad hoc networks. Wirel. Pers. Commun. 2017, 97, 1267–1289. [Google Scholar] [CrossRef]
  50. Shaobo, H.; Zeng, Z.; Ota, K.; Dong, M.; Wang, T.; Xiong, N. An Intelligent Collaboration Trust Interconnections System for Mobile Information Control in Ubiquitous 5G networks. IEEE Trans. Netw. Sci. Eng. 2020. [Google Scholar] [CrossRef]
  51. Hanif, U.; Abu-Tair, M.; McClean, S.; Nixon, P.; Parr, G.; Luo, C. Connecting Disjoint Nodes Through a UAV-Based Wireless Network for Bridging Communication Using IEEE 802.11 Protocols. EURASIP J. Wirel. Commun. Netw. 2020. [Google Scholar] [CrossRef]
  52. Rocha, N.P.; Dias, A.; Santinha, G.; Rodrigues, M.; Queirós, A.; Rodrigues, C. Smart Cities and Healthcare: A Systematic Review. Technologies 2019, 7, 58. [Google Scholar] [CrossRef]
  53. HL7 Organization FHIR Release 3 (STU). Available online: https://www.hl7.org/fhir/resourcelist.html (accessed on 2 December 2020).
  54. Dias, A.; Martins, A.I.; Queirós, A.; Rocha, N.P. Interoperability in Pervasive Health: A Systematic Review. In Proceedings of the International Joint Conference on Biomedical Engineering Systems and Technologies, Funchal, Madeira, Portugal, 19–21 January 2018; Springer: Cham, Switzerland, 2018; pp. 279–297. [Google Scholar] [CrossRef]
  55. Dey, A. Understanding and Using Context. Pers. Ubiquitous Comput. 2001, 5, 4–7. [Google Scholar] [CrossRef]
  56. Hofer, T.; Schwinger, W.; Pichler, M.; Leonhartsberger, G.; Altmann, J.; Retschitzegger, W. Context-awareness on mobile devices—The hydrogen approach. In Proceedings of the 36th Annual Hawaii International Conference on System Sciences, Big Island, HI, USA, 6–9 January 2003; p. 10. [Google Scholar]
  57. Prinsen, C.A.C.; Mokkink, L.B.; Bouter, L.M.; Alonso, J.; Patrick, D.L.; de Vet, H.C.W.; Terwee, C.B. COSMIN Guideline for Systematic Reviews of Patient-Reported Outcome Measures. Qual. Life Res. 2018, 27, 1147–1157. Available online: https://pubmed.ncbi.nlm.nih.gov/29435801/ (accessed on 2 December 2020). [CrossRef]
  58. Poushter, J. Smartphone Ownership and Internet Usage Continues to Climb in Emerging Economies; Benton Institute for Broadband & Society: Chicago, IL, USA, 2016. [Google Scholar]
  59. Vashist, S.K.; Luong, J.H. Commercially Available Smartphone-Based Personalized Mobile Healthcare Technologies. In Point-of-Care Technologies Enabling Next-Generation Healthcare Monitoring and Management; Springer: Cham, Switzerland, 2019; pp. 81–115. [Google Scholar]
  60. Google Distribution Dashboard. Available online: https://developer.android.com/about/dashboards (accessed on 2 July 2020).
  61. Cilfone, A.; Davoli, L.; Belli, L.; Ferrari, G. Wireless Mesh Networking: An IoT-Oriented Perspective Survey on Relevant Technologies. Future Internet 2019, 11, 99. [Google Scholar] [CrossRef]
  62. Casale, P.; Pujol, O.; Radeva, P. Human Activity Recognition from Accelerometer Data Using a Wearable Device. In Pattern Recognition and Image Analysis; Vitrià, J., Sanches, J.M., Hernández, M., Eds.; Springer: Berlin/Heidelberg, Germany, 2011; pp. 289–296. [Google Scholar]
  63. Google What is the Awareness API? Available online: https://developers.google.com/awareness/overview#context-types (accessed on 2 July 2020).
  64. Suárez-Albela, M.; Fraga-Lamas, P.; Fernández-Caramés, T.M. A Practical Evaluation on RSA and ECC-Based Cipher Suites for IoT High-Security Energy-Efficient Fog and Mist Computing Devices. Sensors 2018, 18, 3868. [Google Scholar] [CrossRef]
  65. Daemen, J.; Rijmen, V. The Design of Rijndael: AES-the Advanced Encryption Standard; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2013. [Google Scholar]
  66. Faiqurahman, M.; Novitasari, D.; Sari, Z. QoS Analysis Of Kinematic Effects For Bluetooth HC-05 And NRF24L01 Communication Modules On WBAN System. Kinet. Game Technol. Inf. Syst. Comput. Netw. Comput. Electron. Control 2019, 4, 187–196. [Google Scholar] [CrossRef]
  67. Bluetooth SIG, Inc. GATT Specifications. Available online: https://www.bluetooth.com/specifications/gatt/ (accessed on 2 July 2020).
  68. Profile Battery Usage with Batterystats and Battery Historian. Available online: https://developer.android.com/topic/performance/power/setup-battery-historian (accessed on 2 December 2020).
  69. Docker Dashboard. Available online: https://docs.docker.com/desktop/dashboard/ (accessed on 2 December 2020).
  70. Shammar, E.; Alhomdy, S.; Al-gabri, M. Mutual Interference Mitigation Schemes on Wireless Body Area Networks (WBANs): A Survey. Int. J. Comput. Technol. 2018, 5, 133–147. [Google Scholar]
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
A Flexible Fog Computing Design for Low-Power Consumption and Low Latency Applications
Previous
A Period-Aware Routing Method for IEEE 802.1Qbv TSN Networks
Next