PreprintPDF Available

EAPS: Edge-Assisted Predictive Sleep Scheduling for 802.11 IoT Stations

June 2020

June 2020

Authors:

Santa Clara University

Preprints and early-stage research may not have been peer reviewed yet.

The broad deployment of 802.11 (a.k.a., WiFi) access points and significant enhancement of the energy efficiency of these wireless transceivers has resulted in increasing interest in building 802.11-based IoT systems. Unfortunately, the main energy efficiency mechanisms of 802.11, namely PSM and APSD, fall short when used in IoT applications. PSM increases latency and intensifies channel access contention after each beacon instance, and APSD does not inform stations about when they need to wake up to receive their downlink packets. In this paper, we present a new mechanism---edge-assisted predictive sleep scheduling (EAPS)---to adjust the sleep duration of stations while they expect downlink packets. We first implement a Linux-based access point that enables us to collect parameters affecting communication latency. Using this access point, we build a testbed that, in addition to offering traffic pattern customization, replicates the characteristics of real-world environments. We then use multiple machine learning algorithms to predict downlink packet delivery. Our empirical evaluations confirm that when using EAPS the energy consumption of IoT stations is as low as PSM, whereas the delay of packet delivery is close to the case where the station is always awake.

The end-to-end delay components between a station and a server. The prediction of δc is particularly challenging because it is affected by several factors such as traffic rate, channel utilization, and buffering mechanisms employed by the Linux kernel's network layer and wireless NIC's driver.

…

The AP architecture developed and used in this paper. The Collector module communicates with various kernel and user-space components to collect a set of features required for delay prediction. The Scheduler estimates the sleep duration and conveys it to the station. This figure primarily focuses on the wired-to-wireless interfaces path to compute δc. Some of the modules required to collect other delay components (δa and δ b ) are not included in this figure.

…

Traffic characterisation.

…

MAE of machine-learning algorithms versus the number of samples (transactions) in training dataset for (a) Normal Dynamicity (ND), and (b) High Dynamicity (HD) scenarios. Results are averaged over all ACs. ETR converges the fastest, and LSTM requires up to 3x more datapoints.

…

MAE of machine-learning algorithms with respect to feature history in (a) Normal Dynamicity (ND), and (b) High Dynamicity (HD) scenarios. Results are averaged over all ACs.

…

Figures - uploaded by Jaykumar Sheth

Content may be subject to copyright.

Content uploaded by Jaykumar Sheth

Content may be subject to copyright.

EAPS: Edge-Assisted Predictive Sleep

Scheduling for 802.11 IoT Stations

Jaykumar Sheth∗, Cyrus Miremadi∗, Amir Dezfouli†, and Behnam Dezfouli∗

∗Internet of Things Research Lab, Department of Computer Science and Engineering, Santa Clara University, USA

{jsheth, cmiremadi, bdezfouli}@scu.edu

†Commonwealth Scientiﬁc and Industrial Research Organisation (CSIRO), Sydney, Australia

{amir.dezfouli@data61.csiro.au}

Abstract—The broad deployment of 802.11 (a.k.a., WiFi) access points

and signiﬁcant enhancement of the energy efﬁciency of these wireless

transceivers has resulted in increasing interest in building 802.11-based

IoT systems. Unfortunately, the main energy efﬁciency mechanisms of

802.11, namely PSM and APSD, fall short when used in IoT applica-

tions. PSM increases latency and intensiﬁes channel access contention

after each beacon instance, and APSD does not inform stations about

when they need to wake up to receive their downlink packets. In this

paper, we present a new mechanism—edge-assisted predictive sleep

scheduling (EAPS)—to adjust the sleep duration of stations while they

expect downlink packets. We ﬁrst implement a Linux-based access point

that enables us to collect parameters affecting communication latency.

Using this access point, we build a testbed that, in addition to offering

trafﬁc pattern customization, replicates the characteristics of real-world

environments. We then use multiple machine learning algorithms to

predict downlink packet delivery. Our empirical evaluations conﬁrm that

when using EAPS the energy consumption of IoT stations is as low as

PSM, whereas the delay of packet delivery is close to the case where

the station is always awake.

Index Terms—Energy Efﬁciency, Wireless Communication, Delay, Ma-

chine Learning, Edge Computing.

1 INTRODUCTION

Nowadays, in addition to regular user devices such as

phones, laptops, and tablets, many IoT devices such as

security cameras, smart locks, and medical devices rely on

the 802.11 standard. Several reasons support the importance

of this standard for IoT applications: First, compared to

cellular communication, this standard offers a high band-

width over unlicensed bands. In addition to reducing costs,

these features are particularly useful in domains such as

video surveillance, industrial control, and medical moni-

toring, where high bandwidth is necessary. Second, 802.11

base stations—known as Access Points (APs)—are broadly

deployed in various environments and provide a ready-to-

use infrastructure for IoT connectivity. For example, most

Internet service providers offer WiFi-enabled modems, and

companies such as Comcast and AT&T implement large-

scale hotspot areas in cities across the US [1]. Third, the

power consumption of 802.11 stations has been considerably

reduced during the past decade by introducing various

power-save mechanisms as well as developing enhanced

low-power RF transceiver technologies such as power gat-

ing and clock gating [2]–[4]. Accordingly, nowadays we can

ﬁnd more 802.11-based IoT devices in the market such as

ring security camera and doorbell [5], nest security camera

[6], Schlage locks [7], and LIFX light bulbs [8], to mention

a few. Nevertheless, the increasing number of users and

applications is stressing the capabilities of these networks

to address application demands.

The 802.11 standard offers multiple power-saving mech-

anisms to support energy-constrained stations. Power Save

Mode (PSM) enables the stations to wake up periodically

and check if the AP has any buffered packet(s) for them.

The AP periodically broadcasts beacon packets at certain

intervals called Beacon Interval (BI) to inform the stations

about their buffered packets. Stations send PS-Poll packet to

the AP to request delivery. PSM signiﬁcantly increases com-

munication delay because stations can only receive down-

link packets after each beacon instance. The delay problem

further exacerbates with the concurrent transmission of PS-

Poll packets and the accumulation of downlink delivery

after each beacon instance [9], [10]. To address this concern,

Adaptive PSM (APSM) requires a station waiting for down-

link packets to stay awake for a particular tail time duration

(e.g., 10 ms [2]) after each packet exchange with the AP [11].

The tail time may impose idle listening and further waste of

energy, especially if the delay between uplink and downlink

delivery is longer than tail time. Another enhancement of

PSM is the Automatic Power Save Delivery (APSD), which

enables the stations to request downlink packet delivery by

sending NULL uplink packets to the AP [12]. Nonetheless,

since downlink delivery delay depends on a variety of

factors, employing this mechanism is challenging. A new

power-saving mechanism introduced in 802.11ax is Target

Wake-up Time (TWT), which allows the station to set wake

up agreements with the AP. However, TWT is only a local

agreement with the Medium Access Control (MAC) layer

and it does not specify when the downlink will be ready for

the station to wake up. In general, despite the numerous

features offered by these power-saving mechanisms, the

existing solutions and implementations focus merely on

the energy-delay trade-off of regular user stations such as

smartphones [13]–[16], and no attention has been paid to

IoT application scenarios.

arXiv:2006.15514v1 [cs.NI] 28 Jun 2020

Many IoT applications require the transmission of uplink

reports by station and reception of commands from a remote

server. For example, consider a sample medical application

where an IoT device reports an event and expects to re-

ceive actuation commands in return. Another example is a

security camera that transfers images whenever a motion

is detected, and waits for a command to stream video if

a particular object is recognized. After the transmission

of uplink packets, the IoT station has ﬁve options before

receiving downlink packets:

– (i) stay in awake mode—this is known as Continuously

Active Mode (CAM),

– (ii) return to sleep mode and wake up during the next

beacon period—PSM,

– (iii) stay in awake mode for a short time duration—

APSM’s tail time),

– (iv) send a Null packet to the AP periodically to check if

the downlink packet has arrived—APSD,

– (v) wake up when the downlink packet is about to be

delivered.

Case (i) minimizes delay but does not offer any power

efﬁciency. Case (ii) causes long end-to-end delays [15], [16]

because the station has to wait until the next beacon in-

stance, even if the actual round-trip delay is less than the

time remaining until the next beacon. Besides, the delay

considerably increases when the station and server need

to complete multiple rounds of packet exchange to make

a decision1. Also, accumulating packet deliveries after each

beacon results in intensiﬁed channel access contention and

extends the delay of downlink delivery. Case (iii) is only

effective if the delivery delay is short; otherwise, this case

results in power waste. Case (iv) results in periodic wake

ups and unnecessarily increases channel access contention.

Therefore, none of these cases are suitable for applications

where both delay and energy efﬁciency are the essential per-

formance metrics. Applying case (v) requires an accurate esti-

mation of the delay between uplink and downlink packets, which

is composed of the following delay components: First, the

uplink packet received over the wireless interface must be

sent over the wired interface. The second component is

the interval between the instance the packet leaves the AP

until a response is received from the server. Third, once

the reply is received, the packet must compete with other

downlink packets and be delivered to the station when it is

in awake mode. In this paper, we show that computing the

third delay component is particularly challenging because

it depends on various factors, including airtime utilization,

the intensity of uplink and downlink communication, access

category of packets, and wireless link quality. This is also

veriﬁed by the recent studies that show the delay expe-

rienced at AP is more than 60% of the total communica-

tion delay between a station and server [18], [19]. Besides,

the buffering mechanism employed in the Linux kernel’s

network layer and wireless driver further complicates the

modeling and prediction of these delay components [19]–

[22]. For example, Intel’s IWL and Qualcomm’s ath9k and

ath10 drivers perform packet scheduling; however, these

1. Not only for IoT applications, studies show that every 10 ms

increase in network access results in a 1000 ms increase in page load

time [17].

algorithms are heuristically designed by vendors—further

complicating delay estimations.

In this paper, we propose a novel mechanism called

edge-assisted predictive sleep scheduling (EAPS) to reduce the

idle listening time and energy of stations when waiting for

downlink packets. At a high level, EAPS works as follows:

Once an uplink packet is received from an IoT station, the

delivery delay is computed using machine learning tech-

niques. The estimated delay is then conveyed to the station

using a high-priority data-plane queue. The station then

switches into sleep mode and wakes up at the scheduled

time to retrieve downlink packet.

This paper introduces the following contributions: First,

we present the implementation of a Linux-based AP with

new and modiﬁed kernel and user-space modules to keep

track of the system operation in terms of parameters such

as incoming and outgoing transmissions, buffer status, and

interference level. Second, using the modiﬁed AP, we build

a conﬁgurable testbed that allows us to generate various

trafﬁc patterns similar to real-world deployments. We char-

acterize the similarities by introducing multiple metrics.

Third, the collected information is then fed into a user-space

module, which estimates the delay components. We focus

on wired-to-wireless switching delays and their prediction

using various machine learning algorithms under different

trafﬁc scenarios. EAPS runs at the network edge to en-

sure quick decision-making about sleep schedules, which

implies that all the necessary computations to calculate

sleep schedules are performed by AP to avoid increasing

the computational load of resource-constrained IoT devices.

Fourth, we perform an empirical evaluation of the impact of

delay prediction on both energy efﬁciency and timeliness in

scenarios where IoT stations communicate with cloud and

edge servers. In terms of delay, EAPS outperforms PSM by

45% in the cloud scenario and by 84% in the edge scenario.

The energy consumption of EAPS is 26% lower in the cloud

scenario and 6% in the edge scenario, compared to PSM.

In the edge scenario, the delay of EAPS is close to that

of APSM, while its energy efﬁciency is 37% higher. In the

cloud scenario, EAPS improves delay and energy efﬁciency

by 41% and 46%, respectively, compared to APSM.

The rest of this paper is organized as follows. We present

delay components and implementation details of the AP

in Section 2. We present the edge-assisted sleep scheduling

mechanism in Section 3, and empirical performance evalua-

tions in Section 4. We overview the related works in Section

5, and ﬁnally Section 6 concludes the paper.

2 DE LAY ANALYSIS AND AP DEVELOPMENT

In this section, we ﬁrst analyze the delay components

between uplink and downlink packet delivery, and then

present our proposed AP architecture and implementation.

The proposed AP enables us to collect features that are

necessary for delay prediction and schedule dissemination

to IoT stations.

2.1 Delay Components

As Figure 1 shows, at time t1the station grasps the channel

and transmits its uplink packet. This uplink packet may

TABLE 1

Summary of key notations

Notation Meaning

δawireless to wired interface switching delay

δbAP-server communication delay (round trip)

δcwire to wireless interface switching delay

qqdisc queue utilization

bqMAC queue utilization

cuChannel utilization

cnChannel noise

wRetransmission count

rwired

in Input rate of wired interface

pipacket

δ(pi)Actual deadline of packet pi

δ0(pi)Estimated deadline of packet pi

Buﬀering

STA AP Server

UL Data Packet(s)

DL Data Packet(s)

UL NULL Packet

Sleep

Buﬀering

a

