# Optimizing IoT and Web Traffic Using Selective Edge Compression

Themis Melissaris  Princeton University
<EMAIL_ADDRESS>Kelly Shaw  Williams College
<EMAIL_ADDRESS>Margaret Martonosi  Princeton University
<EMAIL_ADDRESS>
###### Abstract

Internet of Things (IoT) devices and applications are generating and
communicating vast quantities of data, and the rate of data collection is
increasing rapidly. These high communication volumes are challenging for
energy-constrained, data-capped, wireless mobile devices and networked
sensors. Compression is commonly used to reduce web traffic, to save energy,
and to make network transfers faster. If not used judiciously, however,
compression can hurt performance. This work proposes and evaluates mechanisms
that employ selective compression at the network’s edge, based on data
characteristics and network conditions. This approach (i) improves the
performance of network transfers in IoT environments, while (ii) providing
significant data savings. We demonstrate that our library speeds up web
transfers by an average of 2.18x and 2.03x under fixed and dynamically
changing network conditions respectively. Furthermore, it also provides
consistent data savings, compacting data down to 19% of the original data
size.

##  I Introduction

Internet of Things (IoT) environments include elements for sensing, actuation,
and communication, as well as data analysis and computation. IoT ecosystems
promise to change the ways we interact with our homes and cities and to
provide new solutions in industrial settings as well. As domains continue to
benefit from nascent IoT technologies, they further contribute to the
expanding availability and diversity of IoT devices.

Increases in edge device counts, improved network infrastructure and the broad
adoption of services and applications have led to an explosion in mobile and
IoT data traffic, which is expected to increase nearly threefold from 2015 to
2020 [8]. In fact, two-thirds of the total IP traffic by 2020 will be
generated by wireless and mobile devices; this is due to an increase in the
number of available connected mobile devices, adoption of wireless IoT
devices, as well as growth in the devices’ capabilities and data consumption.
Energy is a primary constraint in designing applications and systems for edge
devices and wireless communication accounts for a significant portion of the
total energy budget, often dominating that of computation or other factors [6,
34]. With traffic and energy usage expected to surge, one technique proven to
be efficient in managing the energy consumption and the traffic volume of
wireless mobile devices is compression [28].

IoT’s rise has led to the broader emergence of an ecosystem of networked
devices, supporting services, and new applications across many different
domains [19]. Application areas such as smart surveillance, traffic services,
and mobile sensing rely on data collected at the “edge” (e.g. on smartphones
or other mobile devices, rather than wired devices or cloud infrastructure)
followed by communication of the data towards hub or cloud aggregators for
analysis, often with tight latency requirements [18]. To support these data-
intensive applications, our focus is on selectively using on-edge-device
compression to reduce transferred bytecounts and improve communication
efficiency.

Data compression and decompression are widely available on commodity servers
and can also be used at the edge to reduce the data exchanged in the network,
sometimes reducing network latencies as well. Compression, however, needs to
be used correctly to avoid overheads; if overused, it can add unnecessary
latency and energy overhead to communications, instead of reducing them.
Whether compression is beneficial or not is determined by several factors
outlined below.

First, different mobile and IoT applications generate different types of
content, which vary in size and compressibility. The type of traffic generated
on edge devices can change dynamically based on the users’ interaction with
the devices and the applications in use. Mobile web traffic is typically
comprised of scripts, plaintext, multimedia and markup documents. IoT traffic
includes sensor data that can vary significantly depending on the application
and its usage. Variations in communicated data can mean significant variations
in how compressible the data is. For example, multimedia data items (e.g.
audio, traffic and video) are usually already provided in a compressed format,
preventing additional transfer-time compression from yielding large benefits.

Second, network behavior can significantly alter the effect compression has on
data exchanged over the network. In cases of low network throughput,
compression can reduce the duration of data transfers significantly.
Alternatively, compression can stay in the application’s critical path and
introduce unnecessary overhead when the data compression rate is slower than
the network data transfer rate.

To selectively exploit the benefits of compression while intelligently
avoiding its potential negative impact, this work proposes and evaluates the
IoTZip approach. IoTZip is a tool that allows mobile and IoT applications to
handle compression intelligently. Based on characterizations of the data to be
transferred and estimates of the network conditions, it automatically reasons
about compression trade-offs. It then predicts whether selective compression
will pay off or not, and adaptively decides whether to use it to improve the
performance of network transfers and reduce data usage. Our evaluation
demonstrates that IoTZip achieves the stated goals in a very lightweight
manner, which provides an opportunity for adoption of selective edge
compression based approaches in resource constrained IoT environments.

As the edge increasingly includes data-intensive and latency-sensitive
applications, the bandwidth and performance of wireless mobile devices become
key design challenges. Intelligently compressing data going to and from IoT
and wireless mobile edge devices can improve system functionality.

Our results show that IoTZip offers performance improvements of up to 3.78x
(roughly 2x on average) and data size reductions of up to 81%. Interestingly,
the IoT datasets we experiment on show more uniformity in size and data type
than the mobile web datasets. Nonetheless, selective compression is still
useful even for predictable IoT datasets, because it allows systems to adapt
to varying network conditions as well.

The remainder of this paper is structured as follows. Section II discusses
related work, in order to further establish the motivation for IoTZip. Section
III describes the basic IoTZip functionality and Section IV gives the
methodology and configuration information for its use in our experiments.
Section V presents our experimental results and Section VI offers conclusions.

##  II Related Work

Characterizing Mobile Web Traffic & Applications:  One category of related
prior work pertains to mobile web traffic characterization. The measurement
study in [14] discusses mobile traffic composition and investigates the
performance and energy efficiency of TCP transfers. Butkiewicz et al. [5]
studies parameters that affect web page load times across websites, whereas
WProf [32] performs in-browser performance profiling. In [25], the usage of
bandwidth and energy in mobile web browsing is studied in detail using traffic
collection and analysis tools, whereas [3] and [31] focus on analyzing the
energy consumption of mobile devices’ communication, particularly mobile web
browsing. In contrast to our work, these papers do not study compression, nor
how the performance of a web transfer is affected by compressing data of
varying data sizes and types.

Optimizing Mobile Web Traffic: Various techniques have been proposed to
optimize mobile web transfers for performance and data usage. For example,
Procrastinator [26] decides when to prefetch objects in order to manage
application data usage depending on a user’s connectivity and data plan
limitations. Other techniques like Polaris [23] and Shandian [33] use fine
grained dependency tracking to identify and eliminate the intrinsic
inefficiencies in the page load process. Klotski reprioritizes the delivery of
web content in a dynamic fashion in order to improve the user experience [4].
While their focus is on improving performance and user experience in mobile
web browsing, these approaches do not reduce data usage as we do.

Compression-based approaches have also been proposed in related work to reduce
data usage and improve performance. Locomotive [22] presents a methodology for
determining at runtime whether compression is beneficial for data
transmissions on mobile phones. Our work systematically studies the effect of
compression on devices’ web transfers at the Edge and builds a library that
allows IoT applications to automatically adapt to dynamically changing network
conditions and data heterogeneity. Additionally, compression proxies like
Flywheel [1], Baidu TrafficGuard [20] and Flexiweb [29] offer data savings by
leveraging compression. These approaches, however, channel mobile content
through a proxy server. Such rerouting raises privacy and security concerns if
the proxy is untrusted and potentially latency concerns as well. Our work runs
on mobile devices, performs compression at the Edge and therefore mitigates
such concerns.

Other works study how the use of different communication protocols affect the
performance of mobile web transfers. The study in [11] compares HTTP 1.1 and
SPDY (recently proposed HTTP alternative) performance in practice, showing no
clear alternative advantage of the latter over cellular networks. In [27], the
authors present Lithe, a lightweight implementation of the CoAp protocol for
the Internet of Things using compression to improve data usage and energy
efficiency. This approach, despite its clear advantages, is restricted to low
power wireless technologies (LoWPAN) and communication over CoAp. Recently,
efforts in the industry has developed compression algorithms, like Brotli
[13], [17], [10], specifically designed for mobile traffic data savings and
performance. Prior work has demonstrated that custom compression algorithms
can achieve significant energy and performance gains [28]. Using state of the
art compression algorithms for IoT and mobile web traffic could complement
network adaptive approaches such as IoTZip.

Correctness, Security and Privacy:  Related work also focuses on correctness,
security and privacy aspects of IoT applications. OKAPI [21] identifies
correctness deficiencies and bugs in IoT applications and introduces tools
that enforce correctness guarantees. Other works [15] focus on security
implications such as misuse of application privileges in IoT settings and
develop privacy preserving solutions leveraging data protection and access
control mechanisms [16].

