BeaconCast Practical Information
Dissemination via WiFi beacons
Yan Pu1

Akihiro Nakao1

Shogo Ando1

Yosuke Tsukajima1

Tomoki Ban1

Graduate School of Interdisciplinary Information Studies, The University of Tokyo1

1Introduction

With the advance of 802.11 wireless (Wi-Fi) networking, devices equipped with Wi-Fi have become
pervasive in our daily life. Especially, the mobile
clients nowadays depend strongly on Wi-Fi for the Internet connectivity. Although more and more smart
phones transmit data via 3G wireless connectivity, thethroughput of the 3G communication is limited andits average charge is often higher than Wi-Fi’s. Besides, even when the 3G connectivity available, there
are cases where Wi-Fi is the essential communicationmeans: in Tokyo, the carrier does not allow an iPhone
user to download an application larger than 25MB via
3G connections so one must use Wi-Fi for that purpose.
However, as the number of Wi-Fi hotspots is increasing drastically, we are facing an awkward situation where we must choose which hotspot to use froma tediously long list of hotspots. As a solution to such aproblem, IEEE has recently released a new amendmentcalled 802.11u. It aims to give Wi-Fi hotspots the ability to broadcast themselves with the information of its
network provider and the services it provides. Clientsof 802.11u are allowed to make automatic association,for example, by the authentication information embedded in their SIM cards. Another important feature of
802.11u is that a Wi-Fi base station advertises whatkind of services are provided through its SSID. A client
can then choose a speciﬁc hotspot to associate withdepending on the circumstances. For example, in anemergency, a client can associate with the hotspot thatprovides evacuation direction services, etc. Althoughusers no longer need to choose a network to associatefrom the list of SSIDs if they use 802.11 features, theassociation is still required. In case of emergency oradvertisement, we may just need one-way push communications and association must not be a necessity
here.
In this paper, we propose BeaconCast making useof SSIDs for disseminating information without association. Although the existing work [1] has attempted
to broadcast information using SSIDs in Wi-Fi beacon signals, it only supports text messages. Their proposal is not practical for deployment and especially, its
wide-area deployment is not in their scope. We propose an innovative approach that broadcasts any kind

User

Broadcast Area

User
User

Fetch Data

Broadcast Area

WiVi AP

Send Data

User
Internet

Administrator

Any Source(E.g. Twitter)

WiVi AP
User

WiVi AP

Broadcast Area

User

Fig. 1 Deployment of Example Implementationof data. We demonstrate two example scenarios where
BeaconCast is applicable. Our example applications
are deployed in WiVi that is the wireless extension toCoreLab [5]. Fig.1 shows how BeaconCast is utilized
in a wide area network.
2

Mechanism of Information Broadcasting in
BeaconCast
As we mention above, BeaconCast aims to provide
a solution for broadcasting information without associations. Besides, for a practical deployment, broadcasting and retrieving data is done without changing
anything of the current physical network stack. Thisimplies that we have to utilize the SSID ﬁeld of a beacon frame for broadcasting data before the dedicatedstandard for non-associated data broadcasting of WiFi
is proposed. At the broadcasting side, if informationcan be embedded into SSIDs, then no modiﬁcation ofdriver is necessary for a client to retrieve the data since
API can be deﬁned for application to embed such information.
However, there are three important problems that wehave to resolve when we make use of SSID. First, theSSID ﬁeld of a beacon frame provides only 32 bytes for
information embedding, which means integrated information data should be split into chunks for broadcasting. Second, if data is embedded directly into the SSID
ﬁeld, the SSID may be represented as non-readable
ASCII characters. Our preliminary experiments showthat a client may fail to return such SSIDs. At last, another problem is that clients must have a way to recognize which SSIDs should be collected and processed fordata retrieving. In other words, this means that thereshould also be indication for the frames that contain
information embedded in the SSID ﬁeld. We adopt thefollowing approaches to solve these problems.
Information Data Encoding and Decoding.
To solve the ﬁrst problem, we pre-process information
data with Base64 encoding. After this step of preprocessing, all the data can be represented by readable
characters. However, as we mentioned above, although
identiﬁcation information should also be included into
the SSID ﬁeld, we leave this part unencoded for readable characters to be used as indication of information
embedding.
Data Splitting Data splitting is performed after
data encoding. Besides the indication of information
embedding, sequence number is also necessary for data
to be combined and retrieved. Also, for informing thetotal number of data chunks to be combined, we sendmore frames with the total number of data chunks tobe combined.
SSID Recognition and Data Retrieving At thereceiver side all the SSIDs with the appropriate indication are collected into a buﬀer. A receiver decides
whether data retrieving can be started after the download of data completes. Although in our prototype
implementation, we use 4-byte indication and 2-bytesequence number, we do not ﬁx the format of data
embedding in SSIDs. We take all above approaches
as the common procedure for data broadcasting while
the speciﬁcation for implementation can be adjusted
according to diﬀerent cases.
3Example Implementation of BeaconCast
In this section, we describe the example implementation for both broadcasting side and receiving side
respectively. We implement a receiver application thatcan be used for receiving either advertisement messages
or emergency messages with pointers to more speciﬁc
information such as the URLs to the advertisement oremergency information.
Broadcasting Side Description As mentioned
in Introduction, our example implementation of BeaconCast is deployed on WiVi, which oﬀers virtualized
Wi-Fi interfaces on each access point (AP). We can use
Hostapd[4] for realizing basic hotspot functionality oneach AP. In this case, we force Hostapd to keep reloading its conﬁguration ﬁle with information dynamicallyembedded into SSIDs. This is done by sending HUPsignals. Besides, Lorcon library [3] can be also used tocreate raw 802.11 frames directly.
Receiver Side Description A receiver application
is developed on an iPod touch device. Since the information sent by a hotspot is a text message, when anidentiﬁed SSID is received, the information is retrieved

Jump to The Map(a) Start Receiving(b) Pushing OK to(c) Map to The Bar

Accept Invitation

Fig. 2 Screenshots of the Pop-Up Message Receiver
Applicationand displayed directly as popup messages. Also, as
we mentioned above, the extra information as keys isused for fetching URL from pre-stored key-URL pairdictionary. We can then use the URL to show a direction guidance on the map. The screenshots of ourapplication are shown as Fig. 2We believe that our demo application is practical
for today’s millions of Wi-Fi equipped mobile phones.
As the real usage scenario, during an emergency circumstances, if only a user is within a hotspot’s broadcasting signal range, emergency notiﬁcations can be directly transmitted without association. Besides, there
is practically little limitation in the number of recipients of the emergency notiﬁcations as long as they arein the WiFi range.
4Conclusion
In this paper, we propose an innovative approach ofbroadcasting information by SSIDs of Wi-FI beacon
frames. We show the mechanism of BeaconCast andthen introduce applications using BeaconCast. For thefuture work, we are planning to evaluate performanceusing our prototype system and to improve the designand implementation of BeaconCast.
References[1] R. Chandra and al. et. Beacon-stuﬃng: Wi-ﬁ without associations. In Mobile Computing Systems andApplications, 2007. HotMobile 2007. Eighth IEEE
Workshop on, 2007.
[2] IEEE 802.11u.
http://standards.ieee.org/
findstds/standard/802.11u-2011.html, February 2011.
[3] Wright Joshua. http://802.11ninja.net/.
[4] Malinen Jouni.
hostapd/.

http://hostap.epitest.fi/[5] Akihiro Nakao and al. et. Corelab: an emerging
network testbed employing hosted virtual machinemonitor. In CoNEXT, 2008.