#  SONIC: Connect the Unconnected via FM Radio & SMS

Ayush Pandey<EMAIL_ADDRESS>New York University Abu DhabiAbu
DhabiUnited Arab Emirates ,  Rohail Asim<EMAIL_ADDRESS>New York
University Abu DhabiAbu DhabiUnited Arab Emirates ,  Khalid Mengal
<EMAIL_ADDRESS>New York University Abu DhabiAbu DhabiUnited Arab Emirates ,
Matteo Varvello<EMAIL_ADDRESS>Nokia Bell LabsNew JerseyUnited
States and  Yasir Zaki  yasir.zaki New York University Abu DhabiAbu
DhabiUnited Arab Emirates

(2018)

###### Abstract.

As of 2022, about 2.78 billion people in developing countries do not have
access to the Internet. Lack of Internet access hinders economic growth,
educational opportunities, and access to information and services. Recent
initiatives to “connect the unconnected” have either failed (project Loon and
Aquila) or are characterized by exorbitant costs (Starlink and similar), which
are unsustainable for users in developing regions. This paper proposes SONIC,
a novel connectivity solution that repurposes a widespread communication
infrastructure (AM/FM radio) to deliver access to pre-rendered webpages. Our
rationale is threefold: 1) the radio network is widely accessible – currently
reaching 70% of the world – even in developing countries, 2) unused
frequencies are highly available, 3) while data over sound can be slow, when
combined with the radio network it takes advantage of its broadcast nature,
efficiently reaching a large number of users. We have designed and built a
proof of concept of SONIC which shows encouraging initial results.

††copyright: acmlicensed††journalyear: 2018††doi: XXXXXXX.XXXXXXX††conference:
Make sure to enter the correct conference title from your rights confirmation
emai; June 03–05, 2018; Woodstock, NY††isbn: 978-1-4503-XXXX-X/18/06

##  1\. Introduction

Access to the Internet is vital in today’s interconnected world. According to
the International Telecommunication Union (ITU) about 2.9 billion people are
still offline (ITU, [n. d.]) (96% of them are from developing regions).
Several initiatives have attempted to extend Internet connectivity to remote
areas, such as Google Loon (goo, 2023) (via high-altitude balloons) and
Facebook Aquila (fac, 2023) (via solar-powered drones). Both projects were
eventually halted due to high cost and performance issues (notably Aquila
crash (aqu, 2023)). Starlink (sta, 2023), or Internet access provided via low-
earth orbit satellites, is another recent solution that is vastly growing (1.5
million users as of June 2023) but characterized by excessive costs for most
people from developing regions.

The goal of this work is to design a novel technology to provide some form of
free Internet access in developing regions. Our rationale is to leverage
existing infrastructures which have broad adoption but were not intended for
Internet data dissemination. We propose SONIC, a system which exploits the FM
radio infrastructure – currently covering roughly 70% of the world according
to the United Nations (rad, 2023) – to enable the download of simplified
webpages encoded over sounds. SONIC further relies on the SMS (Short Message
Service) network, when available, as uplink to interact with a webpage or
request a new one. SONIC complements existing initiatives aimed at improving
Internet availability. For instance, (expensive) satellite communication can
be used to provide Internet connectivity to a few radio stations or towers.
These stations can then leverage SONIC to extend access to end-users, making
Internet connectivity more affordable and widespread.

Figure 1. Pre-rendered webpage delivered as WebP via SONIC with no frame lost
(left), 10% losses (center), and pixel interpolated on 10% losses (right).

SONIC consists of a client and a server. The server extends an FM transmitter
with the capability to load webpages, render them, and then encode their
appearances over sounds which are transmitted along with regular radio
programs. The client consists of a low-end mobile device and an FM receiver,
often integrated. The client is equipped with an application to decode a
webpage from the sound received. SONIC transmits images of rendered webpages
for data savings (about 10x compression) and loss resilience, different from
Web objects like HTML and JavaScript. SONIC further uses nearest neighbor
pixel interpolation (Rukundo and Cao, 2012) to recover from errors. Figure 1
shows that a webpage is still readable despite about 10% loss rate.

We have built a proof of concept of SONIC consisting of a Raspberry Pi acting
as FM radio transmitter (git, 2023), and a Xiaomi Redmi Go (Arena, 2023)
acting as a client using its internal FM tuner as well as an external
receiver. For encoding and decoding images of webpages, we rely on the Quiet
library (qui, 2023b) and a chunking mechanism we have developed. Using this
setup, we demonstrate that a rate of 10kbps is sustainable with no losses when
the FM receiver is integrated in the mobile device, and a Received Signal
Strength Indication (RSSI) of -65 to -85 dB is achieved. Next, we demonstrate
that this transmission rate is sufficient to broadcast 100 popular Pakistani
websites with acceptable readability, as confirmed by a user study involving
151 participants. Multiple frequencies can be used to increase the rate,
allowing to either broadcast more content or support user requests via uplink.

##  2\. Background and Related Work