Our Approach:  With IoTZip, application developers can optimize web traffic
transfers from mobile and IoT devices through selective compression
automatically. IoTZip dynamically decides whether to compress based on data
characterizations and network conditions. IoTZip is device and application
agnostic and therefore capable of enhancing all types of Internet of Things
and mobile applications and benefit under heterogeneous traffic and under
changing network conditions. Although IoTZip is provided as a library for
application development, it can also be easily implemented as a browser plugin
or extension. Section III presents IoTZip’s architecture, Section IV describes
our methodology and Section V presents results on performance and data
savings.

##  III IoTZip Library

Figure 1: IoTZip Overview. Compression trade-offs are dynamically assessed
during web transfers at the Edge. Whenever compression is estimated to be
effective by the Policy module, data is compressed and transferred over the
network. Network conditions are estimated using the Throughput Estimation
module. The statistical models used for estimating compression time and size
are generated offline in the Predictive Model Creation module. The tradeoff is
resolved at runtime in the Tradeoff Resolution module.

Overview: IoTZip facilitates IoT and mobile traffic optimization by providing
hooks allowing application programmers to use selective compression easily.
Applications can invoke the library, abstracting away compression decisions.
IoTZip focuses on uplink traffic where compression happens on the edge device.
This is because uplink traffic is particularly latency- and energy-intensive
for constrained IoT devices. IoTZip uses Android HTTP primitives, but can be
extended easily to accommodate other protocols. In addition, a component that
responds to IoTZip requests and handles data decompression runs in the cloud.
The architecture of IoTZip is presented in Figure 1.

IoTZip Policy: For all data transfers, IoTZip makes a two-step compression
decision. First, a threshold determines if compression should be ruled out for
some requests, based on size and compressibility. For small transfer sizes and
for file types that are typically already compressed—such as multimedia—data
compressibility can be low and the time spent compressing the data is likely
to outweigh any benefits achieved. Selective compression avoids compressing in
such cases.

IoTZip next determines if the estimated transfer latency is less with or
without compression. As shown in Equation (I), IoTZip resolves the tradeoff
for each request based on the compression latency $L_{Compression}$, the size
of the request payload data before ($S_{Original}$) and after
($S_{Compressed}$) compression as well as the estimated network throughput,
$N_{Throughput}$. $N_{Throughput}$ changes over time and is periodically
estimated by the Network Connection Module.

TABLE I: Equation (I) resolves the performance tradeoffs of introducing compression. Equations (II) and (III) estimate data size after compression and compression latency, respectively. (I) | $\frac{S_{Compressed}}{N_{Throughput}}+L_{Compression}>\frac{S_{Original}}{N_{Throughput}}$
---|---
(II) | $S_{Compressed}(S_{Original},T)=\frac{S_{Original}}{compressibility(T)}$
(III) | $L_{Compression}(S_{Original},T)=\alpha(T)\cdot S_{Original}+\beta(T)$
i |

Compression Size & Time Estimation: IoTZip estimates compression size and time
using two linear-regression-based statistical models whose input includes the
data type $T$ and data size of the original data. To estimate the data size
after compression, we use equation (II)’s model, where $compressibility$ is
the ratio between the data size of the original data versus the compressed.
Equation (III) estimates the data compression latency, as a linear function of
the data size and the coefficients $\alpha$, $\beta$; the coefficients are
functions of the data type, and are acquired offline via training. To
determine model parameters for equations (II), (III), IoTZip performs training
during an initialization period that happens once at install-time. Since data
patterns may vary over time, our model parameters can be updated with an
online approach such as stochastic gradient descent using linear regression,
but such adaptation is beyond the scope of this paper.

Network Throughput Estimation: IoTZip policy accounts for the dynamic behavior
of network throughput $N_{Throughput}$ while selectively applying compression
in network transfers. IoTZip samples the network periodically in order to
provide accurate estimates in the face of fluctuations in network throughput,
which achieves better accuracy. To acquire network throughput samples, IoTZip
leverages an open source connection quality library and modifies the web
server in the cloud, which are described in more detail in Section IV.

Tradeoff Resolution: IoTZip puts all the estimates together in the Tradeoff
Resolution module to determine whether the web transfer savings of compressed
data warrant incurring the additional compression latency. Once a decision has
been reached, the data is compressed if necessary and a request is generated.

##  IV Evaluation Methodology

Figure 2: Cumulative Distribution Function (CDF) for the data size of all
evaluated datasets. Alexa Top 200 is the most diverse in terms of data sizes,
whereas the Air Quality and RToF Measurements are narrow and contain data
small in size. Activity Recognition contains MB sized data.

Edge implementation: We evaluate our work using mobile web traffic, as well as
IoT and sensor data found in related work. We replay web traffic on mobile
phones using a test application that invokes IoTZip. IoTZip generates HTTP
requests, which transfer web traffic data, as discussed later in this section.
Once a compression decision has been made, the processed data will then be
used to generate an HTTP request. IoTZip is intended to handle arbitrary data
transfers. For the purpose of this work, we focus on HTTP, but other data
transfer protocols could also benefit similarly. The client is implemented on
Android and is run on a Samsung Galaxy S5 phone.

Cloud setup: To enable selective compression, our cloud infrastructure uses a
web server capable of responding to HTTP requests. We vary network conditions
in a controlled manner using Linux traffic shaping tools. The network
throughput settings are 2 Mbps, 5 Mbps and 10 Mbps.

TABLE II: Presentation of average data compressibility and data type distribution for four different Internet of Things and Mobile datasets. Dataset | Data Type | Compressibility | Content Distribution
---|---|---|---
Activity Recognition | Text | 4.12 | 100%
Air Quality | Text | 1.04 | 100%
RToF Measurements | Text | 5.42 | 100%
Alexa Top 200 | Javascript | 3.39 | 38.36%
| Images | 1.02 | 32.07%
| CSS | 4.56 | 10.25%
| HTML | 4.18 | 7.32%
| Other | 1.17 | 8.74%

Benchmarks: We use three datasets to represent a range of IoT application
domains. Activity Recognition [7] contains data taken from a wearable
accelerometer and is collected from participants performing a range of
activities. Air Quality [9] contains hourly responses of a gas multisensor
device deployed on the field in a city in Italy. RToF Measurements [24]
includes Round-trip time-of-flight (RToF) and magnetometer measurements from
30 deployed stationary anchors in a supermarket indoors. For all datasets, we
consider scenarios where data across different networked sensors are
transmitted from the devices and aggregated at the edge.

In addition to the aforementioned datasets, we collected web traffic to replay
on mobile platforms. Collection of the mobile web traffic was performed
offline using Fiddler [30], a web debugging proxy, which captures the raw
payload of each request. To emulate real mobile traffic, we generate HTTP
requests to transfer captured web traffic data as the request payload. We
captured the traffic from mobile versions of the top 200 most popular websites
according to the Alexa list [2]. For each web page load in the Alexa list,
multiple (2 to 200) web page elements are fetched and loaded on the client.
Although the traffic in the Alexa dataset is originating mostly from downlink
traffic, we will consider that the data is living at the edge and will be
using it for transfers between the edge and the cloud. The dataset size is
350MB and consists of 25 different data formats, including scripts (e.g. HTML,
Javascript), text formats (e.g. .txt files, JSON and XML formatted text) and
multimedia (e.g. jpeg, png images, audio files). The Alexa Top 200 list
contains a broad spectrum in terms of data size and data types. To the best of
our knowledge, there are no alternative benchmarks available capable of
capturing traffic representative of the wide range of mobile and Internet of
Things devices.

To study IoTZip’s behavior on different levels of compressibility, we created
two test sets using traffic from 50 different websites. Test set A includes
the 25 most compressible websites (average compressibility 3.07) and test B
includes the 25 least compressible websites (average compressibility 1.23) of
the Alexa Top 200 list. We eliminated web sites that were either very small in
size (order of a few tens of Kilobytes) or contained a small number of files.
The remaining 150 websites comprise our training set, which we use to train
IoTZip’s models.

Figure 2 presents the Cumulative Distribution Functions (CDFs) for each of the
evaluated datasets. Data found in the IoT datasets vary orders of magnitude in
size across datasets, but insignificantly within the same dataset. Data size
in the Activity Recognition dataset is in the order of MBs, in the RToF
Measurements dataset data size is in the order of KBs , whereas Air Quality
data are very small (order of bytes). Alexa Top 200 data sizes spread from
bytes to MBs.

Table II characterizes the datasets per data type and focuses on data
compressibility and content distribution by data size. Activity Recognition
and RToF Measurements include highly compressible text data. The Air Quality
dataset has very low compressibility despite having text data due to the small
data size; the compression algorithm builds a dictionary that is comparable in
size to the original data size. Alexa Top 200 is largely composed by scripts
and text data which are highly compressible and by images that are previously
encoded and therefore yield very low compressibility.

In the experiments performed, we compare IoTZip against other different
compression policies using the aforementioned benchmarks. As the applications
and the target hardware vary significantly, we are not using mobile web
browsers for our evaluation; instead, we focus on the total time required for
a benchmark to complete the transfer over the network. We also account for
compression and decompression latency at the endpoints.

