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

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.

2. Related Work

AAL systems are currently being designed and implemented to improve the quality of life of older adults, be it in terms of health conditions or more general wellness conditions, and to increase or maintain their independence and autonomy, by minimizing the need for external support. One of the ways to introduce AAL systems without disrupting the lives of their potential users is by implementing intelligent buildings, which include the placement of sensors in strategic places and the installation of various automated devices. This approach allows for a high degree of customization, which means that different AAL systems can be integrated and tailored according to the needs of the inhabitants [10]. Most of these systems make use of context awareness (i.e., features to abstract and model the situation of a person, place, or object) in order to correctly identify different types of activities, or to detect daily patterns, abnormal behaviors, and emergency situations [11,12].

For older adults without major physical or mental deteriorations there are several solutions in terms of AAL and intelligent buildings. For instance, the Home Event Recognition System (HOMER) [13] is a platform that allows the integration and configuration of different types of home sensors and automation systems, independently of the buildings floor plans, to provide complex features (e.g., to detect in real time that a user has fallen and hasn’t gotten up, so that an alarm is activated [14]). Furthermore, the project Fit4All sought to use smart technologies to integrate healthy exercise into older adults’ daily lives both at home and outdoors, while also teaching them about topics related to health conditions and physical exercise [15,16].

Introducing AAL systems into a whole building would be an ideal solution, but it can entail a costly and complex implementation. Moreover, for a significant number of individuals a full-building implementation is not necessary. Introducing specific elements into the divisions where an older adult is more likely to require assistance can optimize the whole process. In this respect, the project Low Cost Advanced White Goods for a Longer Independent Life of Elderly People implemented a smart kitchen to facilitate the use of various appliances and to detect and respond to emergency situations [17]. Since the kitchen is a division where many key activities are performed (e.g., food preparation or doing the laundry), the existence of adequate AAL systems can promote older adults’ independence and autonomy without the need for the installation of other complex and less necessary systems.

However, as people age the risk of disease increases, physical or mental capacities decrease and several health conditions (e.g., hearing loss, cataracts and refractive errors, back and neck pain and osteoarthritis, chronic obstructive pulmonary disease, diabetes, depression, and dementia) become more common and more likely to appear concurrently [18], all of which might impair the ability to function independently. Of all diseases that affect older adults, the most damaging are the neurodegenerative diseases, as they not only cause the persons affected to become increasingly dependent on others, but also to overwhelm their caregivers [19]. The project Confidence sought to alleviate this burden by connecting sufferers of dementia to a network of care givers that could assist them in various situations, such as helping them to find their ways to specific destinations or helping them in emergencies, or by simply connecting them with someone to talk to [20]. Other projects have also focused on neurodegenerative diseases, such as the Smart Home for Elderly People (HOPE) [21], a European Community project designed for older adults with Alzheimer’s disease, or the Home-based Empowered Living for Parkinson Disease Patients (HELP) [22], which includes specific sensors to continuously monitor the health conditions of older adults and the progress of their diseases, deliver medication, report to clinicians, or automatically send alarms when emergencies occur [21,22].

Cognitive impairment conditions are recognized as a public health priority by the World Health Organization (WHO), which foresees the need to optimize the cognitive and physical activity of populations [23]. Cognitive and physical activity is an important preventive measure, as presented in [24], which reported a clinical trial involving two thousand persons and concluded that cognitive activity together with physical activity reduces the risk of developing dementia in the following two years by 10%. The literature includes several studies aiming at the development of AAL solutions to minimize the sedentarism of older adults [25,26,27,28,29,30]. In particular, [30] reported a context-aware recommender application that offers personalized recommendations of exercise routes to individuals according to real-time data from a smart city (e.g., air quality, ultraviolet radiation, wind speed, temperature, and precipitation) and envisages, in future research, the inclusion of wearables and body sensors to determine health conditions.