<latexit sha1_base64="dnAzV8EjjEh7TK8kIJHuPj/Nj0w=">AAAB8XicbVBNS8NAEJ3Ur1q/qh69LBbBU0lE0GPRi8cK9gPbUCabTbt0swm7G6GE/gsvHhTx6r/x5r9x2+agrQ8GHu/NMDMvSAXXxnW/ndLa+sbmVnm7srO7t39QPTxq6yRTlLVoIhLVDVAzwSVrGW4E66aKYRwI1gnGtzO/88SU5ol8MJOU+TEOJY84RWOlx37IhMFBjtNBtebW3TnIKvEKUoMCzUH1qx8mNIuZNFSg1j3PTY2fozKcCjat9DPNUqRjHLKepRJjpv18fvGUnFklJFGibElD5urviRxjrSdxYDtjNCO97M3E/7xeZqJrP+cyzQyTdLEoygQxCZm9T0KuGDViYglSxe2thI5QITU2pIoNwVt+eZW0L+qeW/fuL2uNmyKOMpzAKZyDB1fQgDtoQgsoSHiGV3hztPPivDsfi9aSU8wcwx84nz/MaZD8</latexit>

b

<latexit sha1_base64="V7liIK87k8vh42VTBVtIlkvz+Xs=">AAAB8XicbVBNS8NAEJ3Ur1q/qh69LBbBU0lE0GPRi8cK9gPbUDabTbt0swm7E6GE/gsvHhTx6r/x5r9x2+agrQ8GHu/NMDMvSKUw6LrfTmltfWNzq7xd2dnd2z+oHh61TZJpxlsskYnuBtRwKRRvoUDJu6nmNA4k7wTj25nfeeLaiEQ94CTlfkyHSkSCUbTSYz/kEukgD6aDas2tu3OQVeIVpAYFmoPqVz9MWBZzhUxSY3qem6KfU42CST6t9DPDU8rGdMh7lioac+Pn84un5MwqIYkSbUshmau/J3IaGzOJA9sZUxyZZW8m/uf1Moyu/VyoNEOu2GJRlEmCCZm9T0KhOUM5sYQyLeythI2opgxtSBUbgrf88ippX9Q9t+7dX9YaN0UcZTiBUzgHD66gAXfQhBYwUPAMr/DmGOfFeXc+Fq0lp5g5hj9wPn8Aze6Q/Q==</latexit>

c

<latexit sha1_base64="V7HOGNseAmpoZVQkrZ4t7w9x7K8=">AAAB8XicbVBNS8NAEN3Ur1q/qh69LBbBU0lE0GPRi8cK9gPbUDabSbt0swm7E6GE/gsvHhTx6r/x5r9x2+agrQ8GHu/NMDMvSKUw6LrfTmltfWNzq7xd2dnd2z+oHh61TZJpDi2eyER3A2ZACgUtFCihm2pgcSChE4xvZ37nCbQRiXrASQp+zIZKRIIztNJjPwSJbJDz6aBac+vuHHSVeAWpkQLNQfWrHyY8i0Ehl8yYnuem6OdMo+ASppV+ZiBlfMyG0LNUsRiMn88vntIzq4Q0SrQthXSu/p7IWWzMJA5sZ8xwZJa9mfif18swuvZzodIMQfHFoiiTFBM6e5+GQgNHObGEcS3srZSPmGYcbUgVG4K3/PIqaV/UPbfu3V/WGjdFHGVyQk7JOfHIFWmQO9IkLcKJIs/klbw5xnlx3p2PRWvJKWaOyR84nz/Pc5D+</latexit>

DL Control Packet

Fig. 1. The end-to-end delay components between a station and a

server. The prediction of δcis particularly challenging because it is

affected by several factors such as trafﬁc rate, channel utilization, and

buffering mechanisms employed by the Linux kernel’s network layer and

wireless NIC’s driver.

represent a single uplink packet sent by the station or the

last packet of a burst of uplink packets. After this, the

station waits to receive the downlink packet(s) from the

AP. We refer to the process of uplink and downlink packet

exchange as transaction. In event-driven applications, the

downlink packet is usually a command message issued by

a server in response to the message sent by the station.

After the transmission of the uplink packet, the station

has ﬁve options: (i) CAM: stay awake until the reception

of the downlink packet, (ii) PSM: wake up at the next

beacon instance, (iii) APSM: stay awake for a short tail time

duration, transition into sleep mode if no communication

happens during the tail time, and wake up at the next

beacon instance to receive the buffered packet, (iv) APSD:

send a Null packet to the AP periodically to check if the

downlink packet has arrived, and (v) transition into sleep

mode and wake up when the downlink packet is ready

to be sent by the AP. As explained in Section 1, cases (i)

through (iv) are not suitable for applications where both

delay and energy efﬁciency are the essential performance

metrics. Therefore, in this paper, we focus on the case (v) to

enable the station to switch to sleep mode while waiting

for downlink transmission. To reduce the waiting time for

downlink packet delivery, the station transitions into sleep

mode after the reception of a control packet at t2and wakes

up at t7to request and receive the downlink packet. The

sleep duration is conveyed to the station by the AP through

Kernel

Driver

User Space

Collector

PHY

ChMon

NetQMon

Sniffer

MACQMon

Scheduler

NetMon

Wired NIC Wireless NIC 1 Wireless NIC 2

Egress

MAC queues

netfilter qdisc

hostapd

t1,t

<latexit sha1_base64="/uJrnT8ZWvOzw2tAKwgCnWbDAis=">AAAB8nicbVBNS8NAEJ34WetX1aOXxSJ4kJKIYI9FLx4r2A9oQ9lsN+3SzSbsToQS8jO8eFDEq7/Gm//GbZuDtj7Y5fHeDDPzgkQKg6777aytb2xubZd2yrt7+weHlaPjtolTzXiLxTLW3YAaLoXiLRQoeTfRnEaB5J1gcjfzO09cGxGrR5wm3I/oSIlQMIpW6uEg8/JL+9fzQaXq1tw5yCrxClKFAs1B5as/jFkacYVMUmN6npugn1GNgkmel/up4QllEzriPUsVjbjxs/nKOTm3ypCEsbZPIZmrvzsyGhkzjQJbGVEcm2VvJv7n9VIM634mVJIiV2wxKEwlwZjM7idDoTlDObWEMi3sroSNqaYMbUplG4K3fPIqaV/VPLfmPVxXG7dFHCU4hTO4AA9uoAH30IQWMIjhGV7hzUHnxXl3Phala07RcwJ/4Hz+AAgykRM=</latexit>

qvo,

qvi,

qbe,

qbk

<latexit sha1_base64="E54zLxSAFhswR2B+aYB7sgy54J4=">AAACOXicbZDLSsNAFIYn9VbrLerSzWARXEhJtKDLohuXFewFmhAm00k7dCaJM5NCCXktN76FO8GNC0Xc+gJO2izs5YeBn++cw5zz+zGjUlnWm1FaW9/Y3CpvV3Z29/YPzMOjtowSgUkLRywSXR9JwmhIWooqRrqxIIj7jHT80V1e74yJkDQKH9UkJi5Hg5AGFCOlkWc2n7w0dThSQ8HTcZRl2YXjwDlIV0CfrIIjDT2zatWsqeCysQtTBYWanvnq9COccBIqzJCUPduKlZsioShmJKs4iSQxwiM0ID1tQ8SJdNPp5Rk806QPg0joFyo4pf8nUsSlnHBfd+ZLysVaDlfVeokKbtyUhnGiSIhnHwUJgyqCeYywTwXBik20QVhQvSvEQyQQVjrsig7BXjx52bQva3a9dvVQrzZuizjK4AScgnNgg2vQAPegCVoAg2fwDj7Bl/FifBjfxs+stWQUM8dgTsbvHwdysKk=</latexit>

ˆqvo,ˆqvi ,

ˆqbe,ˆqbk

<latexit sha1_base64="l4ZaRVNaej57kf8eBUddZ4Flr+k=">AAACTXicdZHNS8MwGMbT+bE5v6oevQSH4EFGqwM9Dr14nOA+YC0lTbMtLGlrkg5G6T/oRfDmf+HFgyJiuvWg23wh8PD83pe8eeLHjEplWa9GaW19Y7Nc2apu7+zu7ZsHhx0ZJQKTNo5YJHo+koTRkLQVVYz0YkEQ9xnp+uPbnHcnREgahQ9qGhOXo2FIBxQjpS3PDJwRUulj5qWpw5EaCZ5OoizLzuEKQHPgOCuQT/6Z8ccaeGbNqluzgsvCLkQNFNXyzBcniHDCSagwQ1L2bStWboqEopiRrOokksQIj9GQ9LUMESfSTWdpZPBUOwEcREKfUMGZ+3siRVzKKfd1Z76kXGS5uYr1EzW4dlMaxokiIZ5fNEgYVBHMo4UBFQQrNtUCYUH1rhCPkEBY6Q+o6hDsxScvi85F3W7UL+8bteZNEUcFHIMTcAZscAWa4A60QBtg8ATewAf4NJ6Nd+PL+J63loxi5gj8qVL5B1UDuUY=</latexit>

cu,c

n,w

<latexit sha1_base64="t4u1+l6OqbgFZOhu5T+U+Nz0CoI=">AAACCnicbVC7TsMwFHV4lvIKMLIYKiQGVCVQCcYKFsYi0YfURpHjOq1V24lsB1RFmVn4FRYGEGLlC9j4G5w2Q2k5kqVzz7lXvvcEMaNKO86PtbS8srq2Xtoob25t7+zae/stFSUSkyaOWCQ7AVKEUUGammpGOrEkiAeMtIPRTe63H4hUNBL3ehwTj6OBoCHFSBvJt4+wn/Y40kPJ0yTLzuBMLfL60bcrTtWZAC4StyAVUKDh29+9foQTToTGDCnVdZ1YeymSmmJGsnIvUSRGeIQGpGuoQJwoL52cksETo/RhGEnzhIYTdXYiRVypMQ9MZ76lmvdy8T+vm+jwykupiBNNBJ5+FCYM6gjmucA+lQRrNjYEYUnNrhAPkURYm/TKJgR3/uRF0jqvurXqxV2tUr8u4iiBQ3AMToELLkEd3IIGaAIMnsALeAPv1rP1an1Yn9PWJauYOQB/YH39Aghhmxs=</latexit>

Control Packet

Driver Ingress

MAC queues

netlink

t3,t

<latexit sha1_base64="CyBhQ6D1nWMQbCBZLg4TEMawvrE=">AAAB83icbVBNSwMxEJ2tX7V+VT16CRbBg5RdFfVY9OKxgv2AdinZNG1Ds9klmRXKsn/DiwdFvPpnvPlvTNs9aOuDYR7vzZDJC2IpDLrut1NYWV1b3yhulra2d3b3yvsHTRMlmvEGi2Sk2wE1XArFGyhQ8nasOQ0DyVvB+G7qt564NiJSjziJuR/SoRIDwShaqYu99CI7I7ZdZb1yxa26M5Bl4uWkAjnqvfJXtx+xJOQKmaTGdDw3Rj+lGgWTPCt1E8NjysZ0yDuWKhpy46ezmzNyYpU+GUTalkIyU39vpDQ0ZhIGdjKkODKL3lT8z+skOLjxU6HiBLli84cGiSQYkWkApC80ZygnllCmhb2VsBHVlKGNqWRD8Ba/vEya51XPrXoPl5XabR5HEY7gGE7Bg2uowT3UoQEMYniGV3hzEufFeXc+5qMFJ985hD9wPn8AYICRPQ==</latexit>

rwired

<latexit sha1_base64="jCpAvzN3Vormwfy6YCwSMqNvayw=">AAACCXicbVC7TsMwFHXKq5RXgJHFokJiqhKoBGMFC2OR6ENqS+Q4TmvVdiLbAVVRVhZ+hYUBhFj5Azb+BqeNELQcydLxuffq3nP8mFGlHefLKi0tr6yuldcrG5tb2zv27l5bRYnEpIUjFsmujxRhVJCWppqRbiwJ4j4jHX98mdc7d0QqGokbPYnJgKOhoCHFSBvJs6H00j5HeiR5SkWW3f787qkkQZZ5dtWpOVPAReIWpAoKND37sx9EOOFEaMyQUj3XifUgRVJTzEhW6SeKxAiP0ZD0DBWIEzVIp04yeGSUAIaRNE9oOFV/T6SIKzXhvunMz1TztVz8r9ZLdHg+MA7jRBOBZ4vChEEdwTwWGBi3WLOJIQhLam6FeIQkwtqEVzEhuPOWF0n7pObWa6fX9WrjooijDA7AITgGLjgDDXAFmqAFMHgAT+AFvFqP1rP1Zr3PWktWMbMP/sD6+AbkHZu8</latexit>

Driver

netlink

Fig. 2. The AP architecture developed and used in this paper. The

Collector module communicates with various kernel and user-space

components to collect a set of features required for delay prediction.

The Scheduler estimates the sleep duration and conveys it to the

station. This ﬁgure primarily focuses on the wired-to-wireless interfaces