Network Throughput Estimation: We use the open source Network Connection Class
[12], an Android library that allows developers to determine current network
throughput of an application. Network Connection Class achieves this by
listening to the traffic flowing through the application and by measuring
network throughput samples along the way. The library uses throughput samples
to keep a moving average of the network throughput and provides the user with
a notification when there is a significant change.

Performance Evaluation: For performance evaluation, we compare IoTZip against
(i) a policy that performs all data transfers uncompressed (Uncompressed),
(ii) an approach that compresses all data before they get transferred
(Compressed) and against an oracle (Time Oracle). The Time Oracle always makes
a correct decision when reasoning about the compression decision as it is
computed by choosing the minimum request latency between compressing data and
leaving it uncompressed for each individual web data transfer.

For each dataset we evaluate, each individual file or data item is processed
by IoTZip and eventually transferred from the client at the edge to the cloud
using an HTTP request. The resulting time required to transfer the mobile web
site is the aggregate time of individual data transfer times of its elements.

Testing under changing network conditions: IoTZip is able to perform under
varying network conditions. To evaluate our framework in a dynamically
changing environment, we emulate a network whose bandwidth varies over time
and experiment with IoTZip’s capacity to adapt to changes. We generate traces
that encapsulate changes in network conditions and that vary over the course
of our experiment. Each of these network conditions corresponds to a fixed
network throughput level that remains constant during an epoch, a predefined
period of time. Throughout the experiments, network settings are controlled in
the cloud setup by traffic shaping tools and network throughput levels are
sampled to vary in a uniformly random manner. Using this methodology, we can
test across controlled but varying network conditions.

In order to vary network settings in discrete intervals, we create a 4-way
partition of each dataset and consider the time required for each dataset
partition’s transfer to complete as an epoch. During the timeline of the
experiment we monitor the percentage of data compressed for IoTZip and compare
it against the Time Oracle. This comparison will provide us with insight into
how IoTZip adapts to the network changes and whether it decides to compress
data at a higher or lower percentage, depending on the data and the network
conditions. In addition, we compare IoTZip’s performance against the
Uncompressed, Compressed and Time Oracle policies.

##  V IoTZip Evaluation

Figure 3: Speedup of compression policies across datasets and network
settings. Results are presented relative to the Uncompressed policy along with
their respective standard errors.

(a) High compressibility (A), 10 Mbps network bandwidth

(b) Low compressibility (B), 10 Mbps network bandwidth

(c) High compressibility (A), 5 Mbps network bandwidth

(d) Low compressibility (B), 5 Mbps network bandwidth

(e) High compressibility (A), 2 Mbps network bandwidth

(f) Low compressibility (B), 2 Mbps network bandwidth

Figure 4: Performance evaluation across different network settings, using test
sets of high compressibility (A) and low compressibility (B). ZipIoT is
compared against an approach utilizing no compression (Uncompressed), an
approach that compresses all data (Compressed) and a Time Oracle. For relative
speedup comparison, higher is better, with an ideal Time Oracle representing a
“perfect” performance. Comparison is available for network throughput set at
2,5,10 Mbps. Regardless of compressibility or network conditions, IoTZip
demonstrates speedup against non-Oracle approaches. Figure 5: Breakdown of
IoTZip’s Total Runtime into Overhead, Compression time and Transmission Time.
Results are normalized against the Total Runtime along with their respective
standard errors. Figure 6: Presentation of Data Usage across datasets and
network settings. Data Usage is normalized against the Uncompressed policy.
Lower is better.

This section compare IoTZip’s performance against the (i) Uncompressed, (ii)
Compressed and (iii) Time Oracle approaches previously described. In addition,
we present statistics that showcase IoTZip’s efficiency and discuss the most
significant prediction errors that affect its accuracy. We perform experiments
in two different ways, (a) under constant network settings and (b) under
network throughput that varies over time.

###  V-A Evaluation under fixed network conditions

Figure 3 presents the comparison of the aforementioned approaches using
bandwidth thresholds at 2Mbps, 5Mbps and 10Mbps. The benchmarks used are
distributed across four different test sets, Activity Recognition, Air
Quality, RToF Measurements and Alexa, each with different compressibility
characteristics as described in Section IV. The Alexa datasets are presented
in total first, with subsequent graphs separating into the groups A and B
previously described. The results are presented as relative speedup over the
Uncompressed approach, which is always at 1; higher is better. The figure also
includes relative standard errors for each of the policies. As expected, the
Time Oracle always demonstrates superior performance over the other policies
as it represents an ideal scenario in which IoTZip makes decisions correctly
across all data.

As Figure 3 shows, IoTZip performs better relative to the Uncompressed
approach when the available bandwidth is low. That is expected since network
transfers become gradually more expensive as bandwidth declines. Compression
makes better use of limited bandwidth, both in terms of sending less data to
begin with, and also in terms of requiring fewer retries. Similarly, IoTZip
performs better versus Compressed as the network throughput increases. An
always-compress strategy can be inefficient for fast networks, because the
additional compression latency can outweigh the benefits of transferring less
data. IoTZip shows performance advantages against both the Compressed and
Uncompressed approaches.

Apart from the network conditions, the type of data transferred also affects
the performance of each policy. Highly compressible data favor the Compressed
method, as the use of compression allows to pay overhead to reduce the size of
data significantly. However, when data are not compressible, the Uncompressed
approach has better performance since introduction of compression adds
overhead but yields limited data savings in return. IoTZip benefits in both
scenarios as it can make a data driven decision. It achieves a maximum speedup
of 3.78x, whereas the average speedup across datasets is at 2.18x.

For the highly compressible data in the Activity Recognition and RToF
datasets, there are some cases where the Compressed policy edges IoTZip,
whereas in the Air Quality dataset that is highly non compressible,
Uncompressed is marginally better than IoTZip.

Since the Alexa dataset includes data with a wide spectrum of data size and
compressibility, it allows us to better observe the aforementioned tradeoffs
and we will study it in more detail in Figures 4(a)-4(f). Here, since the
Alexa dataset is divided into two test sets according to compressibility, we
can compare IoTZip’s advantages in two distinct scenarios. Each of these test
sets is comprised by 25 mobile website benchmarks, each corresponding to
mobile web data contained in the page load for that particular website. The
benchmarks are sorted in descending order of data compressibility. For each of
these benchmarks we present the relative speedup of the Compressed, IoTZip and
Time Oracle policies normalized over the Uncompressed policy. Additionally, we
present the average of these benchmarks for each of the two test sets A and B
and across the network conditions 2, 5 and 10 Mbps.

Looking at the averages for each figure we conclude that Test set A (more
compressible) provides better performance than test set B, since there are
more opportunities to reduce network transfer times when utilizing
compression. Test set B contains data with low compressibility, which IoTZip
often chooses to leave uncompressed, and often due to the file size and type
threshold criteria. This approach proves to be beneficial in the case of low
throughput at 2 Mbps and 5 Mbps. When throughput is low, compressing is the
common case, as savings from network transfers are more significant.
Therefore, IoTZip makes fewer errors on test set B and has less slowdown
against the Oracle compared to test set A. However, that does not hold for 10
Mbps, where IoTZip performs marginally better on test set A.

TABLE III: Overview of performance and accuracy statistics for IoTZip across different network conditions for the Alexa datasets. Comparison to the Uncompressed, Compressed and Time Oracle approaches presents the percentage of benchmarks (data corresponding to individual mobile web pages) sped up with IoTZip, the respective average speedup and the library’s overhead. | Network conditions
---|---
| 2 Mbps | 5 Mbps | 10 Mbps
Percentage win over Compressed | 76% | 86% | 86%
Percentage win over Uncompressed | 92% | 88% | 90%
Speedup vs Uncompressed | 1.78 | 1.56 | 1.53
Speedup vs Compressed | 1.12 | 1.19 | 1.24
IoTZip overhead | 0.26% | 0.36% | 0.56%
Slowdown vs Oracle | 0.84 | 0.81 | 0.86