_Data Over Sound:_ Several research papers (Ka et al., 2016; Lee et al., 2015;
Santagati and Melodia, 2016; Roy et al., 2017; Bai et al., 2020) and open
source tools (Aud, 2023; GGw, 2023; qui, 2023b) have explored how to transmit
data over both sound and ultrasound or inaudible audio frequencies, i.e.,
above 18kHz. Original studies (Ka et al., 2016; Lee et al., 2015; Santagati
and Melodia, 2016) focus on the near-ultrasound band (i.e., 17-22kHz) and
achieve overall low throughput at variable distances: 15bps (up to 25 meters)
(Lee et al., 2015), 16bps (2.7 meters) (Ka et al., 2016), and 2.76kbps (1
meter) (Santagati and Melodia, 2016). BackDoor (Roy et al., 2017) achieves
higher speed (4kbps and up to 1 meter) by leveraging the non-linearity in
microphone hardware to create a “shadow” in the audible frequency range.
BatComm (Bai et al., 2020) further expands on the BackDoor idea by using
orthogonal frequency division multiplexing (OFDM (Li and Stuber, 2006)) to
transmit data over multiple orthogonal channels with an ultrasound frequency
carrier. Batcomm demonstrates an overall much higher throughput than BackDoor:
47kbps (at 10 centimeters) and 17kbps (at 2.3 meters).

Among open source tools, AudioQR (Aud, 2023) works in the near-ultrasonic
frequency band (17.5-19.5kHz) and can reach low speeds of about 100 bps while
supporting long distances (up to 150 meters). GGwave (GGw, 2023) is a tiny
data-over-sound library implementing a transmission protocol based on
frequency-shift keying (FSK (Watson, 1980)) which can reach up to 128 bps over
short distances. Finally, Quiet (qui, 2023b) enables data over both audible
and inaudible frequencies, as well as different modulations such as 1024-QAM
(Webb and Hanzo, 1994) and gmsk (Doelz and Heald, 1961). Quiet claims audible
transfers at 7 kbps over the air, and up to 64kbps in cases where two devices
are connected over an audio jack cable.

BatComm is an interesting approach for SONIC, but it is not open source and
could not be shared by the authors upon our request. AudioQR is a solid
product but not a good fit for SONIC since it sacrifices transmission speed
for high distance, while we target very low “air distance”, e.g., some phones
directly embed an FM receiver (Figure 3). With this respect, GGwave and Quiet
are better candidates for SONIC; we choose Quiet due to its higher performance
and flexibility.

Figure 2. Visualization of the FM spectrum.

_Innovative Usage of FM Radio:_ To the best of our knowledge, SONIC is the
first system which uses FM radio to disseminate Web content. Further, SONIC
combines the FM radio with the SMS infrastructure to provide both a downlink
and an uplink. Few other systems have proposed innovative usage of FM radio as
a downlink. RevCast (Schulman et al., 2014) leverages the broadcast nature of
FM radio for certificate revocation, i.e., the act of invalidating a TLS/SSL
certificate before the validity period expires. RevCast relies on Radio Data
System (RDS or RDBS in the US), a communications protocol for embedding small
amounts of digital information in FM radio broadcasts. Both RDS and RBDS carry
data at 1,187 bits per second on a 57 kHz subcarrier, as shown in Figure 2.
The authors show, using a 3 kW commercial radio station and an RDS-enabled
smartphone, that RevCast can deliver complete and timely revocation
information, anonymously.

(Bozomitu and Hutu, 2023; Bozomitu and Stoica, 2022) use FM radio broadcasting
to disseminate warning information to drivers. This solution leverages DSSS-
CDMA transmissions (Torrieri, 2005), where each vehicle’s geographical
position is used as a CDMA key to decode the relevant image. The authors
validate their solution using a combination of simulation (MATLAB) and
experimental setup (USRP devices (USR, 2023)) and show data rates of up to 35
kbps. Finally, in 2003 Microsoft used FM subcarrier signals to turn ordinary
gadgets into smart gadgets. MSN Direct (MSN, 2023) was a subscription network
that sent short text updates over DirectBand (see Figure 2), i.e., the 67.65
kHz subcarrier leased by Microsoft from commercial radio broadcasters. This
subcarrier delivers about 12 kbit/s of data per tower, for over 100 MB per day
per city. MSN Direct has found some success in delivering traffic
notifications and weather forecasts to Garmin GPS devices. However, it mainly
suffered from: 1) competition with cellular broadband; 2) downlink only
communication. Microsoft ended the service in 2012.

##  3\. SONIC Design

This Section designs SONIC (SOund NIC, or network interface controller), a
technology which relies on FM broadcasting to provide access to simplified
webpages encoded over sounds. The remainder of this section is organized as
follows. We first provide an overview of SONIC. Next, we dive into the design
of its key components.

###  3.1. Workflow

Figure 3 visualizes how SONIC works. Each mobile phone showcases a potential
SONIC user with different capabilities. User-B owns a smartphone equipped with
a Qualcomm chip mounting an FM receiver, which is popular in developing
regions (sna, 2023). User-A owns a smartphone with no usable FM receiver, but
(s)he is in the proximity of a classic radio, e.g., at home or in the car.
Both users can receive SONIC data, i.e., simplified webpages encoded over
sounds, but cannot request a specific webpage due to their lack of SMS
service.