path to compute δc. Some of the modules required to collect other delay

components (δaand δb) are not included in this ﬁgure.

a control packet sent at t2. Therefore, we need to estimate

the delay between t1to t7. To this end, we ﬁrst modify a

Linux-based AP by adding new user-space and kernel-space

modules.

It is worth noting that the uplink packet sent at t7may

be followed by the delivery of multiple downlink packets.

As per the 802.11e amendment, stations can start a Transmit

Opportunity (TXOP) for downlink delivery. For example, if

the trafﬁc belongs to the voice Access Category (AC), the

AP will reserve a 1.504 ms slot for downlink delivery to the

station.

2.2 AP Development

Unfortunately, the current AP architectures do not provide

the necessary tools to collect and apply predictive schedul-

ing [23]. In this section, we present an AP architecture that

allows us to collect the features necessary for predictive

scheduling. Figure 2 presents the modules we developed

on a Linux-based AP. The user-space components of the

AP are Collector and Scheduler. The Collector is

responsible for collecting all the features required to predict

delay. This information is then shared with and used by

the Scheduler to train a model, estimate the sleep dura-

tion, and dispatch the schedule. The Collector module

includes the following modules: The Sniffer module uti-

lizes the libpcap library to capture the timestamp of pack-

ets as soon as they are sent or received by the wireless NIC.

The NetMon module records packet exchange instances over

the wired interface as well as incoming data rate over this

interface. The NetQMon and MACQMon are responsible for

keeping track of the utilization of qdisc and MAC layer

queues, respectively. The ChUMon module captures channel

utilization.

To perform the standard AP functionalities, we use

hostapd [24], which is a user-space daemon that han-

dles beacon transmission, authentication, and association

of stations. The underlying hardware includes an Atheros

AR9462 wireless NIC, ath9k driver, a Core i3 processor, and

8 GB of RAM. The AP operates in 802.11n mode, uses two

antennas, and supports up to 144 Mbps.

We explain the implementation detail and operation of

the AP in the next three sections.

2.3 Communication Delay Between AP and Server

Once the AP receives an uplink packet, it is stored in

the Linux kernel’s qdisc buffers, and then is sent over the

wired interface. The qdisc is the scheduling mechanism

employed by the kernel to schedule the transmission of

packets while switching them between two interfaces. This

buffering delay, denoted as δa=t3−t1, depends on the

difference between the rate of incoming wireless uplink

packets (destined to the wired interface) and the rate of

transmitting these packets over the wired interface. In this

paper, we assume that the speed of the wired interface is

ﬁxed. This is a reasonable assumption: First, in enterprise

environments, APs are connected to switches via Ethernet

links supporting at least 1 Gbps. This may also be true in

a residential environment where the AP is connected to a

local processing server through Ethernet [25]. For residen-

tial environments, also, ﬁber-to-the-home (FTTH) provides

data rates higher than wireless. Second, the uplink speed

between a home modem and an Internet provider is ﬁxed.

For example, DOCSIS employs a combination of TDMA and

CDMA for deterministic channel access.

Based on these observations, we compute δaby knowing

the number of packets currently in the qdisc2of wired

interface (not shown in Figure 2). We have modiﬁed the qdisc

module to communicate the number of packets in this buffer

with NetMon. For each packet piin qdisc, the Scheduler

computes ν(pi) = 8 ×(s(pi) + hmac +hphy)/lwired

out , where

ν(pi)is the time required to transmit pi,s(pi)is the packet

size (bytes), hmac is the MAC header size (bytes), hphy is the

physical header size (bytes), and lwired

out is the transmission

bit rate supported by the wired link. The switching delay is

therefore computed as δa=P∀pi∈qdisc ν(pi).

The delivery delay between the AP and the server, i.e.,

t4−t3and t6−t5, depend on various factors and primarily

on the number of hops between these two nodes. Based

on this number, we consider edge and cloud computing

scenarios. Edge computing is employed in latency-sensitive

and mission-critical applications to minimize the latency

and overhead of communication over the wired network

[26]. In the cloud computing scenario, the server is located

at least a few hops away from the AP. For both cases, to

measure this delay, we use a moving average, which is

the standard approach used by various protocols such as

TCP to estimate RTT [27], [28]. To this end, we modify the

netfilter [29] kernel module to communicate with the

NetMon module and timestamp t3as the instance the packet

is sent to the wired NIC, and t6as the instance the packet

has arrived in the AP.

2. qdisc implements a scheduler responsible for trafﬁc shaping and

policing at layer 3.

2.4 AP to Station Delivery Delay

An incoming packet from the wired interface ﬁrst passes

through ingress driver queues. Subsequently, the packet is

processed by the netfilter module. The packet is then

queued in the qdisc. Finally, the packets are queued at

the Enhanced Distributed Channel Access (EDCA) queues

inside the wireless NIC’s driver. These packets are served

according to the channel contention parameters speciﬁed by

the 802.11e standard. Speciﬁcally, each of the driver queues

contends (individually) for channel access before packet

transmission.

Here we mainly focus on the delay between the arrival of

a downlink packet through the AP’s wired interface and its

transmission through the wireless interface. This delay is de-

noted as δc=t7−t6. It is particularly challenging to model

and predict this delay because it is affected by several factors

such as queuing strategy and queue utilization at the qdisc

and MAC layer, channel utilization, number of stations, and

link quality. However, in addition to the high complexity

of buffering mechanisms implemented by wireless drivers

such as ath9k and ath10k [20], [21], the actual operation of

non-open source drivers is not known, which makes it im-

possible to develop a mathematical model of buffering de-

lay. Therefore, we follow a data-driven approach to predict

δc. The predicted value is denoted as δ0

c. The Collector

module time stamps the switching delay between the wired

and wireless interfaces. The time of packet arrival from

the downlink transmission is determined by the Sniffer

module, which in turn informs the Collector. During

t6to t8, the Collector also collects statistics regarding

the status of queues and channel condition. The collected

parameters are explained in the following sections.

2.4.1 Input Trafﬁc Rate through Wired Interface

The incoming trafﬁc through wired interface, denoted as

rwired

in (bytes/second), impacts the current and future uti-

lization of AP’s layer-3 and layer-2 queues. Especially, the

burstiness of the trafﬁc cannot be characterized by taking

into account only queue utilization in the APs. Hence, the

NetMon module communicates with wired interface driver

to collect incoming trafﬁc rate.

2.4.2 qdisc Queues

The Linux’s network layer buffering of packets during

wired to wireless switching is administered by qdisc. By

default, every network interface is assigned pﬁfo fast as

its transmission queuing mechanism [19]. This mechanism

contains three bands, and dequeuing from a band only hap-

pens when its upper bands are empty. The PRIO qdisc is a

classful-conﬁgurable alternative of pﬁfo fast and enables us

to conﬁgure the number of bands. To enqueue the packets of

each AC in its own queue, we implement four queues in this

layer. These queues are denoted by Q={qvo, qvi , qbe, qbk }.

We have modiﬁed the PRIO kernel module to communicate

with the NetQMon module to collect the number of packets

in each qdisc band.

With PRIO qdisc, the queuing delay experienced by a

packet enqueued in the lowest priority queue not only

depends on the current utilization level of that queue, but

also on the number of packets in the higher priority queues.

In addition to the four queues mentioned above, we have

also included an additional queue—called control queue—

that is assigned the highest priority level. We will utilize

this queue in order to implement a higher priority data

plane used to send the control packet that conveys sleep

schedules to stations. We will explain this packet later.

It is worth mentioning that, although our implementation

includes only the PRIO qdisc mechanism (the default policy

used in several Linux systems) the concept can easily be

extended to other types of qdisc scheduling strategies as

well.

2.4.3 Wireless Channel Condition

Both interference and channel utilization are the main chan-

nel condition parameters that affect packet transmission de-

lay. However, the duration and intensity of these parameters

depend on various factors, such as the number of contend-

ing stations and APs, burst size, TXOP, and the transmission

power of nearby stations and APs. Therefore, accounting

for the effect of channel condition through measuring the

factors (mentioned above) would be very challenging. In-

stead, we collect three parameters to capture the effect of

interference and channel utilization on the delay of packet

transmission. The ﬁrst parameter is channel utilization (cu),

which refers to the amount of time the AP or its associ-

ated stations are transmitting. The second parameter is the

number of MAC layer retransmissions (w) performed by

the AP to deliver packets to stations. The third parameter

is the channel’s noise level (cn), which reﬂects the activity

of nearby wireless devices (such as other APs, ZigBee, and

Bluetooth devices).

Most 802.11 drivers maintain counters that represent

trafﬁc and channel conditions. For example, the rate of

updating ch_time_busy reﬂects channel utilization during

a sampling interval. The ChUMon module is responsible to

extract these counters from wireless NIC driver.

However, we realized that the interval of obtaining

channel utilization also impacts measurement accuracy. We

obtained the peak accuracy, in terms of Kendall’s corre-

lation coefﬁcient, when the frequency of polling cuis 10

ms. Additionally, the granularity of the measurements also

decreases as we increase the frequency of polling the chan-

nel utilization. This is because the counters provided by

the NIC are reported in milliseconds. For example, if the

sampling frequency is 10 ms, the granularity of cuobtained

in percentage is 10%.

2.4.4 Driver’s Transmission Queues

Using Enhanced Distributed Coordination Function

(EDCF), packets arriving at the MAC layer are categorized

and inserted into one of the four queues assigned to each

station inside the driver. The categorization relies on the

IP header’s Type of Service (ToS) ﬁeld. These queues

are denoted by ˆ

Q={ˆqvo,ˆqvi,ˆqbe,ˆqbk}. Each of these

queues behaves like a virtual station that contends for

channel access independently according to the contention

parameters speciﬁed in beacon frames. In case of internal

collision between two or more queues, the higher priority

queue is granted the transmission opportunity. The status

of these queues are monitored by the MACQMon module

through communicating with the driver.

2.4.5 Summary of the Features Collected

The Scheduler interacts with Collector to gather the

features necessary for delay prediction. In summary, the

developed AP enables us to collect the following features

periodically:

Cu,Cn,Rwired

in ,W,Qvo,Qvi,Qbe,Qbk ,

Qvo,b

Qvi,b

Qbe,b

Qbk

(1)

where Cu,Cn,R,Q,b

Q, and Wrepresent the list of

channel utilization values, list of channel noise values, list

of incoming trafﬁc rate values over wired interface, list of

MAC layer downlink retransmission values, list of qdisc-

queue utilization values (for each AC), and list of driver-

queue utilization values (for each AC), respectively. Each of

these lists includes the values that have been periodically

collected. For example, assuming that each list contains k

values, list Cuis represented as follows:

Cu= [cu(t0−(k−1) ×∆),

cu(t0−(k−2) ×∆), ..., cu(t0−∆), cu(t0)] (2)

where cu(t0)is the last sampled value based on the period-

ical sampling technique, and ∆refers to sampling interval.

In our implementation, we collect samples every 10 ms

(∆ = 10 ms), and each prediction uses the past 5 sam-

pled values (k= 6). We did not use a shorter sampling

interval because that resulted in a high processor utilization

(>30%). Implementing a more efﬁcient AP architecture is

one of our future works.

In addition to the features collected periodically, we add

two features that are computed once for each prediction.

First, since each AC is treated differently at the driver,

we include the AC of the transaction as a feature as well.

The second feature is δa+δb. Including this feature is

motivated by the fact that the predicted delay (δ0

c) depends

on the interval between the uplink packet and the arrival of

downlink packet over the wired interface. For example, if

the server delay is expected to be 30 ms, the prediction for

δcshould be made for a packet that would arrive at the AP

after 30 ms.

2.5 Schedule Announcement

The Scheduler module is also responsible for conveying

the predicted sleep schedule to the station. Once the predic-

tion has been made, the Scheduler creates a UDP control

packet and sends it to the station. This packet includes δa,

δb, and δc, as well as the standard deviation of prediction

error, where each is encoded as one byte. The value of

each byte reﬂects duration in milliseconds. To prioritize the

transmission of this tiny packet over existing data packets,

we modify the qdisc module and add a high-priority band

to it. The ToS ﬁeld of this high-priority band is 7, which

is the highest network layer priority. This band is also

mapped to the voice AC of driver’s queues to expedite

packet transmission. This AC uses a shorter contention

window and smaller Arbitration Inter-Frame Space (AIFS),

as deﬁned by the 802.11e standard. Therefore, all the control

packets generated by the Scheduler are sent through this

high-priority data plane. Once this control packet reaches

the station at t2, the station immediately transitions into