Table III presents statistics about IoTZip’s performance across different
network settings using the Alexa dataset. First, the table presents the
percentage of Alexa website benchmarks for which IoTZip outperforms the
Compressed and Uncompressed approaches. The table presents results at a per-
benchmark granularity, comparing the aggregate network transfer time of each
website’s data for every policy. In addition, the table depicts the average
speedup of IoTZip across both test sets for the Uncompressed and Compressed
approaches and its performance relative to the Time Oracle. It also presents
IoTZip’s average overhead, which ranges from 0.26% to 0.56% of the total
transfer time of a request. To better understand how IoTZip resolves the
tradeoffs we break down the different latencies involved in each request
performed by IoTZip in Figure 5. The Total Runtime is composed by the
Overhead, Compression Time and Transmission time, in order to process,
possibly compress and transfer the data. The latencies are presented
normalized to the Total Time along with their respective relative standard
errors. We observe how IoTZip is affected by the changes in network
conditions. The results at 2 Mbps show that most of the latency is taken up by
the Transmission time and as the network throughput increases the Transmission
Time decreases and the Compression Time increases relative to the Total Time.
This behavior is expected as the compression is constant across network
conditions. As the network throughput increases, the compression overhead
becomes increasingly significant until a tipping point where compression no
longer provides enough data savings and reduction in data transmission time.
Data in the Activity Recognition and RToF datasets are highly compressible and
the percentage of Total Time used for Compression is high compared to the
Alexa dataset where data is less compressible. This happens as IoTZip chooses
to compress more frequently as compression is more beneficial. In addition,
the data savings are much higher in the compressible datasets which
corresponds to shorter overall Transmission Time. For the Air Quality dataset
there is no compression as IoTZip’s threshold is in force due to the small
data size.

IoTZip is designed to inherently provide data savings, as it bases its
approach on compression. We measured the data usage for each policy across
different network conditions and across all datasets and present them in
Figure 6. The data usage for each policy is presented normalized over the data
usage of the Uncompressed policy and lower is better. The Uncompressed policy
is guaranteed to have the highest data usage as there is no compression
involved. Additionally, the Time Oracle, despite providing ideal performance,
does not necessarily provide the most data savings, as in some transfers the
correct decision is to leave data uncompressed. The data usage demonstrates
variation across the different network settings, as IoTZip and the Time Oracle
can become more aggressive on using compression if the network throughput is
reduced and less aggressive if the throughput is high. The figure additionally
shows the data usage based on the different datasets. Having highly
compressible data can drastically change the data usage as is demonstrated by
the Activity Recognition and RToF Measurements dataset. After transferring the
former, IoTZip reduces data Usage to 24.2% of the original and in the case of
the latter data usage goes down to 18.5%. In the case of the Air Quality
dataset, the threshold disallows compression and therefore the data usage
remains unchanged. For the Alexa dataset, data usage is at roughly 60% of the
original at 2, 5, and 10Mbps, while providing applications with performance
speedup. The majority of data savings originates from large transfers of
highly compressible data. For all datasets, IoTZip performs very well in terms
of data savings and is operating close to the optimal, as demonstrated by the
Compressed policy columns.

IoTZip’s performance compared to other policies correlates with its prediction
accuracy, as depicted in Table IV. These results demonstrate the accuracy of
IoTZip across different network conditions for all datasets. For this
comparison, the Time Oracle is used as ground truth. IoTZip is subject to two
different kinds of errors: when it decides to compress when it should not
(false positives) and when it fails to identify that compression is beneficial
(false negatives). Most incorrect predictions are false negatives. The false
negative rate in the Alexa dataset decreases as the throughput increases,
because compression is no longer beneficial for some of the data. The same
trend does not hold in the Air Quality dataset, as IoTZip’s threshold does not
allow compression due to small data size. Activity Recognition and RToF
Measurements datasets have better success rate since large file size and
highly compressible data make the compression decisions easier.

TABLE IV: Characterization of the most significant prediction errors across all datasets for IoTZip using the Time Oracle as ground truth. Dataset | Error Type | 2 Mbps | 5 Mbps | 10 Mbps
---|---|---|---|---
Activ. R. | Success Rate (%) | 100 | 100 | 98.67
| False positives (%) | 0 | 0 | 1.33
| False negatives (%) | 0 | 0 | 0
Air Q. | Success Rate (%) | 65.00 | 80.88 | 74.84
| False positives (%) | 0 | 0 | 0
| False negatives (%) | 35.00 | 19.12 | 25.16
RToF M. | Success Rate (%) | 100 | 87.33 | 92.66
| False positives (%) | 0 | 12.67 | 7.33
| False negatives (%) | 0 | 0 | 0
Alexa | Success Rate (%) | 74.66 | 74.36 | 77.07
| False positives (%) | 3.41 | 4.90 | 4.34
| False negatives (%) | 21.93 | 20.74 | 18.59

Our evaluation of IoTZip under fixed network conditions indicates that it
performs consistently better than the Uncompressed and Compressed policies and
approaches the ideal performance (Time Oracle) in many cases. IoTZip
demonstrates an average speedup of 2.18x over the Uncompressed policy across
all datasets, with a maximum of 3.78x. It does so while maintaining high
accuracy throughout all datasets and while demonstrating significantly reduced
data usage down to 18.5% of the original data size.

Figure 7: Presentation of the percentages of compressed data over time for
IoTZip and Time Oracle. Results are presented across each epoch along the
network throughput level at each epoch. The changes in percentage of
compressed data and IoTZip’s ability to ”follow” the Time Oracle indicate
IoTZip’s adaptivity to changes in network conditions. Figure 8: Speedup of
compression policies across datasets and network settings. Results are
presented across each epoch along the network throughput level at each epoch.
Results are presented relative to the Uncompressed policy along with their
respective standard errors.

###  V-B Evaluation under changing network conditions

Having seen IoTZip’s speedup advantages for constant network conditions, we
next extend our evaluation to demonstrate that IoTZip can offer performance
improvements while adapting to changes in network conditions. Figure 7
demonstrates the percentage of compressed data for IoTZip and the Time Oracle
across the timeline. The figure also depicts the changes in network throughput
across the timeline. For our experiments we use the IoT datasets and Alexa
test sets in sequence to build the timeline. Each dataset is split in 4
partitions and results are presented per partition. The transfer of each
partition corresponds to an epoch. During the timeline, changes in network
throughput happen across epochs, but network settings remain constant within
an epoch. The Time Oracle line presents the percentage of data compressed
under the assumption that perfect compression decisions are made.

In the figure we can observe the fluctuations in the rate IoTZip performs
correct compression decision predictions over time. We observe that the
percentage of compressed data changes over the course of the experiment and is
affected by the data and the network throughput. The IoTZip line demonstrates
the same behavior as the Time Oracle, although with some false positives and
false negatives. As the network throughput decreases, the percentage of
compressed files increases and the trend occurs reversed during an increase in
the available network throughput. Although each change in network throughput
triggers a change in the percentage of data compressed, this percentage is
affected by the size of data in the dataset and their compressibility. When
comparing epochs around the RToF Measurements and the Alexa B datasets, we can
observe that in the first case changes in the network throughput cause the
percentage to fluctuate around 100%, whereas in the latter case the percentage
fluctuates between 20-40%. One exception is the Air Quality dataset. Due to
their very small size, the data don’t pass the IoTZip’s threshold and are
immediately disqualified for compression. Therefore, there is a large gap
between the IoTZip and Time Oracle lines.

IoTZip’s throughput prediction follows the throughput movement the device
observes and has a trend similar to the Time Oracle, although there is a gap
between the two lines. One reason for that gap is that there is a disparity
between IoTZip’s throughput prediction and the real bandwidth. First, IoTZip’s
throughput prediction module uses a moving average that adjusts the prediction
progressively and smooths rapid changes in measured throughput. The reason for
this mechanism is to avoid the throughput estimate to fluctuate significantly
during rapid changes in throughput. The average prediction accuracy is 74.04%
across the timeline. Table V presents an error characterization for IoTZip
across the experiment timeline. The errors are evaluated against the Time
Oracle. We can observe that the success rate of highly compressible datasets
(Activity Recognition and RToF Measurements) is high and in this case most
errors fall under false positives and IoTZip compresses when it should not.
Epochs 5-9 that belong to the Air Quality dataset only have false negatives
and low success rate, as IoTZip’s threshold limits compression on these data.
When comparing the success rate between Alexa A and Alexa B datasets, we
observe that similarly Alexa A has a better success rate due to its higher
compressibility. A technique capable of adapting the threshold based on the
data and network conditions could be investigated in future work.

TABLE V: Characterization of the most significant prediction errors for IoTZip using the Time Oracle as ground truth. The prediction errors are presented per epoch and network throughput varies across epochs. Epoch | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---
Success Rate (%) | 100 | 100 | 95.0 | 100 | 62.9 | 59.9 | 60.9 | 64.7 | 87.8 | 100 | 90.0 | 82.9 | 75.6 | 74.2 | 69.4 | 60.6 | 62.1 | 67.7 | 67.3 | 59.8
False positives (%) | 0 | 0 | 5.0 | 0 | 0 | 0 | 0 | 0 | 12.2 | 0 | 7.5 | 17.1 | 5.4 | 6.4 | 13.2 | 7.0 | 20.3 | 13.7 | 18.6 | 16.3
False negatives (%) | 0 | 0 | 0 | 0 | 37.1 | 40.1 | 39.1 | 35.3 | 0 | 0 | 2.5 | 0 | 19.0 | 19.4 | 17.4 | 32.4 | 17.6 | 18.6 | 14.1 | 23.9

