# Self-Organizing Wearable Device Platform for Assisting and Reminding Humans in Real Time

Authors: Yu Jin Park; Ki Eun Seong; Seol Young Jeong; Soon Ju Kang
Journal: Mobile Information Systems
 (2016)

---

## Abstract

Most older persons would prefer “aging in my place,” that is, to remain in good health and live independently in their own home as long as possible. For assisting the independent living of older people, the ability to gather and analyze a user’s daily activity data would constitute a significant technical advance, enhancing their quality of life. However, the general approach based on centralized server has several problems such as the usage complexity, the high price of deployment and expansion, and the difficulty in identifying an individual person. To address these problems, we propose a wearable device platform for the life assistance of older persons that automatically records and analyzes their daily activity without intentional human intervention or a centralized server (i.e., cloud server). The proposed platform contains self-organizing protocols, Delay-Tolerant Messaging system, knowledge-based analysis and alerting for daily activities, and a hardware platform that provides low power consumption. We implemented a prototype smart watch, called Personal Activity Assisting and Reminding (PAAR), as a testbed for the proposed platform, and evaluated the power consumption and the service time of example scenarios.


---

## Body

## 1. Introduction

The aging baby boomers are causing a rapid increase in the older population, the size of which is already unprecedented in human history. Most older persons would prefer “aging in my place” that is, to remain in their own home as long as possible. According to a report, 90% of people over the age of 65 would prefer to remain in their current residence [1]. In order to maintain their good health and independent lifestyle, life-assisting technology is essential. Numerous Ambient Assisted Living (AAL) systems and devices have been proposed in various fields, such as smart homes, wearable devices, wireless sensor networks, and pervasive systems [2, 3].For the purpose of assisting the independent living of older or disabled people, the ability to gather and analyze a user’s daily activity data, such as usage of external appliances (“turn on gas oven,” “open door-lock,” and “measure blood pressure/weight”), would constitute a significant technical advance, enhancing their quality of life. In Figure1, two approaches for achieving this purpose are shown. In the first approach, technology based on a centralized server requires that many sensors and actuators be installed in the environment (such as the home or building). The gathered or analyzed data are then forwarded to the centralized server (i.e., a cloud service server or home network server). The second, a user-centered system, is a method that needs only a personalized wearable device; however, it is not easy to realize a life-logging system that involves neither infrastructure nor a server. Furthermore, the life-logging data, such as eating, sleeping, and using the bathroom, is very personal. However, most of the previously proposed systems for life-logging or healthcare need to be installed in the environment and are based on a centralized server [4]. This paper proposes a Personal Activity Assisting and Reminding (PAAR) platform to overcome the challenges of technology based on a wearable mobile device in a life-logging system.Figure 1
Two approaches to life assistance, based on (a) a centralized server and (b) a personal wearable device.
(a) (b)The effects of real-time life-logging care using only wearable devices without a centralized server can be summarized in two statements. The short-term effect is that the device can act as a PAAR device. The longer-term effect is that the wearable device can collect daily activities and vital sign information in real time and chronologically store these data, not in a hospital computer, but rather in a personal device such as smartphone. The technical problems that need to be addressed, however, are not straightforward and set challenges in terms of defining precisely not only the communication infrastructure but also the method of capturing the daily life activities in real time [5].To collect and analyze real-time activity data without the user’s intentional intervention [6], a new wearable device platform is required that includes specific functions for these purposes. The platform’s ability to be aware of a user’s situation in real time is essential. The capacity to identify external neighboring devices related to the user’s wearable device is also important. Moreover, functions for predicting a user’s behavior that allow the exchange of IDs between resource supply devices and the user’s wearable device through direct device-to-device (D2D) communication are also required. Furthermore, low power schemes are essential to ensure long operating periods, because the battery capacity of a wearable device is limited. Finally, because user-consistent intervention to operate the device is inconvenient from the user’s perspective, the creation of implicit human-computer interaction (HCI) is an important factor.To address these objectives, self-organized computing and communication concepts, including self-identification of external neighboring devices, self-D2D pairing and communication, self-awareness of indoor location, and delay-tolerant message delivery, are suggested and implemented in the proposed PAAR platform.The organization of this paper is as follows. In Section2, related works regarding smart healthcare systems for AAL are described. In Section 3, the objective of the PAAR platform is presented through a service for older persons. In Section 4, the proposed protocols and core functions and in Section 5 the knowledge-based analysis method in the PAAR platform is described. In Section 6, the implementation software and hardware are described and samples of the application activity history are presented. In Section 7, we present an implementation and performance evaluation discussion. In Section 8, we conclude and discuss future works.


## 2. Related Work

The AAL approach can improve the service efficiency and the quality of life of older people. In relation to this approach, technicians and sociologists are working together to find methods for integrating ICT in formal and informal sociomedical services for elderly persons [7]. The most common AAL system is a smart home-based system for older adults, consisting of ambient monitoring, behavior recognition, and feedback, to support self-management of wellness [8]. Smart home systems support the maintenance of independent living and quality of life of older adults. In the following studies, a smart home was designed, aimed mostly at enabling “aging in my place,” which recorded the residents’ living data. The TigerPlace [9] at the University of Missouri includes a network of wired and wireless sensors that monitor proximity and motion, listen for audio alerts made by the residents, measure vital signs using multiple sensors including bed sensors, track the resident’s gait using the Microsoft Kinect platform, and detect cooking patterns using temperature sensors. In the GatorTech Smart House system [10] at the University of Florida, a large number of sensors, including underfloor pressure sensors, automatic blinds, and smart beds, are combined and the system supports the remote monitoring of patients. In the CASAS Smart Home Project [11] at Washington State University, a three-bedroom apartment testbed was created, which allows data recorded from multiple sources, including motion sensors located approximately 1 m apart throughout the entire house, to be collected. Most of these systems need to be installed in the environment, such as the home or building, and are based on a centralized server (i.e., a home network server or cloud service server). However, the installation, configuration, and usage processes of these systems are cumbersome and expensive, because the specific house for a centralized server-based home network must be created in the design phase. Furthermore, some systems that support the detection of behavior patterns in the assisted living of older adults [12] based on a cloud system have faced a privacy issue.In addition, the wireless sensor networks studies on pervasive healthcare systems addressed information and alerting mechanisms in the case of abnormal conditions, with continuous monitoring to help older people lead an independent life [13]. The technology of Body Area Networks (BANs) for monitoring a person’s kinematics and physiological parameters is also being steadily researched. These network systems use a bio-signal sensor worn by the patient and a smartphone or another sensor node as a central node [14]. In another study on personalized mobile health monitoring [15], a health watch and smartphone applications to provide a user interface were proposed. However, their disadvantage is that they are difficult to use and inconvenient for older persons.As shown, the general AAL solution is environmental, and many homes and buildings are equipped with sensors and wireless/wired communication equipment [13]. This approach has several problems. The first is the usage complexity (in particular for older or disabled persons) and the high price of deployment and expansion. The second is more critical: it is difficult to identify an individual person. For example, we would like to determine who “turned the gas oven on.” The solution, however, is not easy. The approach of using a camera and face recognition has been suggested. However, this approach is overly complex and could cause serious privacy violations. New smart watches are being developed [16–18]; however, these devices do not overcome the identified problems and act only as an extension of more luxurious smartphones.With the rapid expansion of powerful smartphones, the wearable device-based solution is emerging as a viable alternative. It does, however, continue to face problems:(i)
A person may forget to wear the wearable device.(ii)
The wearable device may have a limited battery capacity; therefore, service storage occurs frequently because of the battery.(iii)
The majority of current wearable devices, including smart watches, use only an internal sensor (accelerometer) to detect vital signs and do not support direct peer-to-peer communication among external neighboring resource devices.(iv)
It is difficult to synchronize the wearable device and external service resource devices to provide prompt delivery of the activity information.In addition, the current systems for providing AAL to older persons based on ICT are less effective than expected. In order to solve these critical problems, studies that focus on people are required [19]. Therefore, this paper proposes a protocol and platform for interaction between a wearable device and communication module that require no extra installation of equipment. The suggested solution supports a user-friendly kit consisting of a communication module that can connect with the equipment that the user is utilizing, a location anchor node that can be placed at the desired point, and an individual wearable device to provide identity. The proposed platform contains no-setting and no-recognition self-organizing protocols, communication support for delay-tolerant message delivery, software architecture based on a Real-Time Operating System (RTOS), knowledge-based analysis and alerting for daily activities, a hardware platform that provides low power consumption, and smartphone applications providing a user interface.