User-C connects her phone to an FM radio via the audio jack for higher
performance (see Section 2) and also pays for Short Message Service (SMS).
User-C can both receive and request webpages. In the figure, user-C is
interested in news from cnn.com. This is achieved via an SMS to a SONIC
provided number (1) which triggers the generation of a simplified webpage for
cnn.com (2), e.g., the landing page, and its broadcasting over the FM radio
(3)(4), so that user-C (as well as user-A and user-B) will eventually receive
it (5).

_SONIC Server:_ It is responsible for generating simplified webpages to
broadcast via FM radio. We assume that the FM radio infrastructure consists of
multiple transmitters (and frequencies) at different locations, with some form
of Internet access. Accordingly, the FM transmitters can receive simplified
webpages to be encoded via sound, and then transmit them. A central SONIC
server is responsible to produce such webpages and inform the respective
transmitters.

Figure 3. User-C requests a webpage via SMS (1). The SONIC server fetches and
renders it into a WebP image (2), then passes it to an FM transmitter (3) for
broadcast via sound (4). The webpage is delivered to user-C and any other
device currently listening to the radio (5).

The SONIC server produces simplified webpages according to user requests.
Further, it maintains a list of the most popular websites in a region that are
preemptively pushed to users in an attempt to improve their experience. For
example, popular news sites can be pushed early in the morning.

_SONIC Client:_ As visualized in Figure 3, users access SONIC using different
hardware configurations. The minimum configuration implies a smartphone and
access to an FM radio, either over the air or via an audio jack, which
provides the downlink. An SMS service is also needed for users interested in
having access to the uplink, e.g., request a specific webpage or query a
search engine. Software-wise, SONIC runs as a standalone user space
application we describe next.

The SONIC application allows to browse webpages previously received via the FM
radio and request new ones. Accordingly, the app shows a catalog of available
webpages, organized by content, popularity, and/or user interest. Within a
webpage, a user might be interested in visiting some internal pages by
following classic hyperlinks. If the requested internal page is locally
available, i.e., it was previously received via the FM radio, then the page
would instantly load. If not, an active uplink is required to request such a
page. Similarly, SONIC users with an active uplink can request additional
webpages not previously received, as well as send queries to search engines
(e.g., Google and Duckduckgo) and AI chatbots (e.g., chatGPT). Note that pages
requiring authentication, such as online banking and social media, are not
supported yet due to their privacy risk, as discussed in Section 3.4. SONIC
clients request new webpages, i.e., not previously received and locally
cached, via SMS. Each request contains the URL, e.g., cnn.com/index.html, and
the geographic location of the user. The latter is needed by SONIC server to
inform the proper transmitter along with its frequency, as discussed below. As
the request is received, the SONIC server produces a simplified version of the
webpage, either from its cache, e.g., if recently requested by another user,
or by directly accessing it. The simplified page is then transferred to the
radio transmitter, which can physically reach the current user’s location.
Meanwhile, SONIC server quickly responds to the user via SMS to acknowledge
the request, and provide an estimate on when the page will be received. When
the webpage is received, it is inserted in a cache with expiration date set
according to a time indicated by the server.

###  3.2. Simplified Webpage Creation

According to (web, 2023c), the average webpage size is around 2 MB for mobile
sites. Given the low speeds of data over sound, i.e., tens of kbps at best
(see Section 2), broadcasting 2 MB via SONIC might require tens of minutes.
Further, receivers might not be able to reconstruct the received page, given
that most Web components, like JavaScript, would break in presence of
unrecoverable errors.

It follows that we need a mechanism to: 1) greatly compress webpages, 2) make
webpages resilient to noise. Many solutions exist to reduce webpage sizes,
such as compression proxies (Google, 2019; web, 2023b), reader modes
(Ghasemisharif et al., 2019; saf, 2023), JavaScript cleaners (Chaqfeh et al.,
2020, 2022b, 2022a) and redundant code removal (Kupoluyi et al., 2022;
Malavolta et al., 2023). However, these solutions are still affected by noise
and would thus require a large amount of FEC, which implies dimensioning the
system for a worst-case receiver. Instead, we would like a solution whose
performance decreases as a function of the receiver’s RSSI, similarly to how
the audio quality is reduced for users with bad reception.

We took inspiration from the work in (Bozomitu and Hutu, 2023; Bozomitu and
Stoica, 2022), which shows how the quality of images transmitted over RDS
decreases as a function of a receiver’s RSSI. Accordingly, we propose to
transmit images of loaded webpages instead of actual Web files (html, js, css,
etc.). Such images achieve both our goals since they compress a page, e.g., a
2 MB page can be compressed as a few hundred KB image, and they are loss-
resilient, as despite missing pixels, users might still understand the content
provided.