Figure 8 presents the relative speedup of the Compressed, IoTZip and Time
Oracle policies over the Uncompressed across the epochs of the timeline. The
network throughput level for each epoch is also available for each figure. The
effect of the changes in network conditions are apparent on the results.
Whenever the network throughput increases, we observe that the IoTZip performs
better compared to the Compressed version and worse compared to the
Uncompressed version. Similarly, the reversed behavior occurs when the network
throughput is low. Based on the compressibility of the datasets, IoTZip
provided better speedup when data are highly compressible. However, in some
cases the Compressed policy edges IoTZip. When the data is not compressible as
in the Air Quality dataset, IoTZip always performs better than the Compressed
policy but can marginally perform worse than the Uncompressed policy. As
previously mentioned, change of network conditions affects the prediction
accuracy since IoTZip uses an approach that progressively propagates the
changes in throughput to the model. Therefore, changes in network conditions
affect, even temporarily, the accuracy of compression decisions. As evidenced
by comparing tables IV and V, IoTZip’s prediction errors are on average better
under fixed network settings when compared against measurements performed
under dynamically changing network conditions.

We evaluated IoTZip in dynamically changing network settings across all
datasets where our library proved to be superior than the uniform policies,
Uncompressed and Compressed. Our results demonstrate a maximum speedup of
4.17$\times$ and an average speedup of 2.03$\times$ over the Uncompressed
policy. IoTZip is adaptive to changes in network conditions and follows the
Time Oracle’s behavior while in many cases its performance is close to ideal.
IoTZip showcases an average prediction accuracy of 74.04% despite the varying
network conditions.

##  VI Conclusion

This paper presented IoTZip, a library for optimizing IoT and mobile web
traffic which implements selective compression—using it only when it is likely
to benefit performance. To support this, IoTZip uses compression latency and
network throughput estimates to reason about the compression decision of each
web transfer.

Based on our analysis of IoT data, specific IoT systems operate with a single
type of data and can generate data that exhibit little variation in data size.
Although these data characteristics could be used as indications to reduce the
need for compression selectivity, throughput and network quality variations
will still be present in IoT environments, making compression selectivity
necessary.

Throughout the evaluation of IoTZip, it is clear that the performance and data
usage of IoT communication heavily relies on data characteristics. We envision
that our work can also be utilized as a tool to characterize IoT applications.
IoTZip can identify properties of application data (data size distribution,
compressibility) as well as provide insight on how to handle communication
efficiently based on a Time Oracle that documents correct compression
decisions for the data and the network conditions in question.

IoTZip performs consistently better than uniform policies requiring either
all-compressed or all-uncompressed data and also approaches the Time Oracle
policy in many cases . Its average prediction accuracy is above 70% and its
resulting runtime latency outperforms these naïve policies, delivering a
speedup of up to 3.78x. The average speedup of IoTZip is 2.18x and 2.03x
across datasets under fixed and dynamic network conditions respectively.
Furthermore, the library provides significant data savings across different
network conditions and over different data.

Overall, IoTZip represents an important building block towards broader
implementation of traffic-reduction techniques that can improve latency, save
energy, and reduce the bandwidth requirements for mobile applications and
devices.

## References

  * [1] V. Agababov et al.  Flywheel: Google’s data compression proxy for the mobile web.  In NSDI’15, 2015.
  * [2] Alexa list web page.  http://www.alexa.com/topsites.
  * [3] N. Balasubramanian, A. Balasubramanian, and A. Venkataramani.  Energy consumption in mobile phones: A measurement study and implications for network applications.  In IMC ’09.
  * [4] Butkiewicz et al.  KLOTSKI: Reprioritizing Web Content to Improve User Experience on Mobile Devices.  In NSDI’15. USENIX Association.
  * [5] M. Butkiewicz, H. V. Madhyastha, and V. Sekar.  Understanding Website Complexity: Measurements, Metrics, and Implications.  In IMC ’11. ACM, 2011.
  * [6] A. Carroll and G. Heiser.  An Analysis of Power Consumption in a Smartphone.  In USENIX ATC’10, 2010.
  * [7] P. Casale, O. Pujol, and P. Radeva.  Personalization and user verification in wearable systems using biometric walking patterns.  Personal and Ubiquitous Computing, 2012.
  * [8] Cisco Visual Networking Index: Forecast and Methodology, 2015-2020.
  * [9] S. De Vito et al.  On field calibration of an electronic nose for benzene estimation in an urban pollution monitoring scenario.  Sensors and Actuators B: Chemical, 2008.
  * [10] Dropbox.  Lepton image compression, cited December 2020.  https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs/.
  * [11] J. Erman et al.  Towards a SPDY’Ier Mobile Web?  In CoNEXT ’13, 2013.
  * [12] Facebook Network Connection Class.  https://code.facebook.com/projects/1547113495553528/network-connection-class/.
  * [13] Facebook.  Zstandard is a real-time compression algorithm, cited December 2020.  http://facebook.github.io/zstd/.
  * [14] H. Falaki et al.  A First Look at Traffic on Smartphones.  In IMC ’10, 2010.
  * [15] E. Fernandes, J. Jung, and A. Prakash.  Security Analysis of Emerging Smart Home Applications.  In S&P ’16, 2016.
  * [16] E. Fernandes, J. Paupore, A. Rahmati, et al.  FlowFence: Practical Data Protection for Emerging IoT Application Frameworks.  In Proceedings of the 25th USENIX Security Symposium, August 2016\.
  * [17] Google.  Brotli Compression Format.  https://github.com/google/brotli.
  * [18] K. Hong et al.  Mobile Fog: A Programming Model for Large-scale Applications on the Internet of Things.  In MCC ’13, 2013.
  * [19] R. Khan et al.  Future Internet: The Internet of Things Architecture, Possible Applications and Key Challenges.  In FIT ’12, 2012.
  * [20] Z. Li et al.  Exploring Cross-application Cellular Traffic Optimization with Baidu TrafficGuard.  In NSDI’16, 2016.
  * [21] T. Melissaris, K. Shaw, and M. Martonosi.  OKAPI: In support of application correctness in smart home environments.  In FMEC’19, 2019.
  * [22] T. Melissaris, K. A. Shaw, and M. Martonosi.  Locomotive: Optimizing mobile web traffic using selective compression.  In WoWMoM ’17, 2017.
  * [23] R. Netravali et al.  Polaris: Faster Page Loads Using Fine-grained Dependency Tracking.  In NSDI ’16, 2016.
  * [24] A. Purohit et al.  CRAWDAD dataset cmu supermarket (v. 2014-05-27), cited December 2020\.  http://crawdad.org/cmu/supermarket/20140527.
  * [25] F. Qian, S. Sen, and O. Spatscheck.  Characterizing Resource Usage for Mobile Web Browsing.  In MobiSys ’14, 2014.
  * [26] L. Ravindranath et al.  Procrastinator: Pacing Mobile Apps’ Usage of the Network.  In MobiSys ’14, 2014.
  * [27] S. Raza, H. Shafagh, R. Iida, and L. Wang.  Lithe: Lightweight secure coap for the internet of things.  2013\.
  * [28] C. M. Sadler and M. Martonosi.  Data Compression Algorithms for Energy-constrained Devices in Delay Tolerant Networks.  In SenSys, 2006.
  * [29] S. Singh et al.  Flexiweb: Network-aware compaction for accelerating mobile web transfers.  In MobiCom ’15, 2015.
  * [30] Telerik Fiddler Debugging Proxy.  http://www.telerik.com/fiddler.
  * [31] N. Thiagarajan et al.  Who Killed My Battery?: Analyzing Mobile Browser Energy Consumption.  In WWW ’12, 2012.
  * [32] X. S. Wang et al.  Demystifying Page Load Performance with WProf.  In NSDI ’13, 2013.
  * [33] X. S. Wang, A. Krishnamurthy, and D. Wetherall.  Speeding up Web Page Loads with Shandian.  In NSDI’ 16, 2016.
  * [34] P. Zhang et al.  Hardware Design Experiences in ZebraNet.  In SenSys ’04, 2004.


The Submillimeter Array (SMA) has proven to be a successful instrument for the
study of the youngest molecular outflows and jets from the most deeply
embedded sources (e.g., Hirano et al. 2006; Palau et al. 2006; Lee et al.
2007a,b, 2008, 2009). The detection of excitation from rotational transitions
of SiO up to levels $J$=8–7 and CO up to $J$=3–2 have uniquely identified a
molecular high-velocity jet-like component located within outflow shells. This
component displays similarities to the optical forbidden line jets observed in
T-Tauri stars (Hirano et al. 2006; Palau et al. 2006; Codella et al. 2007;
Cabrit et al. 2007). These observations have provided a new probe of how jets
are launched and collimated during the earliest protostellar phase.

