# Low-Power Platform and Communications for the Development of Wireless Body Sensor Networks

Authors: David Naranjo-Hernández; Laura M. Roa; Javier Reina-Tosina; Miguel A. Estudillo-Valderrama; Gerardo Barbarov
Journal: International Journal of Distributed Sensor Networks
 (2015)

---

## Abstract

Although the roles of body sensor networks (BSNs) are similar to those carried out by the generic wireless sensor networks (WSNs), new solutions must be established to optimize communications for true pervasive biomedical monitoring transparent to the user. In this paper, a proposal of a hardware and software platform for biomedical sensors is performed, which is specially designed to minimize energy consumption in BSNs through a modular processing scheme based on the detection of events and information abstraction. The data flow is implemented through a novel communications protocol that enhances the performances of consumption and time delay of the platform. A novel aspect of the protocol is the explicit incorporation of an additional level of communications to support the distributed processing architecture that allows the execution of multiple applications in parallel within the smart sensors. The results obtained with an implementation of a smart sensor for fall detection demonstrate its feasibility as well as the viability of the communication protocol for the development of energy-efficient BSNs.


---

## Body

## 1. Introduction

The progress in the microelectronics of sensorization and the advances in the wireless communications technologies, together with the reduction in size and cost of the devices, are enabling the development of numerous healthcare and remote monitoring applications based on wireless biomedical sensor networks carried by the patient [1–4] forming a body sensor network (BSN).However, although the tasks performed by BSNs are similar to those performed by the current wireless sensor networks (WSNs), there are important differences that affect the practical use of them. As the networks are centered on the human body [1–3] with battery-powered sensors placed as well as implanted on the body surface, the minimization of energy consumption is a priority objective in BSNs [5]. Prolonging the device life, the maintenance costs are reduced and the transparent use for the patient is favored, preventing forgetfulness in battery replacement or surgical operations for its replacement in the case of sensors implanted [6]. On the other hand, since the structure of the network is normally fixed and is expanded over a small area, the complexity of the network can be notoriously simplified towards more efficient schemes from the point of view of power consumption and time delay compared with those used for the traditional WSNs, which are normally oriented towards the deployment of sensors over a wide area [1–3, 5, 7]. The creation of networks with a star topology with a coordinator device with higher energy resources which in turn serves as a gateway to an external network is common [7]. On the other hand, if a sensor device detects a critical event in the monitored signals, the alarm should be sent as soon as possible. Therefore, the time delay should be guaranteed by providing a low latency [2]. Besides, BSNs should be scalable, to facilitate the integration of new devices to the monitoring system [7].The medium access (MAC) layer is responsible for coordinating the access to the shared radio communications channel, assigning the transmission and reception intervals to the various nodes in the network [5]. In recent years, the MAC layer has been the technological key to minimize the power consumption while maintaining a low latency [8]. This has been the objective of many MAC protocols which have been developed in order to optimize the communications in WSNs [9, 10]. Since idle listening has been identified as one of the main reasons for the waste of energy, a common solution is to turn off the radio transceiver when it does not have to transmit or receive data [11, 12]. This mechanism of sleep and waking up the transceiver is usually implemented through contention-free methods and contention-based methods [7, 8, 12].Contention-free methods normally use the TDMA (time division multiple access) medium access technique where a coordinator deterministically assigns the time slots for transmissions of the various devices [7, 8, 11, 12]. This prevents collisions and minimizes the idle listening intervals. However, as all the devices must be perfectly synchronized, an additional expenditure of energy is necessary in control messages and allocation of time slots, which will be higher for lower latency in communications. TDMA is more suitable for static networks with a limited number of sensors generating data at a fixed rate [13]. In recent years, many TDMA protocols have been proposed in the context of BSNs. On the basis of a TDMA protocol, RE-ATTEMPT [2] uses direct communication for emergency data and multihop communication for normal data. MedMac protocol [13] introduces the concept of guard band to allow the node to sleep for many beacon periods and Low Duty Cycle MAC protocol [13], the concept of guard time, to avoid the overlap between consecutive time slots. ATDMA-based MAC protocol increases the number of time slots assigned to a slave node in case of alarm [14]. In [7], additional slots are reserved for retransmissions. The BATMAC protocol [15] automatically detects the shadowing effect in body environment and quickly adapts the relaying scheduling. The protocol proposed in [16] can be adapted for medical and nonmedical applications and the situation of the user (normal or emergency). H-MAC uses heartbeat rhythm instead of beacons for synchronization purposes [17]. DQ-MAC allows the creation of very dense BSNs [17]. The protocol proposed in [18] improves the communication management including information about battery discharge dynamics.Some contention-based methods use the CSMA/CA (carrier sense multiple access with collision avoidance) medium access technique [7, 8, 11, 12], an approach of great simplicity which is very versatile but less energy-efficient because of the possibility of collisions on the transmission of information and the existence of idle listening time intervals. In contention-based methods the medium access is distributed, so that there is no need for central coordination [19]. However, CSMA/CA protocol has serious collision problems for high traffic nodes [17]. Zigbee employs CSMA/CA [20], and its quality of service can be improved modifying the default parameters from IEEE 802.15.4 standard. The CSMA/CA protocol described in [21] allows high priority nodes to interrupt low priority nodes.Other contention-based solutions propose an asynchronous time scheme, where transmissions are preceded by one or several preamble signals [11]. In this scheme the sensors independently schedule the instants in which they will awake to check the channel waiting for a preamble addressed to them. However, this option increases the power consumption due to the transmission of preambles and the increase of the idle listening intervals. In Low-Power Listening (LPL) protocols, nodes regularly awake for a very short period to check activity of the channel [13]. A long preamble ensures the detection in case of activity [22]. B-MAC [22] is based in LPL, with a preamble that is slightly longer than the sleeping period of the receiver [23]. X-MAC [24] improves B-MAC by dividing preamble into a burst of short subpreambles, each of them with a destination address. The protocol presented in [23] improves the X-MAC with the indication about pending packets. SCP-MAC [24] employs synchronization to reduce the length of preamble. WiseMAC [23] uses a similar technique to B-MAC but adjusts the duty cycle based on neighboring nodes information.Other authors propose mixed solutions (scheduled contention) using fixed and variable periodic listening and sleep schedule to avoid collision, overhearing and also reduce idle listening. S-MAC uses RTS/CTS (request to send/clear to send) procedure to solve the hidden terminal problem in a contention scheme [19]. Neighboring nodes wake up simultaneously in a coordinated schedule for communication and synchronization purposes [25]. T-MAC [23] improves S-MAC adapting its duty cycle through fine-grained timeouts. The duty cycle of the nodes is adapted according to their traffic patterns by themselves in TAD-MAC [22] or by the coordinator in Ta-MAC [26]. PW-MAC [19] uses pseudo random schedules to avoid collisions. pQueue-MAC uses preamble sampling in low traffic condition and TDMA when load increases [24].Other mixed solutions are based in both TDMA and CSMA/CA methods. Body-MAC employs a flexible bandwidth allocation strategy: burst, periodic, and adjusted [27]. CA-MAC [14] has a fixed SuperFrame structure, with customizable contention and TDMA parts. C-MAC [25] is configurable depending on the application (synchronization, contention, acknowledgment, etc). Under low contention, Z-MAC [25] behaves like CSMA and under high contention like TDMA.IEEE 802.15.6 protocol has been proposed as a wireless communication standard with low cost and ultra low-power that can operate on, around, or inside the human body [28, 29], but there are still no commercial devices suitable for its application.On the other hand, as the transmission and reception of packets consume the majority of energy in BSNs, and it is several orders of magnitude greater than the consumption related to the processing [30], the realization of some type of processing on the biomedical signal to summarize and abstract the relevant information provides highly beneficial results. The information transmitted may be so greatly reduced with the consequent reduction in energy expenditure in communications [7]. Besides, if the transmission of the information is contingent upon the detection of attention events in the monitored signal, the power consumption in communications can be drastically reduced [30]. For these reasons, in the design of a BSN it would be desirable to add intelligence to the sensor devices to provide greater autonomy and robustness to the monitoring system. The sensor device is then converted into a hardware and software platform for the capture, processing, and transmission of the biomedical information. In this field of study a major research effort is currently being conducted for the development of sensorization platforms for medical care, as the Telos [30] or Shimmer [31] motes, or Arduino [32] or EnViBo [33] platforms. However, a further research is necessary for the maturation of the technology, since in many cases the power consumption and size are a secondary problem, or they are platforms designed for industrial environments and not for body applications. This is an area of current technological interest, with the continuous emergence of new consumer electronic devices, smart watches, smart glasses, and bracelets for health and fitness applications.In this paper, the proposal of a novel low-power smart platform for biomedical sensors is performed, understanding platform as a hardware and software environment that integrates in a single device sensing, processing, and communication capabilities. This platform has been designed to minimize energy consumption through a modular processing scheme based on the detection of events and the abstraction of biomedical information. The paradigm is completed with a communication protocol specifically designed to maximize energy efficiency of the platform, minimizing the control messages, the idle listening, the packet collision, and the overlistening. The protocol also provides a framework for the communication of applications that are executed in parallel within the smart sensors, which, to the best of the authors knowledge, has not been a problem addressed explicitly in the context of BSNs. The platform and the communications protocol have been validated through its application in a accelerometer smart sensor for fall detection, which is a major problem in the elderly, with proven relationship with morbidity and mortality [34]. A third of adults over 65 have suffered at least one fall per year [34]. In this sense, falling detection is accumulating significant research efforts at the present [35].