## 3. Service Scenario and Design Considerations

### 3.1. Proposed Service Scenario: Wearable Device-Based Life-Logging Care

Figure2 shows a service scenario example that illustrates the process of collecting the user’s daily life activities through a wearable device. A user wearing the PAAR watch presses the digital door-lock button. The door-lock wakes the PAAR watch, which is in sleep mode and verifies the watch’s ID. If the ID is registered, (1) the door-lock opens and the arrival activity is sent to the watch. (7) The same procedure is followed when the device wearer enters or leaves the house. After passing through a door, the watch awakens and announces its presence by sending its ID to a special stationary node called a location anchor (LA) node. Through this process, the PAAR watch receives and saves its location information (living room) from the LA node. (3) If the user measures his/her blood pressure, the watch automatically receives and saves the activity data (value of blood pressure) from the measurement. At the time when the user needs to take medicine, a medication alarm message sent by the smart pill reminder function is shown on the watch’s display. (5) The user reads this message and moves to the bedroom from the living room to take the medicine. The changed location data are sent to the user’s watch and saved from the LA node. In addition, when the user turns on a gas oven or a light, these activities are also recorded in the user’s watch. If the user leaves the house without turning off the gas oven or light, the PAAR watch displays an alert message. The user can transmit all the activity data retained in the PAAR watch to his/her smartphone for storage and analyze the chronologically sorted data for a longer period. The data managed in the user’s smartphone application can be sent and stored periodically or when needed to the LA node for the private cloud server.Figure 2
PAAR watch service scenario as a personal activity black box.In Figure2, the user is not required to enter any commands or settings to the PAAR watch. The user can collect the activity data merely by wearing the PAAR during his/her daily life. This is possible by virtue of the watch’s tasks that can directly communicate with neighboring resource devices (e.g., door-lock, body scale, and pill reminder) and can recognize the user’s indoor location. These processes, localizing and communicating, are autonomously performed by the PAAR watch. In the event that the user is not wearing the watch, the concept of a delay-tolerant communication method with an LA node can be exploited.


### 3.2. Design Considerations

In the preceding service scenario, shown in Figure2, it should be remembered that older people are unfamiliar with IT technology and may be inept at operating ICT devices. Therefore, a wearable device needs to communicate directly with external modules or activity measuring tools and gather/store the information itself or send it to a smartphone without intentional human intervention.To realize the functions identified in Section3.1, the following technical issues must be resolved.(1)
Identification of the neighboring devices must be possible without any configuration of the user’s wearable device. For this purpose, a precise physical proximity (distance) measurement solution must be found to limit the identification range of neighboring devices.(2)
A well-known wireless communication protocol (Bluetooth) used in wearable devices must always assign communication roles to each party before pairing. For example, the host-role device always scans the advertising message (beacon) and the slave-role device always sends the beacon. Role assignment in the proposed approach must be performed autonomously and automatically.(3)
Opportunistic computing means that when the service, time, and location are simultaneously matched, then the service computing and communication should be implemented.(4)
In an indoor environment, location-awareness of the wearable device itself is not easy to implement. An additional stationary device, such as Apple’s iBeacon tag [20], is required as the LA node.(5)
Ultrashort service time: the service between the service provider and demander must be completed within a short period. If the service time is extended beyond this time, the user will be required to wait.In addition, all services and information need to be protected from an outside system or attack, because very personal data, such as eating, sleeping, and using the bathroom, are involved. Therefore, these personal data should be accessible only within the user’s living space or on the user’s wearable device, and the user should read and find a simple alarm or reminder message on his/her wearable device. If necessary, such as in emergency situations, the emergency data are forwarded to the required institutions (i.e., hospital, police office, fire station, or other families).


## 3.1. Proposed Service Scenario: Wearable Device-Based Life-Logging Care

Figure2 shows a service scenario example that illustrates the process of collecting the user’s daily life activities through a wearable device. A user wearing the PAAR watch presses the digital door-lock button. The door-lock wakes the PAAR watch, which is in sleep mode and verifies the watch’s ID. If the ID is registered, (1) the door-lock opens and the arrival activity is sent to the watch. (7) The same procedure is followed when the device wearer enters or leaves the house. After passing through a door, the watch awakens and announces its presence by sending its ID to a special stationary node called a location anchor (LA) node. Through this process, the PAAR watch receives and saves its location information (living room) from the LA node. (3) If the user measures his/her blood pressure, the watch automatically receives and saves the activity data (value of blood pressure) from the measurement. At the time when the user needs to take medicine, a medication alarm message sent by the smart pill reminder function is shown on the watch’s display. (5) The user reads this message and moves to the bedroom from the living room to take the medicine. The changed location data are sent to the user’s watch and saved from the LA node. In addition, when the user turns on a gas oven or a light, these activities are also recorded in the user’s watch. If the user leaves the house without turning off the gas oven or light, the PAAR watch displays an alert message. The user can transmit all the activity data retained in the PAAR watch to his/her smartphone for storage and analyze the chronologically sorted data for a longer period. The data managed in the user’s smartphone application can be sent and stored periodically or when needed to the LA node for the private cloud server.Figure 2
PAAR watch service scenario as a personal activity black box.In Figure2, the user is not required to enter any commands or settings to the PAAR watch. The user can collect the activity data merely by wearing the PAAR during his/her daily life. This is possible by virtue of the watch’s tasks that can directly communicate with neighboring resource devices (e.g., door-lock, body scale, and pill reminder) and can recognize the user’s indoor location. These processes, localizing and communicating, are autonomously performed by the PAAR watch. In the event that the user is not wearing the watch, the concept of a delay-tolerant communication method with an LA node can be exploited.