One unique opportunity offered by the Band 1 frequency range is observation of
the $J$=1–0 transition of the SiO molecule at 43.424 GHz. This transition has
not yet been detected nor surveyed around even the brightest molecular
outflows, except using single-dish telescopes (Haschick & Ho 1990). One
feature of this line that may be potentially distinct from the higher-$J$
transitions of SiO is that it may be tracing the outer and more diffuse gas
located on the outskirts of outflow shells that can be easily excited by
shocks. Potential morphological and kinematic studies of the regions where the
outflows interact with their own pre-natal clouds could be contrasted with
other transitions using knowledge of their excitation conditions. In
particular, the improved sensitivity to extended emission and higher image
fidelity of ALMA make observations of SiO $J$=1–0 toward outflows more
attractive with ALMA than with the JVLA.

####  6.2.7 Co-Evolution of Star Formation and Active Galactic Nuclei

Roughly half of the high-redshift objects detected in CO line emission are
believed to host an active galactic nucleus (AGN). Although they are selected
based on their AGN properties, optically luminous high-redshift quasars
exhibit many characteristics indicative of ongoing star formation, e.g.,
thermal emission from warm dust (Wang et al. 2008) or extended UV continuum
emission. Indeed, galaxies with AGNs in the local Universe reveal a strong
correlation between the mass ($m$) in their supermassive black hole (SMBH) and
that of their stellar bulge (measured from the stellar velocity dispersion
($\sigma$); e.g., Kormendy & Richstone 1995; Magorrian et al. 1998; Gebhardt
et al. 2000). Such a correlation can be explained if the SMBH formed coevally
with the stellar bulge, implying that the luminous quasar activity signaling
the formation of a sub-arcsecond SMBH at high-redshift should be accompanied
by starburst activity. High spatial resolution observations of CO line
emission in high-redshift quasars can be used to infer the dynamical masses,
which are found to be comparable to the derived molecular gas + black hole
masses, meaning that their stellar component cannot contribute a large
fraction of the total mass.

There is mounting evidence that quasar host galaxies at redshifts $z$ = 4–6
have SMBH masses up to an order of magnitude larger than those expected from
their bulge masses and the local relation (Walter et al. 2004; Riechers et
al., in prep.), suggesting that the SMBH may have formed first. The possible
time evolution of the $m-\sigma$ relation is of fundamental importance in
studies of galaxy evolution, and this new finding needs to be made more
statistically robust. Future observations of high-redshift AGN with the Band 1
receivers on ALMA would allow us to address this question through the study of
low-$J$ CO line emission in galaxies beyond redshifts $z\approx 1.3$ (see
§4.2). ALMA especially allows studies of examples of such objects in the south
that are not well observable (if at all) with the JVLA.

####  6.2.8 The Molecular Gas Content of Star-Forming Galaxies at $z\sim 2$

While low-$J$ CO line emission has only been detected in a few high-redshift
objects, high-$J$ CO line emission has been detected in more than sixty
sources, most of which are classified as either submillimeter galaxies (SMGs)
or far-infrared (FIR) luminous QSOs (see Carilli et al. 2011 for a review).
Most of these studies have been conducted with sensitive interferometers and
single-dish facilities operating in the 3 mm band (e.g., ALMA Band 3), which
is sensitive to higher-$J$ CO line transitions at high redshift, as is
illustrated in Figure 6. These lines generally trace warmer and denser gas,
and so previous data may have led to a bias in our understanding of the
molecular gas properties of high-redshift galaxies (e.g., Papadopoulos &
Ivison 2002). The addition of Band 1 receivers on ALMA will allow comparisons
of the cold gas traced by the low-$J$ transitions ($J$=2–1/1–0) in galaxies
from moderate redshifts ($z\approx 1.3$) to those which existed when the
Universe was re-ionized sometime before $z\mathrel{\raise
1.50696pt\hbox{$\scriptstyle>$}\kern-6.00006pt\lower
1.72218pt\hbox{{$\scriptstyle\sim$}}}6$.

Although many previous studies of CO line emission in high-redshift galaxies
have focused on those starburst galaxies and AGN undergoing episodes of
extreme star formation (e.g., $\gg$100 M⊙ yr-1), significant masses of
molecular gas ($>10^{10}$ M⊙) have been discovered in more modest star-forming
galaxies at $z=1.5-2.0$ (Daddi et al. 2008). These “BzK” galaxies are selected
for their location in a B-$z$-K colour diagram (Daddi et al. 2004) and have
star-formation rates of $\sim$100 M⊙ yr-1 (Daddi et al. 2007), while their
number density is roughly a factor of 30 larger than that of the more extreme
SMGs at similar redshifts. Observations of CO $J$=2–1 line emission in these
BzK galaxies reveal comparable masses of molecular gas to that of the SMGs, so
their star-formation efficiencies appear lower. The excitation conditions of
their molecular gas (temperature and density) are similar to those of the
Milky Way (Dannerbauer et al. 2008), as indicated by the “turnover” in the CO
line spectral energy distribution occurring at the J=3–2 transition, i.e.,
lower than that of the SMGs which typically occurs at the J=6–5 or J=5–4
transition (Weiss et al. 2005). To develop a full spectral energy distribution
for the CO line excitation, observations of these galaxies in the $J$=1–0
transition are needed with Band 1 receivers on ALMA. Such data will also
provide a more robust estimate of the total molecular gas mass, along with the
spatial resolution needed to constrain the gas kinematics, as has been done
for the SMGs (Tacconi et al. 2006). Indeed, recent high-resolution studies of
CO $J$=1–0 from lensed Lyman Break galaxies (Riechers et al. 2010) and
unlensed BzK galaxies (Aravena et al., in prep.) have been made with the JVLA.
Also, CO $J$=1–0 emission has been detected with the JVLA or GBT towards SMGs
Ivison et al. 2010, 2011; Frayer et al. 2011; Riechers et al. 2011a,b). ALMA
observations will allow similar important investigations to occur towards
southern objects, especially those traced by ALMA itself in its higher-
frequency Bands.

##  7 Summary

The Band 1 receiver suite has been considered an essential part of ALMA from
the earliest planning days. Even through the re-baselining exercise in 2001,
the importance of Band 1 was emphasized. With the ALMA Development Plan
underway, we have undertaken an updated review of the scientific opportunity
at these longer wavelengths. This document presents a set of compelling
science cases over this frequency range. The science cases reflect the new
proposed range of Band 1, 35-50 GHz (nominal) with an extension up to 52 GHz,
which was in fact chosen to optimize the science return from Band 1. The
science cases range from nearby stars and galaxies to the re-ionization edge
of the Universe. Two provide additional leverage on the present ALMA Level One
Science Goals and are seen as particularly powerful motivations for building
the Band 1 receiver suite: (1) detailing the evolution of grains in
protoplanetary disks, as a complement to the gas kinematics, requires
continuum observations out to $\sim 35\,$GHz ($\sim 9\,$mm); and (2) detecting
CO 3 – 2 spectral line emission from Galaxies like the Milky Way during the
era of re-ionization, $6<z<10$ also requires Band 1 receiver coverage. Band 1
receivers will also allow the pursuit of a diverse range of science cases that
take advantage of the ALMA’s particular strengths over other facilities (e.g.,
the JVLA).

##  8 References

Acke, B., & van den Ancker, M. E. 2004, A&A, 426, 151

Acke, B., et al. 2004, A&A, 422, 621

Adams, F. C., Emerson, J. P., & Fuller, G. A. 1990, ApJ, 357, 606

Anglada, G. 1995, RMAACS, 1, 67

Aikawa, Y., Ohashi, N., Inutsuka, S.-I., Herbst, E., & Takakuwa, S. 2001, ApJ,
552, 639

Aikawa, Y., Herbst, E., Roberts, H., & Caselli, P. 2005, ApJ, 620, 330

Andrews, S., & Williams, J. P. 2007a, ApJ, 659, 705

Andrews, S., & Williams, J. P. 2007b, ApJ, 671, 1800

Aschwanden, M. J., Wills, M. J.; Hudson, H. S., Kosugi, T., Schwartz, R. A.
1996, ApJ, 468, 398

Bailey, J., Chrysostomou, A., Hough, J. H., Gledhill, T. M., McCall, A.,
Clark, S., Menard, F., & Tamura, M. 1998, Science, 281, 672

Bartel, N. et al. 2002, ApJ, 581, 404

Bartel, N., Bietenholz, M.F., Rupen, M.P., & Dwarkadas, V.V. 2007, ApJ, 668,
924

Bauer, F. E., et al. 2008, ApJ, 688, 1210

Beckwith, S., Sargent, A. I., Chini, R. S., & Guesten, R. 1990, AJ, 99, 924

Beckwith, S., & Sargent, A. I. 1991, ApJ, 381, 250

Bertoldi, F. et al. 2003, A&A, 409, L47