## 2. Description of the Software-Hardware Platform and Communications

### 2.1. Software Platform Architecture

The software platform architecture follows the following modular scheme (see Figure1):(1)
Distributed monitoring system: the distributed architecture proposed is formed at a first level by the smart biomedical sensors of the physiological signals monitored. Smart sensors communicate with a second device, called DAD (Decision-Analysis Device) with more computational resources, but also of information storage and energy, which performs a deeper processing of the sensory information. The DAD can be worn by the user but can also be left in a place near or attached in a central position in the monitoring area. Smart biomedical sensors can be carried by the end user forming a wireless body sensor network (WBSN), in which other sensors located proximally to the body can participate. Besides, the DAD can communicate remotely with different e-Health services to attend or assist the users. This processing distribution eases a more robust design of the network, facilitates its modal functionality so as to be applied to several biomedical contexts of applications, provides tools for system personalization to the end user, and minimizes devices power consumption attending to a distributed multitier event calculation. These advantages and others were exposed in [36].(2)
Processing modules in the sensors: the intelligence of the sensor device is supported by the processing modules that are executed in real time and in parallel in the processing unit of the smart sensors. Each processing module has the ability to transmit the captured biomedical information or the result of its processing. This information is structured in information samples generated with a given sampling frequency, which can be configured through commands. In addition, two virtual modules are considered: a processing module for the high level configuration and management of the processing unit and a virtual module for the configuration and management of the communications module.(3)
Modules of analysis and decision in the DAD: each one is associated with a processing module. Taking advantage of the higher processing capabilities of the DAD, these modules are responsible for conducting deeper processing of the data received from the sensor, analyzing the results in detail to make a decision of action.(4)
Bidirectional communication: It works through data frames from the sensors for the sending of information and configuration commands from the DAD for the modification of the sensor processing algorithms.Figure 1
Diagram of the software-hardware platform.


### 2.2. Smart Sensor Architecture

The hardware platform architecture is also based on a modular scheme in order to facilitate the integration of new technologies, both in information processing and communications, as well as in the transduction of the physiological variable monitored. The proposed platform can be decomposed into the following modules (see Figure1):(1)
Sensor device: it is responsible for the transduction of the biomedical signal monitored to appropriate signals for its transmission and/or processing.(2)
Communications module: it is responsible for the transmission of biomedical information and the reception of configuration commands, releasing the processing unit from all tasks related to communications.(3)
Processing unit: it is the intelligent core of the device, where the different processing modules are executed. The processing unit also manages the overall operation of the device and the operating modes of each processing module for minimal power consumption.


### 2.3. Operation Modes

The processing modules of the smart sensors can work in three operation modes, which are especially designed to minimize the power consumption of the system in an environment with event-based sensory information:(1)
Continuous transmission mode: in this mode, the smart sensor transmits in real time the information defined for the processing module. This information is sent with a configurable sampling frequency. The processing module enters in this mode after detecting and sending an alarm event until it is confirmed by a command from the DAD (or until the sending of a preconfigured amount of the data related to the alarm). The confirmation may be delayed to gather more information from the alarm event. Also, this functioning mode can be remotely activated by sending a command.(2)
Event-based mode: this is the normal operating mode of the smart sensors in order to minimize its consumption in communications. In this mode of operation, no data is sent until the sensor device detects an alarm event on the monitored physiological variables. This event may be exceeding one or more preset thresholds, either maximum or minimum, of the monitored variables or others resulting from the internal work of the processing module. The generated alarm includes in its transmission a samples window prior to the alarm event, of configurable size, for a later analysis in the DAD.(3)
Active standby mode: In this mode, no data are transmitted, but they are stored in a buffer. This operation mode can be set remotely, once the alarm event has been recognized, to prevent the system from being saturated with redundant alarm transmissions while the patient is being attended.