DRIVESHAFT (DS) (Bhardwaj et al., 2018) is a system to speed up the mobile Web
by distributing crowdsourced screenshots of webpages. While the overall system
is quite different, e.g., it involves a complex mechanism to merge harvested
screenshots while stripping them of private information, SONIC could leverage
some of DS’s components, e.g., how to add interactivity to the screenshots.
Unfortunately, DS’s code is not available, and we could not experiment with
and integrate it with SONIC. We here discuss SONIC’s mechanism to form images
of webpages and its relationship with DS.

Figure 4. Preliminary performance evaluation of SONIC. (a) Frame loss rate as
a function of the over-the-air distance between FM receiver and a SONIC
client. “Cable” refers to a distance of zero, i.e., either an integrated FM
receiver on the phone or a jack audio cable connection. (b) CDF of the size of
images (WebP) of rendered webpages, assuming variable image quality (Q) and
pixel height (PH). (c) Evolution over time of the amount of data to be
broadcasted as a function of transmission rates and number of webpages (N).

_Interactivity:_ modern webpages allow user interaction either via simple
hyperlinks or with menus, search boxes, etc. Images are instead static by
definition. To allow some interactivity, (Bhardwaj et al., 2018) proposes to
build click maps, i.e., maps containing a list of ¡x,y¿ coordinates of where
an image is interactive. We adopt the same approach: as the user clicks on
such coordinates, SONIC informs the server (via SMS, if available) and
requests the next image, e.g., an internal page accessed via a hyperlink,
unless it is already available in the cache. Due to the more challenging
network conditions of SONIC, e.g., potentially seconds in uplink and minutes
in downlink, we limit the interactivity to hyperlinks only.

_Images Format:_ DS requires lossless png due to its need to desensitize and
merge crowdsourced screenshots. This is not a requirement for SONIC; we thus
resort to WebP (web, 2023a), a modern image format that provides superior
lossless and lossy compression. We capture images of webpages as WebP with 10%
quality, which significantly reduces the size while remaining acceptable, as
we evaluate in Section 4. These images are created with 1,080 pixels width,
and a maximum of 10k pixels height. The idea is to allow a user to “scroll”
down on an image, as commonly done on a webpage, while avoiding to waste
broadcasted data, given that user interest is lower for content below the
fold. Depending on the mobile phone screen resolution, and using the scaling
factor (i.e., mobile phone screen width / 1,080), the images are resized by
multiplying both the width and height with the scaling factor. The scaling
factor is also used to scale the coordinates of the click maps.

###  3.3. Sonic Data Transmission

Using the Quiet library (qui, 2023b), we create a new transmission profile
inspired by their “audible-7k-channel”. The new profile uses Orthogonal
Orthogonal Frequency-Division Multiplexing (OFDM) – a multi-carrier modulation
system where data is transmitted as a combination of orthogonal narrow-band
signals known as sub-carriers – with 92 sub-carriers. The data rates achieved
by this profile reach 10 kbps. Upon transmitting a rendered page, we first
divide the image vertically into multiple partitions, each with a width of 1
pixel. Each partition is then divided into fixed-sized frames of 100 bytes
each. Each frame carries a partition and a sequence number used to reassemble
the image on the receiver end. We further leverage the error detection and
correction schemes using: crc32 as the checksum, the inner Forward Error
Correction (FEC) scheme (v29), and an outer FEC scheme (rs8). These allow the
receiver to correct transmission errors.

In the case of lost frames, the SONIC receiver uses nearest neighbor pixel
interpolation (Rukundo and Cao, 2012) to correct missing pixels. Accordingly,
missing pixels are replaced with the value of their adjacent pixel,
prioritizing the left pixel given that the webpage consists mostly of text
read from left to right. In literature, more advanced and better performing
techniques exist to recover missing pixels in images (Stanković, 2014; Chai et
al., 2020; Qin et al., 2021), leveraging deep neural networks to learn the
patterns and structures of the image or leveraging sparsity and gradients in
the data to fill in the missing regions. These techniques are both memory- and
CPU-intensive, far beyond what a low-end mobile device can support today.

###  3.4. Discussion

_Incentives and Monetization:_ For users, the incentive is clear since they
get access to a simplified Web in areas where such content is currently
inaccessible. For SONIC providers, they could directly charge their users.
This can be challenging since, for example, downlink users are completely
passive leaving no trace to when any content is accessed. Alternatively, they
could bundle their service with an SMS service, thus offering a paid service
for users who can request content in real time, while being free for other
users. Anyway, the cost of broadcasting over the radio is constant regardless
of the number of “listeners”.

Finally, a more interesting monetization scheme arises when considering the
current business model of radio stations: increasing their user base to sell
more advertisements. SONIC represents a novel service that radio stations can
offer to attract more users, thus increasing their revenues via ads. Further,
ads can now also be integrated with webpages, expanding from audio only to
images.

_Privacy Concerns:_ In essence, SONIC functions similarly to Web acceleration
tools like Google AMP (Google, 2019) and WebLight (web, 2023b) which rewrite
the content before sending it to a user. To do so, SONIC requires full
visibility on the requested URL, as well as the content being currently
accessed by a user. It follows that a SONIC server could collect enough
information to build user profiles and eventually violate user privacy.
Differently from these solutions, SONIC relies on a broadcast medium (the FM
radio), thus not knowing precisely how many users might be accessing a given
content. Indeed, no privacy violation is possible for downlink-only users who
can never request any content but just occasionally browse popular content
requested by other users in their area.