Bietenholz, M. F., Bartel, N., & Rupen, M. P. 2004, Science, 304, 1947

Bietenholz, M. F., Bartel, N., & Rupen, M. P. 2010, ApJ, 712, 1057

Blain, A. W., Smail, I., Ivison, R. J., Kneib, J.-P., & Frayer, D. T. 2002,
Phys. Rep., 369, 111

Boley, A., et al. 2012, ApJ, 750, L21

Bonamente, M., Joy, M., LaRoque, S. J., et al. 2008, ApJ, 675, 106

Birkinshaw, M. 1999, Phys. Rep. 310, 97

Buckle, J. V., et al. 2006, Faraday Discussions, 133, 63

Bouwens, R. J., et al. 2009, ApJ, 690, 1764

Boss, A. 2005, ApJ, 629, 535

Butler, B., 2010, VLA Test Memo 232, “Atmospheric Opacity at the VLA”

Butler, B., 1998, VLA Memo 237, “Precipitable Water at the VLA – 1990-1998”

Butler, B. & Desai, K., VLA Test Memo 222, “Phase Fluctuations at the VLA
Derived From One Year of Site Testing Interferometer Data”

Cabrit, S., et al. 2007, A&A, 468, L29

Calvet, N., et al. 2002, ApJ, 568, 1008

Cappelluti, N., Predehl, P., Böhringer, H., et al. 2011, Memorie della Societa
Astronomica Italiana Supplementi, 17, 159

Carilli, C. L., et al. 2007, ApJ, 666, L9

Carilli, C. L., et al. 2008, Ap&SS, 313, 307

Carlstrom, J. E., Holder, G. P., & Reese, E. D. 2002, ARA&A, 40, 643

Casassus, S., et al. 2008, MNRAS, 391, 1075

Chevalier, R.A. 1982, ApJ, 259, 85

Churchwell, E. 2001, ARA&A, 40, 27

Cohen, R. J. 1995, Ap&SS, 224, 55

Codella, C., et al. 2007, A&A, 462, L53

Cool, R.J., et al. 2006, AJ, 132, 823

Cragg, D. M., Sobolev, A. M., & Godfrey, P. D. 2005, MNRAS, 360, 533

Crutcher, R. M. 2012, ARA&A, 50, 29

Crutcher, R. M., Troland, T. H., Lazareff, B., & Kazes, I. 1996, ApJ, 456, 217

Crutcher, R. M., Troland, T. H., Lazareff, B., Paubert, G., & Kazès, I. 1999,
ApJL, 514, 121

D’Addario, L., & Holdaway, M. 2003, ALMA Memo 521, “Joint Distribution of
Atmospheric Transparency and Phase Fluctuations at Chatnantor”

Daddi, E., et al. 2004, ApJ, 617, 746

Daddi, E., et al. 2007, ApJ, 670, 156

Daddi, E., et al. 2008, ApJL, 673, L21

Dannerbauer, H., et al. 2009, ApJL, 698, 178

Dark Energy Survey Collaboration, The 2005, arXiv:astro-ph/0510346

Dib, S., Kim, J., Vázquez-Semadeni, E., Burkert, A., & Shadmehri, M. 2007,
ApJ, 661, 262

Dodds-Eden, K., et al. 2009, ApJ, 698, 676

Draine, B. 2003, ARA&A, 41, 241

Draine, B. 2006, ApJ, 636, 1114

Draine, B., & Anderson, N. 1985, ApJ, 292, 494

Draine, B., & Lazarian, A. 1998, ApJ, 508, 157

Dullemond, C. P., & Dominik, C. 2005, A&A, 434, 971

Dunkley, J., et al. 2009, ApJS, 180, 306

Dunkley, J., Hlozek, R., Sievers, J., et al. 2011, ApJ, 739, 52

Eckart, A., et al. 2006, å, 450, 535

Ellingsen, S. P. et al. 2007, IAUS, 242, 213

Ellingsen, S. P. 2004, IAUS, 221, 133

Ettori, S., & Fabian, A. C. 2006, MNRAS, 369, L42

Falgarone, E., Troland, T. H., Crutcher, R. M., & Paubert, G. 2008, A&A, 487,
247

Fan, X., et al. 2001, AJ, 122, 2833

Fan, X., et al. 2006a, AJ, 132, 117

Fan, X., Carilli, C. L., & Keating, B. 2006b, ARA&A, 44, 415

Fender, R. P., et al. 1999, ApJL, 519, 165

Finkbeiner, D. P., Schlegel, D. J., Frank, C., & Heiles, C. 2002, ApJ, 566,
898

Frayer, D., et al. 2011, ApJ, 726, L22

Gaensler, B. M., et al. 2007, AIP Confer. Ser., ed. S. Immler & R. McCray,
937, 86

Garrod, R. T., Weaver, S. L. W., & Herbst, E. 2008, ApJ, 682, 283

Gebhardt, K., et al. 2000, ApJ, 543, L5

Geisbuesch, J., & Hobson, M. P. 2007, MNRAS, 382, 158

Geisbuesch, J., Kneissl, R., & Hobson, M. P. 2005, MNRAS, 360, 41

Ghez, A., et al. 2008, ApJ, 689, 1044

Gillessen, S., et al. 2009, ApJ, 692, 1075

Glikman, E., et al. 2008, AJ, 136, 954

Goldreich, P., Keeley, D. A., & Kwan, J. Y. 1973, ApJ, 179, 111

Greaves, J., Richards, A. M. S., Rice, W. K. M., & Muxlow, T. W. B. 2008,
MNRAS, 391, 74

Guilloteau, S., et al. 20009, å, 529, 105

Gunn, J.E., & Peterson, B.A. 1965, ApJ, 142, 16331

Hales, A. S., et al. 2004, ApJ, 613, 977

Haschick, A. D., & Ho, P. T. P. 1990, ApJ, 352

Harvey-Smith, L., Soria-Ruiz, R., Duarte-Cabral, A., & Cohen, R. J. 2008,
MRAS, 384, 719

Helfand, D. J., Gotthelf, E. V., & Halpern, J. P. 2001, ApJ, 556, 380

Hincks, A. D., et al. 2009, arXiv:0907.0461

Hirano, N., et al. 2006, ApJL, 636, 141

Holtom, P. D., Bennett, C. J., Osamura, Y., Mason, N. J, & Kaiser, R. I. 2005,
ApJ, 626, 940

Hu, E.,M., Cowie, L. L., & McMahon, R. G. 1998, ApJ, 502, L99

Hunt-Cunningham, M. R., & Jones, P. A. 2004, IAUS, 213, 159

Isella, A, Natta, A., Wilner, D., Carpenter, J. M.. & Testi, L. 2010, ApJ,
725, 1735

Ivison, R. J., et al. 2010, MNRAS, 404, 198

Ivison, R. J., et al. 2011, MNRAS, 412, 1913

Iye, M., et al. 2006, Nature, 443, 186

Kaufmann, P., Raulin, J.-P., de Castro, C. G. G. 2004, ApJ, 603, L121

Kepley, A. A., Chomiuk, L., Johnson, K. E., Goss, W. M., Balser, D. S., &
Pisano, D. J. 2011, ApJ, 739, L24

Kitayama,T., Komatsu, E., Ota, N., Kuwabara, T., Suto, Y., Yoshikawa, K.,
Hattori, M., & Matsuo, H. 2004, PASJ, 56, 17

Koerding E. G., Fender R. P., & Migliari S. 2006, MNRAS, 369, 1451

Komatsu, E., Matsuo, H., Kitayama, T., Kawabe, R., Kuno, N., Schindler, S., &
Yoshikawa, K. 2001, PASJ, 53, 57

Kormendy, J., & Richstone, D. 1995, ARA&A, 33, 581

Korngut, P. M., Dicker, S. R., Reese, E. D., et al. 2011, ApJ, 734, 10

Lai, S.-P., & Crutcher, R.M. 2000, ApJS, 128, 271

Lakićević, M., Zarnado, G., van Loon, Th., Staveley-Smith, L., Potter, T., Ng,
C.-Y., & Gaensler, B. M. 2012, A&A, 541, L2

Lee, C.-F., et al. 2007a, ApJ, 659, 499

Lee, C.-F., et al. 2007b, ApJ, 670, 1188

Lee, C.-F., et al. 2008, ApJ, 685, 1026

Lee, C.-F., et al. 2009, ApJ, 699, 1584

Lee, J., & Komatsu, E. 2010, ApJ, 718, 60

Leger, A., & Puget, J. L. 1984, A&A, 137, L5

Li, Y., et al. 2007, ApJ, 665, 187

Li, Y., et al. 2008, ApJ, 678, 41

Lim, J., & Takakuwa, S. 2006, ApJ, 653, 425

Lonsdale, C. J., et al. 2006, ApJ, 647, 185