### 2.4. Master-Command Sensor-Data MAC Protocol

Due to the characteristics of BSNs, IEEE 802.15.4 standard has been considered in numerous investigations since it is able to achieve low-power transmissions at a short distance [1, 37, 38]. However, despite its low-power consumption, standard usage does not allow reaching the limits for BSNs [1, 5]. Furthermore, if sensor devices require real-time data transfer capabilities, the MAC layer of IEEE 802.15.4 is not the optimal solution [7] due to the high probability of collisions during the contention period, which uses CSMA/CA technique, and the low capability of the up to seven Guaranteed Time Slots (GTS) employed by the protocol with TDMA channel access mode [5].To address this issue, a new MAC protocol (Master-Command Sensor-Data MAC Protocol or MCSD) adapted to the distributed monitoring system has been developed. This protocol minimizes power consumption in a communication scheme where data stream sent to the sensor device is composed of simple configuration commands, allowing the real-time transfer of sensory information in a robust and error-free way.In the proposed configuration, the system forms a star topology where slave nodes are the smart sensors and the master node is the DAD. The master node only sends configuration commands to the slave nodes so that they adapt their operation to the environment, the context, and the user. The smart sensors transmit to the master node the result of sensor information processing, which can be sent in real time or only in the presence of alarm events, depending on the operation mode in which the processing modules of the smart sensors are configured.A MegaFrame (MF) structure defined by the DAD is used to transmit the information. This MF is composed ofN time slots with the same length, which the different devices use to transmit data. Although the MCSD protocol is built over the IEEE 802.15.4 wireless standard, other communications technologies such as UWB (Ultra-WideBand) or IBC (IntraBody Communication) are possible. For this technology we propose a time slot duration of 7.8125 ms, which is enough to send any kind of data and can be directly managed by a 32.768 kHz real-time clock. In this case, the MCSD SuperFrames are encapsulated in the payload of IEEE 802.15.4 physical data packets using the frequency channel selected by the DAD. The frequency channel is set individually for each monitoring system to form a personal BSN. In each slot, one among three types of SuperFrames can be sent: Beacon SuperFrame (BSF), Connection Request SuperFrame (CRSF), and Data SuperFrame (DSF). The first bits in each SuperFrame identify the type. Figure 2 shows a schematic representation of the MF as well as the SuperFrames considered:(1)
BSF: in the first slot of the MF, the DAD sends a BSF so that other devices can be synchronized with the MF structure. This SuperFrame informs on the length of the MF according to its number of slots (N, previously mentioned). This size can be optimally adapted to the temporal dynamics of the biosignal events in order to reduce the communication consumption. Besides, the BSF informs on the slot assignments for each device in the MF and the period of access by the contention technique and includes the configuration commands for the processing modules and the acknowledgement mechanism for the MCSD protocol.(2)
CRSF: when a new sensor wishes to connect to the distributed monitoring system, it must wait and listen until the reception of a BSF related to its DAD. Then, the devices send a CRSF during the contention access period of the MF, using CSMA/CA medium access method.(3)
DSF: any information that the smart sensor has to transmit is packaged in DSFs to be transmitted during the time slots of the MF assigned to the device in the previous BSF. If the device has more than one slot allocated in the MF, it can continue sending DSFs until the number of allocated slots is completed:
(a)
DSF1: smart sensor identifier.(b)
DSF2: indicating the sequence number of the current DSFs in the link of the smart sensor with the DAD.(c)
DSF3: indicating the number of frames to be resent if the acknowledgement is not received.(d)
DSF4: number of DSFs that the device has still to send. The DAD can then accelerate the transmissions in the next BSF assigning a higher number of time intervals to the device.(e)
DSF5: indicating the estimated remaining power of the smart sensor.(f)
DSF6: number of bytes in the data field of the DSF.(g)
DSF7: field for the transmission of the sensor data.Figure 2
MCSD protocol (MegaFrame, SuperFrames, and frames).Sensor-data flow is structured in frames that are generated by the processing modules of the device, distinguishing four types of frames to be sent in the DSFs:(1)
Connection request frame (CRF): it is used to request the connection of a smart sensor processing module with the DAD. This frame includes a processing module description of the smart sensor in an understandable format for the DAD. A suitable option can be the Transducer Electronic Data Sheet (TEDS) formats, like the ones described in the IEEE 1451.0 standard [39], which can be completed with high level description using Sensor Model Language (SensorML).(2)
Command frame (CF): this frame is used to configure a processing module by modifying the internal parameters. A command can also request a response from the processing module.(3)
Command answer frame (CAF): it is used by processing modules to acknowledge and/or answer to a previously received command in the BSF.(4)
Data frame (DF): it is used by the smart sensor processing modules for the real-time transmission of bioinformation to the DAD in the continuous transmission mode.(5)
Alarm frame (AF): this frame will be transmitted by the processing module of the DAD in the event-related mode when an alarm event has been detected. In this moment, a fixed amount of information stored in the device and previous to the event will be sent in one AF.A novel aspect provided by MCSD protocol is the explicit incorporation of an additional level in the communications. Most proposals include the sensor and the hub as end-nodes in the transmissions. However, MCSD protocol provides a framework for the development of communications in the distributed processing architecture proposed, also providing support to the transmissions of the processing modules that can be executed in parallel within a same smart sensor. Figure3 shows a diagram of the elements involved, as well as a breakdown of the frames and SuperFrames applied to each part.Figure 3
Schematic of the elements involved in the protocol MCSD: processing modules in the processing unit of the smart sensors, modules of analysis and decision in the DAD, frames in the internal links, and SuperFrames in the wireless link.As an example, the timeline of Figure4 summarizes the fundamental operations of the protocol as well as the frames and SuperFrames involved. The additional level that exists at both ends of the communication link can also be observed: processing modules in the sensor and modules of analysis and decision in the DAD. An environment in which two processing modules are executed in parallel within the sensor has been considered in this diagram. The communications module of the DAD generates MF structure by the cyclic transmissions of BSFs. The communications module of the smart sensor requests the connection to the network by the transmission of a CRSF during the contention access period. In the next BSF, DAD transceiver allocates a time slot in the MF for the smart sensor transmissions. It also sends a broadcast command to all the processing modules to inform on the connection. Then, each processing module requests the connection with the DAD by the sending of a CRF. These frames are encapsulated in a DSF for the wireless transmission from the transceiver of the sensor to the transceiver of the DAD. After this, CRFs are sequentially sent through the internal communications link that connects the communications module to the processing unit of the DAD. Finally, the frames are demultiplexed in the processing unit of the DAD for the delivery to the corresponding modules of analysis and decision. The connection is accepted by the transmission of a command for the configuration and initialization of the processing modules. Commands are encapsulated in the following BSF and sequentially sent through the internal communication link connecting the communications module with the processing unit of the sensor. Finally, the commands are demultiplexed in the processing unit to be sent to the corresponding processing modules. In response to commands received, the processing modules generate CAFs that are received by modules of analysis and decision in the DAD at the other end of the link, thus ending the process of connection establishment.Figure 4
Timeline of MCSD protocol and frames and SuperFrames involved.As it is shown in Figure4, one of the processing modules is configured with the continuous transmission mode, causing the periodic generation of DFs. These frames are encapsulated in DSFs for the wireless transmission and finally demultiplexed for the delivery to the appropriate modules of analysis and decision. The other processing module is configured in the Event-Based Mode, so that no data frame is sent until the detection of an alarm event. This event generates the transmission of an AF with previous information and a DF with posterior information.The protocol allows a direct control of the transmission rate, from 58 bytes/sec (1 time slot in a MF of 256 time slots) to 14.9 Kbytes/sec (255 time slots in a MF of 256 slots). The DAD dynamically adapts the transmission rate assigning the global number of time slots in the MF and the number of time slots for each device. Time delay and the duration of the MF can be adjusted dynamically according to the real-time transmission needs of the monitoring system and optimized so that the devices always have a slot ready for transmission, avoiding therefore the contention procedure.