Lack of integration is a barrier to widespread use of AAL systems. While various types of technologies and devices are available to choose from, there is a lack of mechanisms that are able to integrate different compounds to provide a usable product in a simple and efficient way. To address this problem, different types of tools have been developed, such as Uranus [25], a middleware infrastructure that aims to provide a means for rapid prototyping of AAL systems and monitoring applications; Cloud-oriented Context-aware Middleware in Ambient Assisted Living (CoCaMAAL), a cloud-based middleware aiming to provide a service that analysis an AAL system’s raw data and, based on context, deliver back the correct response for the system to perform [26]; or the Universal Open Platform and Reference Architecture for Ambient Assisted Living (UniversAAL), an open platform that enables disparate Internet of Things (IoT) devices to communicate and work together in the same system, in spite of differences between them, such as the manufacturer, the type of standards used or the underlying technology. Since this platform is generic, it can be used for any type of IoT device, making their integration an easier and quicker affair and enabling a faster deployment of AAL systems, as shown in several pilot studies across Europe under the name Make it ReAAL (ReAAL) [31,32].

While it is important that different devices can communicate and collaborate, it is also important that the different AAL stakeholders can do the same in the design and implementation of specific solutions. From clinicians, developers, investors, and governmental authorities up to the users themselves, every stakeholder has different requirements and wants these requirements to be correctly specified so that optimal solution can be achieved. Therefore, there are tools such as the Zaragoza Ambient Assisted Services Description Tool (ZAAS-DT), which aims to assist in the design of AAL systems by helping participants understand the requirements and viewpoints of the different stakeholders [33].

Since AAL systems rely on sensory data, devices are required to obtain accurate data about users and the respective environment. A broad range of solutions were developed to gather these data, including wearable and body sensors interconnected by a communication network (i.e., a BAN) to monitor physiological parameters. For instance, the system presented in [34] includes a BAN composed of different types of sensors, each one capable of sensing a specific physiological signal, and a smartphone to aggregate the collected data and send them to a remote server.

By necessity, a BAN requires that various types of sensors are placed and correctly positioned on a person’s body. When the development stage of a project is finished and their results are in use, it becomes the user’s responsibility to correctly equip the BAN’s components, which means that it is necessary to make this step as easy as possible. For that purpose, the sensors are, when possible, embedded in pieces that are easy to put on and take off, such as bracelets, gloves, or clothes.

Most of these types of smart wearable devices are still very specialized and mostly used in scientific research, but wearable devices for consumers do exist, such as the Siren Socks that have sensors that continuously check the temperature of the feet for individuals with peripheral neuropathy [35], or the Ambiotex smart shirt designed for athletes [36], which collects fitness data through several embedded sensors and presents the data collected on the user’s smartphone, or various other commercially available wearable devices. Also, several options already exist on the market that can be used to count steps and heart rate (e.g., Fitbit, Mi Band or Garmin [37]) and they even come in a range of prices that make them affordable to most users. However, only a few come with the ability to also register the blood oxygen level and these can be expensive [38], making them unfit for low-cost solutions such as the one proposed in this article. Moreover, considering the reliability of commercially available devices, there is evidence of a considerable degree of variability in the results of different brands [39,40]. For instance, even though several devices have been shown to be capable of gathering step count and heart rate data, they do so within a largely variable margin of error for each brand [40]. This degree of variability makes those devices less than optimal for a situation in which a formal caregiver requires reliable and accurate data.

As these types of devices become more common and reliable, research and clinical trials will become less dependent on devices like the Smartex Wearable Wellness System (WWS) [41], which is available alongside other types of sensors through the VivoSense company, who use more actual consumer grade hardware to implement their solutions. This increases user acceptance and allows for a less error prone and faster release of the solutions. However, it is also necessary for these devices to be validated by independent and reliable sources, so that caregivers can be assured that the data collected are accurate and reliable [42].

