Published.

I've gotten a poster accepted at LCN!

Notice how I'm not saying, "I've been accepted at LCN." That's deliberate. If I'm going to keep my ego out of my work, I've got to start now.

Anyway, the paper is presenting the architecture for tetherless care, and, to be honest, I was expecting a rejection. I had a clearly defined and well articulated architecture (on which I needed peer-reviewed feedback), but I'm in the process of building the prototype and don't yet have the environment in which to fully test the idea. As such, my experiments and verification were a little light.

A Vague Research Plan

I've been wondering how to know whether we've "captured the context" of the patient in our system. It seems as though we'd need another source to confirm that the determined or computed context is indeed the actual context. And this leads me to believe that we should ask the user to describe their situation from time to time.

To enhance a DTN, our system needs to provide any application with information to make a decision regarding the state of the network and the available energy. When a message needs to be sent, there's a question of whether to transfer it now using whatever means are available, to wait for better opportunities (requiring less energy or having a higher probability of deliver), or to panic and declare it's not worth it to attempt delivery of the message (no network or contact is going to be available in time, there's not enough power). The question is to determine the inputs to that decision making process and to determine how correct it is at making that decision.

For the final piece, we'll need to slice the system in half such that the tetherless care application falls to one side and the tetherless care middleware to the other and then glue the two back together with an API. Where there is an infinite number of ways to do this, we have to determine a good one. The problem here is that I don't yet know how to necessarily prove 'good'.

There are a set of properties we'd like this middleware to possess:

Easy to Develop Tetherless Care Applications

It should be easy to incorporate the system's pieces into a range of tetherless care applications.

Modular

Individual components should be replaceable if alternative or improved functionality is desired.

Versatile

It should support a wide range of use cases and potential applications.

I don't yet see how to scientifically demonstrate that these have been met. At best, it seems I can show a proof of concept.

New Questions

Three questions I need to answer:

Can we develop an abstraction to capture context and situations of the tetherless patient that can be efficiently implemented on a resource constrained device?

Is it possible to enhance DTN networks to exchange information between tetherless patients and healthcare professionals in a reliable and timely fashion?

Is it possible to seamlessly integrate these functional components into a coherent framework to support tetherless care?

Update

I predictably failed to keep up on this all this year. Nevertheless, I've been making progress (finally!!!).
I proposed my thesis topic at the beginning of November, and sort of passed that milestone. I say "sort of" because the idea I proposed was good, but my intended research plan lacked focus and was far too much work.... criticism with which I can agree. At least, the last two and a half years of putting that together weren't a complete waste.

I was told and have heard before that a synthesis of parts is an acceptable contribution for a Ph.D, and that I can narrow my focus down to the construction of a proof-of-concept prototype for tetherless care (side note: we moved from referring to "the tetherless patient" to "tetherless care"). The prototype must be context aware and operate despite communication challenges (think crappy WiFi and 3G/4G signals).

What lingers in my mind is the role of experimentation in this process. What needs to be tested when you're putting building blocks together.

Winter Break

It's always hard to keep my focus through semester breaks. Despite being the perfect time to get some work done, it's so much easier to get distracted and to be lazy. My exercise in Zen is trying to accomplish something in the next two weeks.

Finally Continuing Chapter 3

I had returned to my introductory chapter because, during my first trip to my third chapter (the main one), I discovered I didn't really have a footing for my discussion. I'm finally now back to where I left off.

The Basic Outline

The idea here is reiterate the main questions I posed in the first chapter, and then briefly discuss how I expect to answer each of them, which amounts to the development of this middleware and routing protocol along with a study of the application traffic characteristics.

That discussion should segway into a more in depth discussion of the middleware and its various components. I think, here, I'll finally start introducing the plan for a publish/subscribe interface. I have to connect that information to the routing protocol. And I should probably introduce a location service... although, I don't think I'm going to go into much study there. The tether-less patient just needs location information at the application level, so that the middleware will probably manage and provide that information. However, the info might be useful for routing....

After that, it's finally the research plan, which I already have written... unless I (or my committee) feels like changing it.

Routing and its Environment

I already laid out the questions about the networking environment for the system. What I need to recognize is that there's a relationship between the information that is collected about the environment and the routing algorithm that uses that information. We can change the information we collect to better suit the algorithm, and we can change the algorithm to exploit other information.

This relationship gives us a lot of freedom, but we're constrained by what little knowledge we can collect and the application requirements. The algorithm must be able to effect on-time message delivery, and we must then ask whether it's possible to determine if the network can provide that service to us. Can we construct an algorithm that determines if on-time delivery is possible?

Application Data Model

Here's the basic set of statements arguing for an accurate data model in my study:

Deadline and Reliability Requirements

We're trying to extend the tether-less patient system beyond its current environment.

We're limited in this effort by the application's demands, most notably the delivery deadlines of the messages. If we had infinite deadlines, we could use the cheapest means of transmission in all cases, tolerate the longest delays possible, and "operate" in any environment. As the deadlines shorten, we have to make more informed choices and better infrastructure needs to be available (to accept a given message into the middleware for delivery).

Therefore, we need to know how the deadlines behave.

Their behavior depends on usage behavior.

Therefore, the questions we need to ask relate to how healthcare professionals use the system. Would they ever check in on a patient outside the hospital if everything is normal? Would they trust the devices to alert them to problems? Does the use case reduce to a notification that an important event occurred with the patient? How do these notifications vary in their urgency? How frequently can these notifications occur? Can healthcare professionals accept that a patient may not be in an environment that supports streaming data at the time of a request?

These questions beg a study on the matter such that we can generate a traffic model that both accurately depicts the application data and allows us to synthetically adjust its parameters to stress our routing protocol and middleware system.

Multiple Destinations

The second aspect I might need to consider is the multiple destinations of a given message, but I'm not sure if there's really any challenges involved in providing this functionality.

More than one healthcare professional could be interested in some patient data. We want to save power on the patient's device, so that it'd be beneficial if the patient could transmit the data once instead of addressing multiple copies of the message to each destination. This requirement is the classic multicasting paradigm. As such, the routing algorithm has to support multicasting.

With that, there are several questions we could ask: How do the destinations change over time? Does the patient's state change the set of destinations? Is infrastructure likely to be between the patient and the destinations most of the time (is routing a problem of getting messages to infrastructure)? How does the multicasting paradigm react to longer delays?

Summing it up in a Question

I need a question to sum up everything about the application data model. It consists of notifications, reports, streams, and requests potentially addressed to multiple destinations, each with a deadline and priority. We need to be able to adjust the length of the deadlines, the frequency of the notifications, and the intended destinations to mimic the behavior of an actual tether-less patient system. Such a model will allow us to comment on the potential operability scope of these systems.

Still thinking...

Networking Environment

I've been stuck on this for a couple days now. Here's what I need to talk about:

• That WiFi and 3G interfaces have different characteristics. WiFi is shorter range and varies in quality a lot more. 3G doesn't offer communication with what we might consider peer devices... only infrastructure.
• I feel like I need to talk about why they're different. They both use the airspace around us, but they have different characteristics. ... does my audience know why or need to know why?
• I need mention Bluetooth.
• I need to put things in a broader context of what any wireless radio and network protocol offer where Bluetooth, UMTS/EVDO (3G), 802.11, and LTE/WiMax (sub-4G) are just the current incarnations.
• Must introduce the concept of a contact: coming in and out of communication range
• The idea of a contact implies the importance of movement in wireless networks.
• It's the nature of the patient's movements that we have to study.
• Ask how the general intermingling of a population expresses itself in a time-varying network graph (not the first to ask this question).

And I'm probably going to come up with more too.

The section should ultimately arrive at the

Breaking down the Question

I outlined two sources of challenges for the middleware in a previous post: the networking environment and the application data demands. What I need to do is discuss the needed or possible responses in each of those areas, the questions they raise. Therefore, I'm designing the section around that structure:

1. Middleware Design Issues: Network Environment
2. Middleware Design Issues: Application Data Demands
3. Middleware Design Issues: Routing Algorithm

First, though I have to point out the contradiction between long network delays and real-time requirements. The two properties contradict (and make this work interesting). We know, though, that prototypal systems have been built on wireless communication technology, so that we then know there are wireless environments that can be provisioned to support these systems. The question I want to ask, then, is can we extend beyond those environments because the patient, going about his or her life, is probably going to bring the system beyond intended environments. We might also ask if, by adopting these techniques, we can reduce the provisioning needed in those intended environments.

To answer those questions, we need to know more about the environment. We also need to develop a new networking paradigm, which is the basis for my proposal.

What We Already Know

What follows is a list of facts I can use later to support my argument (believe it or not, I forget and rediscover these guys in my notes all the time). My plan is to continually edit this post as needed.

• Prior Work has demonstrated that a body area network can be built around a human.
• Prior Work has demonstrated that some wireless environments can support the needs of a tether-less patient system.
• DTN has provided a blueprint for dealing with disconnected environments, albeit by introducing unbounded message delays.
• Wireless technologies have different power requirements. WiFi, at its best, is faster and requires less energy than a 3G radio. If it's retransmitting packets a lot, though, it loses.

The Question

The main question I'm hoping to arrive at:

Can we deploy a middleware for the tether-less patient system that attempts to support the real-time and reliability demands of the tether-less patient application in the face of extremely variable and power constrained communication environments?

The task now is to break this down into a set of questions. I already have the problems to solve written for the most part. It's a matter of connecting dots now.

Communication Constraints of Tether-less Patient Systems

A constraint is essentially something about the object under study that can't really be solved. A solution has to work around it. Challenges are sort of the same thing, except that they may offer the potential to be solved. Nevertheless, a solution can work around a given challenge if it doesn't solve it outright. The line between the two is somewhat blurry, e.g. maybe some day we'll solve that whole pesky friction thing when we don't want it to be around. In light of that, we can think of both of them as the properties of the studied object that make the solution... fun.

Constraints of The Tether-less Patient Communication Environment

1. Communication Variability. From the patient's perspective, wireless signals fade in and out as he or she moves about a space.
2. Multiple Communication Technologies. The patient's environment probably has multiple wireless technologies available. There's no need to marry the system to one of them if we can potentially use all of them (well). Furthermore, newer technologies are emerging constantly. The airspace offers an increasing number of choices.
3. Varying delays. A direct, synchronous, end-to-end connection to one or more destinations cannot be guaranteed... especially in a wireless environment. Rather than take the perspective that this results in failures, we can take an understanding that a connection may become available later or that another device in the vicinity can offer a connection. From this perspective, the network offers extended and widely varying delivery delays.
4. Power. Smartphones run on limited battery power.

These issues are introduced mainly as a consequence of the patient's mobility.

Constraints imposed by the Tether-less Patient Application

1. Real-timeliness. Messages have to get delivered by some deadline. For some, the deadline is pretty lax. For others, we could use the phrase "as soon as possible."
2. Reliability. Some messages absolutely have to get delivered without failure (for all intents and purposes). Others can be lost without severe degradation to the data or the systems' mission.
3. Multiple Destinations. A given message may need to be sent to more than one destination.

Revisiting my Introduction

I thought I was past the introduction of my proposal, but, after getting back into the flow of the narrative I'm developing, I realized I haven't fleshed out a specific set of questions yet.

I give my reader a description of a typical Tether-less Patient System, and, from there, I have to begin a focus on the communication aspects of the system and the constraints/challenges imposed on this part of these systems, ultimately (hopefully) arriving at the set of questions I will address.

Continuing my Proposal

I need to finish this thing up.

I've been hung up on the social-based multicasting work out there. After implementing social-based DTN routing in the simulator, I have to come back and write up a section in my literature about it. I've since lost the narrative thread I was on, and the semester's distractions aren't helping me find it again.

My ONE Simulator Contributions

Created a new page on my website listing all the software I've written for the ONE Simulator.

Opportunistic Network Environment Simulator

I've been using a simulator called the ONE (great name, I know) to emulate the movement of mobile nodes. The great thing about it is that I can import real world maps and make the hosts move along specific paths through them. I, therefore, picked none other than Pittsburgh as the basis for my simulation. Here's a picture:

I've probably been annoying the rest of my department as my simulations are taking up all of our condor computing resources. Some trials have been running for almost a month, and I'm starting to get annoyed. I have to reduce the number of nodes I define in the simulation next time.

Life's Dependencies

Was talking to my officemate about the average computer user and their poor computing habits (poor password choices, not keeping their software up-to-date), which essentially let's botnets flourish. It also gives those of us in-the-know a lot of power over anyone who doesn't care about the inner workings of their computers.

Most people don't care how it works, only that it works.

I'm not like that. I have to (1) know every system on which my survival and lifestyle depend and (2) how those systems work: Financial Systems, Food Distribution, Transportation, Utilities, Cars, Motorcycles, The Internet, Governing Bodies. I must know how they all work.

Requirements

Four requirements really dictate the design and influence the architecture of a tether-less patient system. I have to present them to avoid questions about why this architecture versus other possible architectures. Without further ado and straight from my proposal draft:

Mobility Support

At its core, the tether-less patient paradigm amounts to the introduction of patient mobility to the traditional hospital monitoring scenario. The primary goal is to provide a similar level of monitoring while the patient goes about his or her normal routine.

Pervasive Operation

Patients too encumbered by the system's hardware will be unlikely to adopt it. As such, the system must be designed to fade into the background of their consciousness, alerting their attention as little as possible and adding a minimum of extra hardware to their person.

Management of Healthcare Professional's Time

Healthcare Professionals have limited time and oversee multiple patients. Where it may not be possible to in any way limit or discard the information delivered to a healthcare professional, the system should incorporate algorithms to intelligently monitor the patient’s situation such that the healthcare professional only be alerted to the important aspects of the situation.

HIPAA Compliance

The Health Insurance Portability and Accountability Act of 1996 stipulates that reasonable steps be taken to ensure an individual’s health information is kept confidential between a patient and his or her current healthcare professional, both through policy and technical means, except under several specific cases or unless the patient provides written authorization indicating otherwise. It defines four broad security requirements for Health Information Systems: Access Controls, Audit Controls, Integrity Controls, and Transmission Security. Access Controls must identify the system’s users (healthcare professionals) and grant access to patient information based on the role the user is currently fulfilling. Audit Controls require a system to log access grants and other activities for a period of six years. Integrity Controls require a system to put in place mechanisms ensuring health information is not altered or destroyed. Transmission Security requires steps to ensure data is not accessed in transit over a network.

Image Upgrade

Slightly improved on my previous images.

I'm getting more into infographics for communicating information. They take much longer to create, but they communicate information at a higher bandwidth, meaning you pick up the information faster.

In this one, I'm splitting the concepts I need to discuss into a conceptual abstraction of these systems and an architectural outline for them (or for the one I'm proposing).

At the conceptual level, a patient exhibits a current Situation, which is the collection of his or her vital signs together with the environmental factors that not only influence those vital signs but also impact the system itself. This Situation is the target of the systems observation and monitoring efforts. By collecting a view of it, the system can make an assessment of the patient's current state and take any needed action, such has alerting a medical professional.

We implement this observation of the patient's situation with a set of sensors attached to the patient that organize into a body area network (a low power peer-to-peer wireless network). The sensors upload their data to a central coordinator in the body area network, which, having the collected information, can implement the algorithms to assess the patients state. It can then initiate the appropriate actions to respond to this assessment.

If communication with a medical professional is needed, the middleware component handles the details of passing that communication from the coordinator to the appropriate doctor, nurse, first responder, or technician. The system has to rely on the wireless networking infrastructure in the patient's environment (since we don't want to restrict where the patient goes), which makes it tough to make guarantees about how good the connection will be... if it even has one. The middleware hides all this, taking messages from the coordinator, connecting to WiFi and 3G/4G networks as needed, and delivering them when a path is found to their recipient.

This last piece is where my work will focus.