## 2.1. Software Platform Architecture

The software platform architecture follows the following modular scheme (see Figure1):(1)
Distributed monitoring system: the distributed architecture proposed is formed at a first level by the smart biomedical sensors of the physiological signals monitored. Smart sensors communicate with a second device, called DAD (Decision-Analysis Device) with more computational resources, but also of information storage and energy, which performs a deeper processing of the sensory information. The DAD can be worn by the user but can also be left in a place near or attached in a central position in the monitoring area. Smart biomedical sensors can be carried by the end user forming a wireless body sensor network (WBSN), in which other sensors located proximally to the body can participate. Besides, the DAD can communicate remotely with different e-Health services to attend or assist the users. This processing distribution eases a more robust design of the network, facilitates its modal functionality so as to be applied to several biomedical contexts of applications, provides tools for system personalization to the end user, and minimizes devices power consumption attending to a distributed multitier event calculation. These advantages and others were exposed in [36].(2)
Processing modules in the sensors: the intelligence of the sensor device is supported by the processing modules that are executed in real time and in parallel in the processing unit of the smart sensors. Each processing module has the ability to transmit the captured biomedical information or the result of its processing. This information is structured in information samples generated with a given sampling frequency, which can be configured through commands. In addition, two virtual modules are considered: a processing module for the high level configuration and management of the processing unit and a virtual module for the configuration and management of the communications module.(3)
Modules of analysis and decision in the DAD: each one is associated with a processing module. Taking advantage of the higher processing capabilities of the DAD, these modules are responsible for conducting deeper processing of the data received from the sensor, analyzing the results in detail to make a decision of action.(4)
Bidirectional communication: It works through data frames from the sensors for the sending of information and configuration commands from the DAD for the modification of the sensor processing algorithms.Figure 1
Diagram of the software-hardware platform.


## 2.2. Smart Sensor Architecture

The hardware platform architecture is also based on a modular scheme in order to facilitate the integration of new technologies, both in information processing and communications, as well as in the transduction of the physiological variable monitored. The proposed platform can be decomposed into the following modules (see Figure1):(1)
Sensor device: it is responsible for the transduction of the biomedical signal monitored to appropriate signals for its transmission and/or processing.(2)
Communications module: it is responsible for the transmission of biomedical information and the reception of configuration commands, releasing the processing unit from all tasks related to communications.(3)
Processing unit: it is the intelligent core of the device, where the different processing modules are executed. The processing unit also manages the overall operation of the device and the operating modes of each processing module for minimal power consumption.


## 2.3. Operation Modes

The processing modules of the smart sensors can work in three operation modes, which are especially designed to minimize the power consumption of the system in an environment with event-based sensory information:(1)
Continuous transmission mode: in this mode, the smart sensor transmits in real time the information defined for the processing module. This information is sent with a configurable sampling frequency. The processing module enters in this mode after detecting and sending an alarm event until it is confirmed by a command from the DAD (or until the sending of a preconfigured amount of the data related to the alarm). The confirmation may be delayed to gather more information from the alarm event. Also, this functioning mode can be remotely activated by sending a command.(2)
Event-based mode: this is the normal operating mode of the smart sensors in order to minimize its consumption in communications. In this mode of operation, no data is sent until the sensor device detects an alarm event on the monitored physiological variables. This event may be exceeding one or more preset thresholds, either maximum or minimum, of the monitored variables or others resulting from the internal work of the processing module. The generated alarm includes in its transmission a samples window prior to the alarm event, of configurable size, for a later analysis in the DAD.(3)
Active standby mode: In this mode, no data are transmitted, but they are stored in a buffer. This operation mode can be set remotely, once the alarm event has been recognized, to prevent the system from being saturated with redundant alarm transmissions while the patient is being attended.


## 2.4. Master-Command Sensor-Data MAC Protocol