## 3.2. Design Considerations

In the preceding service scenario, shown in Figure2, it should be remembered that older people are unfamiliar with IT technology and may be inept at operating ICT devices. Therefore, a wearable device needs to communicate directly with external modules or activity measuring tools and gather/store the information itself or send it to a smartphone without intentional human intervention.To realize the functions identified in Section3.1, the following technical issues must be resolved.(1)
Identification of the neighboring devices must be possible without any configuration of the user’s wearable device. For this purpose, a precise physical proximity (distance) measurement solution must be found to limit the identification range of neighboring devices.(2)
A well-known wireless communication protocol (Bluetooth) used in wearable devices must always assign communication roles to each party before pairing. For example, the host-role device always scans the advertising message (beacon) and the slave-role device always sends the beacon. Role assignment in the proposed approach must be performed autonomously and automatically.(3)
Opportunistic computing means that when the service, time, and location are simultaneously matched, then the service computing and communication should be implemented.(4)
In an indoor environment, location-awareness of the wearable device itself is not easy to implement. An additional stationary device, such as Apple’s iBeacon tag [20], is required as the LA node.(5)
Ultrashort service time: the service between the service provider and demander must be completed within a short period. If the service time is extended beyond this time, the user will be required to wait.In addition, all services and information need to be protected from an outside system or attack, because very personal data, such as eating, sleeping, and using the bathroom, are involved. Therefore, these personal data should be accessible only within the user’s living space or on the user’s wearable device, and the user should read and find a simple alarm or reminder message on his/her wearable device. If necessary, such as in emergency situations, the emergency data are forwarded to the required institutions (i.e., hospital, police office, fire station, or other families).


## 4. Element Protocols and Middleware of PAAR Platform

### 4.1. Overview of Element Protocols

To resolve the design considerations described in Section3.2, a special software/hardware platform and protocols for wearable devices must be implemented. In the proposed service scenario, there is an ID authentication process for entering the house and a data transferal process when measuring health data. If these processes are implemented using an RF module (e.g., Zigbee or Bluetooth) alone, the RF module must always be turned on or the user must turn it on for every operation. The former case would increase the power consumption of the devices and the latter case is inconvenient and annoying. Moreover, if there are more than two mobile devices near the resource device, then it is impossible to determine which device is the counterpart of this communication. To solve these problems, we suggest two methods: short range (~5 m) 125 KHz low frequency- (LF-) based self-identification and gesture recognition using an accelerometer. We use a smartphone as permanent storage for the daily life activity data. Finally, the analysis and evaluation of the personal activity and vital signs must be automatically performed by the mobile application under the iOS or Android platform.We implemented the following protocols to solve the problems. These protocols and mechanisms are discussed in their context in the following sections.(1) LF Wake-Up-Based Self-D2D Communication. The user’s wearable device should be able to automatically and directly communicate with resource devices (i.e., electronic appliances). In addition, the battery capacity and resources of the wearable device are in general limited. Therefore, we need to realize the concept of opportunistic computing and self-identification of neighboring devices according to their proximity, while maintaining low power consumption.(2) Gesture-Based Activity Recognition. The wearable device should support inference and recognition of the user’s activity patterns through the gyro sensor and accelerometer in the PAAR watch. This ability also requires a low power mechanism (i.e., wake-up by user’s gesture activity).(3) Life-Logging Activity without a Wearable Device. If the user is not wearing the wearable device, his/her activity should be also forwarded to his/her PAAR watch, which has been forgotten somewhere in the house, or to another user’s smartphone.


### 4.2. LF Wake-Up-Based Self-Device-to-Device Communication

For implementing the self-organizing direct D2D communication, we adopt a hardware-based wake-up method that includes a software-based D2D communication protocol, called proximity-based neighbor identification protocol (PNIP). A hardware-based wake-up module (shown in the circle in Figure3) must be installed in each of the service resource devices, such as the door-lock, car, and coffee machine. A wake-up receiver chip must be installed in the target wearable devices, such as the watch.Figure 3
Overview of proximity-based neighbor identification protocol.The most important function for implementing the PNIP is a method to wake the system from sleep mode wirelessly. The method we selected uses an LF module. We chose LF because of its high reliability. As compared with the 2.4 GHz high frequency band, it is better to use LF even when obstacles, such as human bodies, exist nearby. The LF module generates and sends a preamble signal pattern to neighboring devices. One or more devices successfully receive the preamble pattern from the LF sender chip, and then the receiver chip interrupts the main MCU. Utilizing an LF receiver chip that can receive the predefined preamble pattern from the transmitter, the PAAR watch awakens and begins to exchange the data. Because of this mechanism, the PAAR device can always be in deep sleep mode, thus facilitating ultralow power consumption.Without the user’s intervention, the wearable device itself must be able to identify neighboring devices with which to communicate. Because of the power consumption issue, it is impossible to scan neighboring devices constantly. Our strategy is that when a user attempts to use any resource device (e.g., performs the activity “press start button of the resource device”), the resource device broadcasts the LF wake-up signal, including its ID, to devices located in a predefined service range, shown in Figure4. If a wearable device receives the wake-up signal, it awakens and sends a reply packet to the resource device. In the reply packet, the ID and Received Signal Strength Indicator (RSSI) value of the LF source device are included. The resource device gathers all the reply packets from the neighboring devices and determines which is the counterpart of this communication.Figure 4
LF wake-up-based proximity-based neighbor identification protocol. (a) Service range determination using Received Signal Strength Indicator; (b) sequence diagram of the protocol.
(a) (b)By this mechanism, the user’s activity data that involve external devices (such as the gas oven, door-lock, car, and light) are collected in the user’s PAAR watch. The collected data are stored and analyzed in the form of knowledge-based data. Examples of the data are as follows:Activity (user_id, dev_id, “gas_oven”, “ON”, time)Activity (user_id, dev_id, “door_lock”, “IN”, time)Activity (user_id, dev_id, “light”, “ON”, time)These knowledge-based data in the PAAR watch are used to infer an emergency situation and to alert the user to danger.


