frac: design and implementation of an advertisement-based
TRANSCRIPT
FRAC: Design and Implementation of an
Advertisement-based Community Network Sharing
Framework
Lakshman Swaroop Babu
A thesis submitted to the faculty of the
Virginia Polytechnic Institute and State University
in partial fulfillment of the requirements for the degree of
Master of Science
in
Computer Engineering
Yaling Yang, Chair
Yiwei T. Hou
Patrick R. Schaumont
Jeffrey H. Reed
May 16, 2013
Blacksburg, Virginia
Keywords: ad-supported Wi-Fi, public Wi-Fi, hotspots, dd-wrt.
Copyright 2013, Lakshman Swaroop Babu
FRAC: Design and Implementation of an Advertisement-based
Community Network Sharing Framework
Lakshman Swaroop Babu
(ABSTRACT)
There has been an overwhelming interest in public Wi-Fi due to the increasing number of
mobile users and a growing perception that Wi-Fi provides better connection experience at
lower costs. Moreover, end users increasingly expect Wi-Fi to be free, thereby motivating
a strong transition in leading markets to provide free-to-the-end-user Wi-Fi. Providing
free internet to the users is a challenge as potential solutions must be self-sustainable and
provide sufficient financial returns. Framework for Advertisement-based Community Wi-Fi
access, called FRAC is a self-sustainable advertisement-based community network sharing
framework which has the competence to provide significant financial returns. FRAC provides
free internet access to its users by motivating Wi-Fi access point (AP) owners to share their
internet service for benefits. FRAC builds on privately or commercially-owned, existing Wi-
Fi infrastructure. The users accessing the internet using this framework provide a strong
customer base for online marketing and advertising which provides the revenue to sustain
this framework.
This thesis describes the design and implementation of a prototype of the FRAC system. The
design of key features of the framework such as user authentication, advertisement delivery,
quality of service, messaging and security, are described, based on which an overall design of
the framework is provided. The prototype developed includes a browser extension to support
browser-based devices like laptops, netbooks and embeddable software that can be installed
on wireless routers with Linux-based dd-wrt firmware.
Acknowledgments
I am grateful to my advisor, Dr.Yaling Yang for the her continued guidance, support and
motivation throughout my academic and professional endeavors. I also thank her sincerely
for her insights, suggestions and advice which motivated me to pursue this project. I would
like to thank my project team for their inputs, support and technical help. I would like
to thank Dr.Jeffrey Reed, Dr.Patrick Schaumont and Dr.Thomas Hou for serving in my
committee and for their valuable inputs and suggestions. I would like to thank my dear
friends whose support helped me complete my graduate work and without whom life would
not have been the same. Finally, I would like to thank my parents and my brother for their
never-ending love, unmatched support, great many sacrifices and their absolute confidence
in me.
iii
Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Leading Markets and Smart Phones . . . . . . . . . . . . . . . . . . . 5
1.3.2 Low Income Communities . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Emerging Markets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background 7
2.1 Chrome Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Online Advertising and Revenue Models . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Effective Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Revenue Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
iv
2.2.3 Ad Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 DD-WRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Cross-Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Browser Plugins and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Related Work 14
3.1 Protocols and Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Wireless Internet Service Provider roaming (WISPr) . . . . . . . . . 15
3.1.2 Wi-Fi CERTIFIED Passpoint . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3 802.1X & Extensible Authentication Protocol (EAP) . . . . . . . . . 16
3.1.4 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.5 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Wi-Fi sharing solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Hotspot management systems . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Network access control mechanisms . . . . . . . . . . . . . . . . . . . 21
3.2.4 Wifidog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.5 Chillispot & Coovachilli . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 FON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
v
3.3.2 Boingo and Google, enabling free-to-the-end-user Wi-Fi . . . . . . . . 24
4 Design Requirements 26
4.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Quality Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2 Additional Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Design 35
5.1 Architecture and Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.1 HOST AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.2 CLIENT APP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 FRAC Design Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 JSON Unified Messaging Protocol (JUMP) . . . . . . . . . . . . . . . 37
5.2.2 CLIENT Authentication Mechanism . . . . . . . . . . . . . . . . . . 39
5.2.3 Maintaining Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.4 Advertisement Delivery Mechanism (ADM) . . . . . . . . . . . . . . 41
5.2.5 CLIENT Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.6 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.7 Security and Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.8 Billing Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
vi
5.3 FRAC SERVER Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 HOST AP Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5 Browser-based CLIENT APP Design . . . . . . . . . . . . . . . . . . . . . . 58
6 Implementation 60
6.1 CLIENT APP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.1 Background Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.2 Extension UI/ Popup . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.3 Content Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.4 Enforcing Video Advertisements on CLIENT browser . . . . . . . . . 66
6.1.5 JavaScript Obfuscator . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2 HOST AP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.1 Implementation Features . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2.2 Router compatibility with dd-wrt . . . . . . . . . . . . . . . . . . . . 69
6.2.3 Cross Compiling & MIPSEL architecture . . . . . . . . . . . . . . . . 69
6.2.4 LibHTTPD Web-Server API . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.5 Implementing JUMP using JSON-C . . . . . . . . . . . . . . . . . . . 70
6.2.6 Wifidog Iptables API and Utility functions . . . . . . . . . . . . . . . 70
6.2.7 HTTPClient Web-Client API . . . . . . . . . . . . . . . . . . . . . . 71
7 Evaluation 72
7.1 Model Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
vii
7.2 Design Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3 Implementation Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8 Future Work 78
8.1 Future Work on FRAC Prototype Software . . . . . . . . . . . . . . . . . . . 78
8.2 App-based CLIENT APP Design . . . . . . . . . . . . . . . . . . . . . . . . 78
8.3 Plugins: NPAPI vs. NativeClient (NaCl) . . . . . . . . . . . . . . . . . . . . 79
8.4 Automatic Network Discovery and Selection . . . . . . . . . . . . . . . . . . 81
8.5 From Prototype Software to Production Software . . . . . . . . . . . . . . . 81
8.6 Effective Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9 Conclusion 83
Bibliography 84
Appendix 89
A JSON Unified Messaging Protocol 89
viii
List of Figures
1.1 FRAC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Chrome extension architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 802.1X Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 RADIUS Authentication and Authorization Flow . . . . . . . . . . . . . . . 19
3.3 Wifidog Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 CLIENT Authentication Mechanism . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Video Advertisement Delivery Mechanism . . . . . . . . . . . . . . . . . . . 42
5.3 Banner Advertisement Delivery Mechanism . . . . . . . . . . . . . . . . . . . 43
5.4 CLIENT Expiry Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 CLIENT Initiation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6 Initial Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7 Modified Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Proposed QoS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.9 FRAC SERVER design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
ix
5.10 CLIENT database example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.11 HOST database example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.12 HOST AP design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.13 Browser-based CLIENT APP design . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Working screen showing CLIENT APP with an video advertisement published
on the Chrome browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 CLIENT APP: Popup-based User Interface . . . . . . . . . . . . . . . . . . . 65
6.3 Current Tab Video Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1 Oveview of an App-based CLIENT APP design . . . . . . . . . . . . . . . . 79
8.2 Native Client Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
x
Chapter 1
Introduction
1.1 Motivation
Overwhelming interest in public Wi-Fi has created a global trend which has led to the
proliferation of public hotspots, community and municipal Wi-Fi deployments. The telecom
industry has become more bullish about investments into public Wi-Fi in recent times.
According to the survey conducted recently by Wireless Broadband Alliance (WBA) and
Informa Telecom & Media[1], around 43% of the telecom companies are positively open to
investments into public Wi-Fi. Furthermore, 18 of the world’s largest 20 telecom companies
have recently announced new initiatives to deploy their own Wi-Fi hotspot networks.
The accelerated momentum and support for public Wi-Fi can be attributed to the following
reasons. There is a whole new world of Wi-Fi enabled devices which include smartphones,
tablets, e-readers and consoles in the market today. This has created a significant impact
on the Wi-Fi usage behavior due to an increasing perception that Wi-Fi typically provides
better connection experience at much lower costs than mobile broadband services. The
number of mobile users using Wi-Fi has increased over the years. For example, ChinaMobile
saw an increase of Wi-Fi traffic by 102.5% year-on-year in H1 2012[1].
1
Lakshman Swaroop Babu Chapter 1. Introduction 2
This has led to drastic increase in Wi-Fi hotspots and public Wi-Fi deployments in major
cities and towns. Apart from these improvements, end users increasingly expect Wi-Fi to
be a free service. There has been a strong transition to provide free-to-the-end user Wi-Fi
in leading markets. Though these trends vary over different regions and markets, there is a
definite diminishing willingness to pay for Wi-Fi access.
Deploying public Wi-Fi networks and hotspots requires significant capital investment to
cover the cost of installation, operations, maintenance and service. Local governments, mu-
nicipalities, other organizations and companies which sponsor these Wi-Fi deployments are
pursuing various solutions to generate additional revenue to shape long-term sustainability
and maintenance of these networks.[2]
The problem we are trying to solve is to provide free public Wi-Fi to users while trying
to break-even on initial investments and operation costs for public Wi-Fi networks. In this
work, we propose an advertisement based public Wi-Fi framework called FRAC, to create a
self-sustainable public Wi-Fi network which provides free internet access to its users and has
the competence to provide significant financial returns. We take advantage of existing Wi-Fi
infrastructure such as wireless routers with internet service subscription, which are privately
or commercially owned. These internet access subscribers become part of our framework and
provide network access for free public use by sharing their excess bandwidth in exchange for
compensation. The users accessing the internet build a strong customer base for online
marketing and advertising through our framework.
1.2 Overview
FRAC is elaborated as “Framework for Advertisement-based Community Wi-Fi access”.
The key elements in our framework include CLIENTs, HOSTs and ADVERTISERs and the
INTERMEDIARY.
Lakshman Swaroop Babu Chapter 1. Introduction 3
Internet
HOST AP
HTTP
SERVER
HTTP
CLIENT
HOST AP HOST AP
CLIENT_APP CLIENT_APP CLIENT_APP
FRAC_SERVER
DB
DB server
AD server
Web Server
AP Firewall Router
Background
UI Popup
Content Script
AD
Displayed
Browser
Figure 1.1: FRAC Overview
CLIENT represents anyone who is interested to access free internet through our framework.
These clients connect to the host’s wireless access points via software portals installed on the
client. HOSTs represent subscribers who have internet access services from internet service
providers (ISPs) or other sources and are willing to share their excess internet bandwidth
with CLIENTs. We provide suitable compensations for the HOSTs in exchange for publish-
ing advertisements or other messages to the CLIENTs during their Internet access period.
ADVERTISERS represent any party interested to advertise, promote, send messages, get
consumer opinions or create an awareness about any product, service or feature using the
FRAC network. They buy advertising space on the framework to reach a captive audience
and they are the sponsors of the system. The organization which essentially coordinates be-
Lakshman Swaroop Babu Chapter 1. Introduction 4
tween HOSTs, CLIENTs and ADVERTISERs in this framework is the INTERMEDIARY.
The main source of the revenue comes from developing creative high value advertisement
models and promotion schemes, planning and management of the advertisement delivery
process which is handled by the INTERMEDIARY.
The elements in FRAC have to communicate with each other in a reliable manner for the
system to function. Standardized design and implementation is critical for this system to
scale and support more CLIENTs and HOSTs, and to address problems and concerns in this
framework which forms the basis of this work.
INTERMEDIARY uses a set of servers to perform its functions, we refer to these set of
servers as FRAC SERVER. CLIENTs/CLIENT device communicates with other elements
in the framework using a CLIENT APPLICATION (CLIENT APP) on the device (such as
smartphones, laptops). HOSTs install software on their wireless routers which enable them to
be a part of FRAC, these modified HOSTs devices are referred to as HOST APs in the frame-
work. ADVERTISERs publish their advertisements and promotions on the FRAC SERVER
which is delivered to the CLIENTs through the HOST APs. Figure 1 illustrates an overview
of this framework and how advertisements are delivered to the CLIENTs.
The impact of our framework is three fold which makes it self-sustainable:
• Providing free Internet access to CLIENTs.
• Providing benefits to HOSTs to share their superfluous internet bandwidth and deliver
advertisements to the CLIENTs.
• Providing an effective medium for online marketing and advertising for potential AD-
VERTISERs who pay for advertising space on our framework.
Lakshman Swaroop Babu Chapter 1. Introduction 5
1.3 Use Cases
In this section, we discuss some of the potential use cases for our proposed model.
1.3.1 Leading Markets and Smart Phones
Wi-Fi has become the primary form of connectivity for smartphone users globally. Based on
a recent survey conducted by Informa and mobidia [3][4], Wi-Fi accounts for around two-
thirds of the smart-phone originated data traffic globally. This provides a wide user base to
deploy our model in leading markets around the globe.
1.3.2 Low Income Communities
There have been many government and private efforts to provide internet globally as a
basic utility service to low income communities to improve their standard of living. But
these efforts lack self-sustainability and require significant capital investments and continued
financial requirements for day-to-day operations. This framework provides a self-sustainable
way which motivates subscribers to share their excess internet bandwidth with low income
groups.
1.3.3 Emerging Markets
In emerging markets like India, China and Brazil where customers are typically price sensi-
tive, Wi-Fi is the technology of choice for most users due to better connection experience at
lower costs. Our approach has immense potential as it reduces the initial deployment costs,
builds on existing infrastructure, offers free Wi-Fi service to users and offsets internet costs
for subscribers.
Lakshman Swaroop Babu Chapter 1. Introduction 6
1.4 Thesis Organization
The rest of this thesis is organized as follows. Chapter 2 presents the background concepts
and theory. Chrome extension architecture, online advertising and revenue models, iptables,
DD-WRT firmware, cross-compilers and web services are elaborated. Chapter 3 discusses the
related work on Wi-Fi Sharing Solutions, Protocols and Standards and Initiatives. Chapter
4 defines a broad outline of the FRAC system based on which we formulate the important
functions and quality requirements to be considered in the FRAC design. Chapter 5 examines
the design of the main features in the FRAC system based on which the overall design of key
elements are provided. Chapter 6 presents the implementation of the prototype version of
the FRAC system. Chapter 7 provides an evaluation the FRAC system model, design and
implementation. Chapter 8 discusses the future work and enhancements to our model and
design. Chapter 9 concludes the thesis.
Chapter 2
Background
2.1 Chrome Extension
Chrome extensions are browser extensions, which are small software programs written in
HTML, JavaScript and Cascading Style Sheets (CSS) along with Chrome Application pro-
gramming interface (API) to enhance the functionality of the Chrome browser[5]. Extensions
are provided with Chrome APIs which provide tight browser integration. Further, they can
also use other standard web APIs such as JavaScript, Asynchronous JavaScript (AJAX),
JavaScript Object Notation (JSON). AJAX provides a way to exchange data with a server,
and update parts of a web page without reloading the whole page.
Extensions can interact with other web pages using content scripts. They can send cross-
origin AJAX HTTP requests to remote servers outside its origin whereas web pages are
limited to the same origin policy. They interact with browser features, detect browser events
and have an User Interface (UI). Each extension consists of a packaged folder which contains
a manifest file, HTML, CSS and JavaScript files and other required files such as image files.
7
Lakshman Swaroop Babu Chapter 2. Background 8
2.1.1 Manifest
The manifest file provides information about the extension such as version, name, type,
scripts and security policies. It describes how the extension is wired.
2.1.2 Architecture
Chrome extensions have a two layered structure. It has a background page which holds
the main logic of the extension. It can also contain other pages to support other functions
such as extension UI and content scripts. The background page can be persistent/always
open or event based. The UI pages are ordinary HTML pages, displayed in a popup or
a webpage. The views in UI are stateless and communicate with the background page to
retrieve information which is then displayed. Content scripts allow extensions to interact
with webpages, they are basically JavaScript code which are a part of every loaded page on
the browser and they execute on the context of the webpage. They can communicate with
the extension and load/inject scripts, data onto the webpage on the Chrome browser. Pages
within the extension can communicate easily by making direct function calls to each other
as they all execute in the same process. Chrome extensions allow easy storage of data using
web storage API such as localStorage and sessionStorage[5].
Lakshman Swaroop Babu Chapter 2. Background 9
Background Page
(background.html)
Popup/
Extension UI
UI/Popup.html
Content Script
(contentscript.js)
Figure 2.1: Chrome extension architecture
2.2 Online Advertising and Revenue Models
Online advertising is a rapidly growing industry which involves marketing, promoting prod-
ucts and services over the internet. The information and content published has many flexi-
bilities which include animations, dynamically mutable, location-based, behavioral-targeted,
user-interaction and it is not limited by location or time which has led to many different
types of online advertising.
2.2.1 Effective Advertising
We focus only on a few types of online advertising which include display advertising, video
marketing and interactive advertising which are related to this work. Display advertising
mainly consists of text, logos, and photographs such as banner ads and rich media ads.
Video marketing specializes in creating videos which influence user’s decision on a product.
Lakshman Swaroop Babu Chapter 2. Background 10
Interactive advertising is an emerging market which uses creative ideas and interactive media
to communicate with consumers and promote brands, services. According to the Internet
Advertising Bureau (IAB), display-based advertising is still quite popular and dominates
the advertisement industry which includes banner ads and video ads [9]. Further, IAB
also reports a tremendous growth in mobile advertising in the United States indicating the
emerging advertising market in smartphones, tablets and other smart devices.
Advertisement formats, size and placement play an important role in making advertisements
effective. Popular advertisement formats include floating ads, pop-ups, frame-based ads[10]
.
2.2.2 Revenue Models
Revenue models describe how businesses make money by online advertising. The common
pricing models in display advertising and video marketing include Cost per Mille (CPM),
Cost per View (CPV), Cost per Click (CPC), Cost per Action (CPA) and effective CPM.
CPM is the cost per thousand impressions or loads of an advertisement. CPM is a popular
and effective pricing model for video ads, as advertisers pay for exposure of their message
to a specific audience. CPV is the cost for each unique user view of an advertisement. CPC
represents the cost when a user clicks on an advertisement and is redirected to the advertiser’s
website[11]. CPA is performance-based and advertisers only pay for the number of users
who complete a transaction. IAB’s revenue report for HY2012 indicates that performance-
based pricing models such as CPC, CPA are preferred revenue models [9] but there is still
a substantial market for impression-based pricing models such as CPM. Further, IAB also
points out that hybrid pricing models have diminished in popularity. This provides an
overview of the trends in the online advertising industry.
Lakshman Swaroop Babu Chapter 2. Background 11
2.2.3 Ad Serving
The technology and services involved in serving, counting and choosing advertisements for
optimizing profits and evaluating the progress of advertisement campaigns constitute ad
serving. An ad server is typically a web server which is responsible for performing these
functions. The content of the ad server is updated constantly to dynamically serve new
advertisements. Multiple publishers upload their advertisements to this central ad server
and they can track the distribution of their advertisements across the web.
2.3 Iptables
Linux systems have a host based firewall called Netfilter. The management of this Linux
firewall is controlled using the iptables program, which handles packet filtering rules that
can be enforced or removed from the Firewall. Iptables is used to set up, maintain and
inspect the firewall, and provide packet filtering and network address translation (NAT) for
the Linux kernel. It can perform stateful packet inspection, filter packets based on MAC
address (media access control), provides system logging features and rate-limiting features
at improved speed and reliability. Iptables are used to handle IPv4 packet filtering and
ip6tables are used for IPv6 packet filtering.[7][6]
All the packets are inspected by iptables and pass through a set of queues or tables. Several
tables can be defined to control certain types of packets. Each of these tables contains a set
of built-in or user defined chains or rules which match a set of packets. These tables and
associated chains process the packet as per the rules specified.
iptables -A INPUT -s 0/0 -i eth0 -d 192.168.1.1 -p TCP -j ACCEPT
This iptables command allows the firewall to accept TCP packets from any IP address to IP
address 192.168.1.1 coming into interface eth0.
Lakshman Swaroop Babu Chapter 2. Background 12
iptables -A INPUT -s 0/0 -i eth0 -d 192.168.1.1 -p TCP -j DROP
Similarly for the next command, the same set of packets are the dropped at eth0.
2.4 DD-WRT
DD-WRT is a Linux-based open source firmware compatible with a great variety of wireless
routers and embedded devices [14]. DD-WRT is one among the most popular third party
firmware projects which can replace pre-installed firmware on many commercial routers in the
market. It provides easy handling and several features such as IPv6 support, advanced QoS,
RADIUS authentication, VLAN support, daemon-based services, etc. within the framework
of the hardware platform used. DD-WRT allows us to customize the home router. Since it
is Linux-based, additional enhancements can be added using programs and scripts to extend
the functionality.
2.5 Cross-Compiler
A compiler is a software program that transforms source code into object code or binary,
and is executable. Compiler runs of a specific platform which is referred to as the HOST
platform, the platform on which the executable or binary file generated by the compiler runs
on is called TARGET platform. A native compiler runs on a platform and produces a binary
that can run on the same platform, i.e. HOST and TARGET are the same. When the HOST
and TARGET platforms are different, then the compiler is a cross-compiler[13].
Cross-compiling is used if the TARGET platform has very limited resources and cannot
install a native compiler or if the native compiler for that TARGET machine has limited
packages and features. In this work, MISPEL cross-compiler (MIPS architecture in little-
Endian format) is cross-compiled on x86 platform [12] to run software on routers.
Lakshman Swaroop Babu Chapter 2. Background 13
2.6 Browser Plugins and Extensions
Plugins add new features to an existing software application. Common browser plugins
include Adobe Flash Player, Quick Time Player, Java. These plugins allow third parties to
extend their software support to web browsers. Extensions on the other hand, extend the
functionality of the browser. Each browser has its own architecture and APIs to develop
the extension and as such extensions are specific to browsers. For example, they can modify
the browser UI, process loaded webpages on the browser or even change data on the page,
etc. There are development frameworks which can build cross-browser extensions but the
APIs provided may not provide all the flexibilities that a particular browser-specific API can
provide.
2.7 Web Services
A web service is a method of interaction between web-enabled devices over the internet. The
two main web service interaction paradigms are Simple Object Access Protocol (SOAP) and
Representational State Transfer (REST) based on which many web services are implemented.
SOAP provides a framework for exchanging structured information and uses XML for its mes-
sage format. It suggests a communication-oriented model. SOAP provides versatile trans-
port protocol support but is considerably slower as it uses the verbose Extensible Markup
Language (XML) format. REST is predominantly used for implementing web services and
follows a resource-oriented model. REST uses a client-server model via standardized HTTP
interface.[8]
Chapter 3
Related Work
In this section, we discuss the related work on Wi-Fi sharing in recent years. Wi-Fi hotspots
are the most common form of sharing internet access today. A typical hotspot offers internet
access over a wireless local area network using a router with internet subscription. This
typical configuration is set up in many households today but are used for only residential
purposes. There are many solutions, standards and initiatives which extend the concept of
a hotspot to provide service for a much larger user base.
The related work can be broadly classified into three sections, Wi-Fi Sharing Solutions,
Protocols & Standards and Initiatives.
3.1 Protocols and Standards
We will discuss various standards and protocols that are related to Wi-Fi sharing which
include WISPr, Hotspot2.0, 802.1X, and authentication protocols like RADIUS, Diameter,
EAP.
14
Lakshman Swaroop Babu Chapter 3. Related Work 15
3.1.1 Wireless Internet Service Provider roaming (WISPr)
Since it is difficult for a single internet service provider to build infrastructure that offers
global access to its subscribers, roaming between service providers is necessary to provide
global internet access to all the users. Wireless Internet Service Provider roaming (WISPr) is
a draft protocol submitted to the Wi-Fi Alliance that allows users to roam between wireless
ISPs by facilitating inter-network and inter-operator roaming. This allows Wi-Fi enabled
devices to roam into public Wi-Fi hotspots for internet access and services.
WISPr recommends the use of a browser-based Universal Access Method (UAM) which
allows a subscriber to access the network only with a Wi-Fi network interface and web
browser on the user device, and does not require any client software on the subscriber
device. This ensures compatibility for all Wi-Fi products. WISPr also recommends the
use of RADIUS as the recommended backend AAA protocol to support the requirements
of WISPr. Although the WISPr specification is no longer available from the Wi-Fi alliance
and was not really a standard or protocol, the UAM protocol is widely used to access public
IEEE 802.11 Wi-Fi networks.
Recently, the Wireless Broadband Alliance (WBA) released WISPr 2.0 which further en-
hances and corrects the inter-working problems with WISPr 1.0 [15]. The scope of WISPr
2.0 is limited to specification of client software to public WLAN interface. WISPr 2.0 recom-
mendations are a front end to authentication protocols such as Radius and Diameter. WISPr
2.0 requires IP communication with the gateway prior to authentication. WISPr 2.0 extends
support to EAP authentication. It is implemented using a client software and uses a mix
of secure and unsecure HTTP transactions. WISPr transactions are always initiated by the
client software which passes parameters to the access gateway through the parameters of a
HTTP Request. The access gateway responds to these requests by passing XML parameters
in the HTTP response.
Although FRAC design considers certain recommendations from WISPr such as planned
use of a mix of secure and unsecure HTTP control messages, using attribute-value pairs
Lakshman Swaroop Babu Chapter 3. Related Work 16
for messaging but has major design differences as it is not a typical public Wi-Fi network.
FRAC uses RADIUS for authentication, JSON for messaging rather that XML and a client
software to communicate with other elements rather than a browser-based UAM.
3.1.2 Wi-Fi CERTIFIED Passpoint
Wi-Fi certified Passpoint (or) Hotspot 2.0 was developed to address the requirements for
seamless Wi-Fi access in public hotspots and to improve the user experience. A certi-
fied device manages the network association, authentication, sign-up and security in the
background, completely transparent to the user. This includes features like automatic net-
work discovery and selection, seamless network access with EAP authentication, and WPA2-
Enterprise security. Passpoint empowers service providers to fully leverage Wi-Fi ubiquity
in client devices, and offer a more compelling service to the customers. Typically subscribers
have to search and connect to a public hotspot, request connection and enter authentication
credentials every time they connect to a hotspot. Wi-Fi certified passpoint devices provide
features such as automatic network discovery and selection to connect to FRAC Hotspots
or HOST APs without the need to manually search and connect to a HOST AP.
3.1.3 802.1X & Extensible Authentication Protocol (EAP)
802.1X is the IEEE standard for port-based network access control. It provides a mech-
anism to verify network credentials and restrict access to services offered by the LAN to
authenticated and authorized users. 802.1X was defined originally for wired networks but
was adopted to wireless LANs to address the security concerns because of its robust security
framework, authentication mechanisms and data privacy capabilities. 802.1X operates at the
data link layer. It is capable of providing secure exchange of user credentials and prevents
unauthorized network access since the authentication is completed before the IP address is
assigned.[18]
Lakshman Swaroop Babu Chapter 3. Related Work 17
The authentication mechanism involves three parties - supplicant, authenticator and authen-
tication server. The supplicant represents the software on the user device that implements
the client side of 802.1X, and requests access to the network. The authenticator is typically
a network device and the authentication server runs software supporting RADIUS and EAP
protocols. The supplicant provides credentials to the authenticator which is the access gate-
way. The authenticator sends these credentials to the authentication server for validation
and the authenticator allows supplicants only if their user credentials are verified. To ensure
the secure passing and validation of data/credentials and to simplify creation and mainte-
nance of additional authentication methods, EAP was created. 802.1X works in conjunction
with EAP.
Supplicant
EAP
2
RADIUS/DIAMETER
Internet or Other LAN Resources
3
Authenticator Authentication Server
Figure 3.1: 802.1X Authentication
EAP is an authentication framework, mainly designed for use in network access authentica-
tion where the IP layer may not be available. It provides reliable transport for authentication
protocols using different EAP methods. It only supports a single packet in flight and cannot
support bulk data like TCP. EAP uses server initiated authentication mechanism, which
adds additional messages per authentication process. Once an EAP method has been se-
lected, both the supplicant and authentication server must communicate using this EAP
method. EAP messages are transported between the supplicant and the authenticator over
a layer 2 authentication protocol specified by 802.1X - EAP over LAN (EAPoL).
Lakshman Swaroop Babu Chapter 3. Related Work 18
EAPoL is an encapsulated form of EAP that prefixes an Ethernet header onto EAP messages
so that they can be transmitted over an Ethernet network directly by a LAN media access
control (MAC) service between the supplicant and authenticator. The authenticator com-
municates with the authentication server, which understands RADIUS messages via EAP in
RADIUS. This is a Layer 3 transmission which provides a secure channel for authentication
messages and port authorization between the authenticator and authentication server.[17]
EAP provides improved security through layer 2 authentication, but since FRAC is a public
Wi-Fi system offering free Wi-Fi using EAP might be an overkill. Every user would have to
configure 802.1X login settings which creates a support issue for the owner. Additionally, the
hotspot owner would have to setup an authentication server to provide 802.1X capability.
Further, EAP uses a server initiated authentication mechanism which increases message
overhead.
3.1.4 RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a widely deployed networking
protocol that enables centralized authentication, authorization and accounting (AAA) man-
agement for network access [19][20]. AAA refers to a security architecture to enable control
over access to services and resources in the network. Two protocols which provide this
functionality are RADIUS and Diameter.
RADIUS is used to manage access to the internet or internal networks. It is supported
by VPNs, wireless access points, Ethernet switches and other network access types. It is
a client/server protocol running on the application layer and uses UDP as the transport
protocol.
Typically a network access server like dial-up server, VPN server, or wireless access point,
operates as a RADIUS client which sends the user credentials, connection parameters and
accounting messages to the RADIUS server. The RADIUS server is responsible for authen-
Lakshman Swaroop Babu Chapter 3. Related Work 19
ticating users before allowing access to the network [19], authorizing those users for certain
network services and accounting their use of these services. Data is exchanged by using
RADIUS messages which consists of a RADIUS header and RADIUS attributes.
texttext
RADIUS Client RADIUS Server
RADIUS: Access-Request
RADIUS: Access-Accept
OR
RADIUS: Access-Reject
RADIUS: Access-ChallengeOR
Figure 3.2: RADIUS Authentication and Authorization Flow
Apart from many inherent drawbacks in RADIUS [21], there are fundamental difference
between features offered by RADIUS and FRAC requirements, which makes RADIUS an
unlikely choice for our framework. RADIUS provides AAA only between two nodes, the
gateway which has a RADIUS client component and communicates with the RADIUS server,
whereas FRAC system has three nodes involved in the system. The notion of accounting in
FRAC is different from accounting in RADIUS. RADIUS measures network usage in terms
of time and bandwidth whereas FRAC provides its CLIENTs free Wi-Fi and accounts on
online advertisements delivered, clicked or viewed.
3.1.5 Diameter
The emergence of new access technologies like mobile IP and the increased complexity and
density of network access servers have led to new demands on AAA protocols, which RADIUS
cannot handle. The Diameter protocol is defined to address the drawbacks of the RADIUS
protocol and provide additional features. Main feature additions of the Diameter protocol
Lakshman Swaroop Babu Chapter 3. Related Work 20
include using TCP as the transport layer protocol, using IPSEC or TLS for transport layer
security, transition support for RADIUS, attribute-value pairs and 32 bit identifiers, better
roaming support, client-server protocol and extensible support and use of EAP.[22]
Diameter not only addresses these new demands but also adds many other features which
makes it much more sophisticated than the RADIUS protocol. Due to this Diameter is
complex to implement and may consume relatively high authentication overhead. Secu-
rity requirements for FRAC are much lighter compared to the security features offered by
Diameter.
3.2 Wi-Fi sharing solutions
The common Wi-Fi sharing solutions include commercial hotspots, free access hotspots, com-
munity and municipal Wi-Fi networks. All these solutions extend the concept of a hotspot.
The enabler-technologies and solutions include Captive portals, hotspot management sys-
tems and network access control.
3.2.1 Captive Portal
These captive portals force an HTTP client on a network to see a special web page for
authentication and billing purposes before internet access is granted. The user is denied
access first by intercepting or dropping all the packets from any unregistered user and instead
the user’s browser is redirected to a web page which requires authentication details, billing
information or agreeing upon an acceptable use policy. Captive portals are used in many
places like business centers, airports, shops and other venues that offer Wi-Fi hotspot service
to users.
Lakshman Swaroop Babu Chapter 3. Related Work 21
3.2.2 Hotspot management systems
Wi-Fi hotspots are controlled using hotspot management systems which run on the router
or an external computer. Their functions include client authentication, bandwidth hogging,
billing systems.
3.2.3 Network access control mechanisms
Network access control solutions typically uses a set of protocols and policies which control
secure access to a network.
There are many software solutions which implement captive portals, hotspot management
and network access control together or separately which are used in open and commer-
cial wireless networks. Some of the common open-source solutions include ChilliSpot[23],
Wilmagate[24], Wifidog[25], PacketFence[26], NoCat, CoovaChilli[27], pfsense[28], m0n0wall
[29], EasyHotSpot[30], etc. We will discuss a few solutions that are relevant to our proposed
model.
3.2.4 Wifidog
The Wifidog captive portal suite is a complete and embeddable open source captive por-
tal solution to operate a hotspot or a network of hotspots. Its design includes features
such as optional centralized access control, full bandwidth accounting, authentication and
authorization, heartbeat messages and local content specific to the hotspot.[25]
The Wifidog suite consists of two parts, authentication server and gateway. Wifidog gateway
was developed using C which can be included easily into embedded systems like routers,
APs and it can run on any Linux platform even though it was specifically designed for
Linksys WRT54G. The gateway is responsible for dynamically allowing or denying access to
users. The authentication server (Auth Server) is coded in hypertext preprocessor (PHP)
Lakshman Swaroop Babu Chapter 3. Related Work 22
and uses a backend user database. It is responsible for all administrative functions and
user authentication. The database stores the current user data and accounting information.
Whenever users send requests to the gateway, it forwards the data to the authentication
server and waits for further instructions.
text texttext text
AUTH SERVER GATEWAY CLIENT
Validation of ID status
Success page
Initial Web Request
Redirect Request
Request to Auth
Auth Form
User name & Pass
Redirect request to GW
Request with ID to GW
Redirect to successStatus Response
GET for success page
Figure 3.3: Wifidog Flow Diagram
Figure 3.3 shows the authentication flow used in Wifidog. Initial requests from the client0 are
redirected to a local port on the gateway, which allows the client to contact the authentication
server where the client provides user credentials. Once the client has been successfully
authenticated, it is redirected to the gateway with an authentication token. The gateway
validates the token by requesting a confirmation from the authentication server for the token.
Once successful, gateway sends a redirect to the client which obtains the success page from
the authentication server.
Lakshman Swaroop Babu Chapter 3. Related Work 23
3.2.5 Chillispot & Coovachilli
Chillispot is also an open source captive portal and a WLAN access point controller [23].
It used a web based login mechanism for authenticating users. It uses the RADIUS server
for authentication, authorization and accounting. It supports two different access methods:
UAM and Wireless Protected Access(WPA). Chillispot is WISPr compliant. Coovachilli is
based on the Chillispot project (now defunct). It is also a software access controller and
uses RADIUS protocol or simply HTTP protocol for access provisioning and accounting.
Coovachilli is installed on OpenWrt firmware specialized for hotspots called CoovaAP and
supports WISPr 2.0. [27]
Though the basic requirements and functions of these Wi-Fi sharing solutions differ from
FRAC, there is a lot in common with respect to authentication and access control policy,
implementation environment and design limitations. The architecture and technology from
these software solutions have influenced some aspects of design and implementation of the
FRAC system. We also utilize APIs from the Wifidog project in the FRAC HOST AP
software implementation.
3.3 Initiatives
3.3.1 FON
Fon (Fon Wireless Ltd.) [31] is a company that provides a global Wi-Fi network by allowing
members to share their Wi-Fi with other members in the FON community. To be a member
of the FON community, the user must have a Fon Wi-Fi router (called La Fonera) or must
have a router with Fon firmware (ie. Create a Fon Spot). This router will have two separate
Wi-Fi signals one for the host, and one shared signal for other members and visitors. This
enables the host to share their Wi-Fi and, in exchange, allow them to connect to other Fon
Spots.
Lakshman Swaroop Babu Chapter 3. Related Work 24
There are three types of FON users:
• Linuses share their Wi-Fi for free using a FON social router and they can access Wi-Fi
from other Fon spots without any charge in return.
• Bills profit from hosting Fon spots which are using by aliens. They get revenue from
those who purchase FON passes through that Fon spot. Fon provides tools to customize
the splash pages for user sign-in.
• Aliens is any user who wishes to access Wi-Fi from Fon spots but are not FON members.
They typically pay for the service by purchasing passes.
Initial deployments of FON were custom firmware based on OpenWrt for certain compatible
routers (Linksys) and used Chillispot (now CoovaChilli) for authentication without Wi-Fi
encryption and bandwidth-throttling features. FON has developed its commercial line of
Fon routers, La Fonera which still use OpenWrt base as firmware, which provide customized
features to support the Fon network. Further, FON has agreements with leading broadband
providers and ISPs like BT, SFR Softbank, and MTS which allows users to share their excess
bandwidth without breaching user’s terms of service.
FON will be competing with popular wireless router manufacturers provides new product
features based on new wireless standards for market share. Further, users have to buy new
FON equipment to be a part of the FON community, which requires high initial investments.
As we discussed earlier, market is transitioning to free-to-the-end user Wi-Fi, this will reduce
the revenues from FON spots. On the other hand, FRAC provides free-to-end-user Wi-Fi to
users leveraging existing infrastructure.
3.3.2 Boingo and Google, enabling free-to-the-end-user Wi-Fi
Public Wi-Fi deployments have expanded into many venues to support the proliferation
of mobile devices. As such the user’s expectations increasingly skew towards free-to-the-
Lakshman Swaroop Babu Chapter 3. Related Work 25
end-user public Wi-Fi. Wi-Fi has been a key enabler of services beyond internet access.
Sponsored Wi-Fi benefits all the parties involved, consumers get free Wi-Fi, advertisers
reach a captive audience and venue owners improve revenue at the cost of providing Wi-Fi.
Google has recently teamed up with Boingo Wireless to provide free-to-the-end-user Wi-
Fi in New York City subway stations and Wi-Fi hotzones [1]. Google sponsored for free
Wi-Fi service during the summer of 2012, providing a suitable brand-awareness campaign
for Google. Boingo’s model is a sponsor-driven initiative, where the Wi-Fi is sponsored by
companies for brand-awareness to target subways riders at popular stations who represent a
high class customer base. This model is not self-sustainable, as costs involved in sponsoring
Wi-Fi are quite high compared to the overall benefits for the sponsor. Moreover, this model
is suitable only for subsets of the population (high income groups) compared to our model
which can be deployed among different users groups as discussed previously.
Chapter 4
Design Requirements
In this chapter, we envision the outline of the FRAC framework to recognize the requirements
of the FRAC system. We then discuss the quality attributes which will allow the system to
meet user expectations and ensure efficiency. Finally, we discuss the functional requirements
of the system, which defines the important prerequisites for the FRAC system to function
correctly and efficiently.
4.1 Outline
We define a broad outline of the FRAC system based on which we formulate the important
functions and quality requirements that has been considered in the FRAC design. FRAC
is an advertisement-based community network sharing framework. The key elements in this
framework are CLIENTs, HOSTs, ADVERTISERSs and the AGENT.
CLIENT/USER
Any Wi-Fi-enabled device which includes laptop, PC, smartphones, tablets that can connect
to HOSTs on the FRAC framework for free internet access is a potential CLIENT. CLIENTs
26
Lakshman Swaroop Babu Chapter 4. Design Requirements 27
may view advertisements and promotions, or provide feedback and reviews about products,
services and features in exchange for internet access.
HOST
HOSTs represent subscribers who have internet access services from ISPs or other sources
with a Wi-Fi enabled router and are willing to share their excess internet bandwidth with
CLIENTs. Suitable compensations are provided to HOSTs in exchange for delivering adver-
tisements or other messages to CLIENTs during their internet access period.
ADVERTISER
ADVERTISERS represent any party interested to advertise, promote, send messages, get
consumer opinions or create an awareness about any product or service or feature using
the FRAC network. They purchase advertising space on the framework to reach a captive
audience and are the sponsors of the system.
INTERMEDIARY/AGENT
The organization which essentially coordinates between HOSTs, CLIENTs and ADVER-
TISERs in this framework is the INTERMEDIARY (or) AGENT. The main source of the
revenue in this framework comes from developing creative high value advertisement models
and promotion schemes, planning and management of the advertisement delivery process.
AGENT provides suitable compensation to the HOSTs based on proportional revenues gen-
erated. AGENT uses a set of servers to perform its functions, we refer to these set of servers
as FRAC SERVER.
To be a part of the FRAC network, CLIENTs install applications in their system which we
refer to as CLIENT APP and the HOSTs install new software on their wireless routers to
extend the functions of their router to support FRAC functions. We refer to this modified
Lakshman Swaroop Babu Chapter 4. Design Requirements 28
configuration of the HOST’s wireless router as HOST AP.
We discuss the sequence of steps which outlines of the interaction between the elements in
FRAC.
• CLIENT device associates itself to a HOST AP on the FRAC network.
• When the CLIENT uses the web browser to access the internet, the browser is auto-
matically redirected by the HOST AP to a webpage hosted by the INTERMEDIARY.
CLIENT downloads and installs a CLIENT APP, which is basically an application or
browser extension.
• CLIENT APP communicates with the FRAC SERVER through the HOST AP to
register itself on the FRAC network. FRAC SERVER communicates with the HOST
AP to provide free internet access to the respective CLIENT.
• CLIENT APP periodically retrieves advertisements from the FRAC SERVER and
publishes it on the browser. FRAC SERVER quantifies the advertisements and promo-
tions served successfully to CLIENTs using a HOST AP based on which proportional
compensation is provided to that HOST.
• CLIENT is disconnected from the service if the advertisements are not viewed com-
pletely or if the CLIENT APP functions maliciously. The CLIENT is blocked internet
access by the FRAC SERVER through the HOST AP.
• ADVERTISERS promote their advertisements campaigns through the INTERMEDI-
ARY which publishes these advertisements on different CLIENT devices through the
FRAC SERVER.
Lakshman Swaroop Babu Chapter 4. Design Requirements 29
4.2 Quality Requirements
• Scalability: FRAC should be able to support a growing user base. Efficient and
practical design will enable FRAC to support a large number of USERs, HOSTs and
ADVERTISERs.
• Self-sustainability: The goal of the FRAC model is to provide a self-sustainable
framework which benefits all the elements in the framework. The design choices should
be structured to allow all the elements to benefit from the system to enable sustain-
ability.
• Robustness: Stability of the system under perturbations and errors.
• Portability: Using FRAC software in different environments. CLIENTs should be
able to use FRAC CLIENT APP from different devices, operating systems, architec-
ture and hardware to ensure a wide range of customers use the FRAC system. To
support FRAC CLIENT APP for smartphones and tablets apart from laptops, as the
smartphone user base is huge and growing rapidly.
• Maintainability and Flexibility: Providing efficient ways to detect and correct
errors in the framework, perform modifications to enhance the system functionality
allowing for flexible design modifications.
• Reliability: Preventing application and system failures, reducing errors that affects
CLIENTs and HOSTs directly. For example, ensuring the HOSTs are able to use their
internet and are not affected due failure of HOST AP software.
• Efficiency: Reducing the complexity of design, software implementation and ensuring
high performance with little overhead and better response time. For example, since
HOST APs are embedded devices with limited resources, the design should off-load
avoidable functions from the router to ensure better performance.
Lakshman Swaroop Babu Chapter 4. Design Requirements 30
• Usability: Ensure the design provides a functional system, which can be easily used
by all elements in the framework. Providing an easy way to install software and to
register with the FRAC system.
4.3 Functional Requirements
We classify the functional requirements that need to be considered in FRAC design as basic
functions and additional functions. The basic functions discussed will help us design a func-
tional prototype of the FRAC system. The additional functions will provide supplementary
features which will help the FRAC system achieve its quality requirements further.
4.3.1 Basic Functions
4.3.1.1 CLIENT Isolation
It is important to isolate a CLIENT connecting to the HOST AP, this will ensure privacy and
security of HOSTs and CLIENTs. This will also provide better reliability and robustness,
allow HOSTs and CLIENTs to conveniently use their internet without any interruptions
from other CLIENTs.
4.3.1.2 CLIENT and HOST Authentication
The notion of CLIENT authentication in this framework is to simply validate the USER’s
CLIENT APP and register a USER to the FRAC network by storing USER credentials in
the FRAC SERVER through the HOST AP. Once the CLIENT is authenticated by the
FRAC SERVER, the HOST APs allow the CLIENTs to access the internet. Since the
HOSTs are agreed incentives based on the client activity on the HOST AP, the HOST
authentication is not as trivial compared to the CLIENT authentication. Periodic HOST
Lakshman Swaroop Babu Chapter 4. Design Requirements 31
authentication is required to maintain the active HOST APs and their IP addresses in the
FRAC SERVER. Digital signatures, asymmetric encryption and decryption, timestamps can
be used to strengthen HOST authentication. Further, we need to provide a mechanism
to maintain connectivity between all the elements in the framework by using heartbeat
messages.
4.3.1.3 Advertisement Delivery Mechanism (ADM)
Once CLIENTs are authenticated by the FRAC SERVER, the HOST AP allows the CLIENT
to access the internet. CLIENTs watch advertisements which are periodically published on
their browser to sustain their internet access. ADM constitutes the way the advertisements
are delivered to CLIENTs from the FRAC SERVER, and methods to ensure these advertise-
ments are enforced properly. ADM creates an effective advertising medium which ensures
more revenue.
The main requirements to design ADM are the following.
• Advertisements are delivered and published successfully to the CLIENTs.
• Foolproof mechanisms to ensure advertisements are enforced properly at the CLIENT.
• Enforce periodic internet access policies which allow and deny internet access to the
CLIENTs.
4.3.1.4 Quality of Service
Certain QoS features are required to ensure that HOSTs are able to use their internet service
without compromising their internet connection experience by providing priority to HOST
traffic over the CLIENTs. Further, every CLIENT connecting to this framework should get
their fair share of bandwidth and admission control will has to be strictly enforced at HOST
AP, so that the HOST AP is not overloaded with CLIENTs.
Lakshman Swaroop Babu Chapter 4. Design Requirements 32
4.3.1.5 Billing Mechanism
In this framework, HOSTs share their unutilized internet bandwidth with CLIENTs in ex-
change for benefits from INTERMEDIARY. An appropriate billing mechanism is required
to quantify the HOST AP’s ability be a successful advertising medium, based on which com-
parable benefits are provided to respective HOSTs. A similar billing mechanism is required
to charge the ADVERTISERs for promotions using the FRAC network.
As described above, the notion of accounting in our framework differs from other standards
like RADIUS, Diameter and solutions like WifiDog where the users/clients are charged based
on internet usage time or bandwidth. In our framework, a trusted accounting system is re-
quired to distribute incentives to the HOSTs and provide a portal for ADVERTISERs where
they can view their performance statics and pay their charges. The billing mechanism can
be quite simply be any successful advertisement pricing scheme used for online advertising.
4.3.1.6 Security and Firewalls
Providing security ensures safe and secure operation of CLIENTs and HOSTs, ensures all
the elements in this framework work correctly and detects malicious activity. The important
security requirements are as follows.
• Firewall to ensure isolation, access control and restrictions, proper operation of all
functional blocks.
• Use encryption and decryption to ensure critical packets/control messages traverse the
network securely. Creating a secure channel for communication between CLIENTs,
HOSTs and FRAC SERVER.
• Use authentication mechanisms like digital signatures, timestamps to authenticate
HOSTs and CLIENTs in the framework.
Lakshman Swaroop Babu Chapter 4. Design Requirements 33
Providing the right amount of security is critical for better system efficiency and performance,
as this will reduce the overhead from using complex security features.
4.3.1.7 Unified Message Exchange Format
All the nodes in FRAC system have to communicate with each other in order for it to
function. To ensure portability, interoperability and to make the system scalable, a common
message format is a prerequisite. There are a variety of standard options and a fitting choice
would depend on the requirements and functionality of the system. The basic requirements
of this message format is that it should be lightweight, have low implementation complexity,
portability, better support and reduced overhead. It should be flexible, extensible and easy
to parse.
4.3.2 Additional Functions
4.3.2.1 Automatic Network Discovery and Selection
CLIENT APP identifies and associates with HOST APs in the background automatically
without any active intervention from the USER. This will ensure that CLIENTs do not
connect to incorrect APs which are not part of FRAC system. This feature is currently being
released in Wi-Fi certified Passpoint devices, which was discussed earlier in the related work
section.
4.3.2.2 Automatic Software Updates
This feature will enable the all the elements in the FRAC system to update software and
additional features automatically providing more flexibility to add additional improvements
and features.
Lakshman Swaroop Babu Chapter 4. Design Requirements 34
4.3.2.3 Effective Advertising and Promotions
This framework remains self-sustainable only when this framework is an effective marketing
solution for commercial organizations. One of the important goals would be to find creative
solutions which will make this framework an effective advertising and marketing medium.
Chapter 5
Design
First, the most widely used architectures and platforms for HOST AP and CLIENT APP
are considered which determine the flexibilities and limitations in FRAC design. Then, we
examine the design of the essential features in the FRAC system. Finally, the elements and
their overall design based on these features are provided.
5.1 Architecture and Platform
5.1.1 HOST AP
The HOST AP is typically a Wi-Fi router which consists of a router and a wireless access
point. Since the HOST AP has to be configured to perform additional functions like allowing
and denying CLIENTs into the guest network, communicate with the FRAC SERVER or
CLIENT APP, the host firmware has to be modified to perform these additional functions.
To perform these additional functions, we use open source firmware like dd-wrt or OpenWrt
which are quite popular. The router must be compatible with the open source firmware in
order for it to be installed over the proprietary router firmware. As explained earlier, there
is a very wide base of commercial home routers which being used today that are capable of
35
Lakshman Swaroop Babu Chapter 5. Design 36
using open source firmware like dd-wrt and OpenWrt.
Most of the routers in the market use the MIPS or MIPSEL architecture (MIPS architecture
in little endian format). Though the router hardware and support features vary greatly
across different brands and price ranges, their basic hardware and functions remain identical.
More flash memory and RAM on a router improves throughput, performance and supports
larger networks. To ensure better portability across different wireless routers, the HOST
AP software should be designed to support minimal flash and RAM in available in routers
(16MB RAM, 4MB Flash).
5.1.2 CLIENT APP
The CLIENT is typically any device which has a Wi-Fi adapter and is capable of connecting
to the HOST AP. CLIENT devices include PCs, laptops, netbooks, smartphones and tablets.
Based on the device type, the CLIENT APP can be classified as browser-based and app-
based.
Browser-based CLIENT APPs are for PCs, laptops and netbooks. These devices mainly
use the internet through their web-browser like Firefox, Chrome, Internet Explorer, etc.
CLIENT APP in these devices can simply be a browser extension which runs on the back-
ground or system software which interact with the browser. The design of the CLIENT APP
is browser specific rather than platform specific as most of the browsers take care of the com-
patibility through different architectural platforms.
App-based CLIENT APPs are for smartphones and tablets. These devices uses the internet
mainly through Apps on their devices rather than web-browsers. CLIENT APP in these
devices is typically an APP on the device, as such this makes the CLIENT APP platform
dependent. The two commonly used platforms for these devices are Android and iOS, and
the CLIENT APP requires separate design and implementation in both these platforms.
CLIENT APP portability remains a challenge due to varied devices and platforms over which
Lakshman Swaroop Babu Chapter 5. Design 37
CLIENTs typically use the internet. Potential solutions involve designing CLIENT APPs
separately for the most widely used platforms and devices or finding a way to support and
design one CLIENT APP for most platforms and devices.
5.2 FRAC Design Features
Message Abbreviations
HTTP CLIENT AUTH REQ HTTP authentication request from CLIENT APP to HOST AP
HTTP CLIENT AUTH RESP HTTP authentication response from the HOST AP to
CLIENT APP
HTTP AP AUTH REQ HTTP authentication request from HOST AP to FRAC SERVER
for CLIENT
HTTP AP AUTH RESP HTTP authentication response from FRAC SERVER to HOST AP
for CLIENT
HTTP VAD REQ HTTP CLIENT Video Advertisement Request
HTTP VAD RESP HTTP CLIENT Video Advertisement Response
HTTP VAD NOTIFY REQ HTTP CLIENT Video Watched Notification Request
HTTP VAD NOTIFY RESP HTTP CLIENT Video Watched Notification Response
HTTP BAD REQ HTTP CLIENT Banner Advertisement Request
HTTP BAD RESP HTTP CLIENT Banner Advertisement Response
5.2.1 JSON Unified Messaging Protocol (JUMP)
JavaScript Object Notation (JSON) is used to create a unified messaging protocol in FRAC.
JSON is made out of two structures, a collection of field-value pairs and an ordered list of
values [32]. JSON Unified Messaging Protocol (JUMP) is a predefined set of fields used with
JSON as the common message exchange format to communicate across all the elements in
the FRAC network. JUMP uses HTTP as its underlying protocol. Since JUMP is essentially
Lakshman Swaroop Babu Chapter 5. Design 38
JSON, it can be easily extended to support additional fields and data types.
A detailed description of JUMP is provided in the Appendix section of this document.
5.2.1.1 JSON Schema
JSON Schema is a JSON based format for defining the structure of JSON data. JSON schema
provides an overview of the required data for applications and the methods to interact with
data. It validates JSON objects, and provides documentation and hyperlinking.
{
"client_id" : {
"type" : "string",
"value" : "6ge3T9pf"
},
"message" : {
"type" : "number",
"value" : "10"
},
"protocol_version" : {
"type" : "string",
"value" : "1.1"
},
"software_version" : {
"type" : "string",
"value" : "1.0"
},
"session_id" : {
"type" : "string",
"value" : "sid"
},
}
5.2.1.2 Message and Status Codes
Message and Status codes help the application to process requests and responses. JUMP
uses message codes to provide information to the nodes in the framework to identify the
Lakshman Swaroop Babu Chapter 5. Design 39
message in order to process the received data appropriately. JUMP uses status codes to
determine if the status of a request was a success or failure and provides the reason for the
failure.
5.2.1.3 Example: Message Format
The following is an example of the HTTP CLIENT AUTH REQ message using JUMP.
{
client_id: "6ge3T9pf",
message: "10",
protocol_version: "1.1",
software_version: "1.0",
session_id: "1qw3e4v9"
}
5.2.2 CLIENT Authentication Mechanism
The CLIENT authentication requirements are modest and lightweight as discussed previ-
ously. We basically validate the USER’s CLIENT APP and register a USER to the FRAC
network by storing USER credentials in the FRAC SERVER through the HOST AP.
Initially all the packets from the CLIENT are dropped at the HOST AP, as the CLIENT has
not been authenticated. CLIENT APP sends a HTTP CLIENT AUTH REQ to the HOST
AP. This request is received by the HOST AP firewall and it triggers the HOST AP to send
an HTTP AP AUTH REQ for the CLIENT to the FRAC SERVER. The FRAC SERVER
validates the request and adds the CLIENT to the database if the request was success-
ful. It sends back a HTTP AP AUTH RESP to the HOST AP which forwards it to the
CLIENT APP, and if the requests was successful the HOST AP allows the CLIENT to ac-
cess the internet (unblocks CLIENT). Note that HOST AP sends authentication request for
a CLIENT not the CLIENT itself because otherwise, this would allow malicious CLIENTs
to send requests to the FRAC SERVER from behind non-FRAC APs.
Lakshman Swaroop Babu Chapter 5. Design 40
text texttext text
CLIENT_APP HOST AP FRAC_SERVER
HTTP_CLIENT_AUTH_REQ
HTTP_AP_AUTH_REQ
HTTP_CLIENT_AUTH_RESP
HTTP_AP_AUTH_RESP
(HTTP_CLIENT_AD_REQ)
Validate Request
Authenitcate CLIENT
Add CLIENT to DB
Initialize CLIENT data
Forward response.
If Authentication
successful, unblock
CLIENTCLIENT is
allowed a grace
period to send
AD request and
view AD.
Figure 5.1: CLIENT Authentication Mechanism
Uniquely identifying HOSTs and CLIENTs is an important authentication requirement.
We see that CLIENTs are connected to HOST APs at Layer 2, CLIENT MAC IDs are
broadcasted by CLIENTs to the HOST AP. CLIENT MAC is a unique identifier for a
CLIENT at the HOST AP. Since, HOSTs are connected to the FRAC SERVER at layer
3 and they have multiple MAC IDs for different interfaces, the FRAC SERVER cannot
determine the MAC ID of the HOSTs. A unique gateway ID is provided to HOST APs and
CLIENT APPs to identify the valid HOSTs and CLIENTs at the FRAC SERVER.
5.2.3 Maintaining Connectivity
Since, the HOST AP in the framework connected to the FRAC SERVER over the internet
and has a dynamic IP address, secure keep-alive messages are sent periodically to ensure the
HOST AP is not malicious and FRAC SERVER updates the IP address for a valid HOST
AP in the database.
Lakshman Swaroop Babu Chapter 5. Design 41
5.2.4 Advertisement Delivery Mechanism (ADM)
Display advertising and video marketing are preferred advertising methods for this framework
and are effective marketing strategies. ADM provides successful advertisement delivery to
CLIENTs and ensures foolproof ad publishing which enables periodic internet access for the
CLIENTs. Although, the basic principle remains the same, ADM differs based on the type
of marketing strategy and the CLIENT device. ADM for banner ads and video ads for a
browser based CLIENT APP are discussed in this section.
Our prototype design is a video-centric model that provides internet access when the CLIENT
views video advertisements periodically. Since we use HTTP which is a pull protocol.
FRAC SERVER will be able to deliver advertisements only when requested by the browser
or CLIENT APP .
5.2.4.1 ADM for Video Ads on a Browser-based CLIENT APP
Once the CLIENT is authenticated, the HOST AP unblocks the CLIENT and allows internet
access for a grace period. During this grace period the CLIENT APP will request the
video advertisement data from the FRAC SERVER and publishes the received data on the
USER browser. The browser retrieves the video advertisement from the AD Server. The
USER views the video, a trigger button is displayed for a random interval during which the
USER is required to click on the trigger button. This sends out a trigger request to the
FRAC SERVER, this mechanism ensures the video is being watched by the USER. After
the USER views the video completely, a notification request is sent from the CLIENT APP
to the FRAC SERVER. FRAC SERVER updates the timer for the respective CLIENT in
the database provided both the trigger request and notification request are received and
sends back a response to the CLIENT APP. Every time at the start of the grace period, the
CLIENT APP automatically sends out a video advertisement request to the FRAC SERVER
to renew the internet connectivity.
Lakshman Swaroop Babu Chapter 5. Design 42
text texttext text
CLIENT_APP HOST AP FRAC_SERVER
HTTP_VAD_REQ
Send AD response to
valid CLIENT.
Update trigger request.
Update notification request from
CLIENT_APP.
IF both messages are received,
update CLIENT timer in DB.
Send response to CLIENT.
CLIENT_APP receives Video
AD, CLIENT views AD and
clicks on trigger buttons, which
send out a trigger request.
After viewing AD, the APP
sends notification message to
FRAC_SERVER
If successful response, APP
updates CLIENT timer
HTTP_VAD_RESP
trigger_request
HTTP_VAD_NOTIFY_REQ
HTTP_VAD_NOTIFY_RESP
CLIENT_APP sends an video
ad request when CLIENT has
grace period of internet access
remaining.
Figure 5.2: Video Advertisement Delivery Mechanism
The message exchange takes place between the CLIENT APP and the FRAC SERVER, and
does not involve the HOST AP. This reduces the complexity at the HOST AP and prevents
any malicious activity at the HOST AP.
This section focused on delivering the video to the USER’s browser but we also require
mechanisms to enforce the USER to watch these advertisements completely. It would not
be effective if the USER can simply shift between tabs and open new windows, to avoid the
advertisements. This issue is implementation specific and is addressed in the next chapter.
5.2.4.2 ADM for Banner Ads on a Browser-based CLIENT APP
Banner Ads are automatically enabled once the CLIENT is authenticated in the frame-
work. The CLIENT APP sends banner ad requests to the FRAC SERVER periodically. The
FRAC SERVER maintains a counter for the requested banner ads, to ensure CLIENT APP
is working correctly. It sends a HTTP BAD RESP which contains the banner ad data, which
is published on the USER’s browser. The browser requests the banner ad from the ad server.
Lakshman Swaroop Babu Chapter 5. Design 43
text texttext text
CLIENT_APP HOST AP FRAC_SERVER
HTTP_BAD_REQ
Send banner AD
response to valid
CLIENT. Updates
banner ad counter.HTTP_BAD_RESP
CLIENT_APP sends banner
ad request when banner ad
timer expires.
CLIENT_APP publishes
banner ad in USER’s browser
window/tabs.
Figure 5.3: Banner Advertisement Delivery Mechanism
5.2.4.3 CLIENT Expiry Process
CLIENTs are removed from the FRAC network if they do not view advertisements fully
before the timer expires, or if the CLIENT APP functions maliciously.
text texttext text
CLIENT_APP HOST AP FRAC_SERVER
HTTP_EXP_NOTIFY_REQ
HTTP_EXP_REQ
HTTP_EXP_RESP
Event: CLIENT timer expired
(or) malicious CLIENT activity.
Server sends an expiry request
for CLIENT to HOST AP.
Identify CLIENT, block
CLIENT access, send expiry
notification to CLIENT_APP
Sends confirmation to
FRAC_SERVER.
Server removes CLIENT
from DB.
Figure 5.4: CLIENT Expiry Process
CLIENTs usually have a grace period over which they should watch the advertisements. If
Lakshman Swaroop Babu Chapter 5. Design 44
CLIENT fails to do so, the FRAC SERVER communicates with the HOST AP and sends an
HTTP EXP REQ for that CLIENT. The HOST AP removes that CLIENT from the FRAC
network.
5.2.4.4 CLIENT Initiation Process: Launching CLIENT APP
Providing a simple way to connect, install and use FRAC software on the CLIENT is im-
portant and improves the usability of the FRAC system. We suggest an easy way for the
CLIENT to be initiated into the FRAC network from browser of any CLIENT connected to
a HOST AP.
text texttext text
CLIENT
BROWSERHOST AP FRAC_SERVER
HTTP WEB Request
Download Request + User
credentialsServer sends the
CLIENT_APP with
installed unique key and
Id.
CLIENT installs
CLIENT_APP
to connect to
FRAC network.
Detects new unregistered
CLIENT. Sends a redirected
splash page response, allows
CLIENT to download
CLIENT_APP from
FRAC_SERVER.Redirected splash page response
HOST AP firewall allows
only access to only this
link for a new client.
Response: CLIENT_APP
New CLIENT,
CLIENT_APP
not installed
Figure 5.5: CLIENT Initiation Process
Once the CLIENT connects to the HOST AP, it may request a web page from its browser
via HOST AP. Since the CLIENT is not registered with the FRAC network, HOST AP
drops all packets from the CLIENT. But first few packets trigger the HOST AP to send a
splash page redirect to the CLIENT browser. The CLIENT will be able to download the
Lakshman Swaroop Babu Chapter 5. Design 45
CLIENT APP software and instructions from this page on entering required user credentials.
The FRAC SERVER sends a CLIENT APP file with uniquely configured key and ID.
5.2.5 CLIENT Isolation
CLIENT isolation can be achieved with the following steps.
• Separate internal networks and interfaces for CLIENTs and HOSTs, guest network and
main host network which also includes adding a DHCP server and configuring NAT
for the newly configured guest network.
• Multiple SSID broadcast, one for guest network and one for host network.
• Isolating CLIENTs within the guest network, so that they can communicate only with
HOST AP and not any other devices within the network.
• Blocking all incoming packets from unauthenticated CLIENTs, except authentication
requests.
• Provide administrative and access privileges only to HOSTs and not to CLIENTs.
Almost all the recent wireless routers in the market have the capability to broadcast mul-
tiple SSIDs and upgrading to Linux-based dd-wrt router firmware provides the features to
configure separate internal networks, guest isolation and provide access control [33] . These
features can be realized using Linux utilities such as iptables, brctl, ifconfig.
5.2.5.1 Creating Multiple SSIDs and VLANs
We create an additional SSID for the wireless interface and an additional VLAN to for the
guest network. The initial router configuration and modified router configuration is shown.
Lakshman Swaroop Babu Chapter 5. Design 46
LAN1 LAN2WAN LAN3 LAN4
CPU
32MB DDR
SDRAM
802.11b/g/n
8MB Flash
0 1 2 3 4
8
Ethernet Switch
vlan 2
vlan 1
eth0
br0 eth1
Figure 5.6: Initial Router Configuration
LAN1 LAN2WAN LAN3 LAN4
CPU
32MB DDR
SDRAM
802.11b/g/n
8MB Flash
0 1 2 3 4
8
Ethernet Switch
vlan 2
vlan 1
eth0
br0 eth1
br1wl0.1vlan 3
Figure 5.7: Modified Router Configuration
We see in the modified router configuration, wired vlan3 and wireless wl0.1 interfaces are
bridged. Since the CLIENTs are not connected to the HOST AP using wired interfaces, it
is sufficient to create a bridge br1 with the wireless virtual interface wl0.1 and no ports in
vlan3. The wireless virtual interface wl0.1 is configured to broadcast a new guest SSID to
connect to the guest network.
Lakshman Swaroop Babu Chapter 5. Design 47
5.2.5.2 Creating Virtual guest interface and guest network
The following script will create a new bridge and move the wireless interface to it. [33] [34]
nvram set dnsmasq\_enable=1
if [ "‘nvram get dhcpfwd\_enable‘" = "0" ]; then
nvram set dns\_dnsmasq=1
nvram set dhcp\_dnsmasq=1
nvram set auth\_dnsmasq=1
fi
# Create bridge br1 and move the virtual wireless interface wl0.1 to it,
brctl addbr br1
brctl delif br0 wl0.1
brctl addif br1 wl0.1
#Setup IP subnet for guest interface.
ifconfig br1 192.168.2.1 netmask 255.255.255.0
ifconfig br1 up
5.2.5.3 Access Control Rules
This command enables NAT on all the interfaces including the virtual guest interface [33]
[34].
/* Enable NAT on WAN port for virtual interface (br1)/all interfaces */
iptables -t nat -I POSTROUTING -o ‘get\_wanface‘ -j SNAT --to ‘nvram get wan\_ipaddr‘
These set of commands set access control rules for the new virtual guest interface.
/* Allow br1 access to br0, the WAN, and any other subnets */
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
/* Restrict both wireless networks from talking to each other */
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
/* Restricting br1 from accessing the router */
Lakshman Swaroop Babu Chapter 5. Design 48
iptables -I INPUT -i br1 -p tcp --dport telnet -j REJECT --reject-with tcp-reset
iptables -I INPUT -i br1 -p tcp --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -i br1 -p tcp --dport www -j REJECT --reject-with tcp-reset
iptables -I INPUT -i br1 -p tcp --dport https -j REJECT --reject-with tcp-reset
By default, all packets sent to the WAN interface from the guest network are dropped.
/* Blocking WAN for br1 */
iptables -I FORWARD -i br1 -o ‘get\_wanface‘ -j DROP
5.2.6 Quality of Service (QoS)
QoS is required to ensure that HOST internet traffic is not compromised because of CLIENTs
in the guest network and so that every CLIENT in FRAC is provided a fair share of available
bandwidth. The important factors to be considered in QoS design are the following. [25]
• Downloading large files using P2P applications, UDP connections will consume con-
siderable bandwidth. Due to this HOSTs and other CLIENTs using the network from
that HOST AP are affected, and do not get their fair share of bandwidth.
• Since HOSTs are typically private consumers mostly subscribing to internet plans from
ISPs, it is not possible to know internet bandwidth available in advance.
We provide a design which is simple, effective and addresses most of these concerns while
providing priority to HOST traffic.
• Provide priority to HOST traffic over CLIENT traffic at all times. This can be accom-
plished by setting up two queues one for HOST traffic and one for CLIENT traffic,
and using a strict priority scheduler to forward HOST packets first.
• Adding Firewall rules to disallow or throttle certain types of traffic on guest network
like P2P traffic, UDP traffic, large files. This will make sure that a single CLIENT
Lakshman Swaroop Babu Chapter 5. Design 49
does not take up too much bandwidth, and to ensure all CLIENTs get their fair share
of bandwidth.
• Enforce strict Admission control policy, allowing only a fixed number of CLIENTs per
HOST AP.
• To ensure all the CLIENTs get fair share of bandwidth from HOST AP we can use
the following.
– Round-robin scheduling: The HOST AP schedules packets in the CLIENT queue
in a round-robin fashion to all the CLIENTs. One advantage with this approach
is that the entire available HOST-unused bandwidth is divided equally among all
the CLIENTs in HOST AP. Enhanced Stochastic Fair Queuing (ESFQ) can be
used to effectively accomplish the same.
– Static bandwidth allocation: Fixed bandwidth allocation to all CLIENTs using
the HOST AP. Problem with this approach is that it is not possible to know the
available internet bandwidth at a HOST AP.
SP
CLIENT Queue
SFQ
HOST QueueIncoming Packets
br1
br0
To HOST
To CLIENT 1
To CLIENT 2
To CLIENT 3
Figure 5.8: Proposed QoS Configuration
QoS design is simple, lighweight and easily implementable on routers using iptables, tc and
qdisc functions which is available in dd-wrt or other Linux-based firmware.
Lakshman Swaroop Babu Chapter 5. Design 50
5.2.7 Security and Firewall
There are new threats that arise in the FRAC model, which are discussed below.
• A malicious CLIENT tries to avoid viewing advertisements or participating in pro-
motions, and tries to hinder the ADM and get free uninterrupted internet access. The
malicious CLIENT can do this by modifying the CLIENT APP to function differ-
ently, such as sending fake requests to the FRAC SERVER. CLIENT may also try to
eavesdrop on other CLIENTs or HOSTs in the network.
• A malicious HOST attempts to maximize its revenues from the FRAC system by
over-reporting advertisements. Since HOSTs have control of their AP, they can attempt
to maximize benefits by severely rate limiting CLIENTs, removing CLIENT security
features to eavesdrop into CLIENT traffic and steal important critical information.
HOST may try to modify the AP software to function maliciously like changing the
initial splash page to steal USER credentials. An invalid HOST can act as though it
is part of the FRAC network and steal information from the CLIENTs connected to
its AP.
• Malicious HOST-CLIENT coordination can provide a way for HOSTs to max-
imize profits fraudulently or allow CLIENTs to get uninterrupted internet access. A
malicious HOST can create a few bogus CLIENTs/CLIENT APPs and use bots to
click on advertisements. This will maximize revenue for the HOST without actually
serving CLIENTs.
• A malicious unregistered user may connect to the guest network at the HOST AP,
and create DoS attacks by constantly sending packets to the router.
• Any eavesdropper in the internet can steal sensitive information from CLIENTs if
critical data is sent using an unsecured channel without any encryption.
Lakshman Swaroop Babu Chapter 5. Design 51
The security features that are required to address these security threats include authenti-
cation to register/identify CLIENTs and prevent unauthorized entities to act as a HOST,
encryption to provide a secure channel to send and receive critical data between the HOSTs,
CLIENTs and FRAC SERVER. We strengthen security using firewall rules using iptables,
improve the authentication mechanism and ADM. In order to provide the right amount of
security, we use a combination of HTTP messages for non-critical data and HTTPS messages
for critical data for communication between FRAC elements to reduce significant message
overhead and improve performance and scalability.
5.2.7.1 Secure Authentication
Since most of the communication over the FRAC network is not critical, providing lighter
security features serves the purpose and improves scalability. CLIENTs and HOSTs can
send digitally signed the messages to the FRAC SERVER and vice versa using public key
infrastructure which provides authentication for most of the FRAC messages. Common
public-key cryptography algorithms such as MD5, SHA, RSA can be used. Since, the im-
plementation complexity and overhead is much lesser compared to complex encryption and
decryption, this method can be implemented in HOST AP which have limited resources.
Further, timestamps can be used to avoid replay attacks.
5.2.7.2 Encryption
Since HOSTs are provided benefits based on the ads requested or clicked by CLIENTs using
that HOST AP. Encrypting the advertisement responses and notification requests from the
CLIENT to the FRAC SERVER would ensure the HOST AP cannot tamper with these
messages. Further, the HOST AP which has limited resources is not directly involved in the
complex encryption and decryption process. Transport Layer Security (TLS) has been used
quite commonly by web servers and can be used to provide a secure channel for communi-
cation. Due to significant overhead in encryption/decryption process, the FRAC SERVER
Lakshman Swaroop Babu Chapter 5. Design 52
may not scale too well to support a larger client base.
5.2.7.3 Firewall and Access Control
Apart from providing a standard secure firewall, the guest network at the HOST AP uses
access control policies to prevent malicious USERs from using too much resources, or stealing
critical data from other CLIENTs and HOSTs. This can be accomplished by using iptables
to provide firewall and access control. Most of these security vulnerabilities can be resolved
by isolating the CLIENTs as discussed previously. Since any CLIENT can connect to the
guest network in the HOST AP, creating DoS attack on the HOST AP is possible. This
problem can be addressed by rate-limiting CLIENTs connectivity to the HOST AP using
iptables.
5.2.7.4 Strengthening security by design improvements
Although, security in the framework can be improved using these standard approaches, some
of the security vulnerabilities described previously can be addressed only by improving design
to strengthen security. Some of the design considerations to improve security include the
following.
• Randomizing banner advertisement display location would ensure that bots do not
click advertisements to generate revenue for HOSTs.
• FRAC SERVER responds to video advertisement requests from CLIENTs only during
the grace period when the CLIENT is actually required to view the advertisements.
Selective ad response ensures better server scalability.
• Protecting the source code is critical to maintain security. Malicious entities can modify
the source code and change the way CLIENTs and HOSTs function. This can threaten
CLIENTs and HOSTs using this software and create a potential security breach in the
Lakshman Swaroop Babu Chapter 5. Design 53
system. Since CLIENT APP is implemented using JavaScript, it remains open source.
We obfuscate the JavaScript using standard tools and software, which will conceal the
real meaning and intent of the JavaScript code. Since HOST AP is a standard binary,
it is secure and cannot be modified easily.
5.2.8 Billing Mechanism
The AD server is responsible for reporting clicks, impressions, actions generated and updat-
ing information in different databases on the FRAC SERVER. ADVERTISERs are provided
with the statistics and accounting for their published advertisements based on which they
provide equivalent compensation. Similarly, the HOST database is updated based on count-
ing the advertisements viewed, delivered or clicked by different CLIENTs using that HOST
AP, based on which they are provided suitable compensation.
For our current prototype model, we support banner ads and video ads which are quite
popular online advertising types. CPM pricing model can be used for video ads, as ADVER-
TISERs pay for brand exposure and awareness. Performance based pricing models such as
CPC and CPA are most preferred revenue models in the market today and can be used for
banner ads.
5.3 FRAC SERVER Design
FRAC SERVER is the key element which coordinates between HOSTs, CLIENTs and AD-
VERTISERs in this framework. The block diagram shows the basic elements and functions
of the FRAC SERVER.
Lakshman Swaroop Babu Chapter 5. Design 54
HTTP Server
Common Communication Interface
AD Server Database Server
CLIENT Database AD Database HOST Database
HOST AP CLIENT BrowserCLIENT_APP
Internet
File ServerHTTP Client
Figure 5.9: FRAC SERVER design
HTTP Server and Client
The HTTP Server block is responsible for all the control plane messages to the HOST AP
and CLIENT from the FRAC SERVER. It also consists of a HTTP Client module to sends
requests (expiry) to the HOST AP. HTTP Server and Client modules are responsible for the
following functions which were discussed in the previous sections.
• CLIENT Authentication
• CLIENT Expiry
• Advertisement request and response.
• HOST AP Keepalive
The HTTP server communicates with the database server for CLIENT and HOST infor-
mation to validate messages and authenticate CLIENTs and HOSTs. HTTP server re-
Lakshman Swaroop Babu Chapter 5. Design 55
sponds to CLIENT advertisement requests with URLs which deliver advertisements from
the FRAC SERVER. These URLs are generated by the AD server, HTTP server communi-
cates with the AD server to obtain these responses.
AD Server and database
The main function of the AD server is to serve advertisements to CLIENTs in the FRAC
network and to perform accounting operations in the framework. It also has a file server to
download the CLIENT plugin during CLIENT initialization. The AD server also creates and
sends advertisement URLs to the HTTP server which the CLIENT browser retrieves from the
AD server. The AD server does not interact with the CLIENT APP but with the CLIENT
browser. It serves files from the AD database which contains all the advertisements from the
ADVERTISERS in the framework. The AD server updates the number of advertisements
that were clicked, delivered, viewed successfully into the HOST database. Based on these
fields in the database, the HOST compensation is calculated using a suitable cost function.
CLIENT and HOST database
The database server is used to provide response to database lookup and update requests from
the HTTP server and AD server. It also checks for any expired CLIENTs in the CLIENT
database, if there are any expired CLIENTs, then it communicates with the HTTP server
to send an expiry request to the respective HOST AP.
The CLIENT database contains a list of active CLIENTs in the FRAC network and their
credentials which includes their identification, associated HOST IP address and identifica-
tion, the current session identification, service expiry time, security profile and advertise-
ment profile. The CLIENT database also maintains counters to check if advertisements are
published and enforced on the CLIENT device. The security profile information is used
to send and receive critical information using secure channels between the CLIENT and
the FRAC SERVER. The ad profile includes the advertisement selected for delivery to the
CLIENT by the ad server and the advertisement status.
Lakshman Swaroop Babu Chapter 5. Design 56
CLIENT_ID HOST_IP HOST_ID SESSION_IDAD
PROFILE
SECURITY
PROFILE
EXPIRY
TIME
VAD
CTR
BAD
CTR
HOST_IP HOST_ID SESSION_IDBAD
CLICKS
KEEPALIVE
COUNT
VAD
CTR
BAD
CTR
SECURITY
PROFILE
Figure 5.10: CLIENT database example
The HOST database contains the list of active HOST APs in the FRAC network and their
credentials which includes the identification, IP address, billing information and security
profile. The security profile information is used to send and receive critical information
using secure channel between HOST AP and FRAC SERVER. The billing information like
the number of advertisements delivered, viewed and clicked, is updated by the AD server.
CLIENT_ID HOST_IP HOST_ID SESSION_IDAD
PROFILE
SECURITY
PROFILE
EXPIRY
TIME
VAD
CTR
BAD
CTR
HOST_IP HOST_ID SESSION_IDBAD
CLICKS
KEEPALIVE
COUNT
VAD
CTR
BAD
CTR
SECURITY
PROFILE
Figure 5.11: HOST database example
Lakshman Swaroop Babu Chapter 5. Design 57
5.4 HOST AP Design
HOST SSID GUEST SSID
ROUTER
Internet
Internal WLAN
HTTP Client
CLIENT Database
HTTP Server
CLIENT_APP/Browser
FRAC_SERVER
Access Contol +
Firewall + QoS
Common Communication Interface
Figure 5.12: HOST AP design
This diagram shows the design overview of a HOST AP in the FRAC system. Routers are
embedded systems which have small amounts of Flash and RAM, which makes it challenging
to implement all these design features in the HOST AP. Lightweight implementation, modest
APIs and efficient design are important considerations in the design of HOST AP for FRAC.
We have discussed the important issues such as client isolation, firewall and QoS for the
HOST AP in the previous section on FRAC features. The other important blocks in HOST
AP design are the CLIENT database and HTTP client/server.
A simple CLIENT database implementation is required to maintain the list of active CLIENTs
Lakshman Swaroop Babu Chapter 5. Design 58
connected to the HOST AP. Dynamic Access control mainly includes dynamically allowing
and blocking access to CLIENTs in the database based on successful authentication responses
and expiry requests from the FRAC SERVER. HTTP server and client modules in the HOST
AP are used to send and receive control messages from CLIENTs and FRAC SERVER which
are either processed or forwarded based on the message type and status. HTTP server and
HTTP client API should have basic functional features and a modest implementation.
5.5 Browser-based CLIENT APP Design
Wi-Fi Interface
Internet
UI/Popup
Background HTTP Client
HOST AP
FRAC_SERVER
AD SERVER
Common communication interface
Client Browser
Tab 3Tab 2Tab 1
Content Scripts
CLIENT Browser
Figure 5.13: Browser-based CLIENT APP design
Lakshman Swaroop Babu Chapter 5. Design 59
This diagram shows the design overview of a browser-based CLIENT APP design. It con-
tains a User Interface (UI) to provide the user with basic information such as the browsing
time remaining, identification, status and authentication. The CLIENT can use the UI to
disconnect from the FRAC network.
The background page is responsible for communicating with all the other blocks - UI, con-
tent scripts and send requests to the HOST AP and FRAC SERVER. Its main functions
include creating and parsing JUMP messages, sending and receiving data using AJAX HTTP
requests to the HOST AP and FRAC SERVER. Once the advertisement data is received
from the FRAC SERVER, it will publish these advertisements using content scripts to the
browser. CLIENT APP maintains two timers - video ad timer and banner ad timer based
on which it sends out requests to the FRAC SERVER. These timers act as guidelines for
the CLIENT APP to send advertisement requests at the appropriate time. Content scripts
communicate with the background to get the advertisement data. The content script exe-
cutes the JavaScript on the web page to publish advertisements onto the webpage which are
then requested from the AD server.
Chapter 6
Implementation
In this chapter, we discuss the implementation of the prototype version of the FRAC system.
The implementation consists of the following software and features.
Base FRAC Software
• Chrome browser extension for Browser-based CLIENT devices.
• Embeddable HOST Gateway application (executable binary) developed using C with
dd-wrt Firmware
FRAC System Features
• JSON Unified Message Protocol (JUMP)
• CLIENT authentication mechanism.
• Advertisement Delivery Mechanism for Browser-based CLIENT APPs
• CLIENT isolation.
For this setup, we use a basic apache HTTP web server on Amazon EC2 with a global IP
60
Lakshman Swaroop Babu Chapter 6. Implementation 61
as the FRAC SERVER for testing implementations. This is a pretend server which provides
static responses to the JUMP message requests from the HOST AP and CLIENT.
The other design features include the FRAC SERVER prototype implementation, QoS for
CLIENTs at HOST AP and most of the security features discussed in the FRAC design.
These features are currently being implemented by our project team but are not part of this
work.
6.1 CLIENT APP Implementation
CLIENT APP developed in the prototype version is a Chrome browser extension. As we
discussed earlier, Chrome extensions are written in HTML, JavaScript, and CSS using AJAX
and Chrome API to enhance the Google Chrome browsers functionality to run on FRAC
networks. Chrome extensions are not system specific but Chrome browser-specific. So this
CLIENT APP works on all systems which has a Chrome browser installed.
Lakshman Swaroop Babu Chapter 6. Implementation 62
Figure 6.1: Working screen showing CLIENT APP with an video advertisement published
on the Chrome browser
As discussed previously, the Chrome extension has a background page which holds the main
logic of the extension. The extension has a UI to display information to the user and content
scripts to communicate with webpages that the user loads onto the Chrome browser. The
other pages include web storage data using localStorage API and JSON message API [5].
6.1.1 Background Page
The following are the main functions of the background process.
• Sending asynchronous HTTP AJAX POST requests to FRAC SERVER and HOST AP
in the background. JQuery provides additional customization on the AJAX requests.
The code fragment shown below is an example of an AJAX request which retrieves
banner advertisement data from the server.
Lakshman Swaroop Babu Chapter 6. Implementation 63
$.ajax({
url : server\_url,
type : ’POST’,
contentType: ’application/json’,
data : json\_data,
success :
function(data)
{ console.log("Device Control Succeeded");
localStorage.setItem("banner\_data",data);
localStorage.setItem("banner\_exists",1);
},
error :
function()
{ console.log("Device Control Failed"); return 0;}
});
• Creating and parsing JUMP messages – Since Chrome extension uses JavaScript, a
straightforward JUMP implementation is possible. JSON data can be easily created
and parsed from JavaScript code and is well suited for AJAX-based web applications.
Most web browsers including Chrome provide native JSON support which includes
lightweight functions json.parse() and json.stringify() to convert JSON string data
into JSON objects and vice versa respectively [32].
var json\_response = JSON.parse(data);
var json\_data = JSON.stringify(json\_obj);
JSON schema is used to define the message fields in JUMP. We define a small API to get,
set and compare JSON objects in JavaScript. This allows us to construct and manipulate
JSON objects for message exchange.
JUMP.Settings = {
{
"client\_id" : {
"type" : "string",
"value" : "6ge3T9pf"
},
"message" : {
Lakshman Swaroop Babu Chapter 6. Implementation 64
"type" : "number",
"value" : "10"
}
};
JUMP.Settings.set({"message":"73"});
var json\_obj = JUMP.Settings.get();
• Communicates with the extension UI and content scripts using Chrome API functions.
The code fragment shown below sends a message to other scripts in the extension, and
processes the response.
chrome.extension.sendMessage(null, {action: value}, function(response) {
console.log("Response From Background: "+response.status);
if(response.status == 20) {
chrome.extension.getBackgroundPage().location.reload();
}
});
• Detects browser events based on which it interacts with the webpages on the browser
to display advertisements. The code fragment shown below fires an event whenever a
tab in the browser is updated.
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {
if(localStorage.getItem("banner\_exists") == 1) {
display\_banner\_ad(localStorage.getItem("banner\_data"));
}
});
• Persistent local storage support is available on the Chrome browser with HTML5.
Background uses localStorage to store and retrieve application specific data and current
status.
Lakshman Swaroop Babu Chapter 6. Implementation 65
6.1.2 Extension UI/ Popup
The extension UI developed is a popup, which is displayed when the USER clicks on the
extension icon. When the extension UI pops up, it gets CLIENT APP status data from the
background page. The information displayed on the page includes the CLIENT identification,
status, authentication and internet access time remaining. USER can connect and disconnect
from the service as and when required using the UI.
Figure 6.2: CLIENT APP: Popup-based User Interface
6.1.3 Content Script
The received advertisement data from the FRAC SERVER is not the advertisement itself but
its location (URL) on the AD Server. Content scripts communicate with the background
page using Chrome API as shown above, to get the advertisement data. Then, they can
inject this data as new HTML div or iframe elements which contain video objects and image
objects on the webpages which are then viewed by CLIENTs.
Lakshman Swaroop Babu Chapter 6. Implementation 66
6.1.4 Enforcing Video Advertisements on CLIENT browser
Enforcing USERs to view advertisements is an important requirement in the FRAC system
making it an effective advertising medium and boosts the revenues from ADVERTISERS.
Mentioned below are the common ways to publish video advertisements on CLIENT browser.
• New Window: Displaying video ads on a new window, common user response would
be to close the window.
• New Tab: Displaying video ads on a new tab, this will require more than just injecting
content scripts as there is no webpage on a new tab. Moreover, the user will close this
tab or switch to another tab when the ad is displayed.
• Current Tab: Displaying video ads on the current tab that the user is using. This can
be achieved by injecting the advertisement from the background page into the content
script on the page. Further, USER will not necessarily close this tab as he will lose
the current page but may switch to another tab.
These are the common USER responses when displaying video ads in different ways. Our
implementation uses a current tab video display mechanism to enforce video ads on the
Chrome browser.
6.1.4.1 Current Tab Video Display
We publish video ads on the USER’s current tab by injecting video ad data from the extension
background onto the content script of that page. If the USER shifts to a new tab, that page
is refreshed and the video ad is reloaded onto that page and resumes from where it left off
at the previous tab. This ensures that video ads are enforced on the Chrome browser, and
video ads do not restart again and rather resume from previous tab when the USER switches
between tabs. Figure 6.3 describes the current tab video display mechanism.
Lakshman Swaroop Babu Chapter 6. Implementation 67
Vid
eo
ele
men
t re
mo
ved
.
Rem
ove
d f
ram
e t
rack
ing
up
dat
e t
o b
ackgr
ou
nd
.
text
text
text
Tab
2:
con
ten
tscr
ipt.
js
Bac
kgr
ou
nd
Pag
e:
bac
kgr
ou
nd
.js
Tab
1:
con
ten
tscr
ipt.
js
v_ti
mer
en
ters
gra
ce p
eri
od
Sen
d v
ideo
dat
a to
cu
rren
t
tab
.
Sen
d v
ideo
dat
a to
Tab
1
Co
nte
nt
Scr
ipt
Get
vid
eo
dat
a fr
om
FR
AC
_S
ER
VE
R
Co
nte
nt
Scr
ipt
em
bed
s
vid
eo
in
to W
eb
Pag
e.
Tra
cks
vid
eo
fra
mes:
Vid
eo
is d
ivid
ed
in
to f
ram
es
&
up
dat
ed
to
th
e b
ack
gro
un
d
pag
e
Vid
eo
Sta
tus:
Fra
me 1
Vid
eo
Sta
tus:
Fra
me 2
Vid
eo
Sta
tus:
Fra
me 3
Cu
rren
t F
ram
e is
up
dat
ed
in
bac
kgr
ou
nd
web
sto
rage
.
CL
IEN
T s
wit
ches
fro
m
curr
en
t ta
b/o
pen
s n
ew
tab
or
clo
ses
curr
en
t ta
b.
Dete
cted
Eve
nt:
curr
en
t ta
b c
han
ged
.C
heck
s if
vid
eo
is
stre
amin
g.
If v
ideo
is
stre
amin
g, s
en
ds
vid
eo
dat
a an
d c
urr
en
t
fram
e t
o c
urr
en
t ta
b (
tab
2)
afte
r eve
nt.
Sen
d v
ideo
dat
a an
d c
urr
en
t
fram
e v
alu
e t
o t
ab 2
.
If v
ideo
is
stre
amin
g,
refr
esh
pag
e.
Vid
eo
str
eam
s fr
om
curr
en
t fr
ame. T
rack
s
vid
eo
an
d u
pd
ated
to
bac
kgr
ou
nd
pag
e.
Vid
eo
Sta
tus:
Fra
me 4
Vid
eo
Sta
tus:
Fra
me 5
Vid
eo
Sta
tus:
Fra
me 6
Vid
eo
Sta
tus:
Co
mp
lete
d
Cu
rren
t F
ram
e is
up
dat
ed
in
bac
kgr
ou
nd
web
sto
rage
.
Up
dat
e v
ideo
_w
atch
ed
to
1,
vid
eo
no
lo
nge
r st
ream
ing
Rem
ove
vid
eo
tag
s
fro
m w
eb
pag
e.
Rem
ove
vid
eo
tag
s
fro
m w
eb
pag
e.
Tim
er
exp
ires,
HT
TP
_V
AD
_N
OT
IFY
_R
EQ
sen
t to
FR
AC
_S
ER
VE
R
Vid
eo
ele
men
t re
mo
ved
,
vid
eo
sto
ps
pla
yin
g in
th
is
tab
. R
em
ove
d f
ram
e t
rack
ing
up
dat
e t
o b
ackgr
ou
nd
.
Fig
ure
6.3:
Curr
ent
Tab
Vid
eoD
ispla
y
Lakshman Swaroop Babu Chapter 6. Implementation 68
6.1.4.2 Trigger button mechanism
To ensure CLIENTs use the Chrome browser and do not shift to a new browser or use an
incognito window, we implement a trigger button mechanism. Trigger buttons popup at
random intervals on the video ads and banner ads which requires the USER to click on these
ads. If the user does not use the Chrome browser on which these buttons popup, the user will
not be able to click on these trigger buttons and this will be detected by the FRAC SERVER
and user loses internet access.
6.1.5 JavaScript Obfuscator
Since the CLIENT APP is a browser extension which is implemented using JavaScript, it is
open source to the CLIENT, which poses a security concern. In order to hide the code, we
perform code obfuscation which conceals the logic of the code to prevent tampering using
JavaScript Obfuscator software [35].
6.2 HOST AP Implementation
The access points used in HOST AP implementation are CISCO Linksys WRT54GL and
Linksys E1200. We use dd-wrt firmware on these routers, as these are Linux-based, open
source, stable and flexible embedded firmware which provide easy handling and several func-
tionalities within framework of the router’s basic hardware platform.
The HOST AP software is developed in C and can be installed on embedded systems such
as wireless routers with small amounts of flash memory and RAM. Most commercial home
routers commonly have MIPS or MIPSEL architecture as discussed earlier. The routers
used in our implementation have MIPSEL architecture, as such the HOST AP software is
compiled to run on this platform.
Lakshman Swaroop Babu Chapter 6. Implementation 69
6.2.1 Implementation Features
The HOST AP has to perform multiple operations and serve multiple CLIENTs at a time.
Our implementation is multithreaded using pthreads to handle multiple USER requests and
simultaneously send HTTP requests to the FRAC SERVER and CLIENTs. We use ipta-
bles API to dynamically allow and deny access to CLIENTs, provide firewall and CLIENT
isolation.
6.2.2 Router compatibility with dd-wrt
FRAC is based on the idea using existing infrastructure by creating HOST APs from most
wireless home routers being used today. Most Linux-based home routers like Linksys, Asus,
Netgear, Buffalo support dd-wrt today, though the extent of support varies. A detailed list
of routers is provided online [41] .
Since, there is a wide range of popular home routers that support dd-wrt, this will allow most
of the HOSTs to configure their wireless routers to act as HOST APs in the FRAC system,
at a small cost (cost of getting a suitable dd-wrt based home router which is around 40-60$
on the average) or no cost (if they already have a wireless router that supports dd-wrt).
6.2.3 Cross Compiling & MIPSEL architecture
We need to cross-compile the source code developed for the HOST AP into executable code
for MISPEL-based router firmware or compile the code in a native MIPSEL environment to
run it on the router. This is because the router is an embedded system which has limited
resources and does not have the capability to run a compiler or any development environment.
In our implementation, we cross-compile for MIPSEL target using an x86 host machine. We
use uClibc MIPSEL toolchain on Debian Linux x86 platform for cross-compiling to MIPSEL
executables [36] .
Lakshman Swaroop Babu Chapter 6. Implementation 70
6.2.4 LibHTTPD Web-Server API
The CLIENT APP and FRAC SERVER send JSON based HTTP requests to the HOST AP.
Since the HOST AP is a layer 3 device, it does not have any in-built web-based access. So,
we need a web-server and web-client implementation on the HOST AP to send and receive
messages from other FRAC elements.
LibHTTPD provides basic web-server capabilities to embedded systems such as routers [37].
It is an open-source lightweight C library which handles static and dynamic server content
and simplifies creation of web based application interfaces at low overhead. In our imple-
mentation, we incorporate LibHTTPD 1.4 API functions to provide web-server capabilities
for the HOST AP while making minor modifications to support the FRAC system.
6.2.5 Implementing JUMP using JSON-C
Unlike the CLIENT APP which works on the application layer, we do not have native JSON
support to parse and generate JSON. In order to provide JSON support in C, we use JSON-C
package which implements a lightweight reference counting object model [38]. Using JSON-
C, we can construct JSON objects in C, parse and generate JSON. JSON-C API is used to
implement JUMP functions, construct JUMP messages and parse received JUMP messages.
6.2.6 Wifidog Iptables API and Utility functions
Wifidog is a captive portal solution, which we discussed in the related work section. Wifi-
dog gateway was developed using C and is easily embeddable into routers. In our FRAC
HOST AP implementation, we use the list API functions from Wifidog for CLIENT database
operations and Wifidog utilities [25] such as functions to get the MAC and IP address of
interfaces and detect the external interface automatically. Further, we also modify the ipta-
bles functions and firewall APIs from Wifidog source code for compatibility with the FRAC
Lakshman Swaroop Babu Chapter 6. Implementation 71
system.
6.2.7 HTTPClient Web-Client API
To provide web-client capabilities to the HOST AP, we implemented a web-client API in C,
which is lightweight and can be easily integrated into the FRAC system. This web client
allows us to send HTTP requests to CLIENT APPs and FRAC SERVER.
Chapter 7
Evaluation
In this chapter, we evaluate the FRAC system model, design and implementation. We
broadly assess our design choices and discuss how these translate into better system perfor-
mance and quality characteristics.
7.1 Model Evaluation
The proposed model for providing free Wi-Fi to the public is self-sustainable. The evaluation
of this model is based on the assumption that design requirements are clearly satisfied by
the implementation. A self-sustainable system is established based on the following.
• Providing high value creative targeted advertising. Using foolproof mechanisms to
enforce users to participate in these advertising campaigns. Making FRAC system an
effective medium of advertising, which will provide increased revenue.
• Low or No Cost of Deployment. Potential HOSTs can easily convert their wireless
routers to act as HOST APs in the FRAC system. They are provided with suitable
benefits for opening up their access points for public use. DD-WRT firmware can be
72
Lakshman Swaroop Babu Chapter 7. Evaluation 73
loaded in most Linux-based routers and installing HOST AP software on these routers
is just a few steps away.
• Free CLIENT and HOST software with benefits. This motivates CLIENTs and HOSTs
to be part of the framework, increasing the number of USERs and HOSTs, and thereby
boosting revenue.
Potential Challenges in this model include the following.
• FRAC becomes self-sustainable based on the assumption that it creates an effective
advertising medium. This becomes a challenge as advertising trends and preferences
tend to differ across communities and locations. Revenues through online advertising
may not be substantial for self-sustenance.
• User Terms of Service may be a critical barrier for HOSTs to open up their internet for
public use. Like FON, we would need to establish agreements with ISPs/broadband
providers, so that HOSTs do not breach the terms of service by sharing their excess
bandwidth. This implies that significant portion of the revenue may be shared with
ISPs and broadband providers, thus reducing self-sustenance.
Nevertheless, despite these potential challenges our model will substantially offset costs of
deployment of a free public Wi-Fi system unlike any other.
7.2 Design Evaluation
In this section, we evaluate the design choices and discuss the potential weaknesses in the
design and suggest future enhancements to address these problems in the next chapter. We
evaluate design choices mainly with the following factors in mind - scalability, security, and
reliability.
Lakshman Swaroop Babu Chapter 7. Evaluation 74
• Designing a message exchange format which is lightweight, secure and provides reduced
amount of message and data exchange is critical. Two most popular commonly used
data exchange formats are JSON and XML, and the choice is application dependent.
We use JSON over XML to create a unified message exchange format mainly because
JSON is lightweight, uses simple formatting, has terse syntax and matches the data
models supported by most programming languages such as scalar data types, arrays and
objects. Even though, JSON is relatively new compared to XML, the support required
for our framework does not differ much between JSON and XML [40]. Since JSON
is natively supported in JavaScript [40], it makes the CLIENT APP implementation
simpler. Moreover, because of its lightweight implementation, JSON is better suited
for routers which have limited resources [38]. JSON parsing using eval() function
poses some potential security threats [40], which is resolved by using JSON.parse()
and JSON.stringify() functions which parse only JSON and not any other JavaScript
code.
JUMP is simply JSON with a unified set of fields for communication between the FRAC
elements. We do not use SOAP as it relies on XML for its message format which makes
it heavy and not suited for our application [8]. Making JUMP more RESTful may
provide some advantages at the cost of increased implementation complexity. REST
provides certain advantages which may not be required for our framework and JUMP
provides a much simpler implementation.
• The functional complexity at the HOST AP is reduced by design as the routers
have limited resources and as this improves the security of the system. This ensures
FRAC SERVER has control over the framework, so that HOST APs and CLIENTs
cannot dishonestly gain benefits from the framework. Except CLIENT authentica-
tion and expiry, all the other mechanisms are directly handled between CLIENT and
FRAC SERVER such as ADM, billing. This reduces the load and accountability of
the HOST AP providing more robustness.
Lakshman Swaroop Babu Chapter 7. Evaluation 75
• ADM design is implementation specific with different limitations depending on ar-
chitecture and platform. This reduces CLIENT APP portability and usability across
different devices.
• Designing Foolproof Mechanisms makes FRAC more reliable, secure and scalable.
FRAC SERVER responds to advertisement requests sent by CLIENTs only during
their grace period preventing unnecessary advertisement delivery. Changing banner
advertisement locations and enforcing video advertisements using trigger mechanisms
and current tab persistent video ad display are mechanisms which make FRAC more
reliable and secure for advertising and prevents bots.
• Suggested security features include selectively performing encryption and decryption
(TLS/HTTPS) between CLIENT APP and FRAC SERVER for critical messages. Au-
thentication mechanisms such as digital signatures and timestamps can be used for the
remaining messages. By selectively encrypting only critical messages, we can reduce
the system overhead and significantly improve scalability.
We also use firewalls to provide isolation and access restrictions. We authenticate
CLIENTs only after they connect to the HOST AP, which allows malicious CLIENTs
access to router. Providing layer 2 security, authenticating CLIENT on trying to
connect to HOST AP is a much challenging task [43].
7.3 Implementation Evaluation
We evaluate our prototype implementation in this section and discuss the areas for improve-
ment.
• Choosing the right firmware is an important implementation choice, as firmware sup-
ports different features which aids the design and extensibility of the system. Main
factors to be taken into consideration when choosing the firmware is router support
Lakshman Swaroop Babu Chapter 7. Evaluation 76
and support for functional features used in HOST AP software. Over the wide range of
open-source wireless router firmware available, dd-wrt and OpenWrt remain popular
choices due to the overwhelming router support for these firmware projects which pro-
vide the capability to install HOST AP software on most of the Linux-based wireless
home routers [42].
For our prototype implementation, we use dd-wrt because the base firmware on dd-wrt
is more functional compared to OpenWrt and dd-wrt has excellent router support [41].
It may be a good choice to use OpenWrt for creating production software, as it has
excellent feature support and extensibility.
• The CLIENT APP implemented is Chrome browser-specific and has to be modified
or recreated to support other popular browsers. CLIENT APP has more implementa-
tion specific design features, for example CLIENT APP design has to be modified for
smartphones as CLIENTs mostly use apps to access internet rather that the browser
in smartphones.
• CLIENT APP implementation poses certain serious security issues [44][45][46]. Since
CLIENT APP is written in JavaScript, the source code can be viewed by anyone us-
ing the extension. This will allow malicious clients to reconstruct the application to
function differently and remove all foolproof mechanisms and get around the adver-
tisements. We obfuscate the JavaScript using standard tools and software, which will
conceal the real meaning and intent of the JavaScript code. Moreover, using content-
scripts on CLIENT APP leads to cross-site scripting vulnerabilities such as retrieving
HTTP content on an HTTPS page because HTTP content might have been corrupted
by a man-in-the-middle over the network [44] [45] .
• The HOST AP software has to be cross-compiled for router specific architecture. Since
every router model is different, it has different dd-wrt firmware versions which reduces
the portability. Further, the HOST has complete control over the HOST AP, it can
act maliciously and make changes to the CLIENT network configuration. In order to
Lakshman Swaroop Babu Chapter 7. Evaluation 77
prevent that certain settings have to be made immutable and have to be hard-coded
into the firmware.
• The main goals for HOST AP software implementation includes stability, scalability,
and robustness. The HOST AP is developed in C which is lightweight, efficient and can
be cross-compiled to support different platforms. Our implementation provides concur-
rent execution via multithreading using pthreads with conservative memory handling
and error checking, message validation which improves performance and scalability.
The current firewall implementation does not have support for IPv6. Areas for im-
provement include standardizing API functions, improving firewall implementation.
Chapter 8
Future Work
8.1 Future Work on FRAC Prototype Software
To extend the current implementation of our prototype model, we are currently working
on the following improvements which include the FRAC SERVER implementation, firewall
enhancements, QoS, security, billing mechanism implementation.
8.2 App-based CLIENT APP Design
We have designed and implemented a browser-based CLIENT APP in this prototype. Sub-
stantial traffic in the internet nowadays comes from smart devices and Wi-Fi has been an
integral feature on these device for several years. Designing app-based CLIENT APP allows
us to target a much larger and affordable USER base. The CLIENT APP design for smart-
phones and tablets has to be designed to support app-based web access, rather than using
web browsers.
An ground plan of the overall design of the Android app-based CLIENT APP is shown in the
figure, where the CLIENT APP interrupts the currently active app when the timer expires
78
Lakshman Swaroop Babu Chapter 8. Future Work & Vision 79
using startActivity() which allows the CLIENT APP to be placed at the top of the activity
stack [47].
USER activity
interrupted by
CLIENT_APP
CLIENT_APP OTHER_APPsFRAC NETWORK
CLIENT Authentication
HTTP_VAD_REQ to
FRAC_SERVER
text
HOST AP
timer expires
Ad DisplayedHTTP Notification Requests sent
to FRAC_SERVER
timer starts
startActivity()
*Currently active APP on the device is shaded.
Figure 8.1: Oveview of an App-based CLIENT APP design
8.3 Plugins: NPAPI vs. NativeClient (NaCl)
CLIENT APP implementation uses Chrome extensions is open-source, which poses an im-
portant security concern. A common way to include proprietary code in the extension is to
use Netscape Plugin Application Programming Interface (NPAPI) plugins with the extension
which allows us to call native binary code from JavaScript [50].
NPAPI poses an important security threat as the code running in a NPAPI plugin has full
permissions and is not shielded from malicious input from the browser platform. Cross-side
Lakshman Swaroop Babu Chapter 8. Future Work & Vision 80
scripting attacks become more common when working with content scripts and AJAX HTTP
requests which process input from questionable sources. Allowing the plugin unrestricted
access poses a big security vulnerability, may allow attackers to install malicious software on
USER’s machine.
Native Client is a sandboxing technology used to run native code securely on the browser. It
expands the scope of web programming beyond JavaScript, allowing web-based applications
to achieve close to native system performance [48] [49]. A sandbox provides a virtual isolated
environment with controlled resources for guest programs to run in. NaCl uses a double
sandbox to protect system resources. A web application which uses NativeClient will have
JavaScript, HTML and CSS along with a sandboxed NativeClient module bridged by Pepper
API. Pepper API provides a communication interface between NaCl modules and JS code
to create and use browser resources. Further, NativeClient allows same level of portability
for C and C++ as JavaScript.
Bridge
Pepper
Native Client Module
Browser
HTML, CSS, JavaScript
Figure 8.2: Native Client Overview
Using NaCl can provide a solid way to embed proprietary code in the CLIENT APP with
improved security features. This will allow the CLIENT APP to more control in shielding
Lakshman Swaroop Babu Chapter 8. Future Work & Vision 81
loopholes in the ADM and authentication mechanisms.
8.4 Automatic Network Discovery and Selection
CLIENT has to manually choose a HOST AP in the FRAC network which poses security
concerns, as a malicious entity can act as a HOST AP in the FRAC network and get crit-
ical data or harm the user. Automatic network discovery and selection feature allows the
CLIENT APP to identify and associate with the HOST AP automatically without any inter-
vention from the USER, ensuring the CLIENT connects to a valid HOST AP. This feature
is currently being released in Wi-Fi certified Passpoint devices [16].
8.5 From Prototype Software to Production Software
There are other challenges apart from the standard steps involved in converting a prototype
to a production software, such as error-handling, input validation, unit testing, solid API
design, logging and documentation. Creating an effective method to automatically update
software across CLIENTs and HOSTs in the framework provides the flexibility to make
changes to FRAC system. Autoconf is an extensible suite which uses shell scripts to au-
tomatically configure software packages to adapt them to many Unix-based systems with
different OS and features [51]. Using autotools to install HOST AP software on different
router architectures can improve portability to an extent.
8.6 Effective Advertising
Our efforts till now have focused on building a functional prototype for this model. Creating
an effective advertising medium is an important requirement for self-sustainability of this
framework. This can be achieved by designing high value creative advertising schemes using
Lakshman Swaroop Babu Chapter 8. Future Work & Vision 82
location-based advertising and supporting new advertisements and marketing methods like
surveys, rich media advertisements and interactive advertising schemes. Providing more
flexibilities to USERs can improve the confidence on the framework in the market. For
example, allowing users a time window over which they can choose to watch advertisements,
so that they are not interrupted frequently.
Chapter 9
Conclusion
FRAC is a self-sustainable advertisement-based community network sharing framework which
provides users free internet access. We provided a detailed overview of the framework and
formulated the quality and functional requirements to satisfy user expectations, efficiency
and ensure the system functions correctly. This thesis describes the main features of the
FRAC system such as CLIENT and HOST authentication, advertisement delivery mech-
anism, quality of service, security, unified message format etc. based on which an overall
design of the key elements of our framework is formulated.
A prototype implementation of FRAC is detailed in this thesis. We implemented a Chrome
browser extension to support FRAC on browser-based CLIENT devices like laptops and de-
veloped an embeddable HOST gateway software using C on dd-wrt firmware for Linux-based
routers. We evaluated our system model, design and implementation which indicates FRAC
is self-sustainable, lightweight and scalable overall. Further, our evaluation also indicates
potential challenges such as portability due to platform specific design, security issues of
an open source CLIENT APP, for which we suggest additional solutions and enhancements
in the future work section. Overall this thesis provides a proof-of-concept version of the
proposed model, and provides insight into potential barriers, suggests solutions and future
enhancements to develop the framework.
83
Bibliography
[1] WBA Industry Report, Global developments in public WiFi, http://www.wballiance.
com/resource-centre/global-developments-wifi-report.html, Nov, 2012.
[2] Bar, F., & Park, N. (2006). Municipal Wi-Fi networks: The goals, practices, and policy
implications of the US case. Communications & Strategies, 61(1), 107-125.
[3] Understanding the Role of Managed Public Wi-Fi in Today’s Smartphone User Experi-
ence, Informa Telecoms & Media, Feb, 2013
[4] Understanding today’s smartphone user, white paper, Informa Telecoms & Media, Au-
gust, 2012
[5] Chrome extensions. http://developer.chrome.com/extensions
[6] S. C. C. Rita J. Cressy, “Iptables,” LeRoy D. Cressy, 2004
[7] Iptables. http://linux.die.net/man/8/iptables
[8] Kumar, Pavan, et al. “Comparing Performance of Web Service Interaction Styles: SOAP
vs. REST.” Journal of Information Systems Applied Research 6.1 (2013): 4.
[9] 2012 Internet Advertising Revenue Full-Year Report, http://www.iab.net/
AdRevenueReport, 2012
[10] Digital Video Ad Format Guidelines & Best Practices, http://www.iab.net/
guidelines/508676/digitalvideo/DV_Guidelines, May 2008.
84
Lakshman Swaroop Babu Bibliography 85
[11] Broder, Andrei, Vanja Josifovski, and Jayavel Shanmugasundaram. “Introduction to
display advertising: a half-day tutorial.” Proceedings of the fourth ACM international
conference on Web search and data mining. ACM, 2011.
[12] Toolchains. http://www.linux-mips.org/wiki/Toolchains
[13] Introduction to cross-compiling for Linux http://landley.net/writing/docs/
cross-compiling.html
[14] DD-WRT. http://www.dd-wrt.com
[15] WISPr 2.0, Wireless Broadband Alliance, March 2010.
[16] Wi-Fi CERTIFIED Passpoint, white paper, Wi-Fi Alliance, updated June 2012
[17] Aboba, Bernard, et al. “RFC 3748-Extensible authentication protocol (EAP).” Network
Working Group (2004).
[18] 802.1X: Port-Based authentication standard for network access control (NAC), white
paper, Juniper Networks, Inc., 2010
[19] Rigney, C., Willens, S., Rubens, A. and W. Simpson, ”Remote Authentication Dial In
User Service (RADIUS)”, RFC 2865, June 2000
[20] Rigney, C. “RFC 2866: RADIUS Accounting.” Network Working Group June (2000).
[21] RADIUS Protocol Security and Best Practices, http://technet.microsoft.com/
en-us/library/bb742489.aspx, Jan 2002.
[22] Calhoun, P., et al. “RFC 3588-Diameter Base Protocol.” Network Working Group
(2003).
[23] Chillispot.http://www.chillispot.info
Lakshman Swaroop Babu Bibliography 86
[24] Brunato, Mauro, and Danilo Severina. ”WilmaGate: a new open access gateway for
hotspot management.” Proceedings of the 3rd ACM international workshop on Wireless
mobile applications and services on WLAN hotspots. ACM, 2005.
[25] Wifidog captive portal suite. http://dev.wifidog.org
[26] PacketFence: Open Source NAC .http://www.packetfence.org
[27] CoovaChilli.http://coova.org/CoovaChilli
[28] Pfsense Open Source Firewall Distribution. http://www.pfsense.org
[29] M0n0wall: Free embedded firewall software.http://m0n0.ch/wall
[30] EasyHotspot, open source Hotspot Management System. http://easyhotspot.inov.
asia
[31] Fon. www.fon.com
[32] JSON. http://www.json.org
[33] Multiple WLANs. http://www.dd-wrt.com/wiki/index.php/Multiple_WLANs
[34] How to setup multiple BSSIDs using DD-WRT. http://www.pennock.nl/dd-wrt/
Multiple_BSSIDs.html
[35] JavaScript Obfuscator. http://javascript-source.com
[36] MIPSEL Cross-compiler. http://www.uclibc.org/toolchains.html
[37] LibHTTPD : Embedded web server library http://www.hughes.com.au/products/
libhttpd/libhttpd.pdf
[38] JSON-C - A JSON implementation in C. https://github.com/json-c/json-c/wiki
[39] Linux Firewalls Using iptables http://www.linuxhomenetworking.com/wiki/index.
php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables
Lakshman Swaroop Babu Bibliography 87
[40] An Introduction to JavaScript Object Notation (JSON). http://msdn.microsoft.
com/en-us/library/bb299886.aspx
[41] List of DD-WRT supported devices. http://www.dd-wrt.com/wiki/index.php/
Supported_Devices
[42] Heldenbrand, David, and Christopher Carey. “The Linux router: an inexpensive alter-
native to commercial routers in the lab.” Journal of Computing Sciences in Colleges 23.1
(2007): 127-133.
[43] Choi, J.; Sang-Yoon Chang; Diko Ko; Yih-Chun Hu, “Secure MAC-Layer Protocol for
Captive Portals in Wireless Hotspots,” Communications (ICC), 2011 IEEE International
Conference on , vol., no., pp.1,5, 5-9 June 2011
[44] Barth, Adam, et al. “Protecting browsers from extension vulnerabilities.” 17th Network
and Distributed System Security Symposium. 2010.
[45] Liu, Lei, et al. “Chrome extensions: Threat analysis and countermeasures.” Proceeding
of the Network and Distributed System Security Symposium, NDSS. 2012.
[46] Carlini, Nicholas, Adrienne Porter Felt, and David Wagner. “An evaluation of the google
chrome extension security architecture.” Proceedings of the 21st USENIX Conference on
Security. 2012.
[47] Activity class in Android.
[48] Native Client. https://developers.google.com/native-client
[49] Yee, B.; Sehr, D.; Dardyk, G.; Chen, J.B.; Muth, R.; Ormandy, T.; Okasaka, S.; Narula,
N.; Fullagar, N., “Native Client: A Sandbox for Portable, Untrusted x86 Native Code,”
Security and Privacy, 2009 30th IEEE Symposium on , vol., no., pp.79,93, 17-20 May
2009
Lakshman Swaroop Babu Bibliography 88
[50] Netscape Plugin Application Programming Interface (NPAPI). https://wiki.
mozilla.org/NPAPI http://developer.android.com/reference/android/app/
Activity.html
[51] Calcote, John. Autotools: A Practitioner’s Guide to GNU Autoconf, Automake, and
Libtool. No Starch Press, 2010.
Appendix A
JSON Unified Messaging Protocol
The fields in the JSON schema are the following.
client_id : CLIENT_APP Unique Identifier
status : Response Status/Result of REQUEST message.
message : Message Type
protocol_version : Protocol Version Number
software_version : Software Version Number
session_id : Unique Identifier for every REQ-RESP
server_id : FRAC_SERVER Unique Identifier
vad_id : Video AD Unique Identifier
vad_time : Duration of Video ad received
v_timer : Set Video AD Timer value
b_timer : Set Banner AD Timer value
ap_id : HOST AP Unique Identifier
JSON Schema
defaults : {
"client_id" : {
"type" : "string",
"value" : "6ge3T9pf"
},
"message" : {
"type" : "number",
89
Lakshman Swaroop Babu Appendix 90
"value" : "10"
},
"protocol_version" : {
"type" : "string",
"value" : "1.1"
},
"software_version" : {
"type" : "string",
"value" : "1.0"
},
"session_id" : {
"type" : "string",
"value" : "sid"
}
}
server: {
"server_id" : {
"type" : "string",
"value" : "sid"
},
"v_timer" : {
"type" : "number",
"value" : "0"
},
"b_timer" : {
"type" : "number",
"value" : "0"
},
"vad_time" : {
"type" : "number",
"value" : "0"
},
"vad_id" : {
"type" : "string",
"value" : "vid"
},
}
ap: {
"ap_id" : {
"type" : "string",
"value" : "apid"
Lakshman Swaroop Babu Appendix 91
}
}
Message Codes
Nodes Src Dst Message Type Abbreviation Code
Client-APC A Client Authentication Request HTTP CLIENT AUTH REQ 10
A C Client Authentication Response HTTP CLIENT AUTH RESP 13
AP-Server
A S AP Authentication Request HTTP AP AUTH REQ 20
S A AP Authentication Response HTTP AP AUTH RESP 21
S A Server Expiry Request HTTP EXP REQ 22
A S Server Expiry Response HTTP EXP RESP 23
A S AP Keepalive Request HTTP AP KA REQ 24
A S AP Keepalive Response HTTP AP KA RESP 25
Client-Server
C S Video Advertisement Request HTTP VAD REQ 30
S C Video Advertisement Response HTTP VAD RESP 31
C S Video watched Notification Request HTTP VAD NOTIFY REQ 32
S C Video watched Notification Response HTTP VAD NOTIFY RESP 33
C S Banner Advertisement Request HTTP BAD REQ 34
S C Banner Advertisement Response HTTP BAD RESP 35
*Note: C indicates CLIENT APP, S indicates FRAC SERVER and A indicates HOST AP
Status codes
Status Code Description
1xxx Success. Valid request.
2xxx Unauthorized request.
3xxx CLIENT APP error.
4xxx HOST AP error. (FRAC SERVER)
5xxx FRAC SERVER error. (HOST AP)
6xxx Bad request. Request could not be understood
due to invalid syntax.
Lakshman Swaroop Babu Appendix 92
Message Formats
HTTP_CLIENT_AUTH_REQ
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "cl2h03t1",
"message": 10,
"client_id": "6ge3T9pf"
}
HTTP_CLIENT_AUTH_RESP
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "cl2h03t1",
"message": 13,
"status": 1000,
"ap_id": "aw54fg31",
"server_id": "s35v351d",
"client_id": "6ge3T9pf",
"v_timer": 10,
"b_timer": 2
}
HTTP_AP_AUTH_REQ
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "h03t2fs5",
"message": 20,
"ap_id": "aw54fg31",
"client_id": "6ge3T9pf",
"server_id": "s35v351d",
}
HTTP_AP_AUTH_RESP
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "h03t2fs5",
"message": 21,
"status": 1000,
"ap_id": "aw54fg31",
"client_id": "6ge3T9pf",
"server_id": "s35v351d",
"v_timer": 10,
"b_timer": 2
}
HTTP_EXP_REQ
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "cl3xp15y",
"message": 22,
"server_id": "s35v351d",
"ap_id": "aw54fg31",
"client_id": "6ge3T9pf"
}
HTTP_EXP_RESP
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "cl3xp15y",
"message": 23,
"status": 1000,
"server_id": "s35v351d",
"ap_id": "aw54fg31",
"client_id": "6ge3T9pf"
}
Lakshman Swaroop Babu Appendix 93
HTTP_AP_KA_REQ
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "k39a11v3",
"message": 24,
"server_id": "s35v351d",
"ap_id": "aw54fg31"
}
HTTP_AP_KA_RESP
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "k39a11v3",
"message": 25,
"status": 1000,
"server_id": "s35v351d",
"ap_id": "aw54fg31"
}
HTTP_VAD_REQ
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "vad53q5t",
"message": 30,
"server_id": "s35v351d",
"client_id": "6ge3T9pf"
}
HTTP_VAD_RESP
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "vad53q5t",
"message": 31,
"status": 1000,
"server_id": "s35v351d",
"client_id": "6ge3T9pf",
"vad_time": 36,
"vad_id": "qw12er34"
}<video advertisement data>
HTTP_VAD_NOTIFY_REQ
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "vad53q5t",
"message": 32,
"server_id": "s35v351d",
"client_id": "6ge3T9pf",
"vad_id": "qw12er34"
}
HTTP_VAD_NOTIFY_RESP
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "vad53q5t",
"message": 33,
"status": 1000,
"server_id": "s35v351d",
"client_id": "6ge3T9pf",
"v_timer": 7
}
Lakshman Swaroop Babu Appendix 94
HTTP_BAD_REQ
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "bads3q5t",
"message": 34,
"server_id": "s35v351d",
"client_id": "6ge3T9pf"
}
HTTP_BAD_RESP
{
"protocol_version": "1.1",
"software_version": "1.0",
"session_id": "bads3q5t",
"message": 35,
"status": 1000,
"server_id": "s35v351d",
"client_id": "6ge3T9pf",
"b_timer": 1
}<banner advertisement data>