Due to the characteristics of BSNs, IEEE 802.15.4 standard has been considered in numerous investigations since it is able to achieve low-power transmissions at a short distance [1, 37, 38]. However, despite its low-power consumption, standard usage does not allow reaching the limits for BSNs [1, 5]. Furthermore, if sensor devices require real-time data transfer capabilities, the MAC layer of IEEE 802.15.4 is not the optimal solution [7] due to the high probability of collisions during the contention period, which uses CSMA/CA technique, and the low capability of the up to seven Guaranteed Time Slots (GTS) employed by the protocol with TDMA channel access mode [5].To address this issue, a new MAC protocol (Master-Command Sensor-Data MAC Protocol or MCSD) adapted to the distributed monitoring system has been developed. This protocol minimizes power consumption in a communication scheme where data stream sent to the sensor device is composed of simple configuration commands, allowing the real-time transfer of sensory information in a robust and error-free way.In the proposed configuration, the system forms a star topology where slave nodes are the smart sensors and the master node is the DAD. The master node only sends configuration commands to the slave nodes so that they adapt their operation to the environment, the context, and the user. The smart sensors transmit to the master node the result of sensor information processing, which can be sent in real time or only in the presence of alarm events, depending on the operation mode in which the processing modules of the smart sensors are configured.A MegaFrame (MF) structure defined by the DAD is used to transmit the information. This MF is composed ofN time slots with the same length, which the different devices use to transmit data. Although the MCSD protocol is built over the IEEE 802.15.4 wireless standard, other communications technologies such as UWB (Ultra-WideBand) or IBC (IntraBody Communication) are possible. For this technology we propose a time slot duration of 7.8125 ms, which is enough to send any kind of data and can be directly managed by a 32.768 kHz real-time clock. In this case, the MCSD SuperFrames are encapsulated in the payload of IEEE 802.15.4 physical data packets using the frequency channel selected by the DAD. The frequency channel is set individually for each monitoring system to form a personal BSN. In each slot, one among three types of SuperFrames can be sent: Beacon SuperFrame (BSF), Connection Request SuperFrame (CRSF), and Data SuperFrame (DSF). The first bits in each SuperFrame identify the type. Figure 2 shows a schematic representation of the MF as well as the SuperFrames considered:(1)
BSF: in the first slot of the MF, the DAD sends a BSF so that other devices can be synchronized with the MF structure. This SuperFrame informs on the length of the MF according to its number of slots (N, previously mentioned). This size can be optimally adapted to the temporal dynamics of the biosignal events in order to reduce the communication consumption. Besides, the BSF informs on the slot assignments for each device in the MF and the period of access by the contention technique and includes the configuration commands for the processing modules and the acknowledgement mechanism for the MCSD protocol.(2)
CRSF: when a new sensor wishes to connect to the distributed monitoring system, it must wait and listen until the reception of a BSF related to its DAD. Then, the devices send a CRSF during the contention access period of the MF, using CSMA/CA medium access method.(3)
DSF: any information that the smart sensor has to transmit is packaged in DSFs to be transmitted during the time slots of the MF assigned to the device in the previous BSF. If the device has more than one slot allocated in the MF, it can continue sending DSFs until the number of allocated slots is completed:
(a)
DSF1: smart sensor identifier.(b)
DSF2: indicating the sequence number of the current DSFs in the link of the smart sensor with the DAD.(c)
DSF3: indicating the number of frames to be resent if the acknowledgement is not received.(d)
DSF4: number of DSFs that the device has still to send. The DAD can then accelerate the transmissions in the next BSF assigning a higher number of time intervals to the device.(e)
DSF5: indicating the estimated remaining power of the smart sensor.(f)
DSF6: number of bytes in the data field of the DSF.(g)
DSF7: field for the transmission of the sensor data.Figure 2
MCSD protocol (MegaFrame, SuperFrames, and frames).Sensor-data flow is structured in frames that are generated by the processing modules of the device, distinguishing four types of frames to be sent in the DSFs:(1)
Connection request frame (CRF): it is used to request the connection of a smart sensor processing module with the DAD. This frame includes a processing module description of the smart sensor in an understandable format for the DAD. A suitable option can be the Transducer Electronic Data Sheet (TEDS) formats, like the ones described in the IEEE 1451.0 standard [39], which can be completed with high level description using Sensor Model Language (SensorML).(2)
Command frame (CF): this frame is used to configure a processing module by modifying the internal parameters. A command can also request a response from the processing module.(3)
Command answer frame (CAF): it is used by processing modules to acknowledge and/or answer to a previously received command in the BSF.(4)
Data frame (DF): it is used by the smart sensor processing modules for the real-time transmission of bioinformation to the DAD in the continuous transmission mode.(5)
Alarm frame (AF): this frame will be transmitted by the processing module of the DAD in the event-related mode when an alarm event has been detected. In this moment, a fixed amount of information stored in the device and previous to the event will be sent in one AF.A novel aspect provided by MCSD protocol is the explicit incorporation of an additional level in the communications. Most proposals include the sensor and the hub as end-nodes in the transmissions. However, MCSD protocol provides a framework for the development of communications in the distributed processing architecture proposed, also providing support to the transmissions of the processing modules that can be executed in parallel within a same smart sensor. Figure3 shows a diagram of the elements involved, as well as a breakdown of the frames and SuperFrames applied to each part.Figure 3
Schematic of the elements involved in the protocol MCSD: processing modules in the processing unit of the smart sensors, modules of analysis and decision in the DAD, frames in the internal links, and SuperFrames in the wireless link.As an example, the timeline of Figure4 summarizes the fundamental operations of the protocol as well as the frames and SuperFrames involved. The additional level that exists at both ends of the communication link can also be observed: processing modules in the sensor and modules of analysis and decision in the DAD. An environment in which two processing modules are executed in parallel within the sensor has been considered in this diagram. The communications module of the DAD generates MF structure by the cyclic transmissions of BSFs. The communications module of the smart sensor requests the connection to the network by the transmission of a CRSF during the contention access period. In the next BSF, DAD transceiver allocates a time slot in the MF for the smart sensor transmissions. It also sends a broadcast command to all the processing modules to inform on the connection. Then, each processing module requests the connection with the DAD by the sending of a CRF. These frames are encapsulated in a DSF for the wireless transmission from the transceiver of the sensor to the transceiver of the DAD. After this, CRFs are sequentially sent through the internal communications link that connects the communications module to the processing unit of the DAD. Finally, the frames are demultiplexed in the processing unit of the DAD for the delivery to the corresponding modules of analysis and decision. The connection is accepted by the transmission of a command for the configuration and initialization of the processing modules. Commands are encapsulated in the following BSF and sequentially sent through the internal communication link connecting the communications module with the processing unit of the sensor. Finally, the commands are demultiplexed in the processing unit to be sent to the corresponding processing modules. In response to commands received, the processing modules generate CAFs that are received by modules of analysis and decision in the DAD at the other end of the link, thus ending the process of connection establishment.Figure 4
Timeline of MCSD protocol and frames and SuperFrames involved.As it is shown in Figure4, one of the processing modules is configured with the continuous transmission mode, causing the periodic generation of DFs. These frames are encapsulated in DSFs for the wireless transmission and finally demultiplexed for the delivery to the appropriate modules of analysis and decision. The other processing module is configured in the Event-Based Mode, so that no data frame is sent until the detection of an alarm event. This event generates the transmission of an AF with previous information and a DF with posterior information.The protocol allows a direct control of the transmission rate, from 58 bytes/sec (1 time slot in a MF of 256 time slots) to 14.9 Kbytes/sec (255 time slots in a MF of 256 slots). The DAD dynamically adapts the transmission rate assigning the global number of time slots in the MF and the number of time slots for each device. Time delay and the duration of the MF can be adjusted dynamically according to the real-time transmission needs of the monitoring system and optimized so that the devices always have a slot ready for transmission, avoiding therefore the contention procedure.


## 3. Results