<latexit sha1_base64="sjLQ8VYcckeCK/xgYQAyaffDN1s=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0m0oMeiF48V7Qe0oWy2m3bpZhN2J0IJ/QlePCji1V/kzX/jts1BWx8MPN6bYWZekEhh0HW/ncLa+sbmVnG7tLO7t39QPjxqmTjVjDdZLGPdCajhUijeRIGSdxLNaRRI3g7GtzO//cS1EbF6xEnC/YgOlQgFo2ilh6B/2S9X3Ko7B1klXk4qkKPRL3/1BjFLI66QSWpM13MT9DOqUTDJp6VeanhC2ZgOeddSRSNu/Gx+6pScWWVAwljbUkjm6u+JjEbGTKLAdkYUR2bZm4n/ed0Uw2s/EypJkSu2WBSmkmBMZn+TgdCcoZxYQpkW9lbCRlRThjadkg3BW355lbQuql6tenlfq9Rv8jiKcAKncA4eXEEd7qABTWAwhGd4hTdHOi/Ou/OxaC04+cwx/IHz+QPvGY2S</latexit>

<latexit sha1_base64="9ximDC9E40A4s8ueLssgYGifTyk=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0m0oMeiF48V7Qe0oWy2k3bpZhN2N0IJ/QlePCji1V/kzX/jts1BWx8MPN6bYWZekAiujet+O4W19Y3NreJ2aWd3b/+gfHjU0nGqGDZZLGLVCahGwSU2DTcCO4lCGgUC28H4dua3n1BpHstHM0nQj+hQ8pAzaqz0EPRr/XLFrbpzkFXi5aQCORr98ldvELM0QmmYoFp3PTcxfkaV4UzgtNRLNSaUjekQu5ZKGqH2s/mpU3JmlQEJY2VLGjJXf09kNNJ6EgW2M6JmpJe9mfif101NeO1nXCapQckWi8JUEBOT2d9kwBUyIyaWUKa4vZWwEVWUGZtOyYbgLb+8SloXVa9WvbyvVeo3eRxFOIFTOAcPrqAOd9CAJjAYwjO8wpsjnBfn3flYtBacfOYY/sD5/AHwnY2T</latexit>

<latexit sha1_base64="2lklh8830guBScvk9e4sykwChWU=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0m0oseiF48V7Qe0oWy2k3bpZhN2N0IJ/QlePCji1V/kzX/jts1Bqw8GHu/NMDMvSATXxnW/nMLK6tr6RnGztLW9s7tX3j9o6ThVDJssFrHqBFSj4BKbhhuBnUQhjQKB7WB8M/Pbj6g0j+WDmSToR3QoecgZNVa6D/oX/XLFrbpzkL/Ey0kFcjT65c/eIGZphNIwQbXuem5i/Iwqw5nAaamXakwoG9Mhdi2VNELtZ/NTp+TEKgMSxsqWNGSu/pzIaKT1JApsZ0TNSC97M/E/r5ua8MrPuExSg5ItFoWpICYms7/JgCtkRkwsoUxxeythI6ooMzadkg3BW375L2mdVb1a9fyuVqlf53EU4QiO4RQ8uIQ63EIDmsBgCE/wAq+OcJ6dN+d90Vpw8plD+AXn4xvyIY2U</latexit>

g(b2)>✓

<latexit sha1_base64="N6aDVcG8WXXtTfJ68RtDGqicFJ4=">AAAB9XicbVDLSgNBEJyNrxhfUY9eBoMQL2E3BvQkAS8eI5gHJGuYnfQmQ2YfzPQqYcl/ePGgiFf/xZt/4yTZgyYWNBRV3XR3ebEUGm3728qtrW9sbuW3Czu7e/sHxcOjlo4SxaHJIxmpjsc0SBFCEwVK6MQKWOBJaHvjm5nffgSlRRTe4yQGN2DDUPiCMzTSw5CWvX71/LqHI0DWL5bsij0HXSVORkokQ6Nf/OoNIp4EECKXTOuuY8fopkyh4BKmhV6iIWZ8zIbQNTRkAWg3nV89pWdGGVA/UqZCpHP190TKAq0ngWc6A4YjvezNxP+8boL+lZuKME4QQr5Y5CeSYkRnEdCBUMBRTgxhXAlzK+UjphhHE1TBhOAsv7xKWtWKU6tc3NVK9XoWR56ckFNSJg65JHVySxqkSThR5Jm8kjfryXqx3q2PRWvOymaOyR9Ynz/2mpGF</latexit>

g(b3)>✓

<latexit sha1_base64="wcF3cYt4PWoGT+gOSK91g/sIIQU=">AAAB9XicbVDLSgNBEJyNrxhfUY9eBoMQL2HXBPQkAS8eI5gHJGuYnfQmQ2YfzPQqYcl/ePGgiFf/xZt/4yTZgyYWNBRV3XR3ebEUGm3728qtrW9sbuW3Czu7e/sHxcOjlo4SxaHJIxmpjsc0SBFCEwVK6MQKWOBJaHvjm5nffgSlRRTe4yQGN2DDUPiCMzTSw5CWvX71/LqHI0DWL5bsij0HXSVORkokQ6Nf/OoNIp4EECKXTOuuY8fopkyh4BKmhV6iIWZ8zIbQNTRkAWg3nV89pWdGGVA/UqZCpHP190TKAq0ngWc6A4YjvezNxP+8boL+lZuKME4QQr5Y5CeSYkRnEdCBUMBRTgxhXAlzK+UjphhHE1TBhOAsv7xKWhcVp1ap3tVK9XoWR56ckFNSJg65JHVySxqkSThR5Jm8kjfryXqx3q2PRWvOymaOyR9Ynz/4JpGG</latexit>

d(b3)

d(b4)

d(b1)

<latexit sha1_base64="RMoCNakOcoiaehtMuLck+zxayQU=">AAAB7XicbVBNSwMxEJ2tX7V+VT16CRahXsquLeix4MVjBfsB7VKy2Wwbm02WJCuUpf/BiwdFvPp/vPlvTNs9aOuDgcd7M8zMCxLOtHHdb6ewsbm1vVPcLe3tHxwelY9POlqmitA2kVyqXoA15UzQtmGG016iKI4DTrvB5Hbud5+o0kyKBzNNqB/jkWARI9hYqRNWg6F3OSxX3Jq7AFonXk4qkKM1LH8NQknSmApDONa677mJ8TOsDCOczkqDVNMEkwke0b6lAsdU+9ni2hm6sEqIIqlsCYMW6u+JDMdaT+PAdsbYjPWqNxf/8/qpiW78jIkkNVSQ5aIo5chINH8dhUxRYvjUEkwUs7ciMsYKE2MDKtkQvNWX10nnquY1avX7RqXZzOMowhmcQxU8uIYm3EEL2kDgEZ7hFd4c6bw4787HsrXg5DOn8AfO5w9wLY5h</latexit>

d(b2)

g(b5)>✓

g(b6)>✓

<latexit sha1_base64="8m29W87RXUimbtzy1Cke2BLrZ2c=">AAAB9XicbVDLSgNBEOyNrxhfUY9eBoMQL2FXg3qSgBePEcwDkjXMTmaTIbMPZnqVsOQ/vHhQxKv/4s2/cZLsQRMLGoqqbrq7vFgKjbb9beVWVtfWN/Kbha3tnd294v5BU0eJYrzBIhmptkc1lyLkDRQoeTtWnAae5C1vdDP1W49caRGF9ziOuRvQQSh8wSga6WFAyl7v4vS6i0OOtFcs2RV7BrJMnIyUIEO9V/zq9iOWBDxEJqnWHceO0U2pQsEknxS6ieYxZSM64B1DQxpw7aazqyfkxCh94kfKVIhkpv6eSGmg9TjwTGdAcagXvan4n9dJ0L9yUxHGCfKQzRf5iSQYkWkEpC8UZyjHhlCmhLmVsCFVlKEJqmBCcBZfXibNs4pTrZzfVUu1WhZHHo7gGMrgwCXU4Bbq0AAGCp7hFd6sJ+vFerc+5q05K5s5hD+wPn8A/MqRiQ==</latexit>

d(b6)

d(b5)

d(b7)

. . .

g(b1)>✓

<latexit sha1_base64="1M8YFHH6mMnpgW/S7BResYEBFoM=">AAACA3icbVBNS8NAEN34WetX1JteFotQLyXRgp6k4MVjBfsBbQib7bRdutmE3YlQS8GLf8WLB0W8+ie8+W9M2h609cHA470ZZuYFsRQGHefbWlpeWV1bz23kN7e2d3btvf26iRLNocYjGelmwAxIoaCGAiU0Yw0sDCQ0gsF15jfuQRsRqTscxuCFrKdEV3CGqeTbhz1aDHz39KqtIh0yacQDtLEPyPK+XXBKzgR0kbgzUiAzVH37q92JeBKCQi6ZMS3XidEbMY2CSxjn24mBmPEB60ErpYqFYLzR5IcxPUmVDu1GOi2FdKL+nhix0JhhGKSdIcO+mfcy8T+vlWD30hsJFScIik8XdRNJMaJZILQjNHCUw5QwrkV6K+V9phnHNLYsBHf+5UVSPyu55dL5bblQqcziyJEjckyKxCUXpEJuSJXUCCeP5Jm8kjfryXqx3q2PaeuSNZs5IH9gff4AjsiW1w==</latexit>

<latexit sha1_base64="af25PHze9uAjobHMuG3W7S9BU/w=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0m0qMeiF48V7Qe0oWy2k3bpZhN2N0IJ/QlePCji1V/kzX/jts1Bqw8GHu/NMDMvSATXxnW/nMLK6tr6RnGztLW9s7tX3j9o6ThVDJssFrHqBFSj4BKbhhuBnUQhjQKB7WB8M/Pbj6g0j+WDmSToR3QoecgZNVa6D/oX/XLFrbpzkL/Ey0kFcjT65c/eIGZphNIwQbXuem5i/Iwqw5nAaamXakwoG9Mhdi2VNELtZ/NTp+TEKgMSxsqWNGSu/pzIaKT1JApsZ0TNSC97M/E/r5ua8MrPuExSg5ItFoWpICYms7/JgCtkRkwsoUxxeythI6ooMzadkg3BW375L2mdVb1a9fyuVqlf53EU4QiO4RQ8uIQ63EIDmsBgCE/wAq+OcJ6dN+d90Vpw8plD+AXn4xvzpY2V</latexit>

<latexit sha1_base64="pK82w6B72QsQaU2Zc05Ufa8XtsE=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0m0UI9FLx4rWltoQ9lsJ+3SzSbsboQS+hO8eFDEq7/Im//GbZuDtj4YeLw3w8y8IBFcG9f9dgpr6xubW8Xt0s7u3v5B+fDoUcepYthisYhVJ6AaBZfYMtwI7CQKaRQIbAfjm5nffkKleSwfzCRBP6JDyUPOqLHSfdCv98sVt+rOQVaJl5MK5Gj2y1+9QczSCKVhgmrd9dzE+BlVhjOB01Iv1ZhQNqZD7FoqaYTaz+anTsmZVQYkjJUtachc/T2R0UjrSRTYzoiakV72ZuJ/Xjc14ZWfcZmkBiVbLApTQUxMZn+TAVfIjJhYQpni9lbCRlRRZmw6JRuCt/zyKnm8qHq16uVdrdK4zuMowgmcwjl4UIcG3EITWsBgCM/wCm+OcF6cd+dj0Vpw8plj+APn8wf1KY2W</latexit>

g(b4)>✓

<latexit sha1_base64="VmZTryuOrbR/lXT6e3kdnxP4CNc=">AAAB9XicbVDLSgNBEOz1GeMr6tHLYBDiJexqQE8S8OIxgnlAsobZyWwyZHZ2melVQsh/ePGgiFf/xZt/4yTZgyYWNBRV3XR3BYkUBl3321lZXVvf2Mxt5bd3dvf2CweHDROnmvE6i2WsWwE1XArF6yhQ8laiOY0CyZvB8GbqNx+5NiJW9zhKuB/RvhKhYBSt9NAnpaBbObvu4IAj7RaKbtmdgSwTLyNFyFDrFr46vZilEVfIJDWm7bkJ+mOqUTDJJ/lOanhC2ZD2edtSRSNu/PHs6gk5tUqPhLG2pZDM1N8TYxoZM4oC2xlRHJhFbyr+57VTDK/8sVBJilyx+aIwlQRjMo2A9ITmDOXIEsq0sLcSNqCaMrRB5W0I3uLLy6RxXvYq5Yu7SrFazeLIwTGcQAk8uIQq3EIN6sBAwzO8wpvz5Lw4787HvHXFyWaO4A+czx/5spGH</latexit>

Fig. 3. Trafﬁc characterisation.

sleep state for δa+δb+δc−(t2−t1). Note that the station

simply uses a timer to measure t2−t1.

To further reduce the AP’s processing overhead and the

idle listening time of station while waiting for the control

packet from the AP, we use mmap [30] for fast and shared

access. In other words, the most recent information collected

by the Collector (which are shared with the Scheduler)

is stored in the physical memory to eliminate the unpre-

dictability of accessing this data through ﬁles.

At the end of the sleep interval, the station wakes up and

informs the AP about its transition into the awake mode.

This is achieved by relying on APSD, which is supported

by the state-of-the-art wireless NICs. To this end, at t7, the

station wakes up and sends a NULL packet to the AP, con-

veying that the station is ready for receiving a packet. The

AP responds by sending the downlink packet (or starting a

TXOP) at t8.

