By Daniel W. Bliss
In this article, a system-level discussion of body sensor networks and their applications is provided. Because the nature of engineering, it is easy to become focused on a particular aspect associated with one’s area of expertise. Here, the engineer is encouraged to consider a wider range of issues when designing a body sensor network. A wide range of concerns is listed. For an example problem, concerns associated with logistics, communications, signal processing, and user interface are discussed in greater detail.
We have moved beyond the time in which the question “Are wireless body sensor networks useful?” makes any sense. They are here, there are numerous examples , and they are often useful. You see them in sports medicine for monitoring heart and pace. You see them medical settings in an attempt reduce the tangle of wires connected to patients. You see them being developed for first responders’ and soldiers’ welfare, who operate in extreme conditions. Over time these sensing networks will become more useful and more complicated. As much as it pains me to admit it, viewing the body sensor network as a system will become increasingly important.
Many of the current sensing networks have evolved from a specific sensing application. Because of the inevitable system requirements creep, more and more sensors, goals, and tasks are added to the original system. The result of this sort of evolution is typically some sort of “Frankenstein’s monster” system. It is the classic problem that a sequence of local optimizations often does not lead to global optimization. What’s worse, because of “historical” engineering motivations, such as held patents or device familiarity, our local optimizations are often far from optimal. There is also the problem within the engineering culture of design segmentation. We do our piece associated with our specialty and throw the design over the wall. My personal interests are related to signal processing associated with predicting physiological distress or performance [6, 5]. Human nature being what it is, it is easy to focus on topics of my interest to the exclusion of others. I will happily assure you (in demonstrating my own bias) that the most important part of body sensor networks is the signal processing, and, in particular, the feature vector construction. The goal of this article is to remind the designer to occasionally take a step back and to look at a wider range of system issues. This means on occasion, the designer will need to scrap a previous system architecture and start fresh. Furthermore, choosing a system architecture that is naturally open and scalable may alleviate many future problems.
The list of concerns for body sensor networks is vast. I will not be able to list all of them, but a few representative issues are presented in Table I.
Table I: List of body sensor network technical concerns
All of these issues are coupled and often the solutions to these issues are in tension with each other. In some sense, all of these issues are the focus of some engineering subfield, so the issues are obvious to those practitioners. However, the point of this article is that all of these concerns need to be addressed simultaneously. For the sake of brevity, I will focus on just a few issues that are particularly important to body sensor networks: node pairing, network robustness, feature construction, and user interface.
To help make the discussion concrete, let us consider a specific problem. Consider the situation of firefighters responding to a large fire. The firefighter’s body sensor network should determine their position, health, and apparatus status. This information is to be conveyed to the firefighter, his or her fellow firefighters, and back to command. To track their position, we use some combination of GPS, accelerometers and micro gyros. To quantify their well being, we track their heart rate, breathing rate, external temperature, skin temperature, core temperature, eye motion, etc. We may also want to track the status of any equipment they bring into the fire such as air tanks. With the appropriate signal processing of the data within the body sensor network, very little of the data needs to be transmitted to other firefighters or to the command post. When something unusual occurs or if the signal processing identifies some precursor to physiological distress, this information can be communicated to all parties.
Given this scenario, one can imagine a relatively chaotic environment. The firefighters should be focused on the very real danger of the fire. The first problem is node pairing. Pairing is the operation of associating a sensor node with an individual (usually represented by some hub node). While many of the sensor nodes will have been pre-paired with the firefighter many other sensor nodes will need to be paired on scene. This pairing needs to be transparent because the firefighter’s attention is on other issues. However, given that a number of firefighters will inevitably be doing this pairing at the same time in close proximity, how is the right pairing is guarantied. It is easy to imagine an accelerometer node on firefighter “A” getting paired with firefighter “B” by accident in the chaos. The resulting confused data might create erroneous warning signals or might miss important indicators of danger.
Another concern is network interference . While the body sensor network may have worked well in the controlled laboratory environment, in the chaotic real environment, the network may fail if not carefully designed. First, numerous firefighters may operate in close physical proximity. Consequently, the spectrum of the network is shared not just amongst the nodes, but is shared amongst all the nodes of the numerous firefighters. Furthermore, the same spectrum may be used by other communications systems. These external systems may unintentionally jam the network. Given the lower transmit power of sensor nodes, such inadvertent jamming may be relatively easy. Once again, the potential benefits to firefighters would be lost.
In attempting to identify the health state of the firefighter and potentially predict physiological distress, it is likely to be valuable to integrate or fuse information from multiple sensors. An approach that we have found successful in other applications [6, 5] is to develop a set of features (a feature vector) based upon functions of the observations and feed these into machine learning techniques . These algorithms combined represent signal processing approaches that enable detection of distress or hopefully detection of precursors to distress that would inform the firefighter and his or her fellow firefighters that they have exceeded their physical limitations. For most interesting problems, the combination of having access to the right sensors and the construction of the features vectors drives the performance. In some cases, good features enable signal processing techniques to extract physiological distress or performance characterization beyond what can be determined by human observers. This is a strong argument of the usefulness of body sensor networks. However, developing and demonstrating these features can require a significant research investment. Furthermore, there is often a trade between performance and the number and quality of the sensors. The optimal set of sensors may not be viable for the firefighter because of weight, cost, or other factors.
Finally, we, as engineers, must admit that we are often horrible at designing user interfaces. Yet, the usefulness of the information gained by the body sensor network may be lost because the interface is too busy or difficult to use . Engineers are often dismissive of this observation. A good engineering interface is likely to be a bad user interface and visa versa. Just as we often get tied to a particular architecture, it is easy to get overly fond of one’s control and display interface. User acceptance of a technology often has more to do with the interface than the technology. Consequently, one should not view the interface as the thing that gets tacked on at the end of a project. For our firefighter, the user interface concern is particularly important. It must be simple, yet informative. Without working with firefighters directly and iterating on the user interface design, it is unlikely that a good interface could be developed.
In my opinion, we are on the precipice of an exciting period in body sensor network research. As the sensors become smaller and cheaper, and the signal processing becomes richer, there are a range of important problems that can be addressed by the use of body sensor networks. However, in attempting to address these problems, a very large number of system design issues must be addressed. While potentially disruptive, the right path for the designer may often be to take a step back and take in as many of the issues as possible for both the current set of goals and for the inevitable extensions that will occur in the future. Of course, if you ask me, the signal processing is the most important aspect of this system optimization, but you already knew that I would say that.
For Further Reading
6. J. R. Williamson, D. W. Bliss, D. W. Browne, P. Indic, E. Bloch-Salisbury, and D. Paydarfar, “Using Physiological Signals to Predict Apnea in Preterm Infants,” IEEE Asilomar Conference on Signals, Systems, and Computers,” Nov., 2011.
Daniel W. Bliss is an Associate Professor in the School of Electrical, Computer and Energy Engineering at Arizona State University. Dan received his Ph.D. in Physics from the University of California at San Diego.
His current research topics include statistical signal processing, multiple-input multiple-output (MIMO) wireless communications, MIMO radar, cognitive radios, radio network performance bounds, geolocation techniques, channel phenomenology, and signal processing and machine learning for anticipatory physiological monitoring.
He is a senior member of the IEEE. He has published over 70 technical articles and conference papers, and he received the Best Lecture Award for his 2008 Tri-Service radar paper that discussed MIMO radar. Read more