### 3.1. Validation of the Software-Hardware Platform

The platform has been validated through its application to the research, design, development, and validation of an accelerometer smart sensor for fall detection in the elderly. According to the paradigm proposed for the platform, the smart sensor performs a first detection (impact detection) in order to distribute the processing of the accelerometer information by a first processing layer that employs a robust algorithm for detecting impacts without excluding those ones that may be considered as events fall. The DAD perform a deeper processing of the information sent from the sensor to discriminate between a true fall event and other kinds of impact, contacting with remote e-Health services to launch emergency response if necessary.According to the platform, the distributed processing is performed by the following software modules:(1)
A processing module in the accelerometer smart sensor for the detection of impacts.(2)
A module of analysis and decision in the DAD for fall discrimination.The modular architecture of the smart sensor is supported by the following electronic components:(1)
Sensor device: a triaxial LIS3LV02DQ accelerometer from STMicroelectronics has been selected for the purpose of movement monitoring.(2)
Communications module: a Chipcom CC2430 transceiver has been used to develop the MCSD protocol over the IEEE 802.15.4 standard.(3)
Processing unit: a PIC18F2431 microcontroller from Microchip has been used for this purpose to implement the processing module for impact detection, to separate communications from processing, and to facilitate device redesign.Figure5 shows an image of the accelerometer smart sensor implemented following the scheme proposed by the platform.Figure 5
Accelerometer smart sensor prototype.


### 3.2. MCSD Memory Footprint

Since the program memory of biomedical sensor is extremely limited, keeping the size of protocol implementation small is a critical factor. MCSD protocol simplicity enabled it to be implemented in sensors with very limited hardware resources, as the case of the accelerometer smart sensor developed. In order to analyze the memory footprint of the MCSD protocol, it was implemented in the 8051 microcontroller within CC2430 transceiver of the smart sensor using the IAR Embedded Workbench toolbox. Table1 shows the size of program code obtained for the implementation of MCSD protocol in comparison with the IEEE 802.15.4 standard and other energy-efficient protocols. The results disclose the code efficiency of MCSD protocol.Table 1
Memory footprint of MCSD and other MAC protocols.
Protocol
Memory footprint
Reference
Resources employed
MCSD
4149 bytes
This work
8051 microcontrollers within CC2430 transceiver
IEEE 802.15.4
26776 bytes
[25]
ATMega1281 microcontroller with AT86RF230 transceiver
B-MAC
25112 bytes
[43]
TelosB mote with CC2420 transceiver
X-MAC
25304 bytes
[43]
TelosB mote with CC2420 transceiver
S-MAC
24326 bytes
[43]
TelosB mote with CC2420 transceiver
T-MAC
22096 bytes
[43]
TelosB mote with CC2420 transceiver


### 3.3. Validation of the MCSD Protocol

The MCSD protocol was validated through its implementation in a monitoring application: a fall detection system. With the prototype of the accelerometer smart sensor a series of experiments were performed to analyze the energy efficiency for a real implementation.Power consumption was measured experimentally using an equivalent to the configuration proposed in [40]. According to this configuration, a resistance of 10 ohms and an accuracy of 1% were placed on the way out of the current from the battery. The drop voltage across the resistor was measured with an oscilloscope Agilent MSO6032A, allowing establishing the instantaneous current consumed by the device.In order to emulate the conditions of a homecare scenario the experiments were performed in a closed room including different types of furniture (tables, chairs, closets, etc.). The DAD was located on a table and the smart sensor on the back of a volunteer (male, 33 years, 180 cm, and 97 kg). The volunteer was situated at three meters from the DAD and looking at it, so that his body was occluding the way of sight between both devices.The power consumption can then be calculated considering that the sensor was fed by a 3 V battery. To minimize energy consumption, the transceiver activated a low-power mode when it did not have to send or receive data. The internal timers allowed waking up the transceiver in accordance with the timing set of the MF. The MCSD protocol was configured with the following scheme: 64 time slots for a duration of the MF of 500 ms, reserving the time slot number 17 of the MF for transmissions of the smart sensor.The two main operation modes of the protocol were analyzed: continuous transmission of data and event-based transmission. In continuous transmission mode the device generated 40 samples per second and 3 bytes per sample, one byte per axis. In the transmission mode based on events, the alarm included 85 acceleration samples detected prior to impact and 85 samples after the impact event (1 byte per axis, 3 bytes per sample, 40 samples per second, and 510 bytes in total for about 4 seconds of acceleration data).Figure6 shows the consumption obtained in the two sensor configurations. As observed in this figure, MF structure imposes a periodicity in the sensor activity so that device observations can be restricted to the duration of a MF, where it is easy to distinguish the following intervals:(1)
T1: time interval during which the transceiver device in the sensor is listening to the beacon frame.(2)
T2: time interval during which the transceiver transmits acceleration data (only real-time transmission).(3)
T3: time interval to capture and process acceleration data.(4)
T4: smart sensor inactivity time interval.Figure 6
Experimental current consumption in real time (a) and only when an impact is detected (b) with MCSD MAC protocol.Table2 shows the experimental results obtained related to the duration of the intervals and the average power consumption in each of them, of the whole device, and only the communication module.Table 2
Consumption of the smart sensor.
Interval
Duration
Smart sensor current consumption
Communications current consumption
T
1
6 ms
28.4 mA
27.7 mA
T
2
6.2 ms
27.1 mA
26.4 mA
T
3
3.4 ms
1.9 mA
0.09 mA
T
4
21.6 ms
0.79 mA
0.09 mAGiven the structure of the MF and the current consumed at different times, it is then possible to establish an average consumption of 1.6 mA in the real-time setting (0.75 mA corresponds to the communications), which is reduced to 1 mA in an event-oriented transmission setting (listening one of every 4 BSFs). Detected retransmissions to avoid data loss were also considered to obtain these values, assuming a transmission error rate of 7%, which was obtained experimentally counting the number of failed MFs during a period of 15 minutes (both by BSF reception errors and DSF transmission errors). Furthermore, for the calculation of consumption in the transmission mode based on events, a random distribution of 10 impacts per day was considered. If the device is fed by a small battery of 1000 mAh (Panasonic CR 2477), it has an estimated operation duration of 26 days in the continuous transmission mode setting and 41 days in the transmission mode based on events.On the other hand, if only the communications are considered, the operation mode based on events allows a drastic reduction in power consumption as it is shown in Table3 (assuming 10 impacts daily).Table 3
Estimated consumption in communications of the accelerometer smart sensor (impact detection).
Average consumption for a year
No transmissions
93.66 J
Only transmissions with events
102.7 J
Continuous data transmission
2186.5 J