3 PREDICTIVE SCHEDULING

In this section, we ﬁrst present our testbed setup for realistic

trafﬁc generation necessary for training and evaluation. Uti-

lizing this dataset, we discuss various stages of the statistical

learning and modeling process. Finally, we compare the

performance of several machine learning approaches for

delay prediction.

3.1 Trafﬁc Generation

As explained in the previous sections, AP modiﬁcation

is necessary to collect the features required for predictive

scheduling. Also, we need to introduce controlled changes

in the trafﬁc pattern of the environment to study the impact

of these changes on prediction accuracy. Therefore, it is

required to have a testbed that represents the trafﬁc pattern

of real-world environments as well as controllability over

trafﬁc generation parameters. To achieve this, we systemat-

ically characterize and compare the scenarios generated in

our testbed with those collected in real-world environments.

Aburst, denoted as bi, is deﬁned as a train of packets in

either UL or DL direction with inter-arrival time less than

a threshold value θ[31]. Resembling 802.11 trafﬁc, Figure 3

illustrates a series of bursts. The duration (in seconds) of a

burst biis denoted by d(bi). And g(bi)refers to the gap (in

seconds) between two consecutive bursts biand bi+1.

In order to generate trafﬁc that represents various levels

of network dynamics in real-world environments, we have

developed a testbed that includes two categories of stations:

(i) stations such as laptops, phones, and IoT devices, and

(ii) four Raspberry Pi boards to control trafﬁc generation

pattern. Each RPi runs four threads, where each thread can

be involved in a downlink, uplink, or bidirectional ﬂow.

This enables us to introduce up to 16 additional controlled

ﬂows into the network. The implementation of trafﬁc control

capability is composed of a set of Python scripts that use the

iperf tool under the hood. A central controller is in charge

of setting the parameters of trafﬁc ﬂows. Among the ﬂow

parameters, we can modify the access category, transport

layer protocol, packet size, bit rate, burst size, and inter-

burst interval. Also, we note that sharing ﬂow characteris-

tics by consecutive ﬂows is more likely. To represent this

behavior, after each burst, the controller either repeats the

process of trafﬁc selection or chooses the same parameters

for the next burst based on a variability parameter denoted

by ν. Speciﬁcally, a higher value of νresults in a higher

dynamicity. Hence, we use ν= 0.9for generating ﬂows that

resembles high dynamicity (HD) trafﬁc and ν= 0.1for gen-

erating less diverse trafﬁc referred to as normal dynamicity

(ND). Also, for the voice and video ACs, UDP is preferred

because it is the dominant transport protocol for real-time

trafﬁc.

As demonstrated in [31], capturing network dynamics

can be achieved by focusing on characterizing burstiness.

Additionally, Xiao et al. [32] characterized a ﬂow as reg-

ularly bursty when the standard deviation of the inter-

burst intervals (g(·)seconds) and burst sizes (s(·)bytes)

are relatively smaller. Otherwise, the ﬂow is characterized

as randomly bursty. However, based on Xiao’s metrics for

burstiness, trafﬁc with fewer bursts per unit time can still

have a high standard deviation of s(·)and g(·). Hence, we

consider burst frequency (i.e., number of bursts per second)

and burst size for calculating trafﬁc burstiness. Additionally,

due to the difference in the scale of those two parameters,

we normalize the burst rate (per second) in the range [0,1].

We deﬁne trafﬁc burstiness, denoted by B, as follows:

B=1−1

M× PN

i=1 s(bi)

N!(3)

where Nis the number of bursts in the dataset, s(bi)is

the size of burst bi(in bytes), and Mis average number of

bursts per second.

In addition to trafﬁc burstiness, we deﬁne another metric

that represents trafﬁc dynamicity based on various aspects

including burst size, burst duration, inter-burst interval, and

the access category of the packets in each burst. This metric,

which we refer to as dynamicity and denoted by D, is deﬁned

as follows:

D=

1

N×

i=2

|d(bi)−d(bi−1)|

d(bi−1)

g(bi)

+



1

N×

i=2

|s(bi)−s(bi−1)|

s(bi−1)

g(bi)

+



1

N×

i=2

|p(bi)−p(bi−1)|

p(bi−1)

g(bi)

+ 1

N×

i=2

z(bi)

g(bi)!

(4)

(a) (b)

<latexit sha1_base64="l6stLCAqqzr86EFptetBlboSQA0=">AAAB8nicbVDLSgMxFM3UV62vqks3wSK4KjNa0GVRFy4r2AdMh5JJM21oJhmSO0IZ+hluXCji1q9x59+YaWehrQcCh3PuJeeeMBHcgOt+O6W19Y3NrfJ2ZWd3b/+genjUMSrVlLWpEkr3QmKY4JK1gYNgvUQzEoeCdcPJbe53n5g2XMlHmCYsiMlI8ohTAlby+zGBMSUiu5kNqjW37s6BV4lXkBoq0BpUv/pDRdOYSaCCGON7bgJBRjRwKtis0k8NSwidkBHzLZUkZibI5pFn+MwqQxwpbZ8EPFd/b2QkNmYah3Yyj2iWvVz8z/NTiK6DjMskBSbp4qMoFRgUzu/HQ64ZBTG1hFDNbVZMx0QTCralii3BWz55lXQu6l6jfvnQqDXvijrK6ASdonPkoSvURPeohdqIIoWe0St6c8B5cd6dj8VoySl2jtEfOJ8/dGGRYA==</latexit>

<latexit sha1_base64="GRj/uuB2UxcEHaQX7Nai/+UKpIs=">AAAB8nicbVDLSgMxFM3UV62vqks3wSK4KjNa0GXBLlxWsA+YDiWTZtrQTDIkd4Qy9DPcuFDErV/jzr8x085CWw8EDufcS849YSK4Adf9dkobm1vbO+Xdyt7+weFR9fika1SqKetQJZTuh8QwwSXrAAfB+olmJA4F64XTu9zvPTFtuJKPMEtYEJOx5BGnBKzkD2ICE0pE1poPqzW37i6A14lXkBoq0B5WvwYjRdOYSaCCGON7bgJBRjRwKti8MkgNSwidkjHzLZUkZibIFpHn+MIqIxwpbZ8EvFB/b2QkNmYWh3Yyj2hWvVz8z/NTiG6DjMskBSbp8qMoFRgUzu/HI64ZBTGzhFDNbVZMJ0QTCralii3BWz15nXSv6l6jfv3QqDVbRR1ldIbO0SXy0A1qonvURh1EkULP6BW9OeC8OO/Ox3K05BQ7p+gPnM8fd2uRYg==</latexit>

Fig. 4. (a) Standard deviation of burst size, (b) standard deviation of burst

interval, (c) burstiness (B), and (d) dynamicity (D) of trafﬁc generated by

our testbed compared to trafﬁc captured in real-world environments. ND

and HD refer to normal and high dynamicity, respectively.

where,

z(bi) = |pvo(bi)−pvo(bi−1)|

pvo(bi−1)+|pvi(bi)−pvi(bi−1)|

pvi(bi−1)+

|pbe(bi)−pb e(bi−1)|

pbe(bi−1)+|pbk (bi)−pbk(bi−1)|

pbk(bi−1)

(5)

Here, px(bi)is number of packets belonging to an AC xin a

burst bi. Parameter z(bi)reﬂects the change in the number

of packets belonging to each access category in each burst

compared to that in the previous burst.

3.2 Data Collection

Using the metrics mentioned above, we compare our testbed

generated datasets against those collected in multiple real-

world environments. Figure 4 presents the results. In gen-

eral, we can observe that our ND scenario resembles real

trafﬁc. The HD scenario offers higher network dynamics,

which is essential to study the robustness of predictive

scheduling.

When generating data in our testbed, the type of each

transaction is selected from the voice, video, background,

and best-effort ACs with equal probability. The inter-

transaction delays are uniformly distributed between 1 ms

and 500 ms. In addition to the features discussed in Section

2, we also collect δa,δb, and δcvalues per transaction. We

split each dataset, such that 70% of it is used for training and

the remaining 30% is used for validation. We use indepen-

dent datasets consisting of 10,000 data points for evaluating

the performance and robustness of each modelling approach

(test datasets) in the ND and HD scenarios.

3.3 Data Pre-processing

We focus on delay prediction for δc<100 ms, for two

reasons: First, considering edge computing scenarios, ob-

serving RTTs more than 100 ms is very unlikely. Second,

almost all commercial APs implement 102.4 ms as their

beaconing period. Therefore, all stations wake up every

102.4 ms to synchronize with AP beacons and check if the

AP has any buffered packets.

Although we have ascertained that there is no unnec-

essary user-space applications running on the AP, running

kernel tasks, as well as context switching of existing pro-

cesses, can lead to a higher operating system response time.

Hence, we have noticed that the latency of data collection

from the software modules discussed in Section 2 is im-

pacted occasionally and results in longer polling intervals.

We ﬁlter the datasets to remove such stale feature values that

do not reﬂect the latest status of the channel or the queues.

The feature set varies in terms of ranges and units.

For example, cuvaries from 0 to 100%, whereas cnvaries

from −95 dBm to −66 dBm. Since this would result in

disproportional treatment of the features by the machine-

learning algorithms, we scale each of the features into the

range ±1. Furthermore, the dataset contained more samples

(transactions) whose actual delay is within the range [1,50]

ms, compared to the samples whose actual delay was be-

tween [50,100] ms. We under-sample the majority bins to

prevent the machine-learning algorithm from generalizing

the results for the packets whose actual delay is higher.

3.4 Regression models

Given the continuous nature of the target variable, we iden-

tify the problem of predicting δcas a regression problem.

The methods that we considered are Random Forest Regres-

sor (RFR), Gradient Boosting Regressor (GBR), Extra Trees

Regressor (ETR) and Histogram-Based Gradient Boosting

Regressor (HBR), which are widely-used ensemble learning

methods for regression. We also considered (deep) neural

networks, which have been shown to be effective in different

areas of machine learning such as prediction in time-series

data and image processing.

In ensemble learning, ﬁnal prediction can either be cal-

culated by average of the predictions of the model trained

on random subsets of data (bagging) or calculated via

sequentially training the model using prediction success on

the previous sample of the dataset (boosting). RFR is an

example of bagging approach and functions by constructing

several decision trees during training and makes predictions

based on the outputs of the individual trees. RFR is a

popular algorithm and runs efﬁciently on large and high-

dimensional datasets.

GBR is an example of boosting approach. Each tree out-

puts a prediction value at different splits that can be added

together, allowing subsequent models to modify error in

predictions. HBR is a variant of GBR. Since it is a histogram-

based estimator, HBR can reduce the number of splitting

points by binning input samples, and therefore improves the

performance when dealing with large datasets. ETR creates

decision stumps at variable tree depths. The features and

splits are selected randomly, and are less computationally

expensive than other tree-based algorithms.

Neural Networks (NN) have been studied extensively in

the past decade for their efﬁciency in learning complex data

features for making predictions. Recurrent Neural Networks

(RNN) are a class of neural networks in which the predic-

tions are based on the current and also past inputs, and

therefore they are suitable for making predictions about δc

using historical network features. A speciﬁc variant of RNN

is Long Short-Term Memory (LSTM) [33], which is able

(a)

Number of Training Samples

(b)

Number of Training Samples

MAE [ms]

High Dynamicity (HD)Normal Dynamicity (ND)

Fig. 5. MAE of machine-learning algorithms versus the number of sam-

ples (transactions) in training dataset for (a) Normal Dynamicity (ND),

and (b) High Dynamicity (HD) scenarios. Results are averaged over

all ACs. ETR converges the fastest, and LSTM requires up to 3x more

datapoints.

to track long-term dependencies of output predictions on

input history. We use LSTM for predicting δcand compare

its accuracy with RFR, ETR, GBR, and HBR.

For the ensemble learning methods, we use scikit-learn

library [34] and tune the hyper parameters using grid search

and a validation dataset to obtain the highest performance

on the training data while not over-ﬁtting. For the LSTM

model, we use Tensorﬂow and Keras library [35]. Also, we

utilize early stopping mechanism (on the validation dataset)

to prevent over-ﬁtting. The optimal LSTM model contains

one LSTM layer followed by 3 dense layers, each consisting

of 20 neurons and ReLu activation function. The model was

trained using Adam optimiser [36] with learning rate of 0.01.

3.5 Model Evaluation

All the evaluations are based on performance of models on

the test dataset. We ﬁrst investigate the effect of training

data size on model’s performance. Figure 5 illustrates the

Mean Absolute Error (MAE) of δcas a function of the size

of training data. We observed that the performance of ETR

converges at the fastest rate, utilizing 15000 and 20000 data

points for training under the ND and HD trafﬁc, respec-

tively. Compared to ETR, LSTM requires as much as 3x more

training data for its performance to converge, utilizing the

training dataset consisting of 30000 and 50000 datapoints

under ND and HD scenarios, respectively. Therefore, for fur-

ther evaluation of LSTM, we use training datasets consisting

of 30000 datapoints for ND scenarios and 50000 datapoints