Maccarone T. J., 2008, ASPC, 401, 191

Maccarone T. J., Gallo E., Fender R. P. 2003, MNRAS, 345, L19

Magorrian, J., et al. 1998, AJ, 115, 2285

Maness, H. et al. 2008, ApJ, 686, L25

Mannings, V., & Emerson, J. 1994, MNRAS, 267, 361

Markevtich, M., et al. 2000, ApJ, 541, 542

Markevitch, M., et al. 2002, ApJ, 567, L27

Markevitch, M., et al. 2009, arXiv:0902.3709

Mason, B. S., Dicker, S. R., Korngut, P. M., et al. 2010, ApJ, 716, 739

Masuda, S., Kosugi, T., Hara, H., Tsuneta, S., Ogawara, Y. 1994, Nature, 371,
495

McIntosh, G. C., Read Predmore, C., & Patel, N. A. 1994, ApJ, 428, L29

McKee, C. F. & Ostriker, E. C. 2007, ARA&A, 45, 565

Melis, C., et al. 2011, ApJ, 739, L7

Menanteau, F., Hughes, J. P., Sifon, C., et al. 2011, arXiv:1109.0953

Menten, K. 2007, IAUS, 242

Merloni, A., et al. 2012, arXiv, 1209.3114

Migliari S., Fender R. P., Rupen, M., Wachter, S., Jonker, P. G., Homan, J., &
van der Klis, M. 2004, MNRAS, 351, 186

Morandi, A., Ettori, S., & Moscardini, L. 2007, MNRAS, 379, 518

Mortlock, D. J., et al. 2008, arXiv0810.4180

Mouschovias, T.Ch. & Spitzer, L., Jr. 1976, ApJ, 210, 326

Narayanan, D., et al. 2008, ApJS, 174, 13

Narayan, R., Ozel, F., & Sironi, L. 2012, ApJ, 757, L20

Narayan R., & Yi, I. 1994, ApJL, 428, 13

Neufeld, D., & Melnick, G. 1991, ApJ, 368, 215

Ota, K., et al. 2008, ApJ, 677, 12

Otárola, A., Holdaway, M., Nyman, L-Å, Radford, S. J. E., & Butler, B. J.
2005, ALMA Memo 512, “Atmospheric Transparency at Chajnantor: 1973-2003”

Palau, A., et al. 2006, ApJL, 636, 137

Papadopoulos, P. P. & Ivison, R. J. 2002, ApJ, 564, L9

Pascucci, I., Gorti, U., & Hollenbach, D. 2012, ApJ, 751, L42

Peters, T., Longmore, S. N., & Dullemond, C. P. 2012, MNRAS, 425, 2352

Pfrommer, C., Enßlin, T. A., & Sarazin, C. L. 2005, A&A, 430, 799

Plagge, T., et al. 2012, arXiv:1203.2175

Planck Collaboration, Ade, P. A. R., Aghanim, N., et al. 2011, arXiv:1101.2024

Pinte, C., Menard, F., Duchêne, G., & Bastien, P. 2006, A&A, 459, 797

Pinte, C., et al. 2009, A&A, 498, 967

Pollack, J., et al. 1996, Icarus, 124, 62

Poole, G. B., Babul, A., McCarthy, I. G., et al. 2007, MNRAS, 380, 437

Rafikov, R. 2006, ApJ, 646, 288

Reid, M. J. & Brunthaler, A. 2004, ApJ, 616, 872

Reipurth, B., & Bally, J. 2001, ARA&A, 39, 403

Rephaeli, Y. 1995, ARA&A, 33, 541

Rhoads J. E., et al. 2000, ApJ, 545, L85

Ricci, L., Testi, L., Natta, A., Neri, R., Cabrit, S., & Herczeg, G. 2010, å,
512, 15

Riechers, D., et al. 2009, ApJ, 703, 1338

Riechers, D., et al. 2010, ApJ, 724, L153

Riechers, D., et al. 2011a, ApJ, 733, L11

Riechers, D., et al. 2011b, ApJ, 739, L31

Rodmann, J., et al. 2006, A&A, 446, 211

Rodríguez, L. F., et al. 1998, Nature, 395, 355

Rodríguez, L. F., et al. 2003, ApJL, 586, 137

Roy, N., Datta, A., Momjian, E. & Sarma, A. P. 2011, ApJ, 739, L4

Sarazin, C.L. 1988, in “X-ray emission from clusters of galaxies,” Cambridge
University Press

Scaife, A. M. M., et al. 2009, MNRAS, 400, 1394

Scaife, A. M. M., et al. 2010, MNRAS, 403, 46

Sehgal, N., Trac, H., Acquaviva, V., et al. 2011, ApJ, 732, 44

Shang, H., Lizano, S., Glassgold, A., & Shu, F. 2004, ApJL, 612, 69

Sheperd, D. S., Chandler, C. J., Cotton, B., Perley, R. A., Randall, S. K., &
Remijan, A. J. 2013, High Energy Density Physics, 9, 26

Shinnaga, H., & Yamamoto, S. 2000, ApJ, 544, 330

Shu, F. H., Adams, F. C., & Lizano, S. 1987, ARA&A, 25, 23

Sobolev, A. M., et al. 1999, in The Physics and Chemistry of the Interstellar
Medium, ed. V. Ossenkopf et al. (GCA-Verlag: Herdecke), 299

Sobolev, A. M., Cragg, D. M., Godfrey, P. D. 1997, MNRAS, 288, L39

Staniszewski, Z., et al. 2009, ApJ, 701. 32

Sui, L., Holman, G. D. 2003, ApJ, 596, L251

Sunyaev, R. A., & Zel’dovich, Ya. B. 1972, Comm. Astrophys. Space Phys. 4, 173

Sutton, E. C., et al. 2001, ApJ, 554, 173

Suzuki, H., et al. 1992, ApJ, 392, 551

Tacconi L. J., et al. 2006, ApJ, 640, 228

Takakuwa, S., Kamazaki, T., Saito, M., & Hirano, N. 2003, ApJ, 584, 818

Tananbaum H., Gursky H., Kellogg E., Giacconi R., & Jones C. 1972, ApJ, 177,
L5

Taniguchi, Y., et al. 2005, PASJ, 57, 165

Testi, L., Natta, A., Shepherd, D.S., & Wilner, D.J. 2001, ApJ, 554, 1087

Tudose, V., Fender, R. P., Linares, M., Maitra, D., & van der Klis M. 2009,
MNRAS, 400, 2111

Vikhlinin, A., Kravtsov, A. V., Burenin, R. A., et al. 2009, ApJ, 692, 1060

Vlemmings, W. H. T., Diamond, P. J., & Imai, H. 2006, IAUS, 234, 267

Wagg, J., & Kanekar, N. 2012, ApJ, 751, L24

Wagg, J., Kanekar, N., & Carilli, C.L. 2009, ApJL, 697, L33

Walter, F., et al. 2003, Nature, 424, 406

Walter, F., et al. 2004, ApJ, 615, L17

Walter, F., et al. 2009, ApJ, 691, L1

Wang, R., et al. 2008, AJ, 135, 1201

Wang, R., et al. 2010, ApJ, 714, 699

Wang, R., et al. 2011a, AJ, 142, 101

Wang, R., et al. 2011b, ApJ, 739, L34

Watson, W. D. 2008, arXiv0811,1292W

Weintraub, D. A., Sandell, G., & Duncan, W. D. 1989, ApJ, 340, 69

Weiss, A., Downes, D., Walter, F., & Henkel, C. 2005, A&A, 440, 45

Welch, W. J., et al. 2004, in Bioastronomy 2002, eds R. Norris, F. Stootman
(ASP, San Francisco), 213, 59

Weiler, K. W., Panagia, N., Montes, M. J., & Sramek, R. A. 2002, ARA&A, 40,
387

Weibe, D. S., & Watson, W. D. 1998, ApJ, 503, L71

White, S. M., Krucker, S., Shibasaki, K., et al. 2003, ApJ, 595, L111

Wik, D. R., Sarazin, C. L., Ricker, P. M., & Randall, S. W. 2008, ApJ, 680, 17

Williamson, R., Benson, B. A., High, F. W., et al. 2011, ApJ, 738, 139

Willott, C. J., et al. 2009, AJ, 137, 3541

Wilner, D. J., Ho, P. T. P., Kastner, J. H., & Rodriguez, L. F. 2000, ApJ,
534, 101

Wootten, A. 2007, IAUS, 242

Wyatt, M. C., 2009, ARA&A, 46, 339

Yamada, K., et al. 2012, PASJ, in press.

Yokoyama, T., Akita, K., Morimoto, T., Inoue, K., Newmark, J. 2001, ApJ, 546,
L69

Yusef-Zadeh, F., et al. 2012, ApJ, 757, L1

Yusef-Zadeh, F., et al. 2006, ApJ, 650, 189