### 3.4. Performance Analysis of MCSD Protocol

In this section the performance of the MCSD communication protocol is analyzed from a generalized perspective. In the first place, the time delay or latency of the protocol is evaluated. This is an essential parameter in BSN, especially in critical applications, alarm management, and real-time applications. The other parameter to be analyzed is the energy consumption, which is normalized per bit of information, allowing the generalization of the results for different transmission rates. Both parameters have been determined analytically from the experimental results shown in the previous section.Considering that in each MF the sensor has only one time slot allocated, latency is evaluated as the maximum delay in the communication of an event, which in the case of MCSD protocol is the duration of the MF.The average power consumption was evaluated analytically according to (1), where CMF is the average current in a MF, T1 is the duration of the BSF reception interval according to the Table 2, T2 is the duration of the DSF transmission interval, TMF is the duration of the MF, and C1 is the average current consumption in T1, C2 in T2, and C3 during the rest of the time in low-power mode:(1)CMF=T1TMF·C1+T2TMF·C2+TMF-T1-T2TMF·C3.Taking into account that the sensor is powered by a battery of 3 V, energy consumed per bit is calculated according to (2), where Eb is the energy consumed per bit, NB is the number of bytes transmitted in the payload of the DSF (90 bytes), and PER is the probability of error (0.07):(2)Eb=CMF·3·TMFNB·8·1+PER.The graph of Figure7 shows the results obtained for different interval durations of the MF, from 31.25 ms to 1 hour. In this figure, the average power consumption per bit is represented versus the latency associated. This form of representation facilitates the comparison with other communications protocols, as both parameters are difficult to compare in many cases due to the wide variety of cases presented by different applications. Since both parameters are interrelated, simultaneous evaluation of both of them allows establishing a standard framework for the contextual approximation to different results. This representation allows generalizing the results and approximating the energy consumption that a specific application would need in function of the data amount to be transmitted and the latency required.Figure 7
Average power consumption per bit versus latency of MCSD and other protocols.Figure7 also highlights the benefits of consumption and time delay of the communications protocol compared with various wireless communications standards and other protocols proposed recently. These data were evaluated from the results confronted of the latency and consumption provided by different publications (BLE [41], Zigbee [41], ANT [41], Modified SCPMAC [24], Queue MAC [24], pQueue MAC [24], WiserBAN [23], and RMAC [42]).Finally, it should be added that the scalability of the system was tested experimentally in a setup with the participation of up to 16 devices, although a larger number of devices are possible. The system was not affected by the increased load on the network, as each device had assigned its own time slot for the transmissions.


## 3.1. Validation of the Software-Hardware Platform

The platform has been validated through its application to the research, design, development, and validation of an accelerometer smart sensor for fall detection in the elderly. According to the paradigm proposed for the platform, the smart sensor performs a first detection (impact detection) in order to distribute the processing of the accelerometer information by a first processing layer that employs a robust algorithm for detecting impacts without excluding those ones that may be considered as events fall. The DAD perform a deeper processing of the information sent from the sensor to discriminate between a true fall event and other kinds of impact, contacting with remote e-Health services to launch emergency response if necessary.According to the platform, the distributed processing is performed by the following software modules:(1)
A processing module in the accelerometer smart sensor for the detection of impacts.(2)
A module of analysis and decision in the DAD for fall discrimination.The modular architecture of the smart sensor is supported by the following electronic components:(1)
Sensor device: a triaxial LIS3LV02DQ accelerometer from STMicroelectronics has been selected for the purpose of movement monitoring.(2)
Communications module: a Chipcom CC2430 transceiver has been used to develop the MCSD protocol over the IEEE 802.15.4 standard.(3)
Processing unit: a PIC18F2431 microcontroller from Microchip has been used for this purpose to implement the processing module for impact detection, to separate communications from processing, and to facilitate device redesign.Figure5 shows an image of the accelerometer smart sensor implemented following the scheme proposed by the platform.Figure 5
Accelerometer smart sensor prototype.


## 3.2. MCSD Memory Footprint

Since the program memory of biomedical sensor is extremely limited, keeping the size of protocol implementation small is a critical factor. MCSD protocol simplicity enabled it to be implemented in sensors with very limited hardware resources, as the case of the accelerometer smart sensor developed. In order to analyze the memory footprint of the MCSD protocol, it was implemented in the 8051 microcontroller within CC2430 transceiver of the smart sensor using the IAR Embedded Workbench toolbox. Table1 shows the size of program code obtained for the implementation of MCSD protocol in comparison with the IEEE 802.15.4 standard and other energy-efficient protocols. The results disclose the code efficiency of MCSD protocol.Table 1
Memory footprint of MCSD and other MAC protocols.
Protocol
Memory footprint
Reference
Resources employed
MCSD
4149 bytes
This work
8051 microcontrollers within CC2430 transceiver
IEEE 802.15.4
26776 bytes
[25]
ATMega1281 microcontroller with AT86RF230 transceiver
B-MAC
25112 bytes
[43]
TelosB mote with CC2420 transceiver
X-MAC
25304 bytes
[43]
TelosB mote with CC2420 transceiver
S-MAC
24326 bytes
[43]
TelosB mote with CC2420 transceiver
T-MAC
22096 bytes
[43]
TelosB mote with CC2420 transceiver


## 3.3. Validation of the MCSD Protocol