### 4.3. Gesture-Based Activity Recognition

As shown in a previous study [21], the PAAR watch can recognize the user’s behavior pattern from the sensing data, such as that of the gyro sensor and accelerometer inside the watch. In accordance with changes in the sensor value, the PAAR watch analyzes and stores the user’s activities, such as sleeping, walking, and running.In addition, in the LF-based wake-up method, an LF wake-up module must be installed in all resource devices, as shown in Figure3. Because of the high voltage required and the LF transmitter module size, it is difficult to insert it into the watch. Therefore, we applied a gesture recognition-based PNIP by using the accelerometer inside the watch. This service is activated by a gesture pattern, such as that of waving or shaking hands when two people meet. PNIP with gesture recognition is activated using the collected motion data and surrounding information, such as a specific place or context. If the PAAR watch detects a particular gesture pattern or surrounding information that satisfies defined conditions, the protocol begins. When the gesture has been recognized, each device attempts to determine its role. If the role of each device can be determined, the service begins. This protocol is used for ID exchange between wearable devices (watches).Examples of the activity data according to the analysis of the sensing value or the gesture recognition are as follows:Activity (user_id, “walking”, time_from, time_to)Activity (user_id, “sleeping”, time_from, time_to)Activity (user_id, “meeting”, time)


### 4.4. Life-Logging Activity without Wearable Identification Device

Using the previous two PNIP protocols, the PAAR watch can gather the user’s activity data, but it is difficult to ensure that the users inside the house are always wearing the wearable watch. Therefore, the user’s activity should be forwarded to a PAAR watch at a distance from the user or to another user (guardian) who can receive the data, as shown in Figure5.Figure 5
Process of storing user’s life-logging activity without the PAAR watch.Examples of the forwarded activity data according to the other user’s behavior are as follows:Activity (null, dev_id, “gas_oven”, “ON”, time)Activity (null, dev_id, “door_lock”, “IN”, time)Activity (null, dev_id, “light”, “ON”, time)To allow this message to be forwarded to the target, the location of the running resource device, the target PAAR watch, or the target smartphone is always recognized in the house. To resolve the issues of the location-awareness in the indoor environment and the delay-tolerant delivery of activity information to the target wearable device, an architecture and mechanism that allow a service or resource to be discovered and bound with the target are required [22]. In order to indicate the location, an LA node must be installed in each unit space (e.g., room, bedroom, kitchen, and floor) of the indoor area that the user feels requires a location indicator, as shown in Figure 2. The iBeacon [20] produced by Apple, which uses a similar approach, broadcasts the advertising beacon from the stationary node only. In contrast, in the proposed approach the LA node scans the advertising beacon from the wearable devices to preserve the power saving mode of the watch. Further, it is equipped with temporary storage to acquire an activity message of an anonymous user (a user not wearing the wearable device) who performed an activity (e.g., “turned the gas oven on”). The activity is never sent to the user’s wearable device, because the PNIP cannot find the target watch; the data are stored temporarily in the LA node. If a wearable device is identified in the location, then the LA node automatically pushes the message to the watch. To implement this approach, we designed special hardware for the LA node and designed protocols for this functionality, called extended location ID exchange (eLiDx) and Delay-Tolerant Messaging (DTM).Figure6 shows the sequence diagram of eLiDx, an extended version of our LiDx protocol [23] for indoor location-awareness. In this protocol, an LA node, as a stationary node, is located in every unit space. It estimates the location of every advertising beacon from the wearable or resource devices by comparing the strength of the RSSI value of the RF signal. The LA node periodically scans advertising messages (beacons) from wearable and resource devices and compares the RSSI value of the wearable mobile devices and the resource devices permanently located in the unit space. Because each LA node has a predefined location ID for the unit space, it can send location ID beacons to the wearable or resource devices, even when it is the first time that it has received the advertising beacon.Figure 6
Sequence diagram of location ID exchange.In Figure7, the sequence diagram of the DTM protocol is shown. It is designed to function when the user is not wearing the wearable device. We use the PNIP protocol to collect the user’s daily activity data in real time and the user is expected to wear the wearable device to initiate the PNIP with the resource devices. If the user is not wearing the wearable device and performs an activity, then the resource device attempts to identify the neighboring device and fails. In this situation, we execute a probabilistic method. Although he/she is not wearing the watch, the probability of the watch’s presence near the user’s location is high. Therefore, the resource device sends an activity message to the LA node. The LA node pushes the message to the wearable devices that are logically connected in the LA node’s coverage space. Multiple wearable devices can receive the activity message simultaneously. If there are no devices, the LA node temporarily stores the message until a wearable device is encountered.Figure 7
Sequence diagram of Delay-Tolerant Messaging.Figure8 shows a timeline between LA node and mobile node which performs eLiDx and DTM protocol. In the proposed platform, we need to control active and sleep period of radio to guarantee longer operating time. As shown in the figure, both LA node and wearable or resource devices periodically turn on/off the RF communication module to minimize power consumption. A wearable or resource device sends eLiDx beacon to LA node. LA node collects the beacons and sends location ID beacon. In addition, wearable or resource devices periodically send a DTM request message to LA node. If LA receives DTM message from other devices, the LA stores the message until it receives a DTM request from the target device. The stored DTM messages in the LA node are transferred to the target node when LA node successfully receives the DTM request message.Figure 8
Timeline of location ID exchange and Delay-Tolerant Messaging.


## 4.1. Overview of Element Protocols

To resolve the design considerations described in Section3.2, a special software/hardware platform and protocols for wearable devices must be implemented. In the proposed service scenario, there is an ID authentication process for entering the house and a data transferal process when measuring health data. If these processes are implemented using an RF module (e.g., Zigbee or Bluetooth) alone, the RF module must always be turned on or the user must turn it on for every operation. The former case would increase the power consumption of the devices and the latter case is inconvenient and annoying. Moreover, if there are more than two mobile devices near the resource device, then it is impossible to determine which device is the counterpart of this communication. To solve these problems, we suggest two methods: short range (~5 m) 125 KHz low frequency- (LF-) based self-identification and gesture recognition using an accelerometer. We use a smartphone as permanent storage for the daily life activity data. Finally, the analysis and evaluation of the personal activity and vital signs must be automatically performed by the mobile application under the iOS or Android platform.We implemented the following protocols to solve the problems. These protocols and mechanisms are discussed in their context in the following sections.(1) LF Wake-Up-Based Self-D2D Communication. The user’s wearable device should be able to automatically and directly communicate with resource devices (i.e., electronic appliances). In addition, the battery capacity and resources of the wearable device are in general limited. Therefore, we need to realize the concept of opportunistic computing and self-identification of neighboring devices according to their proximity, while maintaining low power consumption.(2) Gesture-Based Activity Recognition. The wearable device should support inference and recognition of the user’s activity patterns through the gyro sensor and accelerometer in the PAAR watch. This ability also requires a low power mechanism (i.e., wake-up by user’s gesture activity).(3) Life-Logging Activity without a Wearable Device. If the user is not wearing the wearable device, his/her activity should be also forwarded to his/her PAAR watch, which has been forgotten somewhere in the house, or to another user’s smartphone.