for HD scenarios. For other algorithms, we use training

datasets consisting of 15000 and 20000 datapoints for ND

and HD scenarios, respectively.

Next, we quantify the effect of feature-history (repre-

sented by kin Eq. 2) on the overall performance of all

algorithms. Figure 6 shows the results. MAE decreases

signiﬁcantly in both HD and ND scenarios for all the al-

gorithms when we include the recent feature history as an

input for training the model. This decrease continues up

to 30 ms, beyond which it does not result in performance

enhancement. Historical data of features helps the model

to anticipate trends of features and accurately predict δc

that would be incurred by the downlink packet shortly.

Therefore, in addition to the most recent record, we include

the three preceding feature values (corresponding to a total

of the preceding 40 ms of feature values) to train the models.

Feature History [ms]Feature History [ms]

(a) (b)

MAE [ms]

High Dynamicity (HD)Normal Dynamicity (ND)

Fig. 6. MAE of machine-learning algorithms with respect to feature

history in (a) Normal Dynamicity (ND), and (b) High Dynamicity (HD)

scenarios. Results are averaged over all ACs.

Access Category

(a)

Access Category

(b)

MAE [ms]

High Dynamicity (HD)Normal Dynamicity (ND)

MAE [ms]

Fig. 7. MAE of machine-learning algorithms versus transaction’s AC in

(a) Normal Dynamicity (ND), and (b) High Dynamicity (HD) scenarios.

MAE of VO and VI packets is lower than BK and BE packets.

Figure 7 compares the performances of the machine-

learning algorithms versus AC of transactions. In the ND

scenario, compared to the average MAE of all the other

machine-learning algorithms, the MAE of LSTM is 17%

lower for all ACs. Similarly, under HD trafﬁc, the MAE of

LSTM is 13% lower than the average MAE of all the other

machine-learning algorithms. This ﬁgure also shows that the

MAE of VO and VI packets is lower than BK and BE packets.

The reason is that the packets of these ACs are prioritized

over higher ACs at the qdisc layer (using PRIO qdisc) as

well as the driver’s queues (using EDCA). This results in

lower delays incurred by the downlink packets.

Figure 7 also shows the effect of dynamicity on MAE.

Averaged over all ACs, the MAE of RFR, ETR, GBR, HBR,

and LSTM is 1.43 ms, 1.26 ms, 1.49 ms, 1.28 ms, and 1.16

ms in ND scenario. Whereas, MAE of RFR, ETR, GBR, HBR,

and LSTM is 2.49 ms, 2.17 ms, 2.69 ms, 2.27 ms and 2.01

ms in HD scenario. Since the performance of LSTM is, on

an average, 16% better than other algorithms, we use this

algorithm for empirical evaluations in Section 4.

Figure 8 shows the Empirical Cumulative Distribution

Function (ECDF) of the deviation of δ0

cfrom δc. All machine-

learning algorithms are able to predict δ0

cfor 95% of the

packets with an error of ±4.3 ms in case of ND scenario,

and ±8.2 ms for the HD scenario. However, note that LSTM

requires about 3x more training data for its performance to

converge compared to other algorithms (cf. Figure 5). Hence,

in scenarios where it is not possible to collect large datasets

for training, either ETR or RFR can also be used.

In LSTM networks, neuron activations are dependent on

the previous network states. The network retains a mem-

ory equal to the number of lookbacks (a.k.a., timesteps)—

allowing the ﬂow of information from all the previ-

Cumulative Probability [%]

|0

cc|[ms]

<latexit sha1_base64="+rEtY+ZQ1va+uN/I+KVBVBcOO+E=">AAACEnicbVA9T8MwEHX4LOWrwMhiUSFgoEqgEowIFsYi0RapiSLHvYKFnUT2BVGF/gYW/goLAwixMrHxb3DaDnw9ydK79+50vhelUhh03U9nYnJqema2NFeeX1hcWq6srLZMkmkOTZ7IRF9EzIAUMTRRoISLVANTkYR2dH1S+O0b0EYk8Tn2UwgUu4xFT3CGVgorO3d+FySyrTDnA7pLR1VR3Pm04yPcola5MoMgrFTdmjsE/Uu8MamSMRph5cPvJjxTECOXzJiO56YY5Eyj4BIGZT8zkDJ+zS6hY2nMFJggH540oJtW6dJeou2LkQ7V7xM5U8b0VWQ7FcMr89srxP+8Toa9wyAXcZohxHy0qJdJigkt8qFdoYGj7FvCuBb2r5RfMc042hTLNgTv98l/SWuv5tVr+2f16tHxOI4SWScbZJt45IAckVPSIE3CyT15JM/kxXlwnpxX523UOuGMZ9bIDzjvX65PniM=</latexit>

(a) (b)

|0

cc|[ms]

Cumulative Probability [%]

High Dynamicity (HD)Normal Dynamicity (ND)

Fig. 8. ECDF of prediction errors (|δ0

c−δc|) while utilizing various ma-

chine learning algorithms in (a) Normal Dynamicity (ND), and (b) High

Dynamicity (HD) scenarios. All machine-learning algorithms are able to

predict δ0

cfor 95% of the packets with an error of ±4.3 ms in case of ND

scenario, and ±8.2 ms for the HD scenario.

LSTM History

MAE [ms]

Fig. 9. MAE with respect to

LSTM history in ND and HD sce-

narios.

Prediction Duration [ms]

Machine Learning Algorithm

Fig. 10. Processing time re-

quired to predict delay for each

transaction.

ous timesteps [37]. Lookback is deﬁned as the number

of timesteps for which the LSTM is unfolded for back-

propagation. Simply put, the number of timesteps reﬂects

the number of previous transactions in the temporal domain

that aids in predicting the delay of the current transactions

by providing contextual information. This is particularly

beneﬁcial when multiple transactions occur during a single

burst or bursts with similar characteristics. To this end, we

estimate the effect of historical data of the previous transac-

tions by including feature values of the past transactions

and the current transaction. Figure 9 shows the MAE of

LSTM versus the number of lookbacks. We observe that the

MAE of the LSTM model decreases up to ﬁve lookbacks.

This means, on average, ﬁve transactions occur during

similar network conditions.

Figure 10 shows the prediction processing overhead of

all the machine learning algorithms on a 2.4 GHz Core-i3

processor. Each marker shows the median of time taken to

predict each data point in the test dataset, and the error bars

present lower and upper quartiles. We observed that the

HBR algorithm takes the least amount of time (24 µs median

and 0.046 µs standard deviation) for prediction, whereas

LSTM requires the most (48 µs median and 3 µs standard

deviation). However, the time taken to predict the delay

in case of LSTM is still considerably shorter than a packet

transmission time. For example, with a 1400 bytes packet

sent over a 54 Mbps link, the ratio of prediction duration to

transmission duration is 48µs/207µs.

Discussion. In our current implementation, we perform

both training and modeling on the AP. However, if the AP

is not powerful enough to train the model, then the training

could be ofﬂoaded to a cloud or fog computing platform. In

any case, edge computing is essential to perform scheduling

immediately and convey the sleep schedule to the station.

4 EMPIRICAL EVALUATION

In this section, we present an empirical evaluation of EAPS

versus the power saving mechanisms of 802.11.

4.1 Testbed

Our testbed includes four IoT stations, four Raspberry Pi

boards, regular stations (smartphones and laptops), an AP,

and a server. We simply refer to the IoT stations as station.

Each station is a Cypress CYW43907 [2], which is a low-

power 802.11n SoC designed for IoT applications. To repre-

sent a real-world scenario affected by variable background

interference, the testbed is located in a residential envi-

ronment surrounded by several APs belonging to different

households. Also, the four Raspberry Pi boards are used to

control network dynamicity and variability in δc.

To represent the request-response behavior of IoT trafﬁc,

for each uplink UDP packet sent, the server responds by

sending a downlink packet back to the station3. The ex-

change of an uplink packet and receiving its response is

referred to as a transaction. In all the ﬁgures of this section,

each marker shows the median of 1000 transactions and

the error bars present lower and upper quartiles. We use

the EMPIOT tool [38] to measure the energy and delay of

each transaction. This tool samples voltage and current at

approximately 500,000 samples per second. These samples

are then averaged and streamed at 1 Ksps. The current and

voltage resolution of this platform are 100 µA and 4 mV,

respectively.

We use two scenarios to evaluate the performance of

EAPS with respect to varying AP-server delays (i.e., δbin

Figure 1): edge, and cloud computing. In the former, the

server is directly connected to the AP, and in the latter, we

use an Amazon AWS server in Oregon. Note that in both

cases the sleep schedules are computed at the edge and by

the AP the station is associated with.

4.2 Baselines and EAPS Variations

The baseline mechanisms used are PSM, APSM, and CAM.

Using PSM, after an uplink packet, the station goes back

into sleep mode and wakes up at each beacon instance to

check for downlink packet delivery. With APSM, instead of

going back into sleep right after uplink, the station stays in

the awake mode for 10 ms. With CAM, the station always

stays in awake mode. Note that for CAM, to avoid the impact of

inter-transaction time on results, we only measure the delay and

energy consumption of transactions (only between the uplink and

downlink packets).

We consider three variants of EAPS based on predic-

tion error. To justify these variations, we ﬁrst present the

distribution of prediction errors in Figure 11 for voice and

background ACs. Based on distribution for each AC, the

station can either choose to wake up at (i) δ0−2σ, (ii) δ0+2σ,

or (iii) δ0. We call these cases EAPS with Early wake-up

(EAPS-E), EAPS with Late wake-up (EAPS-L), and EAPS

with Mid wake-up (EAPS-M). Intuitively, EAPS-E reduces

delay with a higher energy consumption, EAPS-L reduces

3. Note that the case where multiple uplink and downlink packets

are exchanged is simply supported as explained in Section 2.

(a)

0

cc[ms]

<latexit sha1_base64="HSCu05w5Mb7zeuiyUDhKMfSN6ho=">AAACEXicbVC7SgNBFJ31GeMramkzGEQbw64GtAzaWEYwD8guYXZyY4bM7C4zd8Ww5Bds/BUbC0Vs7ez8GyePQhMPDJx7zr3cuSdMpDDout/OwuLS8spqbi2/vrG5tV3Y2a2bONUcajyWsW6GzIAUEdRQoIRmooGpUEIj7F+N/MY9aCPi6BYHCQSK3UWiKzhDK7ULx34HJLKjdsaH9IROqnHh05aP8IBaZcoMg3ah6JbcMeg88aakSKaotgtffifmqYIIuWTGtDw3wSBjGgWXMMz7qYGE8T67g5alEVNggmx80ZAeWqVDu7G2L0I6Vn9PZEwZM1Ch7VQMe2bWG4n/ea0UuxdBJqIkRYj4ZFE3lRRjOoqHdoQGjnJgCeNa2L9S3mOacbQh5m0I3uzJ86R+WvLKpbObcrFyOY0jR/bJATkmHjknFXJNqqRGOHkkz+SVvDlPzovz7nxMWhec6cwe+QPn8wcoy51B</latexit>

Cumulative Probability [%]

(b)

0

cc[ms]

Cumulative Probability [%]

Fig. 11. Distribution of prediction error (δ0

c−δc) for (a) voice, and (b)

background ACs. Prediction error of voice AC is lower than that of

background AC. Depending on the application’s energy-delay trade-off,

the station may wake up before, on, or after the predicted time.

energy with a longer delay, and EAPS-M establishes a trade-

off between energy and delay. Please note that EAPS-E is

only applicable if δ0−2σ > 0.

4.3 Results

Figures 12 and 13 illustrate the average energy consumption

and duration of transactions when the station is communi-

cating with edge and cloud computing platforms under ND

and HD conditions, respectively.

In the cloud computing scenario, CAM and EAPS incur

an average round trip delay of 35 ms and 42 ms, respectively,

while EAPS consumes 63% less energy. This is because

EAPS conserves energy expenditure by switching to sleep

mode and waking up right before the packet is ready for

transmission at AP. In contrast, CAM needs to stay in awake

mode until the response is received. Reduction in energy

consumption of EAPS compared to CAM reduces to 30%

in edge environment due to the shorter duration spent in

awake mode to receive the downlink packet.

With PSM, the station immediately transitions to sleep

mode after transmitting each uplink packet. While this

results in less energy consumption compared to CAM, trans-

actions suffer about 55 ms higher delay on average because

the earliest opportunity for downlink packet delivery is after

the next beacon instance. The transaction duration of EAPS

is 62% lower compared to PSM on average across all the

ACs. With APSM, the station remains in idle (wait) state

for 10 ms after transmission or reception. This is beneﬁcial

only in speciﬁc scenarios. For example, in the edge scenario,

the station receives its downlink packet within the tail time

(similar to CAM). However, when the round trip delay

is more than 10 ms, the station will have to wake up

again to retrieve the downlink packet after the next beacon

announcement, thereby resulting in both long delay and

waste of more energy compared to PSM. On average, for

both edge and cloud scenarios, the energy consumption of

APSM is 30% higher compared to PSM. In contrast, the