_Content Limitations:_ SONIC does not provide access to webpages behind a
login, such as a personal bank website or a social media account. Such access
is impossible for downlink-only users; for users with an uplink, they would
have to share their username and password to allow the SONIC server to
retrieve the required content. Further, the resulting page (e.g., showing the
balance of the user) would be broadcasted to potentially many users, adding to
the privacy issue.

Next, SONIC lacks support for video, which is used at large in today’s Web not
only by video streaming services but also by news websites, social media, etc.
Simply put, SONIC does not have enough bandwidth to support video streaming;
instead, videos are replaced by their thumbnails which are not “clickable”.
Similarly, SONIC transmits simplified (pre-rendered) webpages with no support
of complex visual effects normally achieved via either JS or CSS.

_Scalability:_ SONIC is a best effort system, aiming to offer few webpages to
a large number of users – anyone in the range of an FM radio – despite some
very small bandwidth. This is achieved by bending the current strictness of
webpages, and accepting some visual quality degradation as well as lack of
full interactivity. Further, the catalog of webpages to be served has to be
small (see Figure4(c)) and thus properly curated to offer interesting and
useful content to its users.

##  4\. Preliminary Evaluation

_Methodology:_ We build an FM transmitter using a Raspberry Pi, a 20cm wire
acting as an antenna connected to GPIO pin 4 of the Pi, and the code from
(git, 2023), which uses the general clock output to produce frequency
modulated radio communication in the range from 1MHz to 250MHz. We use 93.7MHz
since it is unused at our location. For data transmission, we use the Mono
channel of the FM baseband (30Hz to 15KHz, see Figure 2) with a carrier center
frequency of 9.2KHz. We envision that other bands can be used to increase the
data rate, e.g., using the left and right band of the Stereo channel, or even
the DARC band. We left this exploration as future work. As FM receivers, we
consider the scenario showcased in Figure 3. User-B leverages the internal FM
tuner of a Xiaomi Redmi Go (red, 2023), and a pair of headphones as an
antenna. User-A is another Redmi Go receiving sound from a nearby FM radio
over the air. Finally, User-C is a Redmi Go connected to the same FM radio but
using the audio jack. We ensure high RSSI between transmitter and receiver.

For encoding data over sound, we use Quiet (qui, 2023b) as discussed in
Section 3.3. For decoding, we develop an Android application extending the
sample application (qui, 2023a) from Quiet. We approximate user-B using the
NextRadio app (nex, 2023) to receive the FM radio signal and a jack cable to
act both as an antenna and to share the received sound to a second device
which runs the SONIC app. In the future, we will integrate FM radio receiving
within the SONIC app.

For the content to be transmitted, we assume a deployment in Pakistan.
Accordingly, we selected the 25 most popular Pakistani websites from the
Tranco list (Le Pochat et al., 2019) filtered using the .pk domain name. For
each landing page, we select three random internal pages, resulting in a total
of 100 webpages (25 landing, and 75 internal). We rendered these 100 pages in
Chrome on hourly basis for three days, while generating variable quality
images of the rendered webpages.

_General Results:_ Figure4(a) shows the frame loss rate, at the receiver as a
function of the distance between the phone and the receiving radio. “Cable”
refers to a scenario where the receiver is directly connected to the FM radio,
either using the internal FM tuner (User-B in Figure 3) or an actual cable
(User-C in Figure 3). Each experiment is repeated 10 times, and we assume high
RSSI (-70 db or higher) at the FM receiver. The figure shows no frame loss
recorded over cable, and up to 10-20% frame losses (at the median) when
considering about one meter of over-the-air communication between a SONIC-
enabled phone and FM receiver. The loss rate growth is not completely linear
with the increased air distance, as the alignment between speaker and
microphone also has a significant impact. We did not control for this
variable, as SONIC users would likely not do so as well. We also observe a
100% loss rate at distances above 1.1m.

Figure 1 visualizes the impact of 10% losses. Overall, the impact is
significant but tolerable, unless unlucky scenarios where losses are
concentrated in important parts of the webpage, like title and text. In our
early prototype, each portion of an image is transmitted equally; one
optimization consists of adopting a dynamic scheme with higher error
protection for important parts of an image/webpage. Nevertheless, we envision
that SONIC users would mostly rely on their phone’s internal FM tuner – or a
cable connection to a radio – to improve their performance and minimize lost
frames.

Figure 4(b) shows the Cumulative Distribution Function (CDF) of the size of
images (WebP) of rendered webpages assuming variable image quality (Q). WebP
image quality is defined on a scale from 0 (worst) to 95 (best). The figure
also reports the pixels height (PH), either “none” (i.e., maximum length of
the webpage loaded) or cropped at 10K pixels (see Section 3.2). Assuming a low
quality of 10, most webpages can be compressed to less than 200 KB, which
instead requires 700 KB at a high quality of 90. For SONIC, given the
challenging network conditions of the FM radio, we opt for a low quality of 10
given that no significant image degradation is observed. The figure also shows
that cropping to 10k pixels saves about 100 KB for 75% of the webpages. The
tails of the CDFs show images with twice the size of the 90th percentile,
e.g., 500 KB versus 250 KB when considering Q equal to 10 and PH equal to 10
k. These images can take significant time to be delivered, e.g., up to 6/7
minutes if assuming a single delivery frequency and a 10 kbps rate (see
Section 3.3), and might thus require some further optimizations.