## 4.2. LF Wake-Up-Based Self-Device-to-Device Communication

For implementing the self-organizing direct D2D communication, we adopt a hardware-based wake-up method that includes a software-based D2D communication protocol, called proximity-based neighbor identification protocol (PNIP). A hardware-based wake-up module (shown in the circle in Figure3) must be installed in each of the service resource devices, such as the door-lock, car, and coffee machine. A wake-up receiver chip must be installed in the target wearable devices, such as the watch.Figure 3
Overview of proximity-based neighbor identification protocol.The most important function for implementing the PNIP is a method to wake the system from sleep mode wirelessly. The method we selected uses an LF module. We chose LF because of its high reliability. As compared with the 2.4 GHz high frequency band, it is better to use LF even when obstacles, such as human bodies, exist nearby. The LF module generates and sends a preamble signal pattern to neighboring devices. One or more devices successfully receive the preamble pattern from the LF sender chip, and then the receiver chip interrupts the main MCU. Utilizing an LF receiver chip that can receive the predefined preamble pattern from the transmitter, the PAAR watch awakens and begins to exchange the data. Because of this mechanism, the PAAR device can always be in deep sleep mode, thus facilitating ultralow power consumption.Without the user’s intervention, the wearable device itself must be able to identify neighboring devices with which to communicate. Because of the power consumption issue, it is impossible to scan neighboring devices constantly. Our strategy is that when a user attempts to use any resource device (e.g., performs the activity “press start button of the resource device”), the resource device broadcasts the LF wake-up signal, including its ID, to devices located in a predefined service range, shown in Figure4. If a wearable device receives the wake-up signal, it awakens and sends a reply packet to the resource device. In the reply packet, the ID and Received Signal Strength Indicator (RSSI) value of the LF source device are included. The resource device gathers all the reply packets from the neighboring devices and determines which is the counterpart of this communication.Figure 4
LF wake-up-based proximity-based neighbor identification protocol. (a) Service range determination using Received Signal Strength Indicator; (b) sequence diagram of the protocol.
(a) (b)By this mechanism, the user’s activity data that involve external devices (such as the gas oven, door-lock, car, and light) are collected in the user’s PAAR watch. The collected data are stored and analyzed in the form of knowledge-based data. Examples of the data are as follows:Activity (user_id, dev_id, “gas_oven”, “ON”, time)Activity (user_id, dev_id, “door_lock”, “IN”, time)Activity (user_id, dev_id, “light”, “ON”, time)These knowledge-based data in the PAAR watch are used to infer an emergency situation and to alert the user to danger.


## 4.3. Gesture-Based Activity Recognition

As shown in a previous study [21], the PAAR watch can recognize the user’s behavior pattern from the sensing data, such as that of the gyro sensor and accelerometer inside the watch. In accordance with changes in the sensor value, the PAAR watch analyzes and stores the user’s activities, such as sleeping, walking, and running.In addition, in the LF-based wake-up method, an LF wake-up module must be installed in all resource devices, as shown in Figure3. Because of the high voltage required and the LF transmitter module size, it is difficult to insert it into the watch. Therefore, we applied a gesture recognition-based PNIP by using the accelerometer inside the watch. This service is activated by a gesture pattern, such as that of waving or shaking hands when two people meet. PNIP with gesture recognition is activated using the collected motion data and surrounding information, such as a specific place or context. If the PAAR watch detects a particular gesture pattern or surrounding information that satisfies defined conditions, the protocol begins. When the gesture has been recognized, each device attempts to determine its role. If the role of each device can be determined, the service begins. This protocol is used for ID exchange between wearable devices (watches).Examples of the activity data according to the analysis of the sensing value or the gesture recognition are as follows:Activity (user_id, “walking”, time_from, time_to)Activity (user_id, “sleeping”, time_from, time_to)Activity (user_id, “meeting”, time)


## 4.4. Life-Logging Activity without Wearable Identification Device

Using the previous two PNIP protocols, the PAAR watch can gather the user’s activity data, but it is difficult to ensure that the users inside the house are always wearing the wearable watch. Therefore, the user’s activity should be forwarded to a PAAR watch at a distance from the user or to another user (guardian) who can receive the data, as shown in Figure5.Figure 5
Process of storing user’s life-logging activity without the PAAR watch.Examples of the forwarded activity data according to the other user’s behavior are as follows:Activity (null, dev_id, “gas_oven”, “ON”, time)Activity (null, dev_id, “door_lock”, “IN”, time)Activity (null, dev_id, “light”, “ON”, time)To allow this message to be forwarded to the target, the location of the running resource device, the target PAAR watch, or the target smartphone is always recognized in the house. To resolve the issues of the location-awareness in the indoor environment and the delay-tolerant delivery of activity information to the target wearable device, an architecture and mechanism that allow a service or resource to be discovered and bound with the target are required [22]. In order to indicate the location, an LA node must be installed in each unit space (e.g., room, bedroom, kitchen, and floor) of the indoor area that the user feels requires a location indicator, as shown in Figure 2. The iBeacon [20] produced by Apple, which uses a similar approach, broadcasts the advertising beacon from the stationary node only. In contrast, in the proposed approach the LA node scans the advertising beacon from the wearable devices to preserve the power saving mode of the watch. Further, it is equipped with temporary storage to acquire an activity message of an anonymous user (a user not wearing the wearable device) who performed an activity (e.g., “turned the gas oven on”). The activity is never sent to the user’s wearable device, because the PNIP cannot find the target watch; the data are stored temporarily in the LA node. If a wearable device is identified in the location, then the LA node automatically pushes the message to the watch. To implement this approach, we designed special hardware for the LA node and designed protocols for this functionality, called extended location ID exchange (eLiDx) and Delay-Tolerant Messaging (DTM).Figure6 shows the sequence diagram of eLiDx, an extended version of our LiDx protocol [23] for indoor location-awareness. In this protocol, an LA node, as a stationary node, is located in every unit space. It estimates the location of every advertising beacon from the wearable or resource devices by comparing the strength of the RSSI value of the RF signal. The LA node periodically scans advertising messages (beacons) from wearable and resource devices and compares the RSSI value of the wearable mobile devices and the resource devices permanently located in the unit space. Because each LA node has a predefined location ID for the unit space, it can send location ID beacons to the wearable or resource devices, even when it is the first time that it has received the advertising beacon.Figure 6
Sequence diagram of location ID exchange.In Figure7, the sequence diagram of the DTM protocol is shown. It is designed to function when the user is not wearing the wearable device. We use the PNIP protocol to collect the user’s daily activity data in real time and the user is expected to wear the wearable device to initiate the PNIP with the resource devices. If the user is not wearing the wearable device and performs an activity, then the resource device attempts to identify the neighboring device and fails. In this situation, we execute a probabilistic method. Although he/she is not wearing the watch, the probability of the watch’s presence near the user’s location is high. Therefore, the resource device sends an activity message to the LA node. The LA node pushes the message to the wearable devices that are logically connected in the LA node’s coverage space. Multiple wearable devices can receive the activity message simultaneously. If there are no devices, the LA node temporarily stores the message until a wearable device is encountered.Figure 7
Sequence diagram of Delay-Tolerant Messaging.Figure8 shows a timeline between LA node and mobile node which performs eLiDx and DTM protocol. In the proposed platform, we need to control active and sleep period of radio to guarantee longer operating time. As shown in the figure, both LA node and wearable or resource devices periodically turn on/off the RF communication module to minimize power consumption. A wearable or resource device sends eLiDx beacon to LA node. LA node collects the beacons and sends location ID beacon. In addition, wearable or resource devices periodically send a DTM request message to LA node. If LA receives DTM message from other devices, the LA stores the message until it receives a DTM request from the target device. The stored DTM messages in the LA node are transferred to the target node when LA node successfully receives the DTM request message.Figure 8
Timeline of location ID exchange and Delay-Tolerant Messaging.


