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.