Figure 5. Distribution of median user ratings (0-10 Likert scale) per top 50
Pakistani webpages, for question-b (plain) and question-a (hatched), with and
without pixel interpolation (orange and blue, respectively).

Finally, Figure 4(c) shows the evolution over time of the amount of data
broadcasted with SONIC assuming the above 100 Pakistani webpages, and the
current rate we have verified (10kbps) as well as 20 and 40 kbps which can be
achieved via multi-frequency (see Section 3). Note that we truncated the
figure at two days – despite three days of data – since the pattern repeats
and it helps improve its visibility.

Figure 4(c) shows that, with the current transmission rate (10 kbps), SONIC
can only work in broadcast mode. In fact, the amount of data to be sent – due
to variation in the supported webpages – rarely reaches zero (for which a rate
of 20 or 40 kbps is required). However, SONIC is scalable, meaning that the
amount of data to be sent does not grow indefinitely.

_Variable RSSI:_ We evaluate SONIC’s frame losses across various levels of
RSSI (Received Signal Strength Indication). RSSI measures signal strength in
decibels, typically ranging from 0 (strongest) to -120 (lowest). FM requires
RSSI comprised between -65 and -80 dB; e.g., radio stations in our area
exhibit RSSI between -70 and -80 dB.

We utilize the TR508 FM Transmitter (Retekess, [n. d.]), which supports
transmissions up to 1 km. We pair the SONIC client in “cable” mode (i.e., with
no additional frame loss rate, as shown in Figure 4(a)) with the Real FM Radio
app (Veluga, [n. d.]), which records RSSI values. We broadcast on an empty FM
frequency and manually explore distances between transmitter and receiver to
observe RSSI signals within the -65 to -90 dB range. At approximately 5 dB
intervals, we transmit a single webpage up to 10 times and measure SONIC’s
frame loss rate. For the RSSI range from -65 to -85 dB, we consistently
observe no frame losses. For the -85 to -90 dB range, we record a fluctuating
frame loss rate between 2 and 15%. As expected (Sonicwall, [n. d.]), for RSSI
below -90 dB, we are unable to receive any frames.

_User Study:_ To assess the impact of losses on webpage readability, we create
screenshots of the top 50 Pakistani webpages (according to Tranco (Le Pochat
et al., 2019)) with synthetic variable losses (5%, 10%, 20%, and 50%). Missing
pixels are either shown as dark or corrected using nearest neighbor pixel
interpolation (see Section 3.3). This results in 400 screenshots (50 pages
$\times$ 4 loss rates $\times$ 2 approaches, i.e., with and without pixel
interpolation). We then recruit 151 students from a university in Pakistan to
evaluate 20 randomly selected screenshots, thus averaging at least 7 ratings
per screenshot.

Students rate screenshots on a Likert scale from 0 to 10 based on two
questions: a) Indicate your perception of content understanding in the above
image (0 = extremely unclear, 5 = neutral, and 10 = extremely clear); and b)
Rate the readability of the text in the above image considering the level of
noise present (0 = very difficult to read, 5 = neither easy nor difficult, and
10 = very easy to read). Figure 5 shows boxplots of the median rating per page
for both questions (plain for question-b and hatched for question-a),
differentiating whether pixel interpolation is used (orange) or not (blue).
Overall, the figure demonstrates the benefits of pixel interpolation to
enhance both text readability and content comprehension, improving the rating
by at least one point regardless of the loss rate. For example, even at a loss
rate of 20%, observed at a distance of 1.1 meters and above (see Figure 4(a)),
pixel interpolation achieves a median content readability score of 7 (somewhat
clear understanding). Text readability is more susceptible to losses, but
still acceptable even with 20% losses.

