Download RT-WiFi: Real-Time High Speed Communication Protocol for

RT-WiFi: Real-Time High Speed Communication Protocol for
Wireless Control Systems
Yi-Hung Wei∗ 1 , Quan Leng∗ , Song Han∗ , Aloysius K. Mok∗ , Wenlong Zhang† , Masayoshi Tomizuka†
∗ Department
† Department
of Computer Science, The University of Texas at Austin
{yhwei, qleng, shan, mok}@cs.utexas.edu
of Mechanical Engineering, University of California, Berkeley
{wlzhang, tomizuka}@berkeley.edu
Abstract— Applying wireless technologies in control systems
can significantly enhance the system mobility and reduce the
deployment and maintenance cost. Existing wireless technologies,
however either cannot provide real-time guarantee on packet
delivery or are not fast enough to support high speed control
systems, which typically require 1KHz or higher sampling rate.
Nondeterministic packet transmission and insufficiently high
sampling rate will severely hurt the control performance. To
address this problem, in this paper, we present our design and
implementation of a real-time high speed wireless communication
protocol called RT-WiFi. RT-WiFi is a TDMA data link layer
protocol based on 802.11 physical layer to provide deterministic
timing guarantee on packet delivery and high sampling rate up
to 6KHz. It incorporates configurable components for adjusting
design trade-off including sampling rate, latency variance, reliability, and compatibility to existing Wi-Fi network, thus can
serve as an ideal communication platform for supporting a wide
range of high speed wireless control systems. We implemented RTWiFi on commercial off-the-shelf hardware and integrated it into
a mobile gait rehabilitation system. Our extensive experiments
demonstrate the effectiveness of RT-WiFi in providing deterministic packet delivery in both data link layer and application layer,
which further eases the controller design and improve the control
performance.
I. Introduction
Wireless control systems (WCSs) have received significant
attention these years because of their great advantages of
enhanced mobility, easier deployment as well as reduced
configuration and maintenance cost. WCSs have been widely
applied in many application domains including industrial process control and automation [1], healthcare and biomedical
systems [2],smart structures [3], and intelligent robotic systems [4], to name a few. A key step in building a wireless
control system is to choose the most appropriate wireless communication protocol according to its desired control behavior.
Control designers generally look at three most critical design
factors when making the decision: sampling rate, reliability
and real-time data delivery. These factors directly influence the
quality of control, and the performance of the whole system.
Many existing wireless technologies have been adopted in
wireless control systems. However each of these protocols
can only support a small number of specific control applications. Some of them are based on low data rate physical
layers, like 802.15.4, and focus on the real-time data delivery
1 The
first two authors have equal contribution to this work.
Fig. 1: Vision of RT-WiFi protocol
and reliability performance, thus are only suitable for lowspeed control applications; Others including Wi-Fi focus more
on improving network throughput but pay less attention to
the deterministic behavior of data delivery, so that cannot
be adopted in control systems which have stringent timing
requirements. The lack of a flexible and high speed real-time
wireless communication platform makes it difficult to find
an ideal wireless communication protocol for many wireless
control applications and complexify the control designers’ job.
Taking our recent work [4] of designing a semi-autonomous
remote robotic system as an example, because no available
wireless technology can support both high data rate sensing
flow and real-time control flow at the same time, we have
to use a combination of two wireless technologies, Wi-Fi and
WirelessHART, which complicates the system design, prolongs
the developing time and increases the maintenance cost.
To address this problem, in this paper we introduce RTWiFi, a flexible real-time high speed communication protocol
designed for supporting a wide range of wireless control
systems. We keep the following goals in mind when we design
the protocol:
Real-time Data Delivery and High Sampling Rate: Control applications rely on bounded latency for estimating and
controlling the state of target system. Our previous research
[5] shows that a control system usually prefers a sampling
rate higher than 1kHz. Thus, RT-WiFi is based on 802.11
physical layer. To achieve deterministic timing behavior, we
adopt TDMA mechanism in the RT-WiFi data link layer design
for channel access and set stringent timing requirement on the
transactions in each time slot.
Flexible Data Link Layer Configuration: Different control
applications may have different communication requirements
on data delivery, it is hard to apply a rigid design to a wide
range of applications. We envision to design RT-WiFi as a
configurable platform, such that control designers have great
flexibility to choose their own design parameters according
to their target applications. These design tradeoff include
sampling rate, energy efficiency, communication reliability,
real-time data delivery, and co-existence to existing Wi-Fi
networks.
Transparent System Design: In order to make RT-WiFi easily
available and simple to integrate with the existing applications,
it should reuse current hardware and make minimum changes
on softwares. Users should be able to use RT-WiFi on the
commercial off-the-shelf (COTS) IEEE 802.11 network interface, and existing application should be able to run on top
of RT-WiFi with no or only minimum changes. Additionally,
the transparent system design allows us to use existing 802.11
security techniques and build mesh networks easily.
Our contributions in this paper are three-fold:
•
•
•
We designed the RT-WiFi protocol to provide a
flexible real-time high speed wireless communication
platform for a wide range of wireless control systems. According to their target applications, control
designers can customize their design tradeoff among
sampling rate, jitter level, reliability, and compatibility
with regular Wi-Fi network. RT-WiFi supports up to
6kHz sampling rate in our selected COTS hardware,
and to the best of our knowledge, this is among the
highest sampling rates that can be supported by any
existing wireless real-time communication protocols.
We built a prototype for the RT-WiFi protocol on
COTS hardware. We shared our first-hand experience
in addressing the challenges we met during the RTWiFi implementation and discussed how to choose
design parameters that helps users to customize RTWiFi depending on their target applications.
We presented a comprehensive case study to utilize
the RT-WiFi protocol to integrate heterogenous sensors and assistive robotic devices together to build
a mobile gait rehabilitation system and evaluate the
performance through extensive experiments.
The remainder of this paper is organized as follows: In
Section II we give a review on existing wireless protocols
applied in wireless control systems. We present the system
design of RT-WiFi in Section III, and describe the implementation details in Section IV. We describe the use case of a
mobile gait rehabilitation system in Section VI. We conducted
extensive performance evaluation on RT-WiFi and summarize
our experimental results in Section V. Section VII concludes
the paper and discusses the future work.
II.
Related Works
There are some well-developed wireless protocols which
can be used for wireless control. They include Bluetooth [6]
and Zigbee [7] for home automation, WirelessHART [1] and
ISA100.11a [8] for industrial process control, MBStar [9]
for body area networks and so on. However these protocols are not perfect for high speed wireless control. Bluetooth [6] cannot guarantee real-time data delivery, except
for voice packets. Zigbee [7] can provide real-time data
delivery in beacon-enabled mode, but the data rate is limited
to 250kbps. WirelessHART [1] is a Time division multiple
access (TDMA)-based wireless protocol, which is specially
designed for industrial process control. It can provide realtime communication, but the maximum sampling frequency
is only 100Hz. ISA100.11a [8] is a another wireless protocol
which is developped by International Society of Automation
(ISA) to support industrial wireless control neeeds. Similar to
the problem of WirelessHART, the data rate of ISA100.11a
is low. MBStar is designed to provide higher sampling rate
than WirelessHART for process control, but the highest rate it
can reach is 400Hz, which is still far away from the preferred
sampling rate for some applications.
Zigbee, WirelessHART ,MBStar and [10], [11] cannot
provide high enough sampling rate because their physical
layer (IEEE 802.15.4 [12]) is designed for low rate wireless
personal network. Comparatively Wi-Fi, based on IEEE 802.11
[13], is a wireless protocol designed for high speed wireless
local area newtork and can have data rate up to 150Mbps
(IEEE 802.11n). However, Wi-Fi does not provide any realtime guarantee on data delivery.
Wi-Fi normally operates in distributed coordination function (DCF) mode, in which each station use distributed randomized algorithm to access the channel to avoid collision.
Thus the delivery time of data is not deterministic. In Wi-Fi,
there is another optional access method: Point coordination
function (PCF) [13] In PCF, the access point (AP) operates as
a point coordinator (PC) and determines which station has the
right to transmit the data. Unlike DCF, PCF is a centralized
channel access method. PC divides the interval between two
beacon frames into two periods: contention free period and
contention period. In contention free period, PC coordinates
the data transmission and in contention period, stations use
DCF to access the channel.
Although PCF can be used to schedule packet transmission,
it cannot rely on any timing information, and thus does not
provide real-time data delivery guarantee. Also, once a station
get the access to the channel, it may occupy the channel
for a non-deterministic time. Thus, it is not sure when the
subsequent packets will be sent.
TDMA is a channel access method which relies on accurate
timing information and may potentially provide real-time data
delivery. Some TDMA protocol have been proposed [14], [15],
[16], [17]based on IEEE 802.11. However, both of [14], [15]
are focused on the time synchronization issue of multi-hop
network. They are not targeted at providing flexible platform
for control application, and they does not consider the coexistence with regular Wi-Fi network. On the other hand, the
purpose of [16], [17] is to provide efficient long range wireless
network in rural areas. It is because the original CSMA/CA
EĞƚǁŽƌŬ
DĂŶĂŐĞƌ
ŽŶƚƌŽů
ƉƉůŝĐĂƚŝŽŶ
ZdͲtŝ&ŝ
ĐĐĞƐƐWŽŝŶƚ
ƉƉůŝĐĂƚŝŽŶ
ŽŶƚƌŽůƉƉůŝĐĂƚŝŽŶƐ
dƌĂŶƐƉŽƌƚ
hWͬdW
EĞƚǁŽƌŬ
/W
ZdͲtŝ&ŝ
YƵĞƵĞƐ
ZdͲtŝ&ŝ
^ƚĂƚŝŽŶϭ
ZdͲtŝ&ŝ
^ƚĂƚŝŽŶϮ
ZdͲtŝ&ŝ
^ƚĂƚŝŽŶϯ
dŝŵĞƌ
&ůĞdžŝďůĞŚĂŶŶĞů
ĐĐĞƐƐŽŶƚƌŽůůĞƌ
DĞƐƐĂŐĞ
,ĂŶĚůŝŶŐ
DŽĚƵůĞ
D
ĐƚƵĂƚŽƌϭ
^ĞŶƐŽƌϭ
ĐƚƵĂƚŽƌϮ
^ĞŶƐŽƌϮ
ĐƚƵĂƚŽƌϯ
^ĞŶƐŽƌϯ
DĞƐƐĂŐĞ
,ĂŶĚůŝŶŐ
DŽĚƵůĞ
Fig. 2: A example of RT-WiFi-based wireless control system
>ŝŶŬ^ĐŚĞĚƵůĚĞƌ
^ƵƉĞƌĨƌĂŵĞ
dĂďůĞ
>ŝŶŬ
dĂďůĞ
ĞǀŝĐĞ
WƌŽĨŝůĞ
YƵĞƵĞ
mechanism in Wi-Fi network is inefficient when Wi-Fi is used
for outdoor long-distance communication. The main objective
of them is to increase the throughput of the network, but not
to provide high sampling rate real-time data delivery.
III.
RT-WiFi Protocol Design
In this section, we describe the design details of RT-WiFi
protocol. RT-WiFi is a data link layer protocol based on 802.11
PHY and aims to provide real-time data delivery for a wide
range of wireless control systems from low-speed industrial
process control to high speed mechanical device control.
The design goals of RT-WiFi are to provide both realtime high sampling rate and application-dependent flexible
data link layer configuration. Real-time data delivery is crucial
to control systems because control applications rely on precise
timing for monitoring and controlling the state of a system.
High sampling rate is required to achieve good quality of
control and to support ever-increasing number of sensors and
actuators in a control systems. For instance, a communication
protocol is required to support an aggregate 2KHz sampling
rate for a control system with one sensor and one actuator,
if both of them demands 1KHz sampling rate. For supporting
a wide range of control applications, the design of RT-WiFi
shall consider the various requirements of different types of
control applications. The design philosophy of RT-WiFi is to
provide enough freedom for control designer to choose their
preferred communication behavior, which best fits to their
existing controller design. At the same time, the design of
RT-WiFi minimizes the modification on the original Wi-Fi
protocol, so that it can be transparent to both the upper layer
software stack and underlying hardware, and provide the most
compatibility and usability.
Figure 2 shows the typical architecture of a control system
that adopts RT-WiFi network. In this case, a system architect
plans to deploy three sensors and three actuators in this control
system. Depending on the physical proximity of each sensor/actuator, they are attached to different RT-WiFi stations. In
a RT-WiFi network, a network manager and control programs
are running on top of RT-WiFi access point (AP). The network
manager is software in the application layer that is responsible
for configuring the RT-WiFi network based on the communication requirements specified by a control designer. The network
manager dynamically allocates the communication links and
generates network configuration to configure the data link layer
of RT-WiFi AP and RT-WiFi stations. After the configuration
stage, RT-WiFi network periodically transmit the sender data
to and receive control data from the control application. In the
WŚLJƐŝĐĂů
/ϴϬϮ͘ϭϭŽŵƉĂƚŝďůĞ,ĂƌĚǁĂƌĞ
Fig. 3: System architecture of RT-WiFi protocol
following, we are focusing on the design and implementation
of the RT-WiFi data link layer.
Fig. 3 presents the overall architecture of RT-WiFi protocol.
At the very bottom, RT-WiFi adopts the physical layer of
IEEE 802.11 [13]. IEEE 802.11 is one of the most pervasively
adopted wireless technologies and supports up to 150Mbps
bandwidth which is sufficient for most wireless control systems. Control application users can easily deploy the RTWiFi data link layer on a commercial off-the-shelf IEEE
802.11 compatible hardware for supporting high speed and
real-time data delivery. Sitting on top of the 802.11 PHY is
the RT-WiFi data link layer which will be elaborated in the
remaining of this section. The RT-WiFi data link layer provides
a nice abstraction for the upper layers, thus standard UDP or
TCP-based applications will be supported seamlessly. Various
control protocols can be well supported by wrapping the their
control payload in TCP/UDP packets.
The core of the RT-WiFi protocol is the TDMA-based
data link layer. Since there is no centralized channel access
controller of a regular Wi-Fi network, it adopts carrier sense
multiple access with collision avoidance (CSMA/CA) to avoid
collision. This mechanism helps improve the network throughput but not feasible for supporting high speed real-time traffic
with stringent timing requirements. As Fig. 4a shows, the
transmission of the regular Wi-Fi packet with a hard deadline
will be blocked by a nondeterministic of time because of
carrier sense, and further delayed by random backoff mechanism. To address this problem, we adopts TDMA mechanism
and a centralized channel and time management to access
the channels according to strict timing. Fig. 4b presents the
channel access pattern of a RT-WiFi network. Since only one
node can access a certain channel in a given time slot, RT-WiFi
provides collision free and deterministic communications.
As shown in Fig. 3, there are three key components in
the RT-WiFi data link layer: a timer for maintaining global
synchronization among all RT-WiFi nodes and triggering timing events; a link scheduler for coordinating the access to
shared media, and executing the dedicated event at scheduled
time points; and a flexible channel access controller which
dynamically configures the hardware parameters for executing
the timing event according to the target application behavior.
We shall explain the design of each of these components in
ƵƐLJ
DĞĚŝƵŵ
/&^
ĞĨĞƌĐĐĞƐƐ
͙͘͘͘
ĂĐŬŽĨĨƐůŽƚƐ
Đϭ
/&^
ĂƚĂ
ĞĨĞƌĐĐĞƐƐ
ƚϭ
ĐϮ
^ůŽƚϬ
ĂƚĂ
W
ƌŽĂĚĐĂƐƚ
ĂĐŬŽĨĨ
ƐůŽƚƐ
ƚϮ
Đϭ͕ĐϮ͗ĚĂƚĂƌĞĂĚLJƉŽŝŶƚ
ƚϭ͕ƚϮ͗ĚĂƚĂƚƌĂŶƐŵŝƚƉŽŝŶƚ
(a) Regular Wi-Fi
dŝŵĞ^ůŽƚ
ĂƚĂ
dŝŵĞ^ůŽƚ
ĂƚĂ
^ŚĂƌĞĚ
^ůŽƚϮ
^ůŽƚϯ
^ůŽƚϰ
^ůŽƚϱ
^ůŽƚϲ
^ůŽƚϳ
^dϭ
W
^dϮ
W
^dϯ
W
W
^dϭ
W
^dϮ
W
^dϯ
Fig. 5: An example of a superframe with 8 time slots.
There are three key data structures maintained in the link
scheduler:
dŝŵĞ^ůŽƚ
ĂƚĂ
(b) RT-WiFi
Fig. 4: Comparison of media access methods between regular
Wi-Fi and RT-WiFi
the following sections.
A. Timer Design
To achieve high sampling rate, RT-WiFi has very stringent
timing requirements on each device. For instance, if the
required aggregate sampling rate is 5kHz, the timer is required
to deliver an accurate timer interrupt for every 200µs, and
all tasks related to that sample (including data transmission,
acknowledgement and possible in-slot retransmission) shall be
completed within that short interval (called time slot). A time
slot is a rigid channel access unit in the RT-WiFi network.
In order to provide better timing predictability for the target
applications, each RT-WiFi node can only access the channel
in their pre-assigned time slots. Depending on the current
sampling rate, the size of a time slot is required to be larger
than the inverse of the sampling rate.
Fig. 6a shows a generic RT-WiFi slot timing, and the slot
size is determined by Equation 1. The guard interval is used
to ensure the consecutive transmission does not interfere with
each other due to synchronization inaccuracy. Data transmission is followed by the guard interval, and the transmission
time depends on the transmission rate and packet size. When
a station successfully receives the data, it should response an
acknowledgement (ACK) message after short inter-frame space
(SIFS). If sender does not receive ACK after the ACK wait
period, then it assumes the packet is lost.
T T imeS lot ≥ TGuardInterval + T Data + T S IFS + T ACK
^ůŽƚϭ
(1)
Our timer design is based on the Timing Synchronization
Function (TSF) in IEEE 802.11. TSF is achieved by having all
nodes keep a local 1MHz TSF timer, and synchronize to the
master clock in RT-WiFi Access Point periodically through the
beacon frames. The timer then triggers accurate time interrupts
to ensure the correct operation of the data link layer. We shall
present the implementation details of our timer module on WiFi chips in Section IV-B.
B. Link Scheduler
If accurate time synchronization with the master clock in
the Access Point is achieved, every station in the RT-WiFi
network forms a consensus to a global time. Based on this
globally synchronized timing information, a link scheduler is
designed to coordinate the channel access among the stations.
Link: A link describes the communication behavior within
a time slot. It is specified by its source, destination and the
associated link type. We define four link types in RT-WiFi:
transmit, receive, broadcast and shared. A broadcast link is
used to transmit a data frame to all the neighbor nodes in
the network; a transmit link is used for dedicated data frame
transmission to the given destination; a receive link is used
for receiving a data frame from the given source; and a shared
link is for multiple source nodes to compete for transmitting
a data frame to the same destination.
Notice that, RT-WiFi is designed to be compatible to
existing Wi-Fi systems. A RT-WiFi node can support both realtime and non-real-time traffic simultaneously. Link scheduler
shall differentiate the priority of different traffics and assign
them to either dedicated or shared links.
Superframe: Superframe is a sequence of consecutive time
slots. It defines the device’s communication pattern with neighbors and the superframe will repeat itself infinitely. Fig. 5
illustrates an example of a superframe configured in a RTWiFi AP with 8 time slots (the time slot length is 250µs). In
this RT-WiFi network 3 stations are present, and each station
is configured with a pair of dedicated transmit and receive link
to the AP in the superframe.
Device Profile: RT-WiFi Access Point keeps the device profile
for the centralized network manager to generate superframe
and links for each RT-WiFi station. The device profile is
gathered when a RT-WiFi station joins a RT-WiFi network,
and the device information is forwarded to network manger via
RT-WiFi AP. The network manger installed in the RT-WiFi AP
performs access control, generates the schedule information by
looking up the sampling rate requirement of the new joined
device that is specified by control designer, and reply the
superframe and link configuration for that station. The network
manager design and schedule construction is out of the scope
of this paper and will be briefly discussed in the future work.
To execute the TDMA schedule specified by the superframe, link scheduler is invoked by every timer interrupt.
The link type of current time slot is determined by looking
up the superframe using the timing information. Depending
on the link type, link scheduler either requests a frame for
the destination node from the message handling module or
redirect the receiving frame to the upper layer. Before put the
transmit frame into the physical layer, link scheduler setup the
transmission parameters by using the flexible using channel
access controller, which shall be described in the following
section.
C. Flexible Data Link Layer Design
To support a wide range of control applications, we apply
a flexible design in RT-WiFi data link layer. RT-WiFi allows
the available computation resources and the specific control
applications.
dŝŵĞ^ůŽƚ
ĂƚĂ
'ƵĂƌĚ
/ŶƚĞƌǀĂů
^/&^
<
In-slot retry: The in-slot retransmission mechanism is shown
in Fig. 6b. the retransmission is invoked immediately if the
sender does not receive an ACK message from the receiver.
The retransmission time of a in-slot retry should not exceed
the length of a time slot.
<tĂŝƚ
(a) RT-WiFi timeslot with successful transmission
dŝŵĞ^ůŽƚ
ĂƚĂ
'ƵĂƌĚ
/ŶƚĞƌǀĂů
ĂƚĂ
^/&^
<tĂŝƚ
Out-of-slot retry: If a packet is failed to transmit in one time
slot, RT-WiFi node can retransmit it in the next available link.
Notice that the retransmission heavily depends on the desired
application behavior. For example, in the next available link,
if new control/sensor data is available, then it does not make
sense to retransmit the old data.
<
<tĂŝƚ
(b) RT-WiFi timeslot with in-slot retransmission
dŝŵĞ^ůŽƚ
ŽƵŶĚĞĚ>ĞŶŐƚŚ
EŽƌŵĂůtŝ&ŝdƌĂĨĨŝĐ
/&^
ZdͲtŝ&ŝĂƚĂ
^/&^
<
'ƵĂƌĚ
/ŶƚĞƌǀĂů
(c) RT-WiFi slot timing when considering Wi-Fi traffic
Fig. 6: RT-WiFi time slot design
users to choose the following design parameters to achieve the
expected application behavior.
1) Sampling rate: Higher sampling rate helps control applications perform more accurate monitoring on the target
systems, which further improves the quality of control. Increasing the sampling rate, however is challenging because higher
sampling rate requires smaller size of the time slot, which is
heavily dependent on the following factors.
Packet size and Data rate: Apparently, RT-WiFi can not
afford to transmit packet if the transmission time of a packet
if larger than the time slot size according to Eq. 1. IEEE 802.11
specifications allow the use of multiple transmission rates at
the physical layer that utilize different modulation and coding
schemes. For example, the 802.11g supports twelve data rate
from 1Mbps to 54Mbps. Higher transmission rate provides
higher potential throughput, but it is also less resilient to noise
and easily prone to error [18]. A flexible data link layer design
should be able to select the adequate rate adaptively which best
fit the current channel condition and desired time slot size.
Computational resource: Increasing the sampling rate of
the TDMA data link layer will reduce the time slot size. For
executing tasks in a shorter time, more computational resource
are required. The maximum sampling rate supported by a RTWiFi node is limited by its computation capability.
Synchronization accuracy: The guard interval in Fig. 6
is reserved for the drift between two RT-WiFi devices. The
minimum slot size is related to the synchronization accuracy
because the size of time slot depends on the size of the guard
interval. We can reduce the guard interval size by utilizing
more accurate clock or decrease the synchronization interval.
2) Reliability: RT-WiFi applies two retransmission mechanisms to improve the reliability of a communication link. These
two mechanisms can be used either independently or combined
together. To use which retransmission mechanism depends on
3) Co-existence with regular Wi-Fi network: Due to the
pervasively existing Wi-Fi signal, the RT-WiFi data link layer
design needs to take its co-existence performance with regular
Wi-Fi network into consideration. With the presence of Wi-Fi
networks in the operational environment, the RT-WiFi data link
layer should keep real-time characteristics while minimizing its
influence to surrounding regular Wi-Fi networks as well.
We assume that a regular Wi-Fi node obeys the CSMA/CA
channel access mechanism and the maximum consecutive
channel access time of a regular Wi-Fi node can be bounded
by a constant time. This can be achieved by restricting the
maximum transmit unit (MTU) size in the MAC layer of Wi-Fi
network, and limiting the lowest available transmission speed
of that Wi-Fi network. This assumption must be hold because
if any Wi-Fi node (i.e. a jammer) can occupy a channel and
continuously transmit data for arbitrarily long time then there is
no way to achieve real-time data delivery. If this assumption is
valid, then RT-WiFi can apply the following two mechanisms
to improve its co-existence performance with regular Wi-Fi
network.
Performing Carrier Sense: Without the presence of WiFi traffic in the operation environment, a RT-WiFi node does
not perform carrier sense in its assigned links before the
transmission. This is because the network manager will make
sure that there is no temporal or spatial reuse in the operating
environment. However, if there are regular Wi-Fi networks
operating in the surrounding environment, the co-existence performance between RT-WiFi and regular Wi-Fi is poor because
the probability for the two types of traffic to collide with each
other is high. In this case, RT-WiFi nodes should perform clear
channel assessment and only start the transmission when the
channel is clear.
Shortening Inter-frame Spacing (IFS): IFS is an interval
defined between the transmission of two consecutive Wi-Fi
packets. Wi-Fi nodes are required to wait for a pre-defined
IFS before they can start to transmit the next frame. To allow
the RT-WiFi node has higher priority to access a channel, a
shorter IFS can be set for RT-WiFi node so that they can start
to transmit before regular Wi-Fi node.
Fig. 6c illustrates the slot timing when we consider the
co-existence of Wi-Fi and RT-WiFi traffic. The real-time data
delivery still can be achieved because RT-WiFi only wait for
a bounded time, and RT-WiFi node has a higher priority to
occupy a channel. The price of improving the co-existence
performance is to delay the data transmission of RT-WiFi
traffic. We shall expect higher jitter in the sensor and control
data if we enable this functionality, and it also limits the
highest supported sampling rate because we need to reserve
blocking time from Wi-Fi traffic.
D. Association Process
Before joins to a RT-WiFi network, a RT-WiFi node has
no information about the TDMA schedule. It behaves like
a regular Wi-Fi node, which uses CSMA/CA to access the
channel, and it follows the same authentication and association
process as regular Wi-Fi node to join a RT-WiFi network. After
the association process is completed, a RT-WiFi node wait
for the next beacon message, which consists of the TDMA
scheduling information. The scheduling information consists
of time slot size, superframe size, TSF value of the next
superframe, and the TDMA schedule. After processing this
message, RT-WiFi station synchronizes its local clock with the
TSF value provided by RT-WiFi AP, configures timer interrupt,
and starts to execute the TDMA schedule.
Notice that the TDMA scheduling information is appended
in the beacon frame by using vendor specific field [13], which
retain the original format of a beacon frame. Thus, a regular
Wi-Fi station can easily associate with a RT-WiFi AP without
any modification. To support regular Wi-Fi station with RTWiFi network, the co-existence technique that mentioned in
the preivous seciton should be enabled. Currently, a station
can only directly associate with a RT-WiFi AP, which forms
a star network. We will mention how to extend the network
topology of RT-WiFi to a multi-hop mesh network in the future
work.
IV. System Implementation
In this section, we present the implementation details of
the RT-WiFi protocol on Atheros AR9285 [19] Wi-Fi chip.
We first summarize our hardware and software platform, and
then describe the challenges and our solutions when implement
the key components in the RT-WiFi protocol.
A. Hardware and Software Platform
RT-WiFi does not rely on specific IEEE 802.11 hardware
implementation, and our design should be able to port to
any IEEE 802.11 compatible hardware. We choose Atheros
AR9285 Wi-Fi chip for our proof of concept implementation
because it is one of the most commonly used Wi-Fi chip and
it has open source driver module in Linux operating system.
AR9285 Wi-Fi chip supports IEEE 80211 b/g/n specification.
AR9285’s maximum transmission rate is 150Mbps and it
operates in the 2.4GHz frequency band.
We use Ubuntu 12.04 as the operating system, which runs
Linux kernel 3.2.0. On top of that, We adopt open source
Linux compat-wireless driver [20] as the foundation of RTWiFi. Two software modules originated from compat-wireless
driver, mac80211 and hardware-dependent driver module, are
incorporated with the TDMA design to build the MAC layer
of RT-WiFi. mac80211 is a framework for developing software
based MAC driver, it is used for supporting the IEEE 802.11
frame management and serving as the interface between upper
network layer and the message handling module of RT-WiFi
MAC layer. We use hardware driver module ath9k for supporting AR9285, and a software interface is implemented for
message handling and flexible channel access configuration.
Since we only made very limited modification to create an interface between RT-WiFi module and the hardware-dependent
modules for building RT-WiFi design, it will be easy to port the
design of RT-WiFi to other IEEE 802.11 compatible hardware.
B. Timer Module
The basic time unit in RT-WiFi network is a time slot.
Depending on the adopted version of IEEE 802.11 standard,
the size of the time slot could be estimated by Equation 1.
In the following, we give a concrete example by using IEEE
802.11g with ERP-OFDM modulation scheme. TGuardInterval
depends on the accuracy of timing synchronization, which
relies on the Timing Synchronization Function (TSF) in IEEE
802.11. According to the IEEE 802.11 standard [13], the drift
rate of TSF should be within ±10ppm. Users can control
the maximum amount of drift between AP and stations by
controlling the broadcasting interval of TSF. For example if
the beacon is broadcasting every 100ms, then the maximum
drift is within 20µs. To determine the value of T Data , we
assume the application payload is 200 bytes, UDP header is
8 bytes, and IPv4 header is 20 bytes. The MAC header is 32
bytes with 4 bytes frame check sequence. According to [21],
the physical layer convergence procedure (PLCP) preamble
and header delay are 20µs. If the data is transmitted by the
maximum data rate (54Mbps), then
(200 + 8 + 20 + 32 + 4) ∗ 8
= 59.11µs. (2)
54 ∗ 106
T S IFS is 10µs for 802.11g. The total size of ACK frame is 14
bytes. Similary, we can derive T ACK = 22.07µs. Theoretically
the minimum slot size for the previous setting is
T Data = 20 +
T T imeS lot ≥ 20 + 59.11 + 10 + 22.07 = 111.18µs.
(3)
The size of the time slot for in-slot retry and co-existence with
regular Wi-Fi can be calculated by similar manner.
Based on TSF, timer sets its local hardware timer in
AR9285 and triggers the timer interrupt for each time slot.
Originally, the handler of this timer interrupt is deferred and
handled by a kernel tasklet later. However, in our implementation, we observed that this tasklet could be blocked by
other tasklet that has the same priority, which delayed the
execution of time sensitive RT-WiFi task. In order to avoid this
delay for meeting the stringent timing requirement of RT-WiFi,
instead of deferring execution of RT-WiFi task to tasklet we
directly executed it in interrupt service routine. Notice that this
design reduces the delay for executing RT-WiFi task with the
cost of increasing kernel response time. However, the average
execution time of RT-WiFi task for Intel Atom N450 CPU
is less 20µs, which only has limited influence to the kernel
response time.
C. Link Scheduler and Message Handling Module
To implement TDMA-based channel access, we build
two message handling modules in RT-WiFi for sending and
receiving packets. To ensure efficient message handling, the
transmission message module consists of multiple queues, one
for each dedicated real-time communication link and one for
W
/ŶƚĞůŝϯϮϯϮϬD
Ϯ͘Ϯ',nj
^dϭ
/ŶƚĞůŝϳϮϲϮϬD
Ϯ͘ϳ',nj
^dϮ
/ŶƚĞůƚŽŵEϰϱϬ
ϭ͘ϲϲ',nj
^dϯ
/ŶƚĞůĞůĞƌŽŶD
ϵϬϬD,nj
(a) Setting 1
Wϱ
/ŶƚĞůŝϳϮϲϮϬD
Ϯ͘ϳ',nj
Wϲ
/ŶƚĞůŝϯϮϯϮϬD
Ϯ͘Ϯ',nj
^dϱ
/ŶƚĞůĞůĞƌŽŶD
ϵϬϬD,nj
^dϲ
/ŶƚĞůƚŽŵEϰϱϬ
ϭ͘ϲϲ',nj
EĞƚǁŽƌŬͲ
EĞƚǁŽƌŬͲ
(b) Setting 2
Fig. 7: An overview of the testbed setting
(a) Interference free environment
non-real-time communication link. The transmission message
module accepts packet from mac80211 module, and will be
controlled by Link Scheduler to transmit a scheduled packet
to the lower layer at each time slot. The receiving message
module enqueues messages to upper layer whenever it gets a
message.
Both real-time and non-real-time traffic could be present
in a RT-WiFi node. In order to identify the traffic type in the
data link layer, we utilize the type of service (TOS) field in
the IP header. Application developer can create a socket with
specified TOS, by using user level API i.e. setsockopt(). Then
mac80211 module will map TOS to an access class. Currently,
RT-WiFi maps the highest priority class to RT-WiFi queues,
messages in that class will be sent by dedicated transmit links.
For non-real-time packets, the link scheduler will transmit
them by shared links.
After the RT-WiFi associates with the AP, link scheduler
configures the timer interrupt, and will start to transmit and
receive messages according to the configured communication
schedule.
D. Flexible Channel Access Controller
To achieve flexible channel access, we implement an adaptive channel access controller. The controller configures the
hardware setting according to the user specified parameters.
Changing sampling rate is done with modifying the hardware
timer. AR9285 has a feature called retry series, which can
be used to set a series of in-slot retry with a corresponding
transmission rate. If out-of-slot retry is enabled, RT-WiFi will
confirm the delivery of a frame by checking the ACK message.
If the ACK message is missing, RT-WiFi will re-queue that
frame into RT-WiFi queue. To enable co-existence mode
with regular Wi-Fi network, we can manipulate the hardware
register of AR9285 to control its carrier sense. AR9285 has
eight hardware queues, and we can map the RT-WiFi traffic to
one of the hardware queue. For configuring the IFS, we can
set the IFS of the hardware queue for RT-WiFi traffic, which
lets RT-WiFi traffic has higher priority to access a channel.
V. Performance Evaluation
To validate our design of the RT-WiFi protocol and evaluate
its performance in providing high speed real-time wireless
communication, we setup a testbed for the performance comparison between RT-WiFi and regular Wi-Fi.
(b) Office environment
Fig. 8: Experiment environment
As shown in Fig. 8a, the testbed consists of one Access
Point (AP) and three stations (STA1, STA2 and STA3) which
form into a star network topology. All the four devices are
equipped with the same Atheros AR9285 IEEE 802.11 compatible wireless interface but different CPUs with varied computation power. This is to demonstrate that the implementation
of RT-WiFi only introduces limited computation overhead, and
can even run on resource-constrained embedded devices.
To emulate the sensing and control flows in a wireless
control system, we install a UDP socket program in each
device. Sensor data with a fixed size payload are transmitted from each station to the Access Point according to the
configured sampling rate. On the other direction, the Access
Point periodically transmits control data with the same packet
size back to each station. Notice that sensors, actuators, and
controllers are all running in the application layer. The overall
delay from a sensor to a controller or from a controller
to an actuator includes the application layer to MAC layer
delay in each device and the MAC layer to MAC layer delay
between the devices. In this section we focus on evaluating
the MAC layer performance. We will evaluate the application
layer performance in Section VI through a case study.
We compare the MAC layer to MAC layer performance
between RT-WiFi and regular Wi-Fi in two test scenarios, an
interference-free environment and an office environment with
intensive Wi-Fi traffic. The main performance metrics we used
in the experiments include the data link layer transmission
latency, and the packet loss ratio. The data link layer transmission latency is calculated as the difference of a frame’s TSF
timestamps between the receiver side and the sender side; The
packet loss ratio measures the percentage of packets lost by
tracking the sequence number of each packet.
A. Interference-free Environment
To create an interference-free environment for performance
comparison, we deploy the testbed in a parking lot of a hiking
trail at Austin city suburban area around Texas State Highway
Loop 360 and Loop 1. Table I summarizes the comparison
results between RT-WiFi and regular Wi-Fi in this test scenario.
The results include the max, mean and standard deviation of
the MAC layer to MAC layer transmission delay, and the
packet loss ratio for each of the six links. The empirical cumulative density function (ECDF) of the transmission latency
for uplinks (STAs to AP) and downlinks (AP to STAs) are
presented in Figure 9. We observed from the experiment results
that RT-WiFi protocol can provide accurate real-time packet
delivery that more than 99.98% of packets are delivered within
the assigned 500µs time slot and the standard deviation of the
latency in RT-WiFi network is less than 5.3µs. The occasional
packet loss is caused by the interference from other visitors’
mobile devices. This is verified by observing uncontrolled
probe request frames from unknown devices to RT-WiFi AP
when visitors are nearby.
On the contrast, Wi-Fi network has higher average delay
and larger transmission variation. This is because four nodes
in the Wi-Fi network compete for media access by utilizing
CSMA-CA and random backoff mechanisms. The mean delay
of downlinks are higher than that of uplinks is because the
packets sent from AP not only have to wait for channel
access but also are delayed due to the queuing effect. RTWiFi network is seldom affected by the queuing effect. This is
because to delay a packet transmission in the AP, one packet
needs to be deferred for more than two time slots (1000µs)
according to our configured link schedule. As shown in Fig. 9,
only less than 0.01% of packets in RT-WiFi network has
latency larger than 1000µs. The latency variation in Wi-Fi
network is up to 90 times to that of RT-WiFi network, and
the maximum delay is more than 30 times to RT-WiFi, which
poses great challenges for the controller design.
Another observation from Fig. 9a is that the minimum
latency of RT-WiFi on the uplinks is higher than that of
regular Wi-Fi. This is due to the delay of the TDMA guard
interval and the implementation overhead in the MAC layer
software module. However, as Fig. 9b shows, the difference
Empirical CDF
1
Wi−Fi
RT−WiFi
0.8
0.6
0.4
0.2
0
0
500
1000
1500
2000
2500
Latency (µs)
3000
3500
4000
(a) Latency ECDF for uplinks (STAs→AP)
1
Empirical CDF
The following configuration is used in our experiments.
We run each experiment for 600 seconds. Both the Wi-Fi
and RT-WiFi are configured to use channel 6 of IEEE 802.11
b/g/n. There are in total six pairs of UDP sockets in the
experiment setting between the stations and the Access Point
(STA1→AP, STA2→AP, STA3→AP, AP→STA1, AP→STA2
and AP→STA3). For each UDP socket, we publish the data
every 4ms. The application layer payload is fixed as 460
bytes. For RT-WiFi network, we set the time slot size as
500µs, and we use the same superframe and link schedule
as shown in Fig. 5. Due to the limit of space, in this paper
we only compare the regular Wi-Fi with the baseline of RTWiFi protocol by fixing the data rate as 54Mbps, and disabling
both the retransmission and co-existence mechanisms. For the
more comprehensive comparison between regular Wi-Fi and
RT-WiFi, please refer to our technical report.
Wi−Fi
RT−WiFi
0.8
0.6
0.4
0.2
0
0
500
1000
1500
2000
2500
Latency (µs)
3000
3500
4000
(b) Latency ECDF for downlinks (AP→STAs)
Fig. 9: MAC layer transmission latency comparison between
Wi-Fi and RT-WiFi in an interference-free environment
of the minimum latency between regular Wi-Fi and RT-WiFi
is smaller for the downlinks. This is because the minimum
latency of regular Wi-Fi is increased by queuing delay.
B. Office Environment
To evaluate the performance of RT-WiFi network with
presence of interference, we also deploy the testbed on the 5th
floor in UT GDC building. This floor is covered with more
than 10 Wi-Fi APs, which spread to all the orthogonal Wi-Fi
channels in ISM 2.4GHz band. Under this setting, we repeat
the same experiments as in the interference-free environment.
Fig. 10 compares the MAC layer latency between RT-WiFi
and Wi-Fi network in the office environment. Compared with
the interference-free environment, the latency of regular Wi-Fi
network is increased because the office environment has more
inference from existing Wi-Fi network. Thus, the CSMA/CA
and random backoff mechanism has higher chance to defer the
transmission of regular Wi-Fi packets. The latency distribution
of RT-WiFi network in Fig. 10 is similar to Fig. 9, because
we adopts the same TDMA design, which targets to provide
small latency variation.
Table II shows the latency and packet loss ratio of
RT-WiFi network and Wi-Fi network. The maximum latency
of RT-WiFi network is increased up to 4.2ms because there
are more uncontrolled mobile devices around in the office
environment. The loss ratio of RT-WiFi network is raised up
to 10% due to the collision to background traffic. However,
because of the TDMA design of RT-WiFi network, the
mean delay in the office environment remains similar to the
interference-free environment, which will be convenient for
control designer to reuse their controller design. Moreover,
the delay variation of RT-WiFi is still small (less than 30µs),
which makes control application easy to compensate the
packet loss.
Link
STA1→AP
STA2→AP
STA3→AP
AP→STA1
AP→STA2
AP→STA3
Max Delay(µs)
RT-WiFi
Wi-Fi
535
16448
529
13387
525
13589
827
16472
544
17465
1055
17049
Mean Delay (µs)
RT-WiFi
Wi-Fi
173
191
172
181
174
202
184
250
187
298
188
248
Delay Standard Deviation (µs)
RT-WiFi
Wi-Fi
4.88
231.60
2.52
214.15
3.01
236.75
5.29
342.24
3.98
360.66
4.87
325.50
Loss Ratio
RT-WiFi
Wi-Fi
0.19%
0%
0.16%
0%
0.21%
0%
0.06%
0%
0.04%
0%
0.01%
0%
TABLE I: Latency and loss ratio comparison in an interference-free environment
Empirical CDF
1
Wi−Fi
RT−WiFi
0.8
0.6
0.4
0.2
0
0
500
1000
1500
2000
2500
Latency (µs)
3000
3500
4000
(a) Latency ECDF for uplinks (STAs→AP)
Empirical CDF
1
Wi−Fi
RT−WiFi
0.8
0.6
0.4
0.2
0
0
500
1000
1500
2000
2500
Latency (µs)
3000
3500
4000
(b) Latency ECDF for downlinks (AP→STAs)
Fig. 10: MAC layer transmission latency comparison between
Wi-Fi and RT-WiFi in an office environment
Regular Wi-Fi
RT-WiFi baseline
RT-WiFi co-ex
RT-WiFi co-ex + retry
Max
Delay
(µs)
62629
953
2507
2831
Mean
Delay
(µs)
580
183
220
254
Delay
Standard Deviation
(µs)
1679.04
27.75
149.27
166.37
Loss
Ratio
0%
50.21%
10.92%
4.96%
TABLE III: Latency and loss ratio comparison with present of
large network traffic
On the other hand, Wi-Fi network has zero packet loss
because it keeps retransmitting until the data is delivered.
However, retransmitting old sensor data does not give effective
system information if new sensor data is available. According
to Table II the maximum delay of regular Wi-Fi network is up
to 100ms, and the standard deviation is increased to 2800µs.
The large delay of sensor data will make controller out track
of the system state, and large latency for delivering control
data could also makes target system out of control for a long
period. Also the high latency variance of Wi-Fi network could
be very challenging for controller design.
C. Flexible Channel Access Controller
To evaluate the performance of flexible channel access
controller, we setup a testbed in the same office environment
with two networks as shown in Fig. 8b. Network-A is a
regular Wi-Fi network, which utilizes network traffic generator,
iperf [?], to generate a 10Mbps UDP traffic from STA5 to
AP5. The MAC layer maximum transmission unit of Wi-Fi
network is configured as 300 bytes, for bounding the packet
transmission time. For Network-B, we run the same UDP
socket program, which publishes data every 4ms from AP6
to STA6. We configured Network-B by using four settings,
regular Wi-Fi, RT-WiFi baseline, RT-WiFi with co-existence,
RT-WiFi with co-existence and one in-slot-retry, and observe
the latency and packet loss ratio for link (STA6→AP6).
Table III shows the experiment results. Because of the
interference from Network-A, the mean delay of regular Wi-Fi
is increased to 580µs, which is 47% higher than the average
mean delay of the upload links in the previous experiment. The
packet loss ratio of baseline RT-WiFi network is also increased
dramatically to 50.21%, due to the large interference from
Network-A. For RT-WiFi network with co-existence mode, the
loss ratio is decreased to 10.92%. It is because we enable
the carrier sense mechanism, but the carrier sense can not
detect potential hidden terminals. The variance also increases
to 149.27 since the transmission may be blocked by traffic
from Network-A. The loss ratio is further decreased to 4.96%
when we enable in-slot-retry, which also increases the mean
delay and delay variance.
VI. Case Study - A Mobile Gait Rehabilitation System
To demonstrate the benefit of applying RT-WiFi in wireless control systems and applications, we built a networkedbased rehabilitation system with RT-WiFi integrated. In the
proposed system, RT-WiFi network serves as the wireless
communication links between control applications and the
rehabilitation device for improved system mobility and telerehabilitation. Control algorithms run in the application layer
of a host computer, which also serves as RT-WiFi AP, and the
rehabilitation device is connected to the RT-WiFi station.
Fig. 11 gives an overview of the network-based rehabilitation system, which consists of two smart shoes [22] with
embedded air press sensors, multiple IMU motion sensors,
a robotic assistive device [23] and a host computer running
control applications. There are two types of wireless communication links in the system, all based on RT-WiFi. One is used
to transmit sensing signals from sensing devices (air pressure
sensors and IMU sensors) to the control applications in the
host computer [24]. Information on this wireless link is used
for health monitoring and rehabilitation strategy design, so the
sampling rate can be chosen from 100Hz to 1kHz depending
on the high-level decision making algorithms (100Hz is chosen
in the current design). The other type of wireless link is for
controlling the robotic assistive device, which requires at least
1kHz sampling rate for precise motion control. More details
of the system design can be found in [2].
Link
STA1→AP
STA2→AP
STA3→AP
AP→STA1
AP→STA2
AP→STA3
Max Delay(µs)
RT-WiFi
Wi-Fi
3865
10078
4193
81499
3861
75298
1197
78089
1342
78923
2186
77860
Mean Delay (µs)
RT-WiFi
Wi-Fi
176
401
171
348
174
429
184
788
189
790
189
799
Delay Standard
RT-WiFi
25.86
27.62
25.16
16.86
15.19
19.03
Deviation (µs)
Wi-Fi
1491.69
1000.60
1221.72
2861.42
2806.56
2855.89
Loss Ratio
RT-WiFi
Wi-Fi
8.64%
0%
9.97%
0%
7.55%
0%
9.52%
0%
8.09%
0%
9.31%
0%
TABLE II: Latency and loss ratio comparison in an office environment
achieve this synchronization, we utilize IEEE 1588 Precision
Time Protocol (PTP) [26] by using its software implementation
PTP daemon [27], and using a dedicate PCI Express Ethernet
link for PTP. The synchronization error between the two
system clocks was measured to be under 40µs. This was
precise enough to measure the end-to-end application layer
latency and compare the control performance between RT-WiFi
and regular Wi-Fi.
B. Emulation of a Wireless Control System
Fig. 11: An overview of the network-based rehabilitation
system
Fig. 12: Integration of smart shoes with a RT-WiFi station.
A. System Integration
We take the smart shoe as an example to show how we
integrate the sensing and control devices into the rehabilitation
system through RT-WiFi. Smart shoe is a human gait detecting
device, which has been developed for health monitoring from
our previous research.
Our network-based gait rehabilitation system periodically
requests sensing signals from air pressure sensors for abnormal
gait detection. There are four air pressure sensors embedded in
each shoe, and sensing signal from each sensor is encapsulated
as 8-byte packet. Including a 8-byte time index, we have
72 bytes of data in total for two shoes to be transmitted in
each time step. Fig. 12 shows how we integrated smart shoes
with RT-WiFi network. The real-time sensor data were first
collected from an analog-input module NI 9221 [25] on a NI
9116 compactRIO chassis, and then sent through a UDP socket
from an Ethernet port of the NI 9022 real-time controller on
the compactRIO chassis to a RT-WiFi station. The RT-WiFi
station then forwarded the sensor data through the RT-WiFi
wireless communication link to the RT-WiFi AP on which the
controller was running.
To evaluate the performance of the network-based rehabilitation system, we need to measure the application layer latency
between the smart shoes and the RT-WiFi AP, which relies
on a precise system clock synchronization between them. To
To better demonstrate the performance of the RT-WiFi
wireless communication protocol, we ran some simulations
based on the data traces we collected through smart shoes.
Note that in the real control system, there should be two links
for transmitting both sensing and control signals as shown in
Fig. 11. As the first step of wireless control system integration,
we integrated smart shoes to acquire the network dynamics
(latency and packet loss ratio), and then ran some simulations
to evaluate the performance of the wireless control system
before we integrated the robotic hardware.
The model of our robotic device in this networked rehabilitation system was used for simulation. We ran both regular
Wi-Fi and RT-WiFi network at 1kHz for 60 seconds in an
in-door office environment. At each time step, we recorded
whether the sensing packet was successfully transmitted to
the wireless AP. If so, we recorded the latency between the
application layer of wireless station and wireless AP. In this
simulation, the control signal was implemented every 1ms, and
a sensing packet would be ignored if its latency was larger
than 1ms. To compare the performance of wireless network
for control system applications, we define the effective packet
loss ratio (EPLR) as follows:
EPLR =
Nl + Nd
× 100%,
N
(4)
where Nl is the number of lost packet, Nd is the number
of packets with latency longer than the sampling interval, and
N is the total number of packets transmitted over a certain
period.
A proportional-derivative (PD) controller was implemented
as the main controller, and the wireless control system was
asked to track a sinusoidal signal with unit magnitude. Simulations were conducted with different controller gains and
reference frequencies to test the effectiveness of network
dynamics. The root-mean-square (RMS) error are given in
Table IV. Empirical cumulative distribution functions (ECDFs)
of tracking errors are given in Figs.13 to 15.
Based on our simulation, the EPLR for regular Wi-Fi is
26.07%, and the EPLR for RT-WiFi is 9.5%, which is 63.56%
RMS Error (deg)
f = 1Hz
RMS Error (deg)
f = 2Hz
RT-WiFi
1.633
0.796
0.160
7.236
3.323
0.636
Wi-Fi
Improvement
2.097
1.037
0.257
9.872
4.526
1.140
1
Emperical CDF
Controller Gain
Kp
Kd
0.5
0.005
1
0.01
5
0.05
0.5
0.005
1
0.01
5
0.05
22.13%
23.24%
37.74%
26.70%
26.58%
44.21%
0.6
0.4
0.2
0
TABLE IV: RMS tracking error in simulations
WiFi
RT-WiFi
0.8
0
1
2
3
4
5
Tracking Error (deg)
6
7
8
(a) ECDF of tracking error with 1Hz reference
1
WiFi
RT-WiFi
0.8
Emperical CDF
Emperical CDF
1
0.6
0.4
0.2
0
0
2
4
6
8
10
Tracking Error (deg)
12
14
16
WiFi
RT-WiFi
0.8
0.6
0.4
0.2
0
0
2
4
6
8
10
Tracking Error (deg)
(a) ECDF of tracking error with 1Hz reference
12
14
16
(b) ECDF of tracking error with 2Hz reference
Fig. 14: ECDF of tracking error with K p = 1, Kd = 0.01
WiFi
RT-WiFi
0.8
1
0.6
0.4
0.2
0
0
2
4
6
8
10
12 14
16
Tracking Error (deg)
18
20
22
24
26
Emperical CDF
Emperical CDF
1
(b) ECDF of tracking error with 2Hz reference
WiFi
RT-WiFi
0.8
0.6
0.4
0.2
0
0
0.5
1
Fig. 13: ECDF of tracking error with K p = 0.5, Kd = 0.005
1.5
2
Tracking Error (deg)
2.5
3
(a) ECDF of tracking error with 1Hz reference
VII. Conclusion and Future work
In this paper, we present the design principles and implementation details of a real-time wireless communication
protocol called RT-WiFi to support high speed wireless control
systems. RT-WiFi is a TDMA data link layer protocol based on
802.11 physical layer to provide high sampling rate and deterministic timing guarantee on packet delivery in wireless control
systems. It incorporates configurable components for adjusting
design tradeoff including sampling rate, real-time performance,
communication reliability, and compatibility to existing Wi-Fi
networks. RT-WiFi can be implemented on commercial offthe-shelve hardware and supports up to 6kHz sampling rate.
1
Emperical CDF
lower than regular Wi-Fi. As we can see from Table IV
that compared with regular Wi-Fi, RT-WiFi consistently yields
much smaller RMS tracking errors under different settings of
the controller gains. This demonstrates its significant improvement on control performance compared with regular Wi-Fi.
From Figs.13 to 15, we can see that the probability to achieve
small tracking errors is always higher for RT-WiFi than regular
Wi-Fi. Moreover, the system is more sensitive to packet loss
when the controller gain is smaller, and larger tracking errors
occur when we ask the system to tracking faster reference
signals. In clinic test, to protect patients from injury, we need
to make sure that the position tracking error is no larger than
10 degrees at all times. Due to the limitation of actuator power,
we also prefer small control gains (e.g.,K p = 0.5, Kd = 0.005).
In this setting, only RT-WiFi can be employed.
WiFi
RT-WiFi
0.8
0.6
0.4
0.2
0
0
0.5
1
1.5
2
2.5
3
Tracking Error (deg)
3.5
4
4.5
5
(b) ECDF of tracking error with 2Hz reference
Fig. 15: ECDF of tracking error with K p = 5, Kd = 0.05
We integrate RT-WiFi into a mobile gait rehabilitation system.
Our results of extensive experiments validate our design and
demonstrate the significant improvement from RT-WiFi on
both data link layer and application layer latency in wireless
control systems compared with regular Wi-Fi, which further
lead to easier controller design and better control performance.
As the future work, we are working towards reducing the
form factor of the RT-WiFi communication module, addressing
the relatively high power consumption issue, developing a
resource management and scheduling framework for RT-WiFi
system to extend the network topology to mesh structure
and support multi-hop real-time sensing and control flows
to meet end-to-end delay constraints. With all these pieces
in place, we envision that RT-WiFi will serve as an ideal
communication platform for a wide range of real-time wireless
control systems.
[21]
Acknowledgment
This work is supported by National Science Foundation
under Grant CMMI-1013657.
[22]
[23]
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
J. Song, S. Han, A. K. Mok, D. Chen, M. Lucas, M. Nixon, and
W. Pratt, “WirelessHART: Applying wireless technology in real-time
industrial process control,” in Real-Time and Embedded Technology
and Applications Symposium (RTAS). IEEE, 2008, pp. 377–386.
W. Zhang, X. Zhu, S. Han, N. Byl, A. K. Mok, and M. Tomizuka,
“Design of a network-based mobile gait rehabilitation system,” in IEEE
International Conference on Robotics and Biomimetics (ROBIO). IEEE,
2012, pp. 1773–1778.
B. Li, Z. Sun, K. Mechitov, G. Hackmann, C. Lu, S. J. Dyke, G. Agha,
and B. F. Spencer, “Realistic case studies of wireless structural control,”
in International Conference on Cyber-Physical Systems (ICCPS), 2013.
S. Han, A. K. Mok, J. Meng, Y.-H. Wei, P.-C. Huang, Q. Leng,
X. Zhu, L. Sentis, K. S. Kim, and R. Miikkulainen, “Architecture of a
cyberphysical avatar,” in International Conference on Cyber-Physical
Systems (ICCPS), 2013.
Y.-H. Wei, Q. Leng, S. Han, A. K. Mok, W. Zhang, M. Tomizuka,
T. Li, D. Leith, and D. Malone, “RT-WiFi: Real-time high speed
communication protocol for wireless control systems,” in Real-Time
Systems Symposium Work-in-Progress Session (RTSS WiP), 2012.
“Bluetooth,” http://www.bluetooth.com.
“Zigbee Alliance,” http://www.zigbee.org.
“ISA100,” http://www.isa.org/isa100.
X. Zhu, S. Han, P.-C. Huang, A. K. Mok, and D. Chen, “Mbstar: A
real-time communication protocol for wireless body area networks,” in
Euromicro Conference on Real-Time Systems (ECRTS). IEEE, 2011, pp.
57–66.
V. Gabale, B. Raman, K. Chebrolu, and P. Kulkarni, “LiT MAC:
addressing the challenges of effective voice communication in a low
cost, low power wireless mesh network,” in Proceedings of the First
ACM Symposium on Computing for Development. ACM, 2010, p. 5.
B. Raman, K. Chebrolu, S. Bijwe, and V. Gabale,
“PIP: a
connection-oriented, multi-hop, multi-channel TDMA-based MAC for
high throughput bulk transfer,” in Proceedings of the 8th ACM
Conference on Embedded Networked Sensor Systems. ACM, 2010, pp.
15–28.
“IEEE 802.15 WPAN Task Group 4,” http://www.ieee802.org/15/pub/
TG4.html.
“IEEE 802.11 working group,” http://www.ieee802.org/11/.
D. Koutsonikolas, T. Salonidis, H. Lundgren, P. LeGuyadec, Y. C. Hu,
and I. Sheriff, “TDM MAC protocol design and implementation for
wireless mesh networks,” in Proceedings of the 2008 ACM CoNEXT
Conference. ACM, 2008, p. 28.
P. Djukic and P. Mohapatra, “Soft-TDMAC: A software TDMAbased MAC over commodity 802.11 hardware,” in IEEE International
Conference on Computer Communications (INFOCOM). IEEE, 2009,
pp. 1836–1844.
A. Dhekne, N. Uchat, and B. Raman, “Implementation and evaluation
of a TDMA MAC for wifi-based rural mesh networks,” in Proceedings
of the 4th ACM workshop on networked systems for developing regions.
ACM, 2009.
Y. Ben-David, M. Vallentin, S. Fowler, and E. Brewer, “JaldiMAC –
taking the distance further,” in Proceedings of the 4th ACM workshop
on networked systems for developing regions. ACM, 2010, p. 2.
M. Lacage, M. H. Manshaei, and T. Turletti, “IEEE 802.11 rate adaptation: a practical approach,” in Proceedings of the 7th ACM international
symposium on Modeling, analysis and simulation of wireless and mobile
systems. ACM, 2004, pp. 126–134.
“Atheros AR9285,” http://www.qca.qualcomm.com/media/product/
product 79 file1.pdf.
“Linux Compat-wireless Driver,” http://wireless.kernel.org/.
[24]
[25]
[26]
[27]
D. Vassis, G. Kormentzas, A. Rouskas, and I. Maglogiannis, “The IEEE
802.11 g standard for high data rate WLANs,” Network, IEEE, vol. 19,
no. 3, pp. 21–26, 2005.
K. Kong and M. Tomizuka, “A gait monitoring system based on air
pressure sensors embedded in a shoe,” IEEE/ASME Transactions on
Mechatronics, vol. 14, no. 3, pp. 358–370, 2009.
K. Kong, J. Bae, and M. Tomizuka, “A compact rotary series elastic
actuator for human assistive systems,” IEEE/ASME Transactions on
Mechatronics, vol. 17, no. 2, pp. 288–297, 2012.
J. Bae, K. Haninger, X. Wai, D.and Garcia, and M. Tomizuka, “A
network-based monitoring system for rehabilitation,” in Advanced Intelligent Mechatronics (AIM), 2012 IEEE/ASME International Conference
on. IEEE, 2012, pp. 232–237.
“National Instruments,” http://www.ni.com/compactrio/.
J.C. Eidson, Measurement, control, and communication using IEEE
1588, Springer Publishing Company, Incorporated, 2010.
“Precision Time Protocol Daemon,” http://sourceforge.net/projects/
ptpd/.