The MCSD protocol was validated through its implementation in a monitoring application: a fall detection system. With the prototype of the accelerometer smart sensor a series of experiments were performed to analyze the energy efficiency for a real implementation.Power consumption was measured experimentally using an equivalent to the configuration proposed in [40]. According to this configuration, a resistance of 10 ohms and an accuracy of 1% were placed on the way out of the current from the battery. The drop voltage across the resistor was measured with an oscilloscope Agilent MSO6032A, allowing establishing the instantaneous current consumed by the device.In order to emulate the conditions of a homecare scenario the experiments were performed in a closed room including different types of furniture (tables, chairs, closets, etc.). The DAD was located on a table and the smart sensor on the back of a volunteer (male, 33 years, 180 cm, and 97 kg). The volunteer was situated at three meters from the DAD and looking at it, so that his body was occluding the way of sight between both devices.The power consumption can then be calculated considering that the sensor was fed by a 3 V battery. To minimize energy consumption, the transceiver activated a low-power mode when it did not have to send or receive data. The internal timers allowed waking up the transceiver in accordance with the timing set of the MF. The MCSD protocol was configured with the following scheme: 64 time slots for a duration of the MF of 500 ms, reserving the time slot number 17 of the MF for transmissions of the smart sensor.The two main operation modes of the protocol were analyzed: continuous transmission of data and event-based transmission. In continuous transmission mode the device generated 40 samples per second and 3 bytes per sample, one byte per axis. In the transmission mode based on events, the alarm included 85 acceleration samples detected prior to impact and 85 samples after the impact event (1 byte per axis, 3 bytes per sample, 40 samples per second, and 510 bytes in total for about 4 seconds of acceleration data).Figure6 shows the consumption obtained in the two sensor configurations. As observed in this figure, MF structure imposes a periodicity in the sensor activity so that device observations can be restricted to the duration of a MF, where it is easy to distinguish the following intervals:(1)
T1: time interval during which the transceiver device in the sensor is listening to the beacon frame.(2)
T2: time interval during which the transceiver transmits acceleration data (only real-time transmission).(3)
T3: time interval to capture and process acceleration data.(4)
T4: smart sensor inactivity time interval.Figure 6
Experimental current consumption in real time (a) and only when an impact is detected (b) with MCSD MAC protocol.Table2 shows the experimental results obtained related to the duration of the intervals and the average power consumption in each of them, of the whole device, and only the communication module.Table 2
Consumption of the smart sensor.
Interval
Duration
Smart sensor current consumption
Communications current consumption
T
1
6 ms
28.4 mA
27.7 mA
T
2
6.2 ms
27.1 mA
26.4 mA
T
3
3.4 ms
1.9 mA
0.09 mA
T
4
21.6 ms
0.79 mA
0.09 mAGiven the structure of the MF and the current consumed at different times, it is then possible to establish an average consumption of 1.6 mA in the real-time setting (0.75 mA corresponds to the communications), which is reduced to 1 mA in an event-oriented transmission setting (listening one of every 4 BSFs). Detected retransmissions to avoid data loss were also considered to obtain these values, assuming a transmission error rate of 7%, which was obtained experimentally counting the number of failed MFs during a period of 15 minutes (both by BSF reception errors and DSF transmission errors). Furthermore, for the calculation of consumption in the transmission mode based on events, a random distribution of 10 impacts per day was considered. If the device is fed by a small battery of 1000 mAh (Panasonic CR 2477), it has an estimated operation duration of 26 days in the continuous transmission mode setting and 41 days in the transmission mode based on events.On the other hand, if only the communications are considered, the operation mode based on events allows a drastic reduction in power consumption as it is shown in Table3 (assuming 10 impacts daily).Table 3
Estimated consumption in communications of the accelerometer smart sensor (impact detection).
Average consumption for a year
No transmissions
93.66 J
Only transmissions with events
102.7 J
Continuous data transmission
2186.5 J


## 3.4. Performance Analysis of MCSD Protocol

In this section the performance of the MCSD communication protocol is analyzed from a generalized perspective. In the first place, the time delay or latency of the protocol is evaluated. This is an essential parameter in BSN, especially in critical applications, alarm management, and real-time applications. The other parameter to be analyzed is the energy consumption, which is normalized per bit of information, allowing the generalization of the results for different transmission rates. Both parameters have been determined analytically from the experimental results shown in the previous section.Considering that in each MF the sensor has only one time slot allocated, latency is evaluated as the maximum delay in the communication of an event, which in the case of MCSD protocol is the duration of the MF.The average power consumption was evaluated analytically according to (1), where CMF is the average current in a MF, T1 is the duration of the BSF reception interval according to the Table 2, T2 is the duration of the DSF transmission interval, TMF is the duration of the MF, and C1 is the average current consumption in T1, C2 in T2, and C3 during the rest of the time in low-power mode:(1)CMF=T1TMF·C1+T2TMF·C2+TMF-T1-T2TMF·C3.Taking into account that the sensor is powered by a battery of 3 V, energy consumed per bit is calculated according to (2), where Eb is the energy consumed per bit, NB is the number of bytes transmitted in the payload of the DSF (90 bytes), and PER is the probability of error (0.07):(2)Eb=CMF·3·TMFNB·8·1+PER.The graph of Figure7 shows the results obtained for different interval durations of the MF, from 31.25 ms to 1 hour. In this figure, the average power consumption per bit is represented versus the latency associated. This form of representation facilitates the comparison with other communications protocols, as both parameters are difficult to compare in many cases due to the wide variety of cases presented by different applications. Since both parameters are interrelated, simultaneous evaluation of both of them allows establishing a standard framework for the contextual approximation to different results. This representation allows generalizing the results and approximating the energy consumption that a specific application would need in function of the data amount to be transmitted and the latency required.Figure 7
Average power consumption per bit versus latency of MCSD and other protocols.Figure7 also highlights the benefits of consumption and time delay of the communications protocol compared with various wireless communications standards and other protocols proposed recently. These data were evaluated from the results confronted of the latency and consumption provided by different publications (BLE [41], Zigbee [41], ANT [41], Modified SCPMAC [24], Queue MAC [24], pQueue MAC [24], WiserBAN [23], and RMAC [42]).Finally, it should be added that the scalability of the system was tested experimentally in a setup with the participation of up to 16 devices, although a larger number of devices are possible. The system was not affected by the increased load on the network, as each device had assigned its own time slot for the transmissions.


## 4. Conclusion

The proposed hardware and software platform has shown its feasibility for the development of smart sensors in energy-efficient BSNs. In this type of networks, the minimization of energy consumption and low latency are two priority objectives to improve the portability with devices with greater autonomy and ensure a rapid response to alarm conditions. The platform has been validated through its application in a accelerometer smart sensor for fall detection in the elderly. The implementation of the platform allows a drastic reduction of the energy consumption associated with communications via a modular processing scheme in the sensors based on the abstraction of the bioinformation and the event detection. Thus, a reduction of 95.3% in the total energy consumption of the sensor, including the continuous sensing process and the real-time processing, is obtained using the event-based mode of transmission. The proposed scheme significantly reduces the amount of data transmitted while facilitating the integration of new functionalities into the devices or the modification of existing ones.To develop the communications a medium access control protocol has been proposed, specifically designed to minimize the power consumption in the scheme of information derived from the operation modes of the processing modules of the platform, which in turn is especially adapted for biomedical environments. This protocol also avoids the idle listening, the packet collision, and the overlistening, minimizing the control messages, which are the main causes of energy loss in BSNs. The experimental results obtained with the implementation of the proposed communication protocol have shown better performance of energy consumption in communications and time delay compared with low-power standards and other recent proposals. These results highlight the validity of the solution for the development of BSNs. In addition, the distributed processing architecture and the proposed protocol provide a novel framework for the implementation and communication of parallel applications within smart biomedical sensors.



---

*Source: 431798-2015-07-30.xml*