## References

  * (1)
  * web (2023a) 2023a.  An image format for the Web.  https://developers.google.com/speed/webp.
  * qui (2023a) 2023a.  Android app built with Quiet which allows o pass data through the speakers of an Android device.  https://github.com/quiet/org.quietmodem.Quiet.
  * Aud (2023) 2023\.  AudioQR.  https://github.com/jamesonrader/AudioQR.
  * goo (2023) 2023\.  Expanding internet connectivity with stratospheric balloons.  https://x.company/projects/loon/.
  * aqu (2023) 2023\.  Facebook Halts Aquila, Its Internet Drone Project.  https://www.nytimes.com/2018/06/27/technology/facebook-drone-internet.html.
  * GGw (2023) 2023\.  GGwave.  https://github.com/ggerganov/ggwave.
  * fac (2023) 2023\.  High altitude connectivity: The next chapter.  https://engineering.fb.com/2018/06/27/connectivity/high-altitude-connectivity-the-next-chapter/.
  * web (2023b) 2023b.  Load mobile pages faster with Web Light.  https://support.google.com/websearch/answer/9836344?hl=en.
  * MSN (2023) 2023\.  MSN Direct.  https://en.wikipedia.org/wiki/MSN_Direct.
  * nex (2023) 2023\.  NextRadio Free Live FM Radio.  https://play.google.com/store/apps/details?id=com.nextradioapp.nextradio&hl=en_US&gl=US.
  * qui (2023b) 2023b.  Quiet modem project.  https://github.com/quiet/quiet.
  * rad (2023) 2023\.  Radio: The universal medium that leaves no one behind.  https://news.un.org/en/story/2022/02/1111882.
  * saf (2023) 2023\.  Safari Reader Mode.  https://support.apple.com/guide/safari/hide-ads-when-reading-sfri32632/mac.
  * sna (2023) 2023\.  Snapdragon 835 Mobile Platform.  https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-835-mobile-platform.
  * sta (2023) 2023\.  Starlink.  https://starlink.com/.
  * USR (2023) 2023\.  Universal Software Radio Peripheral.  https://www.ettus.com/all-products/un210-kit/.
  * git (2023) 2023\.  Use the Raspberry Pi as an FM transmitter. Works on every Raspberry Pi board.  https://github.com/markondej/fm_transmitter.
  * web (2023c) 2023c.  Web Almanac.  https://almanac.httparchive.org/en/2022/.
  * red (2023) 2023\.  Xiaomi Redmi Go.  https://www.gsmarena.com/xiaomi_redmi_go-9534.php.
  * Arena (2023) GSM Arena. 2023.  Xiaomi Remi Go.  https://www.gsmarena.com/xiaomi_redmi_go-9534.php.
  * Bai et al. (2020) Yang Bai, Jian Liu, Li Lu, Yilin Yang, Yingying Chen, and Jiadi Yu. 2020.  BatComm: enabling inaudible acoustic communication with high-throughput for mobile devices. In _Proceedings of the 18th Conference on Embedded Networked Sensor Systems_. 205–217.
  * Bhardwaj et al. (2018) Ketan Bhardwaj, Ada Gavrilovska, Moritz Steiner, Martin Flack, and Stephen Ludin. 2018.  DRIVESHAFT: Improving Perceived Mobile Web Performance.  _arXiv preprint arXiv:1809.09292_ (2018).
  * Bozomitu and Hutu (2023) Radu Gabriel Bozomitu and Florin Doru Hutu. 2023.  Drivers’ Warning Application Through Personalized DSSS-CDMA Data Transmission by Using the FM Radio Broadcasting Infrastructure.  _IEEE Access_ 11 (2023), 11711–11731.
  * Bozomitu and Stoica (2022) Radu Gabriel Bozomitu and Ştefan Corneliu Stoica. 2022.  A Robust Radiocommunication System for FM Transmission Based on Software Defined Radio Technology. In _2022 IEEE 28th International Symposium for Design and Technology in Electronic Packaging (SIITME)_. IEEE, 78–81.
  * Chai et al. (2020) Xintao Chai, Hanming Gu, Feng Li, Hongyou Duan, Xiaobo Hu, and Kai Lin. 2020.  Deep learning for irregularly and regularly missing data reconstruction.  _Scientific Reports_ 10, 1 (24 Feb 2020), 3302.  https://doi.org/10.1038/s41598-020-59801-x
  * Chaqfeh et al. (2022a) Moumena Chaqfeh, Russell Coke, Jacinta Hu, Waleed Hashmi, Lakshmi Subramanian, Talal Rahwan, and Yasir Zaki. 2022a.  Jsanalyzer: A web developer tool for simplifying mobile web pages through non-critical javascript elimination.  _ACM Transactions on the Web_ 16, 4 (2022), 1–31.
  * Chaqfeh et al. (2022b) Moumena Chaqfeh, Muhammad Haseeb, Waleed Hashmi, Patrick Inshuti, Manesha Ramesh, Matteo Varvello, Lakshmi Subramanian, Fareed Zaffar, and Yasir Zaki. 2022b.  To Block or Not to Block: Accelerating Mobile Web Pages On-The-Fly Through JavaScript Classification. In _Proceedings of the 12th International Conference on Information and Communication Technologies and Development, ICTD 2022, Seattle, USA, June 27-29, 2022 (accepted)_.
  * Chaqfeh et al. (2020) Moumena Chaqfeh, Yasir Zaki, Jacinta Hu, and Lakshmi Subramanian. 2020.  JSCleaner: De-Cluttering Mobile Webpages Through JavaScript Cleanup. In _Proceedings of The Web Conference 2020_. 763–773.
  * Doelz and Heald (1961) Melvin L Doelz and Earl T Heald. 1961.  Minimum-shift data communication system.  US Patent 2,977,417.
  * Ghasemisharif et al. (2019) Mohammad Ghasemisharif, Peter Snyder, Andrius Aucinas, and Benjamin Livshits. 2019.  Speedreader: Reader mode made fast and private. In _The World Wide Web Conference_. 526–537.
  * Google (2019) Google. 2019.  AMP is a web component framework to easily create user-first web experiences - amp.dev.  https://amp.dev.  Accessed: 2019-05-05.
  * ITU ([n. d.]) ITU. [n. d.].  Facts and Figures 2021: 2.9 billion people still offline.  https://www.itu.int/hub/2021/11/facts-and-figures-2021-2-9-billion-people-still-offline/.
  * Ka et al. (2016) Soonwon Ka, Tae Hyun Kim, Jae Yeol Ha, Sun Hong Lim, Su Cheol Shin, Jun Won Choi, Chulyoung Kwak, and Sunghyun Choi. 2016.  Near-ultrasound communication for tv’s 2nd screen services. In _Proceedings of the 22nd Annual International Conference on Mobile Computing and Networking_. 42–54.
  * Kupoluyi et al. (2022) Jesutofunmi Kupoluyi, Moumena Chaqfeh, Matteo Varvello, Russell Coke, Waleed Hashmi, Lakshmi Subramanian, and Yasir Zaki. 2022.  Muzeel: assessing the impact of JavaScript dead code elimination on mobile web performance. In _Proceedings of the 22nd ACM Internet Measurement Conference_. 335–348.
  * Le Pochat et al. (2019) Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczyński, and Wouter Joosen. 2019.  Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation. In _Proceedings of the 26th Annual Network and Distributed System Security Symposium_ _(NDSS 2019)_.  https://doi.org/10.14722/ndss.2019.23386
  * Lee et al. (2015) Hyewon Lee, Tae Hyun Kim, Jun Won Choi, and Sunghyun Choi. 2015.  Chirp signal-based aerial acoustic communication for smart devices. In _2015 IEEE Conference on Computer Communications (INFOCOM)_. IEEE, 2407–2415.
  * Li and Stuber (2006) Ye Geoffrey Li and Gordon L Stuber. 2006.  _Orthogonal frequency division multiplexing for wireless communications_.  Springer Science & Business Media.
  * Malavolta et al. (2023) Ivano Malavolta, Kishan Nirghin, Gian Luca Scoccia, Simone Romano, Salvatore Lombardi, Giuseppe Scanniello, and Patricia Lago. 2023.  JavaScript Dead Code Identification, Elimination, and Empirical Assessment.  _IEEE Transactions on Software Engineering_ (2023).
  * Qin et al. (2021) Zhen Qin, Qingliang Zeng, Yixin Zong, and Fan Xu. 2021.  Image inpainting based on deep learning: A review.  _Displays_ 69 (2021), 102028.  https://doi.org/10.1016/j.displa.2021.102028
  * Retekess ([n. d.]) Retekess. [n. d.].  TR508 FM Transmitter Low Power Broadcast Station for Drive-in Church School.  https://www.retekess.com/tr508-fm-transmitter/.
  * Roy et al. (2017) Nirupam Roy, Haitham Hassanieh, and Romit Roy Choudhury. 2017.  Backdoor: Making microphones hear inaudible sounds. In _Proceedings of the 15th Annual International Conference on Mobile Systems, Applications, and Services_. 2–14.
  * Rukundo and Cao (2012) Olivier Rukundo and Hanqiang Cao. 2012.  Nearest Neighbor Value Interpolation.  _International Journal of Advanced Computer Science and Applications_ 3, 4 (2012).  https://doi.org/10.14569/IJACSA.2012.030405
  * Santagati and Melodia (2016) G Enrico Santagati and Tommaso Melodia. 2016.  A software-defined ultrasonic networking framework for wearable devices.  _IEEE/ACM Transactions on Networking_ 25, 2 (2016), 960–973.
  * Schulman et al. (2014) Aaron Schulman, Dave Levin, and Neil Spring. 2014.  RevCast: Fast, private certificate revocation over FM radio. In _Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security_. 799–810.
  * Sonicwall ([n. d.]) Sonicwall. [n. d.].  Wireless: SNR, RSSI and Noise basics of wireless troubleshooting.  https://www.sonicwall.com/support/knowledge-base/wireless-snr-rssi-and-noise-basics-of-wireless-troubleshooting/180314090744170/.
  * Stanković (2014) Isidora Stanković. 2014.  Recovery of Images with Missing Pixels using a Gradient Compressive Sensing Algorithm.  _ArXiv_ abs/1407.3695 (2014).  https://api.semanticscholar.org/CorpusID:15997634
  * Torrieri (2005) Don Torrieri. 2005.  _Principles of spread-spectrum communication systems_. Vol. 1.  Springer.
  * Veluga ([n. d.]) Vladislav Veluga. [n. d.].  Real FM Radio.  https://github.com/vladislav805/RFM-Radio.
  * Watson (1980) Bob Watson. 1980.  FSK: signals and demodulation.  _Watkins–Johnson Company Tech–notes_ 7, 5 (1980).
  * Webb and Hanzo (1994) William T Webb and Lajos Hanzo. 1994.  _Modern Quadrature Amplitude Modulation: Principles and applications for fixed and wireless channels: one_.  IEEE Press-John Wiley.