energy consumption of EAPS is 20% and 43% lower than

PSM and APSM, respectively. Also, the transaction duration

of PSM, APSM, and EAPS are 77 ms, 10 ms, and 12 ms in

edge computing scenario, and 77 ms, 72 ms, and 42 ms in

cloud computing scenario.

With EAPS, the station has the freedom to choose be-

tween EAPS-E, EAPS-M, or EAPS-L, according to appli-

cation requirements. We observed that with EAPS-E, the

station suffers from slightly higher energy consumption

because it wakes up early, waits for the packet to be received

from the AP, and then transitions into sleep mode. In the

case of EAPS-L, since the station wakes up 2×σafter the

predicted delay, the downlink packet will be buffered at

the AP. However, the station can immediately transition

to sleep mode once the packet is received. Thus, energy

consumption of EAPS-L is 14% lesser compared to EAPS-

E, whereas, the transaction duration of EAPS-L is 18%

higher than EAPS-E. EAPS-M balances the trade off between

energy consumption and transaction duration.

5 RE LATED WORK

Peck et al. [13] propose PSM with adaptive wake-up (PSM-

AW), which includes a metric called PSM penalty to enable

the user to establish their desired energy-delay trade-off.

The authors deﬁne server delay as the total delay between

sending a request to a server and receiving a reply. Based

on RTT variations, the sleep duration is dynamically ad-

justed to satisfy the desired trade-off. Also, the size of the

history window of server variations is dynamically tuned

based on the range of server delay variations. Compared to

our presented work, PSM-AW [13] assumes the signiﬁcant

component of the uplink-downlink delay is communication

time with the server, thereby ignoring the variable, long

impact of downlink wireless communication delay. Also,

RTT sampling and averaging are performed by stations.

Therefore, delay estimation is directly affected by station-

server communication, and estimation accuracy drops as

the interval between transactions increases. In contrast, our

work does not impose overhead on stations, and once a

model is trained, it does not rely on ongoing communication

to compute sleep schedules. Jang et al. [11] proposed an

adaptive tail time adjustment mechanism by relying on

inter-packet arrival delays. A moving average scheme is

used to predict inter-packet arrival delay when a burst of

packets arrives at a station. The station stays in the awake

mode if the next packet arrival time is before the tail time

expiry. If packet delivery is after the tail time expiry, the

station might extend its tail time based on the outcome of

an energy-delay trade-off model. In contrast to our solution,

neither [13] nor [11] considers the impact of buffering and

channel access delay as variable and essential components

of downlink delivery delay. Furthermore, the effectiveness

of these approaches highly depends on the burst length and

variability of end-to-end delays. Speciﬁcally, the moving av-

erage scheme employed in [11] would not be effective in IoT

scenarios where most of the bursts are short-lived. Sui et al.

[39] propose WiFiSeer, a centralized decision-making system

to help stations choose the AP providing the shortest delay.

WiFiSeer works in two phases: During the learning phase,

a set of parameters (such as RSSI, RTT) are pulled every

minute from all APs using SNMP. Then a random forest

model is trained to generate a two-class learning model

for classifying APs into high latency and low latency. A

user agent installed on smartphones communicates with the

controller and associates the station with the recommended

AP. WiFiSeer is complementary to our solution to further

reduce station-AP delay.

Jang et al. [14] study the overhead of radio switching

and show that stations can achieve signiﬁcant energy saving

Energy Consumption | Cloud Scenario Transaction Duration | Cloud Scenario Energy Consumption | Edge Scenario Transaction Duration | Edge Scenario

(a) (b) (c) (d)

Fig. 12. Performance comparison of EAPS with 802.11 power saving mechanisms in ND conditions for all ACs. (a) and (b) show the average per-

transaction energy and duration in cloud scenario, respectively. (c) and (d) show the average per-transaction energy and duration in edge scenario,

respectively.

Energy Consumption | Cloud Scenario Transaction Duration | Cloud Scenario Energy Consumption | Edge Scenario Transaction Duration | Edge Scenario

(a) (b) (c) (d)

Fig. 13. Performance comparison of EAPS with 802.11 power saving mechanisms in HD conditions for all ACs. (a) and (b) show the average per-

transaction energy and duration in cloud scenario, respectively. (c) and (d) show the average per-transaction energy and duration in edge scenario,

respectively.

during inter-frame delays while the AP is communicating

with other stations. The proposed AP-driven approach,

called Snooze, utilizes the global knowledge of the AP to

schedule sleep and awake duration of each station based

on inter-packet delays and trafﬁc load of the station. To

distribute the schedule, the AP needs to exchange control

messages with stations. Compared to Snooze, our work

considers the sensing-actuation pattern of IoT applications

and reduces the idle listening time between sensing and ac-

tuation. In addition, our work takes into account the impact

of interference by measuring airtime utilization perceived

by the AP. Also, Snooze does not beneﬁt from APSD. Sheth

and Dezfouli [40] propose Wiotap, an AP-based, layer-3

scheduling mechanism for IoT stations that employ APSM.

Their proposed mechanism uses an Earliest Deadline First

(EDF) scheduling strategy to maximize the chance of packet

delivery before tail time expiry. Rozner et al. [15] propose

NAPman, which prioritizes the delivery of PSM trafﬁc as

long as other stations are not affected. Tozlu et al. [4] show

that increasing AP load has a higher impact on packet loss

and RTT compared to out-of-band interference. Pei et al. [18]

argue that 802.11 link delay comprises more than 60% of

round trip delay. They also show that more than 50% (10%)

of packets experience more than 20 ms (100 ms) latency by

station-AP links. For TCP trafﬁc, the authors proposed an

approach to measure the delay of wired latency as well

as uplink and downlink channel access delay. Using the

Kendall correlation, they also show that airtime utilization,

RSSI, and retry rate are the top three factors affecting station-

AP delay. Their study also shows that the physical rate offers

the highest relative information gain to predict latency. This

is because of physical rate changes based on RSSI, frame

loss, and channel quality. Then, a decision tree model is used

to tune the parameters of APs and reduce the overall delay

experienced by stations. This is in contrast to our work,

which offers per-station, ﬁne-granularity sleep scheduling.

Primarily designed for VoIP trafﬁc, Liu et al. [41] propose a

mechanism to reduce contention among stations waking up

using APSD to retrieve packets from the AP. After receiving

a burst of voice data, the station measures the tolerable

deadline of incoming packets and informs the AP about its

wake up time before switching to sleep mode. The wake-up

instance is approved only if the AP will be idle when the

station will wake up.

6 CONCLUSION

In this paper, we presented the design and implementation

of a predictive scheduling mechanism, named EAPS, to

enable IoT stations to transition to sleep mode and wake up

when the downlink packet is expected to be delivered. The

proposed solution beneﬁts from edge computing, meaning

the computations of sleep scheduling are performed at the

network edge and by the AP. We presented an AP architec-

ture capable of collecting queues status, channel condition,

and packet transmission and reception instances. Once the

AP receives an uplink packet, a machine learning model is

used to compute the sleep delay, and the station is informed

about its schedule using a high-priority data plane. Using

empirical evaluations, we conﬁrm the signiﬁcant enhance-

ment of EAPS in terms of energy efﬁciency and transaction

delay.

EAPS can be considered as an enhancement of the APSD

and TWT (introduced in 802.11ax). For example, with the

next generation of IoT stations that support TWT, they can

set up their wake up time based on the sleep schedule

computed by the AP. By protecting IoT stations against

the effect of concurrent trafﬁc and interference, EAPS is

a particularly useful mechanism in scenarios where both

regular and IoT stations exist. For example, EAPS can reduce

the energy cost of households and reduce the impact of IoT

on global ICT footprint.

To extend this work, we plan to integrate EAPS with

a software-deﬁned architecture and enable the stations to

receive their downlink packet from the AP offering the low-

est delay. We also plan to incorporate a predictive buffering

mechanism to provide delay bound guarantees for mission-

critical applications. EAPS can also signiﬁcantly beneﬁt

from wake-up radio technology: After sending the uplink

packet(s), the station can immediately transition into sleep

mode and use its secondary low-power radio to receive the

schedule message. When it is time to receive the downlink

packet, the secondary radio can ﬁrst communicate with the

AP to verify if the downlink packet is ready to be sent.

REFERENCES

[1] D. K. Jha, J. P. Rula, and F. E. Bustamante, “eXploring Xﬁnity,” in

International Conference on Passive and Active Network Measurement.

Springer, 2016, pp. 136–148.

[2] Cypress Semiconductor. CYW43907: IEEE 802.11 a/b/g/n SoC

with an Embedded Applications Processor. [Online]. Available:

http://www.cypress.com/ﬁle/298236/download

[3] AVNET Inc. BCM4343W: 802.11b/g/n WLAN, Blue-

tooth and BLE SoC Module. [Online]. Avail-

able: https://products.avnet.com/opasdata/d120001/medias/

docus/138/AES-BCM4343W-M1- G data sheet v2 3.pdf

[4] S. Tozlu, M. Senel, W. Mao, and A. Keshavarzian, “Wi-Fi enabled

sensors for internet of things: A practical approach,” IEEE Com-

munications Magazine, vol. 50, no. 6, pp. 134–143, 2012.

[5] Ring. [Online]. Available: https://ring.com

[6] Nest. [Online]. Available: https://nest.com

[7] Schlage. [Online]. Available: https://www.schlage.com

[8] Lifx. [Online]. Available: https://www.lifx.com

[9] Y. He, R. Yuan, X. Ma, and J. Li, “Analysis of the impact of

background trafﬁc on the performance of 802.11 power saving

mechanism,” IEEE Communications Letters, vol. 13, no. 3, pp. 164–

166, 2009.

[10] J. Manweiler and R. Roy Choudhury, “Avoiding the rush hours:

WiFi energy management via trafﬁc isolation,” in Proceedings of

the 9th international conference on Mobile systems, applications, and

services, 2011, pp. 253–266.

[11] S. Y. Jang, B. Shin, and D. Lee, “An adaptive tail time adjust-

ment scheme based on inter-packet arrival time for IEEE 802.11

WLAN,” in IEEE International Conference on Communications (ICC).

IEEE, 2016, pp. 1–6.

[12] A. Vinhas, V. Bernardo, M. Pascoal Curado, and T. Braun, “Per-

formance analysis and comparison between legacy-PSM and U-

APSD,” 13th Conference on Computer Networks (CRC), pp. 1–12,

2013.

[13] B. Peck and D. Qiao, “A practical PSM scheme for varying server

delay,” IEEE Transactions on Vehicular Technology, vol. 64, no. 1, pp.

303–314, 2015.

[14] K.-Y. Jang, S. Hao, A. Sheth, and R. Govindan, “Snooze: Energy

management in 802.11n WLANs,” in Proceedings of the Seventh

Conference on emerging Networking Experiments and Technologies (Co-

NEXT). ACM, 2011, p. 12.

[15] E. Rozner, V. Navda, R. Ramjee, and S. Rayanchu, “NAPman:

Network-assisted power management for WiFi devices,” in Pro-

ceedings of the 8th international conference on Mobile systems, applica-

tions, and services (MobiSys). ACM, 2010, pp. 91–106.

[16] A. J. Pyles, X. Qi, G. Zhou, M. Keally, and X. Liu, “SAPSM: Smart

adaptive 802.11 PSM for smartphones,” in Ubiquitous Computing

(UbiComp). ACM, 2012, pp. 11–20.

[17] S. Sundaresan, N. Magharei, N. Feamster, R. Teixeira, and S. Craw-

ford, “Web performance bottlenecks in broadband access net-

works,” ACM SIGMETRICS Performance Evaluation Review, vol. 41,

no. 1, pp. 383–384, 2013.

[18] C. Pei, Y. Zhao, G. Chen, R. Tang, Y. Meng, M. Ma, K. Ling, and

D. Pei, “WiFi can be the weakest link of round trip network latency

in the wild,” in International Conference on Computer Communica-

tions (INFOCOM). IEEE, 2016, pp. 1–9.

[19] T. Høiland-Jørgensen, P. Hurtig, and A. Brunstrom, “The good,

the bad and the WiFi: Modern AQMs in a residential setting,”

Computer Networks, vol. 89, pp. 90–106, 2015.

[20] T. Høiland-Jørgensen, M. Kazior, D. T ¨

aht, P. Hurtig, and A. Brun-

strom, “Ending the anomaly: Achieving low latency and airtime

fairness in WiFi,” in USENIX Annual Technical Conference, 2017, pp.

139–151.

[21] A. Showail, K. Jamshaid, and B. Shihada, “Buffer sizing in wireless

networks: challenges, solutions, and opportunities,” IEEE Commu-

nications Magazine, vol. 54, no. 4, pp. 130–137, 2016.

[22] M. Heusse, F. Rousseau, G. Berger-Sabbatel, and A. Duda, “Perfor-

mance anomaly of 802.11b,” in Twenty-second Annual Joint Confer-

ence of the IEEE Computer and Communications Societies (INFOCOM),

vol. 2. IEEE, 2003, pp. 836–843.