## 5. Knowledge-Based Activity Analysis and Alarming

By analyzing the daily activity data that are stored inside the wearable device in real time, indoor accidents can be prevented. For example, if a user turns on the gas oven and forgets and leaves the house, the user’s watch senses this situation and generates an alert message to him/her in real time. Although this appears to be a simple and easy service, the effect of ensuring the safety of the older or disabled person in his/her daily life is significant and can prevent accidents in the home.To realize this service, we designed a knowledge-based Activity Interpreter Engine (AIE) as a core component of the proposed software platform. Figure9 illustrates the process of interpreting the activity log by task. To allow the automatic interpretation of the activity list, the interpretation rules for target activities and the alerting methods must be defined via a smartphone application or similar activity.Figure 9
Procedure to identify fault activity in real time.Table1 presents a sample of the rules for activating an alert related to real-time activities. For example, when a user turns on the gas oven, “the gas oven is turned on” activity is stored in the activity list. And then, the AIE interprets it using the predefined rules. If the current activity set matches the alerting condition, the watch periodically alerts the user with a vibration and pop-up window. For stronger alerting, the message is sent to the application on the user’s smartphone. If two alerting messages occur at the same time, the higher priority alert is shown first. For example, the alert about the gas oven has a higher priority than the message about the coffee machine; the user can set the priority of each activity.Table 1
Rule table to interpret the fault activities.
Activity category Triggering/free condition Alerting timeout condition (user presetting) Alerting activity condition Gas oven Turn on/off 30–60 min Outgoing door-lock on Faucet Turn on/off 10–30 min Outgoing door-lock on Coffee machine Turn on/offNumber of activations 30–60 min Exceeds 5 cups per day Car Engine on/off — Car door open Boiler Turn on/off — Outgoing door-lock on Lighting Turn on/off — Outgoing door-lock on Pill box Turn off/on Predefined time schedule Scheduled time exceeded Fitness Turn on/off Predefined time schedule Scheduled time exceeded Toothbrush (motorized) Turn off/on Predefined time schedule Scheduled time exceeded Toilet Sensing weight/handling activity −10 min Exit bathroom Cabinet door On/off −10 min Proximity distance more than 10 mInside the PAAR watch, which includes an AIE with a forward chaining strategy, all activities are evaluated according to the condition part of the first rule. If the condition is met, the PAAR watch performs actions in accordance with action rules, such as activating an alert or alarm, as shown in Figure10. Figure 11 shows the rules, activities, and conditions listed in Table 1 and the data flow using forward chaining in the AIE.Figure 10
Hierarchy architecture of the rules and activities in the knowledge-based Activity Interpreter Engine.Figure 11
Activity rules and data flow using forward chaining.


## 6. Implementation of PAAR Platform

### 6.1. Software Architecture

Figure12 shows the layered software architecture of the proposed PAAR platform. The platform concentrates on minimizing required user intervention. The proposed platform is divided into three primary layers. The lowest level, the operating system (OS) layer, is composed of the RTOS kernel and Board Support Package (BSP). The middle level, the system layer, provides the core and managing functions. The highest level, the applications layer, provides direct services.Figure 12
Procedure to identify fault activity in real time.The most important characteristic of this platform is the realization of the implicit HCI, implying that the user is never required to provide intentional intervention to the wearable device. For this reason, all the software components, including PNIP, eLiDx, and DTM, are developed at the top of the UBINOS RTOS. UBINOS [24] was developed by our research team for resource-constrained devices such as wearable devices.


### 6.2. PAAR Watch Prototype

As illustrated in Figure13(a), the proposed hardware architecture is similar to that of the recently developed RTOS-based smart watch platforms [16]; however, it is significantly different from Google’s Android [17]. One of the distinguishing components is the LF wake-up receiver for implementing the PNIP protocols on a hardware basis. Figure 13(b) illustrates the actual shape of the prototype version of the PAAR watch, including the glucose measurer. In particular, the daily management of glucose measured values is very important for people suffering from diabetes, and therefore we incorporated the glucose measurer in the wearable smart watch that can always carry it.Figure 13
Implemented hardware of the PAAR watch platform. (a) Hardware architecture diagram; (b) actual shape of the prototype.
(a) (b)


### 6.3. Application of Activity Record

In this section, we describe the diverse usage of activity data that are collected by the self-D2D communication with the external resource devices. This service allows users to review their health trend information and life patterns. We implemented the service scenario that is proposed in Section3. Figure 14 displays the results. Figure 14(a) displays actual activities that are accumulated by the PAAR watch. Figure 14(b) presents health data, such as weight, blood glucose, and blood pressure, through a smartphone application connected to the proposed PAAR platform. The long-term relationship between daily exercise and vital signs can be easily gathered and analyzed without the user’s intentional intervention.Figure 14
Screen shots of the sample applications. (a) User’s activities of service scenario and health info data; (b) daily exercise data and vital signal data automatically acquired by PAAR device for a long period (about six months); (c) medication reminder message window; (d) alert/ignition reminder message window.
(a) (b) (c) (d)The activity reminder service indicates a specific action to the user and issues an alert message according to the schedule. Sending a medication alert message is a representative example. Figure14(c) illustrates the actual medication alert message that is sent by the pill reminder service. Another reminder service is used by the AIE. Figure 14(d) displays a sample pop-up alert message.


