THE MEDIATION DEVICE (MD)
 
THE MEDIATION DEVICE (MD)
4.3.1 The Md Protocol
The time-average power consumption of a network node can be
written as
where
-
P = time-average power consumed, W
-
α = duty cycle of operation
-
Po = power consumed while
in active operation, W
-
Ps = power consumed while
in standby mode, W
To reduce the time-average power consumption, both the operation
power and the standby power should be reduced. For a given technology and set of
applications supported by the network, however, a practical limitation exists
for both the operation power and the standby power. For most applications, the
operation power is much larger than the standby power:
Under this assumption, we can see that by reducing the duty cycle,
low power consumption levels and associated long battery lifetimes can be
reached. For example, for a node with 10-mW operation power and 10-μW standby power, if the duty cycle is 0.1 percent, then
the time-average power drain is about 19.99 μW. If
the node is supplied by a 750 mAh AAA battery, linearly regulated to 1 V, it
will have a battery life of more than 37,000 hours, or more than 4 years.
For such an aggressive low duty cycle system, it is very difficult
for nodes to discover and synchronize with each other; all nodes in the network
are inactive 99.9 percent of the time the network is in operation. To keep the
power consumption to a minimum, and still achieve reliable communication, a
mediation device (MD) is introduced. The MD acts as a mediator between wireless
devices within the network, and is capable of recording and playing back control
message related information, as illustrated in Exhibit 2.
Exhibit 2: Mediation Device Operation
In normal network operation, each node in the network transmits a
short (< 1 ms) query beacon, listing its node identity (address) while
stating that it has no message traffic for any other node and is available to
receive traffic. Following each beacon, the node listens for a short period to receive any replies. The beacons are sent at
a fixed, periodic rate defined for the network (e.g., every 2 seconds); however,
because the time bases for the nodes are independent and generated from
inexpensive components, beacons may slowly drift in time, with respect to each
other, in an uncontrolled fashion. This creates an unslotted ALOHA multiple
access mechanism. If a node generates a message for another node, it indicates
this by stopping query beacon transmission and instead transmitting a
request-to-send, or RTS, beacon, containing its address and the address of the
message destination. The RTS beacon exactly replaces the query beacon; it is
sent periodically at the same rate and, like the query beacon, is followed by a
brief receiving period.
In the simplest case, and for pedagogical purposes, the MD may be
assumed to be mains powered, with its receiver continuously active. It records
(or, equivalently, calculates from an internal timebase) the relative time
differences (offsets) between the received beacons of each node in range.
Because the data throughput of wireless sensor networks is expected to be low,
the majority of the beacons the MD receives will be query beacons.
Assuming node A needs to send a message to node B, a message
transfer would proceed as follows:
-
Step 1: Node A begins to transmit a series of RTS beacons
and waits for an RTS reply message. Node B is asynchronous with node A, so it
will not be able to directly receive node A's RTS beacon. The MD will record
node A's RTS beacon, which includes the identity of both node A and node B.
-
Step 2: When node B wakes up, node B transmits a query
beacon. The MD records the time offset between the beacon schedule of node A and node B (i.e., the time difference between
the RTS beacon of node A and the query beacon of node B). Upon reception of node
B's query beacon, the MD transmits a query response message to node B,
indicating the message available at node A, and including the time offset
between the two nodes.
-
Step 3: After node B receives the query response message
from the MD, node B adjusts its timing and synchronizes with node A, which is
still transmitting RTS beacons. Node B now transmits a CTS packet to node A
during the receiving period of node A, and the two nodes may start transferring
the message.
-
Step 4: After acknowledgment of message receipt, node A
returns to periodic transmission of query beacon packets. To avoid collisions
with node A, node B readjusts its timing to its original state and also returns
to periodic transmission of query beacon packets.
A detailed timing schedule procedure for this protocol is
illustrated in Exhibit
3. Intuitively, the MD is seen to function in a manner analogous to that of
a telephone answering machine; callers may call, and machine owners may listen
to their machines, in an asynchronous manner, but the scheduling information left in the recorded message (e.g.,
"Please call at noon today.") enables both caller and owner to temporarily
synchronize and achieve communication. This synchronization of network nodes
only when communication is necessary is known as "dynamic synchronization." Note
that the particular sequence of beacons received at the MD (i.e., which beacon
was received first) is unimportant; should device B's beacon have been received
first, the MD would still be able to calculate the proper time difference and
transmit it to device B.
Exhibit 3: Timing Schedule for the Mediation
Device Protocol
4.3.2 The Distributed MD Protocol
The MD can be a dedicated device, as just described;
however, ensuring the placement of an MD within range of all network nodes only
implies the type of system administration and planning that self-organizing
wireless sensor networks attempt to avoid. Further, requiring the MD to receive
constantly is not compatible with the concept of a low-power network. An
improvement on this situation can be realized if the MD function is distributed
throughout all nodes in the network. In this scheme, each node in the network
temporarily operates as an MD at a time chosen by an independent random process
(i.e., a node begins operation as an MD at a random time, independent of other
nodes). To ensure all beacons within range are received, each node receives for
a period of time equal to one beacon period, plus the length of a beacon
transmission, and then makes transmissions required of an MD to other network
nodes when the nodes are receiving. After this procedure, the node returns to
normal (i.e., non-MD) operation. Because each device functions as an MD only
rarely, the average communication duty cycle of each device can remain very low,
and the overall network to remain a low-power, low-cost asynchronous
network.
Assuming node A needs to send a message to node B, a message
transfer under the distributed MD protocol would proceed as follows:
-
Step 1: Node A begins to transmit a series of RTS beacons
and waits for an RTS reply message. Nodes B and C are asynchronous with node A,
and so will not be able to directly receive node A's RTS beacon. However, at
this time, node C changes to "MD mode," as the result of a random process, and
will record node A's RTS beacon, which includes the identities of both node A
and node B.
-
Step 2: When node B wakes up, node B transmits a query
beacon. Node C, still operating in MD mode, records the time offset between the
beacon schedule of node A and node B (i.e., the time difference between the RTS
beacon of node A and the query beacon of node B). Upon reception of node B's
query beacon, node C transmits a query response message to node B, indicating
the message available at node A and including the time offset between the two
nodes.
-
Step 3: After node B
receives the query response message from node C, node B adjusts its timing and
synchronizes with node A, which is still transmitting RTS beacons. Node B now
transmits a CTS packet to node A during the receiving period of node A, and the
two nodes may start transferring the message. Node C, having completed its MD
function, returns to normal operation and begins transmitting regular query
beacons.
-
Step 4: After acknowledgment of message receipt, node A
returns to periodic transmission of query beacon packets. To avoid collisions
with node A, node B readjusts its timing to its original state and also returns
to periodic transmission of query beacon packets.
A detailed timing schedule procedure for this protocol, the
"distributed Mediation Device protocol," is illustrated in Exhibit 4.
Exhibit 4: Timing Schedule for the Distributed
Mediation Device Protocol
The distributed MD protocol
overcomes many weaknesses of the original MD protocol. Because the MD function
is randomly distributed among all network nodes, there is no need to precisely
locate dedicated MDs to protect against network portioning. Further, because
each device only rarely becomes an MD, its duty cycle is not unduly affected.
However, message latency may be affected, because a node must wait for a nearby
node to become a mediation device to transmit a message. Message latency of the
distributed MD protocol is analyzed in Section 4.4.
One issue with the distributed MD protocol is the possibility that
two nodes may enter the MD mode simultaneously. If these nodes are both within
range of nodes A and B, the MD nodes will simultaneously respond to node A's RTS
beacon, resulting in a packet collision at node B and a failure of node
synchronization.
This issue is addressed in two ways. When an MD finishes its MD
reception period, it transmits a short beacon announcing this. Any other MD
listening is now aware of the first MD, and can either (1) go to sleep and
assume that the first MD will handle any available message transfers or (2)
remain listening and eavesdrop on the activities of the first MD. If the first
MD handles all RTS beacons heard by the second MD, the second MD takes no action
and returns to sleep; however, the second MD may hear an RTS beacon from a node
outside the range of the first MD, upon which the first MD (of course) does not
act. The second MD may then respond to that RTS beacon without fear of
interference from the first MD.
The second method of avoiding MD collisions is to randomize
the MD period of each node within a range. A range of ± 25 percent about a
nominal value is an appropriate value; after each MD activity, the node selects
a random time period within this range to wait before entering MD mode again.
This prohibits nodes from synchronizing their MD activities and repeatedly
interfering with each other.
4.3.3 "Emergency" Mode
In some applications, only the minimum possible message
latency is permissible. Applications such as security systems require very low
message latency, yet still require very long battery life. This may be an issue
with the distributed MD protocol, especially if the beacon period is long (for
low duty cycle and good battery life) and only a few network nodes are within
range. A solution to this problem is the use
of the distributed MD protocol, while disabling the random process used to
induce nodes to act as MDs. Instead, nodes begin "MD mode" only when a message
is generated (or received for forwarding). During the MD receiving period, the
node receives the beacon of the desired node (if present); the node then
contacts the desired node and transmits the message. This mode has the advantage
of minimal latency; however, it adds the duty cycle overhead of receiving for
half of the beacon period (on average) for each transmitted message. If messages
are frequent, this can seriously affect battery life. For some applications,
such as security systems, messages are infrequent, and this may not be an issue.
Also, note that, as described in Section 4.4, if a significant number of nodes are within
range, the latency of the distributed MD protocol can be acceptably
low.
4.3.4 Channel Access
The MD protocols described so far do not consider channel
access per se; they rely on the ALOHA strategy (due to the low data
throughput/channel capacity ratio) to minimize packet collisions within the
network. This would be quite suitable if the network was a licensed service and
no other services were present in the channel.
Implementation of wireless sensor networks is expected to be
mainly (if not exclusively) in unlicensed radio bands, however. The selection of
a suitable channel access technique for a wireless device operating in an
unlicensed radio band, such as an Industrial, Scientific, and Medical (ISM)
band, is a complicated one, especially if coexistence with other services, such
as WLANs, is required. In an unlicensed band, the usual assumption made in
licensed bands that any signal present must be from the same network, or at most
a different network in the same service, does not apply; any signals, from
sources as varied as microwave ovens and WLANs, may be present. In such
interference-limited cases, if a Carrier Sense Multiple Access with Collision
Avoidance (CSMA-CA) strategy is employed, based solely on detected energy in the
channel, the "fairness doctrine" for channel access often fails. Data throughput
may suffer as the device repeatedly backs off in the presence of interference
from other services. Some of these services will not employ CSMA-CA in return to
ensure channel access at a later time (e.g., microwave ovens). In the MD
protocols, channel status assessments are not made prior to beacon transmissions
because beacon timing is of critical importance to network operation. Because
the duty cycle is so low, this causes little interference to other coexisting
services. One alternative to this approach would be to employ a simple channel
energy detection CSMA-CA algorithm with the backoff quanta set to be a beacon
period (i.e., devices back off only in multiples of the beacon period).
For channel status assessment in unlicensed bands, it is
generally necessary not just to detect energy in the channel prior to
transmission, but also to identify (as far as possible) the signal present. This
must be done quickly, for the channel status (i.e., presence of interference)
may change rapidly; in addition, channel status assessment costs precious
battery life. Algorithms meeting these requirements are an area for future
research.
144 times read
|