[23] F. Wilhelmi, S. Barrachina-Munoz, B. Bellalta, C. Cano, A. Jonsson,

and V. Ram, “A ﬂexible machine-learning-aware architecture for

future WLANs,” IEEE Communications Magazine, vol. 58, no. 3, pp.

25–31, 2020.

[24] J. Malinen. hostapd: IEEE 802.11 AP, IEEE

802.1X/WPA/WPA2/EAP/RADIUS Authenticator. [Online].

Available: https://w1.ﬁ/hostapd/

[25] Y.-H. Wei, Q. Leng, S. Han, A. K. Mok, W. Zhang, and

M. Tomizuka, “RT-WiFi: Real-time high-speed communication

protocol for wireless cyber-physical control applications,” in IEEE

34th Real-Time Systems Symposium (RTSS). IEEE, 2013, pp. 140–

149.

[26] C. Powell, C. Desiniotis, and B. Dezfouli, “The fog development

kit: A development platform for SDN-based edge-fog systems,”

IEEE Internet of Things Journal, 2019.

[27] V. Jacobson, “Congestion avoidance and control,” in SIGCOMM

computer communication review, vol. 18, no. 4. ACM, 1988, pp.

314–329.

[28] R. Ludwig and K. Sklower, “The Eifel retransmission timer,”

SIGCOMM Computer Communication Review, vol. 30, no. 3, pp. 17–

27, 2000.

[29] R. Russell and H. Welte. Linux netﬁlter hacking howto.

[Online]. Available: http://www.netﬁlter.org/documentation/

HOWTO/netﬁlter-hacking-HOWTO

[30] Linux Programmer’s Manual. MMAP. [Online]. Available:

http://man7.org/linux/man-pages//man2/munmap.2.html

[31] K.-c. Lan and J. Heidemann, “A measurement study of correla-

tions of internet ﬂow characteristics,” Computer Networks, vol. 50,

no. 1, pp. 46–62, 2006.

[32] Y. Xiao, Y. Cui, P. Savolainen, M. Siekkinen, A. Wang, L. Yang,

A. Yl¨

a-J¨

a¨

aski, and S. Tarkoma, “Modeling energy consumption

of data transmission over Wi-Fi,” IEEE Transactions on Mobile

Computing, vol. 13, no. 8, pp. 1760–1773, 2013.

[33] S. Hochreiter and J. Schmidhuber, “Long short-term memory,”

Neural computation, vol. 9, no. 8, pp. 1735–1780, 1997.

[34] F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B. Thirion,

O. Grisel, M. Blondel, P. Prettenhofer, R. Weiss, V. Dubourg et al.,

“Scikit-learn: Machine learning in python,” the Journal of machine

Learning research, vol. 12, pp. 2825–2830, 2011.

[35] F. Chollet et al., “Keras, github,” GitHub repository, https://github.

com/fchollet/keras, 2015.

[36] D. P. Kingma and J. Ba, “Adam: A method for stochastic optimiza-

tion,” arXiv preprint arXiv:1412.6980, 2014.

[37] K. M. Koudjonou and M. Rout, “A stateless deep learning frame-

work to predict net asset value,” Neural Computing and Applica-

tions, pp. 1–19, 2019.

[38] B. Dezfouli, I. Amirtharaj, and C.-C. Li, “EMPIOT: An energy

measurement platform for wireless IoT devices,” Journal of Network

and Computer Applications, vol. 121, pp. 135–148, 2018.

[39] K. Sui, M. Zhou, D. Liu, M. Ma, D. Pei, Y. Zhao, Z. Li, and

T. Moscibroda, “Characterizing and improving WiFi latency in

large-scale operational networks,” in Proceedings of the 14th Annual

International Conference on Mobile Systems, Applications, and Services

(MobiSys). ACM, 2016, pp. 347–360.

[40] J. Sheth and B. Dezfouli, “Enhancing the energy-efﬁciency and

timeliness of IoT communication in WiFi networks,” IEEE Internet

of Things Journal, vol. 6, no. 5, pp. 9085–9097, 2019.

[41] L. Liu, X. Cao, Y. Cheng, and Z. Niu, “Energy-efﬁcient sleep

scheduling for delay-constrained applications over WLANs,”

IEEE Transactions on Vehicular Technology, vol. 63, no. 5, pp. 2048–

2058, 2014.

ResearchGate has not been able to resolve any citations for this publication.

A Flexible Machine-Learning-Aware Architecture for Future WLANs

Article

Full-text available

Mar 2020

Lots of hopes have been placed on machine learning (ML) as a key enabler of future wireless networks. By taking advantage of large volumes of data, ML is expected to deal with the ever-increasing complexity of networking problems. Unfortunately, current networks are not yet prepared to support the ensuing requirements of ML-based applications in terms of data collection, processing, and output distribution. This article points out the architectural requirements that are needed to pervasively include ML as part of future wireless networks operation. Specifically, we look into wireless local area networks (WLANs), which, due to their nature, can be found in multiple forms, ranging from cloud-based to edge-computing-like deployments. In particular, we propose to adopt the International Telecommunication Union (ITU) unified architecture for 5G and beyond. Based on ITU's architecture, we provide insights on the main requirements and the major challenges of introducing ML to the multiple modalities of WLANs. Finally, we showcase the superiority of the architecture through an ML-enabled use case for future networks.

A stateless deep learning framework to predict net asset value

Article

Full-text available

Jul 2020
NEURAL COMPUT APPL

Recurrent neural networks (RNN) such as Long Short-Term Memory and Gated Recurrent Unit have recently emerged as a state-of-art neural network architectures to process sequential data efficiently. Thereby, they can be used to model prediction of time series data, since time series values are also a sequence of discrete time data. However, due to various existing RNN architectures, their functioning modes, the growth of hyper parameters and some other bottlenecks arise when it comes to train them. Thus, it becomes perplex to find out the most suited model for a given task. To address these matters, we propose a step-wise approach to predict the time series data, especially net asset value in this paper. We have started the study with the memory size of RNN to set the optimal memory size based on the prediction accuracy. Then, the study follows by analyzing existing data preparation methods and proposing a new one. The proposed data preparation methods prove their effectiveness in both stateless and stateful mode with single RNN layer. Finally, we confront the single RNN layer to stacked and bidirectional RNN to sort out the best performing models based on their prediction accuracy in various time horizons.

Enhancing the Energy-Efficiency and Timeliness of IoT Communication in WiFi Networks

Article

Full-text available

Aug 2019

Increasing the number of IoT stations or regularstations escalates downlink channel access contention and queu-ing delay, which in turn result in higher energy consumption andlonger communication delays with IoT stations. To remedy thisproblem, this paper presentsWiotap, an enhanced WiFi accesspoint that implements a downlink packet scheduling mechanism.In addition to assigning higher priority to IoT traffic comparedto regular traffic, the scheduling algorithm computes per-packetpriorities to arbitrate the contention between the transmissionof IoT packets. This algorithm employs a least-laxity first (LLF)scheme that assigns priorities based on the remaining wake-uptime of the destination stations. We used simulation to showthe scalability of the proposed system. Our results show thatWiotap achieves 37% improvement regarding the duty cycle ofIoT stations compared to a regular access point. In addition, wedeveloped a testbed to confirm the implementation correctnessand the performance benefits of Wiotap in a network with fourIoT stations and regular traffic. For the edge and cloud scenarios,our empirical evaluations show up to 44% and 38% improvementin energy and 52% and 41% improvement in delay, respectively.

EMPIOT: An energy measurement platform for wireless IoT devices

Article

Full-text available

Apr 2018

Profiling and minimizing the energy consumption of IoT devices is an essential step towards employing IoT in various application domains. In this paper we propose EMPIOT, an accurate, low-cost, easy to build, and flexible, power measurement platform. We present the hardware and software components of this platform, and study the effect of various design parameters on accuracy. In particular, we analyze the effect of driver, bus speed, input voltage, and buffering mechanism, on sampling rate, measurement accuracy and processing demand. These extensive experimental studies enable us to configure the system in order to achieve its highest performance. We also propose a novel calibration technique and report the calibration parameters under various settings. Using five different IoT devices performing four types of workloads, we evaluate the performance of EMPIOT against the ground truth obtained from high-accuracy devices. Our results show that, for very low-power devices that utilize 802.15.4 wireless standard, measurement error is less than 4%. In addition, for 802.11-based devices that generate short and high power spikes, error is less than 3%.

Characterizing and Improving WiFi Latency in Large-Scale Operational Networks

Conference Paper

Full-text available

Jun 2016

WiFi latency is a key factor impacting the user experience of modern mobile applications, but it has not been well studied at large scale. In this paper, we design and deploy WiFiSeer, a framework to measure and characterize WiFi latency at large scale. WiFiSeer comprises a systematic methodology for modeling the complex relationships between WiFi latency and a diverse set of WiFi performance metrics, device characteristics, and environmental factors. WiFiSeer was deployed on Tsinghua campus to conduct a WiFi latency measurement study of unprecedented scale with more than 47,000 unique user devices. We observe that WiFi latency follows a long tail distribution and the 90th (99th) percentile is around 20 ms (250 ms). Furthermore, our measurement results quantitatively confirm some anecdotal perceptions about impacting factors and disapprove others. We deploy three practical solutions for improving WiFi latency in Tsinghua, and the results show significantly improved WiFi latencies. In particular, over 1,000 devices use our AP selection service based on a predictive WiFi latency model for 2.5 months, and 72% of their latencies are reduced by over half after they re-associate to the suggested APs.

The Good, the Bad and the WiFi: Modern AQMs in a residential setting

Article

Full-text available

Jul 2015
COMPUT NETW

Several new active queue management (AQM) and hybrid AQM/fairness queueing algorithms have been proposed recently. They seek to ensure low queueing delay and high network goodput without requiring parameter tuning of the algorithms themselves. However, extensive experimental evaluations of these algorithms are still lacking. This paper evaluates a selection of bottleneck queue management schemes in a test-bed representative of residential Internet connections of both symmetrical and asymmetrical bandwidths as well as WiFi. Latency under load and the performance of VoIP and web traffic patterns are evaluated under steady state conditions. Furthermore, the impact of the algorithms on fairness between TCP flows with different RTTs, and also the transient behaviour of the algorithms at flow startup is examined. The results show that while the AQM algorithms can significantly improve steady state performance, they exacerbate TCP flow unfairness. In addition, the AQMs severely struggle to quickly control queueing latency at flow startup, which can lead to large latency spikes that hurt perceived performance. The fairness queueing algorithms almost completely alleviate the algorithm performance problems, providing the best balance of low latency and high throughput in the tested scenarios. However, on WiFi the performance of all the tested algorithms is hampered by large amounts of queueing in lower layers of the network stack inducing significant latency outside of the algorithms’ control.

WiFi can be the weakest link of round trip network latency in the wild

Conference Paper

Apr 2016

An adaptive tail time adjustment scheme based on inter-packet arrival time for IEEE 802.11 WLAN

Conference Paper

May 2016

Buffer Sizing in Wireless Networks: Challenges, Opportunities, and Solutions

Article

Jan 2015

Buffer sizing is an important network configuration parameter that impacts the quality of service characteristics of data traffic. With falling memory costs and the fallacy that "more is better," network devices are being overprovisioned with large buffers. This may increase queueing delays experienced by a packet and subsequently impact stability of core protocols such as TCP. The problem has been studied extensively for wired networks. However, there is little work addressing the unique challenges of wireless environments such as time-varying channel capacity, variable packet inter-service time, and packet aggregation, among others. In this article we discuss these challenges, classify the current state-of-the-art solutions, discuss their limitations, and provide directions for future research in the area.

A Practical PSM Scheme for Varying Server Delay

Article

Jan 2015

Today, many individuals use smartphones or other battery-powered mobile devices equipped with Wi-Fi to access the Internet. Since the network interface cards (NICs) often use a substantial portion of available energy, schemes such as the 802.11 power saving mode (PSM) have been used to limit the amount of time a NIC is awake in an operable state so as to extend battery life. However, since the NIC cannot retrieve packets while sleeping, PSM may negatively impact packet delay. These delays are also unbounded and can significantly increase communication time, particularly in a mobile environment where server delays may change drastically. To mitigate this, we present PSM-AW: a PSM with adaptive wake-up. PSM-AW is a client-side solution that allows the client device to sleep for a maximum time interval while still keeping a tight bound on performance. We present and prove a bound on performance using PSM-AW and demonstrate its effectiveness through extensive simulations and experiments.

EAPS: Edge-Assisted Predictive Sleep Scheduling for 802.11 IoT Stations

Abstract and Figures

Recommended publications

Green Wi-Fi Management: Implementation on Partially Overlapped Channels

EAPS: Edge-Assisted Predictive Sleep Scheduling for 802.11 IoT Stations

MonFi: A Tool for High-Rate, Efficient, and Programmable Monitoring of WiFi Devices

Towards Understanding and Enhancing Association and Long Sleep in Low-Power WiFi IoT Systems

Enhancing the Energy-Efficiency and Timeliness of IoT Communication in WiFi Networks