## 6.1. Software Architecture

Figure12 shows the layered software architecture of the proposed PAAR platform. The platform concentrates on minimizing required user intervention. The proposed platform is divided into three primary layers. The lowest level, the operating system (OS) layer, is composed of the RTOS kernel and Board Support Package (BSP). The middle level, the system layer, provides the core and managing functions. The highest level, the applications layer, provides direct services.Figure 12
Procedure to identify fault activity in real time.The most important characteristic of this platform is the realization of the implicit HCI, implying that the user is never required to provide intentional intervention to the wearable device. For this reason, all the software components, including PNIP, eLiDx, and DTM, are developed at the top of the UBINOS RTOS. UBINOS [24] was developed by our research team for resource-constrained devices such as wearable devices.


## 6.2. PAAR Watch Prototype

As illustrated in Figure13(a), the proposed hardware architecture is similar to that of the recently developed RTOS-based smart watch platforms [16]; however, it is significantly different from Google’s Android [17]. One of the distinguishing components is the LF wake-up receiver for implementing the PNIP protocols on a hardware basis. Figure 13(b) illustrates the actual shape of the prototype version of the PAAR watch, including the glucose measurer. In particular, the daily management of glucose measured values is very important for people suffering from diabetes, and therefore we incorporated the glucose measurer in the wearable smart watch that can always carry it.Figure 13
Implemented hardware of the PAAR watch platform. (a) Hardware architecture diagram; (b) actual shape of the prototype.
(a) (b)


## 6.3. Application of Activity Record

In this section, we describe the diverse usage of activity data that are collected by the self-D2D communication with the external resource devices. This service allows users to review their health trend information and life patterns. We implemented the service scenario that is proposed in Section3. Figure 14 displays the results. Figure 14(a) displays actual activities that are accumulated by the PAAR watch. Figure 14(b) presents health data, such as weight, blood glucose, and blood pressure, through a smartphone application connected to the proposed PAAR platform. The long-term relationship between daily exercise and vital signs can be easily gathered and analyzed without the user’s intentional intervention.Figure 14
Screen shots of the sample applications. (a) User’s activities of service scenario and health info data; (b) daily exercise data and vital signal data automatically acquired by PAAR device for a long period (about six months); (c) medication reminder message window; (d) alert/ignition reminder message window.
(a) (b) (c) (d)The activity reminder service indicates a specific action to the user and issues an alert message according to the schedule. Sending a medication alert message is a representative example. Figure14(c) illustrates the actual medication alert message that is sent by the pill reminder service. Another reminder service is used by the AIE. Figure 14(d) displays a sample pop-up alert message.


## 7. Performance Evaluation

### 7.1. Power Consumption Evaluation

Wearable devices have a hard constraint for power consumption imposed by the limited battery capacity. We proposed advanced concepts, such as self-organizing D2D communication and opportunistic computing. If these implemented functions require excessive energy, in terms of both peak current and average current consumption, we cannot adopt these concepts as core components. Therefore, power management is an essential technical issue.Figure15 presents the PAAR’s current consumption in various states. The current consumption is increased when the computing functions are awakened and is minimized during the rest period. The current consumption ratio of the proposed PAAR is one of the lowest ratios of all available devices. We can guarantee that, even with the high power functions of PNIP and eLiDx, the consumption ratio of the energy will be minimized and well matched to the properties of wearable devices. In fact, the PAAR watch uses a 240 mAh battery having a lifetime of about 30 days.Figure 15
Current consumption ratios in various watch states.
(a)
Idle (watch only) (b)
Watch + eLiDx (c)
Watch + smartphone pairing (d)
Watch + gesture + smartphone pairing


### 7.2. Proximity-Based Neighbor Identification Protocol Performance Evaluation

To ensure that the wearable device is transparent in ordinary life conditions, the user must not consider the wearable device to be an obstacle. Because PNIP is the core protocol, its operation is the most important evaluation factor. Therefore, the PNIP service time is the primary parameter for measuring the user-friendliness of the system. In Table2, various resource devices with services are listed in the service column. The activity event is a possible activity event related to the resource device or service. The total time is the average time for average human behavior; this time includes the time taken to leave the physical distance range of the LF wake-up signal. All the values in this table are average values according to thousands of trials of the service. For example, in the door-lock service “returning” activity event, the time taken by a human from opening the door-lock to moving approximately 3 m from the door-lock will be a minimum of 2000 msec. The PNIP service turnaround time is that required to capture all the actions performed by two or more neighboring devices (including a PAAR device and service resource devices) related to this PNIP transaction. For all the human behaviors related to these resource devices, the PNIP transaction always requires less time than the matching human behavior; the user is never required to wait until the communication and computation terminate.Table 2
Service performance evaluation of proximity-based neighbor identification protocol.
Service Activity event Total time (ms)∗ PNIP service time (ms) Success ratio (%) Door-lock Leaving/returning 1500/2000 1217/1207 98.96 Coffee port Turn on/off 1000 1214 99.92 Count number of cups 3000 1216 95.36 Gas oven Turn/on/off 2000/1500 1216/1194 99.87 Blood pressure measurement Start button/transfer measured data 45000 882/1351 96.76 Weight measurement Ride/release 2000 1216 95.05 Treadmill Working on and press start button/release by stop button 3000/2000 1312/1207 97.85 Faucet Turn on/off 3000/2000 1220/1230 93.77 Name card exchange Shake hands 5000 3000/7000 78.05 ∗Time from action start to leaving the communication range of LF and/or RF.The success ratio indicates the probabilistic success of the PNIP transaction collecting the user’s daily activities. The activities collected by the PNIP with LF wake-up are acquired with excellent results, because we utilize a hardware-based mechanism. The last service, the name card exchange service, using the PNIP with gesture recognition is software-based. The results were somewhat disappointing. Additional research is required to improve the success ratio. In the case of the gesture recognition-based PNIP, if we use the 2.4 GHz RF (Bluetooth Low Energy), we can set the time for the PNIP to the physical range of RF communication. Therefore, the time is measured from when two people shake hands until they move away from each other. The results for both the LF wake-up-based PNIP and the gesture recognition PNIP confirm that the communication time will not interfere with ordinary life functioning.Table3 presents the performance results of the required time for fault activity identification and the success ratio. To identify a fault or irregular activities using the PAAR device, the fault preconditions must be registered by the user (e.g., guardian or doctor). Therefore, we supposed in this experiment that the fault or alerting activity condition for each activity event is already registered using the method explained in the previous section. Because we are attempting to assist human activity and issue reminders in real time, the fault activity identification mechanism is simple and flat (it does not use complex algorithms).Table 3
Performance evaluation for fault activity identification and alarm activation.
Activity Fault or alerting condition Response time after fault condition (ms) Success ratio (%) Gas oven Door-lock (outside) open 565 97.69 Predefined timeout 610 99.03 Faucet Door-lock (outside) open 512 96.78 Predefined timeout 550 98.58 Coffee port Door-lock (outside) open 570 98.23 Number of cups per day (predefined) exceeded 780 92.31 Scheduled pill time Pill time approaching/exceeded 220/620 99.27/98.72 Scheduled blood-sugar measurement Measurement time approaching/exceeded 210/610 99.98/99.42 Toilet Exited the bathroom without flushing 1600 89.67 Timeout (predefined) after toilet usage (stay in bathroom overly long) 750 92.39