Monitoring systems designed for healthcare purposes, namely for monitoring persons at risk, must be ready to respond to emergencies and respond to them correctly. A false positive, when a situation is reported as an emergency when it is not, might just be an annoyance on the short term, but repeated false positives bring the whole system’s reliability into question. False negatives, when an emergency is not reported as such, are even graver, because for the user it can be the reason for discomfort, injuries, unnecessary pain, or even, in extreme cases, death. With regard to this, one study [43] proposed a Context Aware Body Area Network (CABAN) that could collect several types of physiological parameters and correctly transmit them independently of the surrounding conditions. Moreover, the projects reported in [44,45] expanded the concept by creating systems that not only make use of the sensors of a BAN, but also a network of sensors installed across the user’s domiciles, which react autonomously to changing conditions, only disturbing users when their inputs are needed or to give them information.

One of the most significant limitations of Wireless Sensor Networks (WSNs), and thus of BANs, is that, by design, they rely on portable power and, as such, the time during which they can work is limited, since one of the most energy-consuming tasks is communication between nodes. As such, improvements are needed to optimize the way in which nodes communicate in order to improve overall energy efficiency [46], namely by harvesting the energy from received radio frequency signals [47] or improving how automated mobile devices collect data to optimize movement trajectories [48].

Another serious limitation is that a WSN often requires a connection to a remote server for data storage. When in use, a mobile WSN can operate in areas where it does not have coverage, which means that a device capable of connecting to other nearby devices to create communication relays will increase its connectivity in areas where it would normally be low [49]. This is only possible if the problems of trust and attack prevention are satisfactorily addressed [50]. Another possibility is using a network of Unmanned Aerial Vehicles (UAV) to serve as a communication bridge [51].

Although, there are studies aiming to promote physical activity among older adults [25,26,27,28,29,30], it should be emphasized that smart cities infrastructures have not been conveniently exploited [30,52]. Therefore, considering the existing scientific evidence, the SmartWalk project intends to contribute an AAL solution supported by the smart city paradigm to minimize the sedentarism of older adults together with the optimization of the opportunities for socialization. Another novelty is the remote supervision of formal caregivers such as physiotherapists. With regard to this, the Fast Healthcare Interoperability Resources (FHIR) [53] were considered to guarantee healthcare data interoperability, a concern that is absent in most implementations [54]. Moreover, in the development of a critical component of the project, the BAN, the connectivity between multiple BANs was considered as an important requirement to enable the possibility of multiple instances being controlled by a single smartphone. This was an important feature since older adults constitute a heterogeneous population group with different needs, life experiences, expectations, and personal factors, which means that different types of solutions supported by a broad range of mobile devices should be available.

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.

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.

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).

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).

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).

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. Battery usage.

Time in use	Battery Percentage Consumed by			Total Battery Drain	Sensors Used
	App	Screen	BLE
15 min	0.36%	0.63%	0.12%	1.86%	GPS
15 min	0.39%	0.68%	0.14%	1.74%	GPS and heart rate
30 min	0.71%	1.26%	0.20%	2.81%	GPS
30 min	0.74%	1.29%	0.20%	4.44%	GPS and heart rate
1 h	1.35%	2.40%	0.32%	3.94%	GPS
1 h	1.42%	2.45%	0.31%	7.70%	GPS and heart rate

, 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.

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.

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. Impact of connectivity failures.

Scenario	Initial Connection Status	Final Connection Status	Results
I	Connected	Connected	Map was loaded Collected data was sent to the server
II	Connected	Connected	Map was loaded Collected data was sent to the server
III	Disconnected	Connected	Map was loaded when connection was established Collected data was sent to server
IV	Connected	Disconnected	Map was loaded Collected data was stored in the smartphone
V	Disconnected	Disconnected	Map was not loaded Collected data was stored in the smartphone

) 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.

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. BLE coverage.

Max Distance	Obstructions	Average Reconnection Time		Bluetooth Version
		Sensor Restart	Out of Range
10.3 m	Two walls	15 s to 20 s	2 s to 5 s	4.0
12.2 m	Two walls	15 s to 20 s	2 s to 5 s	4.2
15.2 m	No obstructions	15 s to 20 s	2 s to 5 s	4.0
17.1 m	No obstructions	15 s to 20 s	2 s to 5 s	4.2

.

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.