## 7.1. Power Consumption Evaluation

Wearable devices have a hard constraint for power consumption imposed by the limited battery capacity. We proposed advanced concepts, such as self-organizing D2D communication and opportunistic computing. If these implemented functions require excessive energy, in terms of both peak current and average current consumption, we cannot adopt these concepts as core components. Therefore, power management is an essential technical issue.Figure15 presents the PAAR’s current consumption in various states. The current consumption is increased when the computing functions are awakened and is minimized during the rest period. The current consumption ratio of the proposed PAAR is one of the lowest ratios of all available devices. We can guarantee that, even with the high power functions of PNIP and eLiDx, the consumption ratio of the energy will be minimized and well matched to the properties of wearable devices. In fact, the PAAR watch uses a 240 mAh battery having a lifetime of about 30 days.Figure 15
Current consumption ratios in various watch states.
(a)
Idle (watch only) (b)
Watch + eLiDx (c)
Watch + smartphone pairing (d)
Watch + gesture + smartphone pairing


## 7.2. Proximity-Based Neighbor Identification Protocol Performance Evaluation

To ensure that the wearable device is transparent in ordinary life conditions, the user must not consider the wearable device to be an obstacle. Because PNIP is the core protocol, its operation is the most important evaluation factor. Therefore, the PNIP service time is the primary parameter for measuring the user-friendliness of the system. In Table2, various resource devices with services are listed in the service column. The activity event is a possible activity event related to the resource device or service. The total time is the average time for average human behavior; this time includes the time taken to leave the physical distance range of the LF wake-up signal. All the values in this table are average values according to thousands of trials of the service. For example, in the door-lock service “returning” activity event, the time taken by a human from opening the door-lock to moving approximately 3 m from the door-lock will be a minimum of 2000 msec. The PNIP service turnaround time is that required to capture all the actions performed by two or more neighboring devices (including a PAAR device and service resource devices) related to this PNIP transaction. For all the human behaviors related to these resource devices, the PNIP transaction always requires less time than the matching human behavior; the user is never required to wait until the communication and computation terminate.Table 2
Service performance evaluation of proximity-based neighbor identification protocol.
Service Activity event Total time (ms)∗ PNIP service time (ms) Success ratio (%) Door-lock Leaving/returning 1500/2000 1217/1207 98.96 Coffee port Turn on/off 1000 1214 99.92 Count number of cups 3000 1216 95.36 Gas oven Turn/on/off 2000/1500 1216/1194 99.87 Blood pressure measurement Start button/transfer measured data 45000 882/1351 96.76 Weight measurement Ride/release 2000 1216 95.05 Treadmill Working on and press start button/release by stop button 3000/2000 1312/1207 97.85 Faucet Turn on/off 3000/2000 1220/1230 93.77 Name card exchange Shake hands 5000 3000/7000 78.05 ∗Time from action start to leaving the communication range of LF and/or RF.The success ratio indicates the probabilistic success of the PNIP transaction collecting the user’s daily activities. The activities collected by the PNIP with LF wake-up are acquired with excellent results, because we utilize a hardware-based mechanism. The last service, the name card exchange service, using the PNIP with gesture recognition is software-based. The results were somewhat disappointing. Additional research is required to improve the success ratio. In the case of the gesture recognition-based PNIP, if we use the 2.4 GHz RF (Bluetooth Low Energy), we can set the time for the PNIP to the physical range of RF communication. Therefore, the time is measured from when two people shake hands until they move away from each other. The results for both the LF wake-up-based PNIP and the gesture recognition PNIP confirm that the communication time will not interfere with ordinary life functioning.Table3 presents the performance results of the required time for fault activity identification and the success ratio. To identify a fault or irregular activities using the PAAR device, the fault preconditions must be registered by the user (e.g., guardian or doctor). Therefore, we supposed in this experiment that the fault or alerting activity condition for each activity event is already registered using the method explained in the previous section. Because we are attempting to assist human activity and issue reminders in real time, the fault activity identification mechanism is simple and flat (it does not use complex algorithms).Table 3
Performance evaluation for fault activity identification and alarm activation.
Activity Fault or alerting condition Response time after fault condition (ms) Success ratio (%) Gas oven Door-lock (outside) open 565 97.69 Predefined timeout 610 99.03 Faucet Door-lock (outside) open 512 96.78 Predefined timeout 550 98.58 Coffee port Door-lock (outside) open 570 98.23 Number of cups per day (predefined) exceeded 780 92.31 Scheduled pill time Pill time approaching/exceeded 220/620 99.27/98.72 Scheduled blood-sugar measurement Measurement time approaching/exceeded 210/610 99.98/99.42 Toilet Exited the bathroom without flushing 1600 89.67 Timeout (predefined) after toilet usage (stay in bathroom overly long) 750 92.39


## 8. Conclusion

In order to assist older people to lead an independent life, this paper proposed a self-organizing platform that can support user-friendly and convenient services for older adults who prefer “aging in my place.” In this paper, we proposed software and hardware architecture for a wearable device platform, called PAAR, which can track and analyze an older person’s daily activity for various relevant actions. Furthermore, several reminder services based on a record of the personal activity are provided. To implement the activity-tracking services with low power consumption, the platform requires functions such as PNIP, eLiDx, and DTM.We presented a service scenario that demonstrated the process of self-collecting of the user’s selected activities without his/her intentional intervention and also implemented the function for longer-period activities, including sending vital sign history to a smartphone. Moreover, we implemented an activity reminder service preventing a user from missing a medication time or causing a home accident.In the performance evaluation, all the D2D communications were completed within the time it takes a human to complete the related behavior. The watch platform does not interfere with the user’s normal life. The functions for tracking and analyzing a user’s activities can be used for services further to the applications identified above. If analysis of a user’s behavior or activity information is available, an accurate pattern of daily life can be realized. Future research will focus on extending the advanced PAAR platform package, such as including a dementia diagnosis kit.



---

*Source: 6048213-2016-08-16.xml*