Demo Abstract: A Research Platform for Real-World Evaluation of Routing Schemes in Delay Tolerant Social Networks %A Case Study on the Need for an Opportunistic Routing testbed for In vivo
\IEEEauthorblockN{Michael Shell
% \IEEEauthorblockN{Corey E. Baker
\IEEEauthorblockN{Corey E. Baker\textsuperscript{1
\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1
% %----------------------------------------------------------------------------- % % Online social networks continue to thrive and serve hundreds % % to millions of mobile and active users. % % % % % In recent years, a number of social-aware and social-based % % routing schemes have been developed that leverage social % % interactions to deliver data in delay tolerant networks (DTNs), % % including a distributed mobile social networking protocol developed by the authors. % % % % % However, a major challenge of DTN research is how to assess % % real-world performance? % % % % % Simulation analysis of DTN networks can lead to unrealistic expectations in terms of performance metrics, such as message delivery, delay, and routing performance. % % % % % It is ideal to test DTN protocols in environments % % that reflect the real use-cases for which they are designed. % % % % % In this paper, we present the AlleyOop Social Networking testbed, which is a real-life secure mobile social network application. After an overview % % of related work in DTN, the paper describes the AlleyOop Social app, which allows users to interact, publish messages, and discover others % % that share common interests without accessing any cellular or WiFi access infrastructure. The AlleyOop system architecture is then described and followed by a discussion of security and privacy management. Finally, a small-scale testbed experiment is presented which provides results for usage, message delivery, delay and routing performance. % % % %AlleyOop Social can be used to analyze a variety of use cases, from every day social use to coordinated focused use, such as first responder emergency scenarios. % % % %The AlleyOOp architecture is described as well as security management for this ad hoc % % % %A small-scale test has been performed that provides perfomance results on a specific group's social media usage and the performance of the ad hoc network with respect to message delivery, delay, routing. ed The testbed collects sanitized data are collected and performance results are provided based on message delivery statistics, locality and evolving social structures. % % % %A survey was conducted to determine the participant's usage of current social media platforms, as well as patterns of Internet availability for the participants, and to gauge various possible use cases for the AlleyOop Social app. % Over the past decade, online social networks (OSNs) such as Twitter and Facebook have thrived and experienced rapid growth to over 1 billion users. % %OSNs have become a major tool for 21st century message dissemination and offers a platform ranging from advertising to socializing with friends to social justice response. % % % %Unfortunately, as the name implies, OSNs require Internet availability to function, redu % A major evolution would be to leverage the characteristic of OSNs to evaluate the effectiveness of the many routing schemed developed by the research community in real-world scenarios. %opportunistically % %in developing communities that have limited Internet access or during times when centralized infrastructures are compromised. %Recent products like WiFi Direct, Bluetooth, and LTE-D, allow mobile devices to communicate directly with each other without the need of an access point or cellular tower. However, with these devices, messages are local and do not travel out of the aforementioned radio communication ranges of the originating devices, e.g., from phone to printer, or for gaming in a co-located group. %D2D communication alone does not address the need of delivering information in an intermittent social group. % In this demo, we showcase the AlleyOop Social, a secure delay tolerant networking research platform that serves as a real-life mobile social networking application for iOS devices. AlleyOop Social allows users to interact, publish messages, and discover others that share common interests in an intermittent network using Bluetooth, peer-to-peer WiFi, and infrastructure WiFi. The research platform serves as an overlay application for the SOS middleware which allows different routing schemes to be easily implemented relieving the burden of security and connection establishment. % \\ % %To validate the capabilities of AlleyOop Social, a small-scale (10 devices) field experiment was conducted. % %In addition, a case study was conducted to identify possible settings in which the AlleyOop Social app is desirable. %
infocom_demo.tex

%% bare_conf.tex
%% V1.4b
%% 2015/08/26
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.8b or later) with an IEEE
%% conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/pkg/ieeetran
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall the IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%*************************************************************************


% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. The IEEE's font choices and paper sizes can   ***
% *** trigger bugs that do not appear when using other class files.       ***                          ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



\documentclass[conference]{IEEEtran}
% Some Computer Society conferences also require the compsoc mode option,
% but others use the standard conference format.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/pkg/ifpdf
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of the IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off
% such as if a citation ever needs to be enclosed in parenthesis.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 5.0 (2009-03-20) and later if using hyperref.sty.
% The latest version can be obtained at:
% http://www.ctan.org/pkg/cite
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
   \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
   \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation
% can be obtained at: 
% http://www.ctan.org/pkg/graphicx
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found at:
% http://www.ctan.org/pkg/epslatex
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). The IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics.
%
% Note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/pkg/amsmath





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as the IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/pkg/algorithms
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/pkg/algorithmicx




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/pkg/array


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.




% *** SUBFIGURE PACKAGES ***
%\ifCLASSOPTIONcompsoc
%  \usepackage[caption=false,font=normalsize,labelfont=sf,textfont=sf]{subfig}
%\else
  \usepackage[caption=false,font=footnotesize]{subfig}
%\fi
% subfig.sty, written by Steven Douglas Cochran, is the modern replacement
% for subfigure.sty, the latter of which is no longer maintained and is
% incompatible with some LaTeX packages including fixltx2e. However,
% subfig.sty requires and automatically loads Axel Sommerfeldt's caption.sty
% which will override IEEEtran.cls' handling of captions and this will result
% in non-IEEE style figure/table captions. To prevent this problem, be sure
% and invoke subfig.sty's "caption=false" package option (available since
% subfig.sty version 1.3, 2005/06/28) as this is will preserve IEEEtran.cls
% handling of captions.
% Note that the Computer Society format requires a larger sans serif font
% than the serif footnote size font used in traditional IEEE formatting
% and thus the need to invoke different subfig.sty package options depending
% on whether compsoc mode has been enabled.
%
% The latest version and documentation of subfig.sty can be obtained at:
% http://www.ctan.org/pkg/subfig




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure.
% Be aware that LaTeX2e kernels dated 2015 and later have fixltx2e.sty's
% corrections already built into the system in which case a warning will
% be issued if an attempt is made to load fixltx2e.sty as it is no longer
% needed.
% The latest version and documentation can be found at:
% http://www.ctan.org/pkg/fixltx2e


%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/pkg/stfloats
% Do not use the stfloats baselinefloat ability as the IEEE does not allow
% \baselineskip to stretch. Authors submitting work to the IEEE should note
% that the IEEE rarely uses double column equations and that authors should try
% to avoid such use. Do not be tempted to use the cuted.sty or midfloat.sty
% packages (also by Sigitas Tolusis) as the IEEE does not format its papers in
% such ways.
% Do not attempt to use stfloats with fixltx2e as they are incompatible.
% Instead, use Morten Hogholm'a dblfloatfix which combines the features
% of both fixltx2e and stfloats:
%
% \usepackage{dblfloatfix}
% The latest version can be found at:
% http://www.ctan.org/pkg/dblfloatfix




% *** PDF, URL AND HYPERLINK PACKAGES ***
%
\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version and documentation can be obtained at:
% http://www.ctan.org/pkg/url
% Basically, \url{my_url_here}.




% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}

% *** COREY ADDED PACKAGES ***
\graphicspath{{pdf/}{jpeg/}{png/}{eps/}{figures/}}
\DeclareGraphicsExtensions{.pdf,.jpeg,.png,.eps}
\usepackage{algorithmic}
\usepackage[table]{xcolor}
\usepackage{multirow}
\usepackage{listings}
%\usepackage{hyperref}
\usepackage{stfloats}
\usepackage{balance}
\usepackage{soul}
\usepackage[normalem]{ulem}
\usepackage{cancel}

% *** Custom functions ***
\newcommand{\specialcell}[2][c]{%
  \begin{tabular}[#1]{@{}c@{}}#2\end{tabular}}

\newcommand{\cb}[1]{{\color{red}{\textbf{COREY:} #1}}}
\newcommand{\as}[1]{{\color{red}{\textbf{ALLEN:} #1}}}
\newcommand{\thj}[1]{{\color{red}{\textbf{TANISHA:} #1}}}
\newcommand{\jm}[1]{{\color{red}{\textbf{JANISE:} #1}}}
\newcommand{\Expect}{\mathbb{E}}

\newcommand{\add}[1]{{\color{blue}{#1}}}
\newcommand{\remove}[1]{{\color{red}{\st{#1}}}}

\newcommand{\replace}[2]{\remove{#1} \add{#2}}


\begin{document}
%
% paper title
% Titles are generally capitalized except for words such as a, an, and, as,
% at, but, by, for, in, nor, of, on, or, the, to and up, which are usually
% not capitalized unless they are the first or last word of the title.
% Linebreaks \\ can be used within to get better formatting as desired.
% Do not put math or special symbols in the title.
\title{Demo Abstract: A Research Platform for Real-World Evaluation of Routing Schemes in Delay Tolerant Social Networks %A Case Study on the Need for an Opportunistic Routing testbed for \textit{In vivo} Evaluation%testbed for Delay Tolerant Social Networks
}


% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
%\author{\IEEEauthorblockN{Michael Shell}
%\IEEEauthorblockA{School of Electrical and\\Computer Engineering\\
%Georgia Institute of Technology\\
%Atlanta, Georgia 30332--0250\\
%Email: http://www.michaelshell.org/contact.html}
%\and
%\IEEEauthorblockN{Homer Simpson}
%\IEEEauthorblockA{Twentieth Century Fox\\
%Springfield, USA\\
%Email: homer@thesimpsons.com}
%\and
%\IEEEauthorblockN{James Kirk\\ and Montgomery Scott}
%\IEEEauthorblockA{Starfleet Academy\\
%San Francisco, California 96678--2391\\
%Telephone: (800) 555--1212\\
%Fax: (888) 555--1212}}

% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
% \author{
% \IEEEauthorblockN{Corey E. Baker} 
% \IEEEauthorblockA{
% %Department of Electrical \\ 
% %and Computer Engineering, 
% University of California\\
% Email: cobaker@eng.ucsd.edu
% }
% \and
% \IEEEauthorblockN{Allen Starke} 
% \IEEEauthorblockA{
% %Department of Electrical \\
% %and Computer Engineering \\
% University of Florida\\
% Email: allen1.starke@ufl.edu
% }
% \and
% \IEEEauthorblockN{Shitong Xing}
% \IEEEauthorblockA{
% %Department of Electrical \\ 
% %and Computer Engineering, 
% University of California, San Diego\\
% Email: sxing@ucsd.edu
% }
% \and
% \IEEEauthorblockN{Janise McNair}
% \IEEEauthorblockA{
% %Department of Electrical \\
% %and Computer Engineering \\
% University of Florida\\
% Email: mcnair@ece.ufl.edu
% }}

\author{\IEEEauthorblockN{Corey E. Baker\textsuperscript{1}, Allen Starke\textsuperscript{2}, Shitong Xing\textsuperscript{1}, Janise McNair\textsuperscript{2}}
\IEEEauthorblockA{
\textsuperscript{1}Department of Electrical and Computer Engineering, University of California, San Diego\\
\textsuperscript{2}Department of Electrical and Computer Engineering, University of Florida\\
Email: cobaker@eng.ucsd.edu, allen1.starke@ufl.edu, sxing@ucsd.edu, mcnair@ece.ufl.edu}}

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% 
%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
%Homer Simpson\IEEEauthorrefmark{2},
%James Kirk\IEEEauthorrefmark{3}, 
%Montgomery Scott\IEEEauthorrefmark{3} and
%Eldon Tyrell\IEEEauthorrefmark{4}}
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
%Georgia Institute of Technology,
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
%Email: homer@thesimpsons.com}
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle

% As a general rule, do not put math, special symbols or citations
% in the abstract
% \begin{abstract}
% %-----------------------------------------------------------------------------
% % Online social networks continue to thrive and serve hundreds
% % to millions of mobile and active users. 
% % %
% % In recent years, a number of social-aware and social-based 
% % routing schemes have been developed that leverage social 
% % interactions to deliver data in delay tolerant networks (DTNs), 
% % including a distributed mobile social networking protocol developed by the authors. 
% % %
% % However, a major challenge of DTN research is how to assess 
% % real-world performance? 
% % %
% % Simulation analysis of DTN networks can lead to unrealistic expectations in terms of performance metrics, such as message delivery, delay, and routing performance. 
% % %
% % It is ideal to test DTN protocols in environments 
% % that reflect the real use-cases for which they are designed. 
% % %
% % In this paper, we present the AlleyOop Social Networking testbed, which is a real-life secure mobile social network application. After an overview
% %  of related work in DTN, the paper describes the AlleyOop Social app, which allows users to interact, publish messages, and discover others 
% % that share common interests without accessing any cellular or WiFi access infrastructure. The AlleyOop system architecture is then described and followed by a discussion of security and privacy management. Finally, a small-scale testbed experiment is presented which provides results for usage, message delivery, delay and routing performance.
% %
% %AlleyOop Social can be used to analyze a variety of use cases, from every day social use to coordinated focused use, such as first responder emergency scenarios. 
% %
% %The AlleyOOp architecture is described as well as security management for this ad hoc 
% %
% %A small-scale test has been performed that provides perfomance results on a specific group's social media usage and the performance of the ad hoc network with respect to message delivery, delay, routing. ed The testbed collects sanitized data are collected and performance results are provided based on message delivery statistics, locality and evolving social structures.
% %
% %A survey was conducted to determine the participant's usage of current social media platforms, as well as patterns of Internet availability for the participants, and to gauge various possible use cases for the AlleyOop Social app.

% Over the past decade, online social networks (OSNs) such as Twitter and Facebook have thrived and experienced rapid growth to over 1 billion users. 
% %OSNs have become a major tool for 21st century message dissemination and offers a platform ranging from  advertising to  socializing with friends to social justice response.
% %
% %Unfortunately, as the name implies, OSNs require Internet availability to function, redu
% A major evolution would be to leverage the characteristic of OSNs to evaluate the effectiveness of the many routing schemed developed by the research community in real-world scenarios. %opportunistically 
% %in developing communities that have limited Internet access or during times when centralized infrastructures are compromised. %Recent products like WiFi Direct, Bluetooth, and LTE-D, allow mobile devices to communicate directly with each other without the need of an access point or cellular tower. However, with these devices, messages are local and do not travel out of the aforementioned radio communication ranges of the originating devices, e.g., from phone to printer, or for gaming in a co-located group. %D2D communication alone does not address the need of delivering information in an intermittent social group.
% In this demo, we showcase the AlleyOop Social, a secure delay tolerant networking research platform that serves as a real-life mobile social networking application for iOS devices. AlleyOop Social allows users to interact, publish messages, and discover others that share common interests in an intermittent network using Bluetooth, peer-to-peer WiFi, and infrastructure WiFi. The research platform serves as an overlay application for the SOS middleware which allows different routing schemes to be easily implemented relieving the burden of security and connection establishment. 
% \\

% %To validate the capabilities of AlleyOop Social, a small-scale (10 devices) field experiment was conducted. 
% %In addition, a case study was conducted to identify possible settings in which the AlleyOop Social app is desirable.
  
% \end{abstract}

% no keywords
% \begin{IEEEkeywords}
% opportunistic communication, delay tolerant networking, routing, device-to-device, peer-to-peer, ad-hoc, Bluetooth, WiFi, social network, middleware, mobile applications, research platform, real-world evaluation, testbeds
% \end{IEEEkeywords}



% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle


\section{Introduction}\label{sec_intro}
% no \IEEEPARstart

% You must have at least 2 lines in the paragraph with the drop letter
% (should never be an issue)
%-----------------------------------------------------------------------------
Over the past decade, online social networks (OSNs) such as Twitter and Facebook have thrived and experienced rapid growth to over 1 billion users~\cite{faloutsos2010online}. 
%OSNs have become a major tool for 21st century message dissemination and offers a platform ranging from  advertising to  socializing with friends to social justice response.
%
%Unfortunately, as the name implies, OSNs require Internet availability to function, redu
A major evolution would be to leverage the characteristics of OSNs to evaluate the effectiveness of the many routing schemes developed by the research community in real-world scenarios. %opportunistically 
%in developing communities that have limited Internet access or during times when centralized infrastructures are compromised. %Recent products like WiFi Direct, Bluetooth, and LTE-D, allow mobile devices to communicate directly with each other without the need of an access point or cellular tower. However, with these devices, messages are local and do not travel out of the aforementioned radio communication ranges of the originating devices, e.g., from phone to printer, or for gaming in a co-located group. %D2D communication alone does not address the need of delivering information in an intermittent social group.
%
In natural disaster situations, Internet and cellular 
communication infrastructures can be severely disrupted, prohibiting users from 
notifying family, friends, and associates about safety, location, food, water, and 
other resources. 
%
Disasters typically damage infrastructure, which increases network traffic demands 
on any available undamaged infrastructure, causing congestion and delays.
%


Opportunistic communication can seamlessly supplement Internet connectivity 
when needed and keep communication channels open even during high-use and 
extreme situations.
% Over the past 10-12 years, Internet-based, or online social networks (OSNs), 
% like Twitter and Facebook have thrived and experienced rapid growth to serve
% over 1 billion users (1.5 billion in the case of Facebook, and 300 million in 
% the case of Twitter)~\cite{faloutsos2010online}.
% %
% %Originally, OSNs were mainly used for establishing social connections with 
% %friends, colleagues and family. 
% %
% %However, OSNs have grown in their application and are now used to access 
% %large numbers of people for forming social groups, entertainment, natural 
% %disasters, or responding to social justice issues. 
% %
% %A major evolution of these networks would be to disconnect them from the 
% %Internet to create a true, people-centric and opportunistic social 
% %network. 
% %
% A major shortcoming of OSNs is the dependence on Internet which is often 
% sparse, difficult to maintain, or not available in rural areas or developing 
% communities. 
% %
% In developed communities with cellular infrastructure, networks can become 
% overwhelmed by too many users, particularly during emergencies.
% %
%
% The proliferation of smart cities and the Internet of Things (IoT) encourage information 
% sharing between devices and sensors. 
% %
% Coupling smart cities and opportunistic communication could provide a low-cost 
% solution for delivering and relieving data demands of centralized infrastructures. 
%The dissemination of messages would therefore be possible during natural disasters, 
%when seeking emergency medical care in a crowded stadium where wireless 
%access is overloaded, or when issuing warnings of imminent danger to disconnected
%groups of people during hazardous or nefarious incidents.
%
%
%This would open a host of possibilities for the use of new real-time 
%applications in critical situations when no Internet or cellular service is 
%available. 
%
% Additionally, opportunistic communication can serve as a low-cost solution for smart cities,
% allowing developing and metropolitan areas to route smart city data through mobile 
% and stationary nodes, such as pedestrians, vehicles, street lights, public transportation. 
%-----------------------------------------------------------------------------
%Privacy concerns associated with OSNs such as censorship,
%location awareness, lack of anonymity, and disclosure of content can also be 
%addressed by disconnecting such networks from the Internet~\cite{buchegger2009delay,Juste2013a}.
%
%Recently, research and industry have focused on decreasing the dependence on the centralized communication such as the Internet~\cite{Baker2013}. 
% Innovations in technology such as WiFi Direct and Bluetooth, 
% enable mobile devices to communicate directly with each other without the
% need for a WiFi access point or cellular tower. 
%
%However, these device applications usually operate in a local context 
%where messages do not travel out of the aforementioned radio 
%communication ranges of the originating devices, e.g., from phone to 
%printer, or for gaming in a co-located group. 
%
%D2D communication alone does not address the need of delivering 
%information in an intermittent social group. 
%
DTN routing has the ability to deliver data in an intermittent network, 
but a major challenge for DTN routing is assessing real-world 
performance~\cite{Baker2013}. %~\cite{hui2008phase,Keraenen2009}. 
%
To truly understand the reliability of DTNs and their ability to support social networks, it is imperative that DTN routing schemes are evaluated 
\textit{in vivo} with use-cases that are replicable, comparable, and available 
to a variety of researchers. 

% \begin{figure*}[htbp]%[t!]
% 	\centering
% \subfloat[AlleyOop Social architecture]{\includegraphics[width=0.65\textwidth, height=3.0in]{alleyoop_arch}
% 	%\caption{AlleyOop Social architecture}
% 	\label{fig_alleyoopArch}}
%     %
%     \subfloat[AlleyOop Social system stack. The orange stack represents the modular Routing layer which researchers can add additional DTN routing protocols. The blue layers are not modular and are the foundation layers of AlleyOop Social.]{\includegraphics[width=.35\textwidth, height=2.5in]{fig_alleyoop_sys_stack}
% 	%\caption{AlleyOop Social system stack. The orange stack represents the modular Routing layer which researchers can add additional DTN routing protocols. The blue layers are not modular and are the foundation layers of AlleyOop Social.}
% 	\label{fig_alleyoop_sys_stack}}
    
    
%     \caption{AlleyOop Social Architecture and System Stack}
%     \label{fig_alleyoop}
% \end{figure*}

%-----------------------------------------------------------------------------
% In this demo, we present the Secure Opportunistic Schemes (SOS) middleware, a 
% novel middleware that facilitates secure message delivery in cases where 
% mobile connectivity is limited, unavailable, or non-existent. 
% %
% The SOS middleware supports real-life delay tolerant social networks on 
% mobile devices. 
% %
% This allows mobile devices to leverage SOS to dynamically deliver messages to 
% interested nodes when network infrastructure is not available and improve 
% message delivery when infrastructure is available.
% %
% Additionally, 
% In this demo, we showcase the AlleyOop Social research platform, 
% which uses SOS as an underlying middleware to create a delay tolerant social network for Apple iOS devices. 
In this demo, we showcase AlleyOop Social, a secure delay tolerant networking research platform that serves as a real-life mobile social networking application for Apple iOS devices. AlleyOop Social allows users to interact, publish messages, and discover others that share common interests in an intermittent network using Bluetooth, peer-to-peer WiFi, and infrastructure WiFi. The research platform serves as an overlay application for the Secure Opportunistic Schemes (SOS) middleware which allows different routing schemes to be easily implemented relieving the burden of security and connection establishment.
%
AlleyOop Social is named after the basketball play known as an ``alley oop''. 
%
An ``alley oop'' occurs when one player throws the ball close to the basket, but it 
is not able to reach the final destination. 
%
While the ball is in flight, a teammate that is closer 
to the basket catches the ball and scores. 
%
In the same regard, AlleyOop Social enables wireless mobile users to 
communicate over longer distances by sending messages that cannot reach 
the final destination, but are ``caught'' by intermediate mobile devices, 
which continue to catch and pass the messages until they are delivered to 
the final destination.

% %-----------------------------------------------------------------------------
% This demo makes the following contributions: 

% \begin{itemize}

% \item A novel middleware (SOS) designed to operate in the mobile application paradigm without requiring devices to be jailbroken. 
% %
% The modular design of the SOS middleware abstracts security, privacy, and 
% connectivity, allowing for multiple DTN routing protocols to be easily 
% supported. % successfully deliver data across multiple hops in an intermittent network. %(3) The research platform is widely available to researchers worldwide. It can reside on any users' mobile device (currently Apple iOS only) and is available for download from the Apple Store. 

% \item A simple one-time public key infrastructure (PKI) requirement security 
% scheme that enables opportunistic applications to communicate off-the-grid, 
% ensuring data are encrypted and authenticated when the Internet is not available.

% \item A novel publish-subscribe research platform (AlleyOoop Social) that leverages the SOS middleware to create a delay tolerant social network. 
% %
% AlleyOop Social uses each device as an iBeacon to maximize operation time in 
% background mode on iOS devices to opportunistically dissiminate information 
% to users even when the application is not in use.
% %
% Features includes selecting DTN routing schemes within the application, simultanious 
% sending of messages online and offline, discovering surrounding friends offline, 
% and integration with Twitter and Facebook when online.  %, allowing researchers to analyze performance metrics, such as delay and packet delivery ratio, mobility and use patterns in a real-life ad hoc social network.

% \item A small-scale field experiment was conducted at the University of Florida which demonstrates AlleyOop Social's ability to engage users and deliver messages using the interest-based (IB) DTN routing scheme. %under given delay and message delivery constraints.

% \item Case study results are provided that examine the typical usage of current 
% social media platforms as well as patterns of Internet availability for the participants.

% \end{itemize}

% %-----------------------------------------------------------------------------
% The remainder of the demo is organized as follows: 
% Section~\ref{sec_sos_middleware} discusses the design of the SOS middleware. 
% %
% Section~\ref{alleyoop_sec_architecture} provides an overview of AlleyOop 
% Social design architecture. 
% %
% Section~\ref{alleyoop_sec_privacy} describes 
% AlleyOop Social privacy and security.  %Section~\ref{alleyoop_sec_dissemination} discusses how AlleyOop Social propagates messages, and is followed by 
% %
% Section~\ref{alleyoop_sec_dissemination} describes how D2D messages are 
% transmitted securely.
% %
% Section~\ref{alleyoop_sec_results} discusses results from a field study of undergraduate/graduate students using the app at the University of Florida. % in Section~\ref{alleyoop_sec_results}. 
% %
% Section~\ref{survey} provides the case study results for typical usage of current social media apps. 
% %
% Section~\ref{related_work} describes current related work on analyzing mobile social networks. 
% %
% Finally, the demo concludes with a summary and future work in Section~\ref{alleyoop_sec_summary}.

% Online social networks (OSNs) continue to thrive and serve hundreds to millions of 
% active users~\cite{faloutsos2010online}.
% %
% Due to the popularity of social networks, new use cases are being explored for creating social networks that are less reliant on centralized infrastructures or operate completely offline CITE. % exploration of the designs of 
% %social networks that are less reliant or completely independent of centralized
% %infrastructures. %is being initiated by researchers.
% %
% Privacy concerns associated with OSNs such as censorship,
% location awareness, lack of anonymity, and disclosure of content, can be 
% addressed by decentralized infrastructures~\cite{Juste2013}. 
% %
% For example, delay tolerant social networks have the opportunity to 
% address many of the aforementioned privacy concerns while providing 
% many of the benefits OSNs afford to users in areas where centralized 
% infrastructures are fragile or non-existent~\cite{buchegger2009delay}.  
% %
% In recent years, a number of social-aware and social-based routing 
% schemes have been developed that leverage social interactions to deliver 
% data in DTNs~\cite{wei2014survey}.
% %
% However, the challenge of DTN research is assessing the real-life 
% performance of routing protocols.
% %
% To truly understand the reliability of DTNs and their ability to support a 
% social network, it is imperative that the DTN environment is tested \textit{in vivo} 
% using cases that are replicable, comparable, and available to a 
% variety of researchers. 
% %accurate representations of their intended use cases. 
% %To truly demonstrate the feasibility of delay tolerant opportunistic routing 
% %protocols, improved testing environments are necessary.
% % 
% Sections~\ref{ch_lesc} and~\ref{ch_efficient_routing} discuss how DTN protocols 
% are typically measured by their performance in simulation environments. 
% %
% Simulations can be insightful because they provide a framework to
% estimate fundamental measurements of routing protocols such as delay and 
% delivery ratio for many different scenarios~\cite{hui2008phase}. 
% %
% %ability to test DTN routing protocols in environments for which they are 
% %intended are critical to understanding the a protocols ability to deliver 
% %messages and realistic power consumption.
% % 
% Related works have approached the problem of message delivery for mobile devices 
% during intermittent scenarios, but have primarily evaluated protocols in simulation\remove{,} 
% using synthetic mobility patterns to emulate node movement.
% %
% Mobility patterns assist with characterization and efficacy of message 
% delivery and delay for a routing protocol in various scenarios~\cite{wei2014survey}.
% %
% Along with mobility modeling, simulations tend to abstractly model the radio 
% capabilities of commodity wireless technologies\cite{Keraenen2009}. 
% %
% %without considering the capabilities of current 
% %commodity wireless technologies.
% %
% DTNs are evaluated in simulation for many reasons including but not limited to: the cost of deploying infrastructure such as beacons; ability to replicate 
% various use case mobility scenarios; and the complexity of 
% implementing DTN routing protocols to the specifications of current 
% underlining wireless technologies.
% %
% Depending solely on simulation analysis can lead to ambitious and possibly 
% unrealistic expectations in terms of message delivery, delay, and routing 
% performance~\cite{ristanovic2012traps}.
% %
% Few works~\cite{pentland2004daknet,doria2009providing} have demonstrated 
% the capabilities of implementing DTNs in realistic applications. 
% %
% In addition, few~\cite{doering2008ibr,paul2015challenges,moraleda2014link} 
% provide adequate research platforms to measure the capabilities of DTN routing protocols in environments 
% for which they are intended to operate.   

% %-----------------------------------------------------------------------------
% Section~\ref{ch_alleyoop} introduces a novel secure delay tolerant social 
% networking research platform called, \textbf{A} \textbf{L}ightweight \textbf{L}ow-\textbf{E}nergy 
% s\textbf{Y}stem for disruption t\textbf{O}lerant s\textbf{O}cial message 
% \textbf{P}assing (AlleyOop) Social. 
% %
% The application can be used to analyze the performance of a 
% variety of real-life delay tolerant social networking use cases, from every day 
% social use to coordinated focused use \remove{,} such as first responder emergency scenarios.
% %AlleyOop Social provides a publish-subscribe mobile social networking app intended 
% %for everyday use by people as well as serve as an evaluation research platform for DTN 
% %routing protocols.
% %
% Section~\ref{ch_alleyoop} also discusses how to navigate the complexity of designing 
% a delay tolerant social networking research platform and provides a framework to design 
% a modular DTN application that can evaluate multiple routing protocols. 

% %-----------------------------------------------------------------------------
% AlleyOop Social is a front-end delay tolerant social networking application 
% written in Swift for iOS. 
% %that allows users to interact, send/receive messages, and discover friends.
% %      
% %Through the AlleyOop Social app, nodes subscribe to each other, send receive messages, 
% %and discover other nodes on and offline. 
% %
% The application can serve as downloadable research platform evaluator 
% for many of the DTN protocols in the research community. 
% %
% AlleyOop Social allows researchers to designate a prescribed 
% DTN process that enables users to interact, publish messages 
% according to the DTN process, and discover others that share 
% social circles or common interests --- all using a secured 
% application that can operate offline. 
% %
% Sanitized data are collected and performance results are provided based on 
% message delivery statistics, locality and evolving social structures.

% The application also allows nodes to post messages to notable social media 
% platforms such as Facebook and Twitter\remove{,} when Internet is available.  
% %
% Social interactions, message delivery statistics, and locality are captured by AlleyOop Social.% and compared to simulations results.
% %
% An ``alley-oop'' is a basketball term that 
% refers to when one player throws the ball near the basket to a 
% teammate who jumps, catches the ball in mid-air, and 
% immediately puts the ball in the hoop. 
% %
% The alley-oop combines elements of teamwork, pinpoint passing, 
% timing and finishing. 
% %
% In a similar manner, the AlleyOop Social app allows socially 
% associated users to knowingly (or unknowingly) behave as 
% a team to deliver messages. 
% %
% The sender passes encrypted messages to nearby users who 
% catch the respective messages and assist in delivering the message to the destination.
% %
% A survey was conducted to determine particpants' usage of current social media platforms, identify patterns of Internet availability for the participants, and to gauge various possible use cases for the AlleyOop Social app.

% %-----------------------------------------------------------------------------
% The remainder of the demo summarizes related work in 
% delay tolerant communication (Section~\ref{alleyoop_sec_related_work}), 
% provides an overview of AlleyOop Social design architecture 
% (Section~\ref{alleyoop_sec_architecture}), describes 
% AlleyOop Social privacy and secrurity (Section~\ref{alleyoop_sec_privacy}), and discusses 
% Alley Oop Social message propagation (Section~\ref{alleyoop_sec_dissemination}).
%hfill mds
 
%\hfill May 17, 2013

\begin{figure}
	\centering
	\includegraphics[width=.48\textwidth, height=2.1in]{sos_middleware}
	\caption{SOS middleware system stack - green represents mobile applications created by developers, orange represents the modular routing layer consisting of multiple opportunistic schemes created by academic researchers, blue represents foundational layers in the middleware that consist of encryption, authentication, peer discovery, connection management, and data dissemination. Managers marked with the color ``blue'' cannot be modified by mobile application developers or academic researchers.}
	\label{fig_alleyoop_sys_stack}
\end{figure}

\section{AlleyOop Social Research Platform}\label{alleyoop_sec_architecture}
%-----------------------------------------------------------------------------
AlleyOop Social is designed to feel familiar to users of 
well-known social networking applications such as
Twitter and Facebook.
%
In addition, AlleyOop Social simultaneously operates as 
an online and offline delay tolerant mobile social network. 
%
%Users download the app and create an account which automatically executes the security and privacy authentication process shown in Figure~\ref{fig_alleyoop_sign_up}. 
Users download the app and create an account, enabling them to develop social 
circles, and then pass and publish messages to each other. %or to a lightweight Twitter or Facebook interface. 
%
AlleyOop Social is a research platform allowing users to 
select any DTN routing protocol available in the SOS middleware (discussed in Section~\ref{sec_sos_middleware})
to disseminate messages. 
%
Researchers can perform controlled studies by asking people 
to select various protocols in AlleyOop Social and post messages.
%
AlleyOop Social gathers analytics about D2D encounters
with friends and AlleyOop Social users.
%
Unlike the Haggle project \cite{su2007haggle} which is not fully functional on 
iOS and prefers devices to be rooted on Android, AlleyOop Social gathers 
analytics about encryption/decryption duration, sign/verify duration, the 
app was in: foreground, background, and suspended, along with the size of 
data that was disseminated.
%
%Understanding the amount of time an OS allows for an application to operate 
%in the foreground and background is essential to maximizing opportunistic 
%communication on today's mobile OS's and to the best of our knowledge, has
%not been captured by other research applications.

\begin{figure*}%[htbp]
\centering
%Enabling offline security: one-time infrastructure requirement
    \subfloat{\includegraphics[width=0.48\textwidth, height=2.49in]{alleyoop_sign_up}\label{fig_alleyoop_sign_up}} 
    ~%\hfill
	\subfloat{\includegraphics[width=0.48\textwidth, height=2.49in]{alleyoop_decentralized}\label{fig_allleyoop_decentralized}} 
    %Decentralized communication
   
\caption{(a) One-time infrastructure requirement, occurs during account creation to enable DTN security. (b) Decentralized communication between nodes.} %AlleyOop Social secure message dissemination
\label{fig_alley_security}
\end{figure*}


\section{Secure Opportunistic Schemes (SOS) Middleware}\label{sec_sos_middleware}
%-----------------------------------------------------------------------------
The SOS middleware is an underlying framework that turns the AlleyOop Social 
research platform into a delay tolerant mobile social network.
%
The SOS middleware takes a modular approach to abstract away much of the 
complexity involved in implementing opportunistic routing schemes such as 
device dicovery, establishing D2D connections, and handling device security and 
privacy.
%
%The MPC framework in Section~\ref{alleyoop_subsec_ios} is incorporated into the
%{Ad Hoc Manager} which directly oversees the transport, network, data link, 
%and physical layers.%, AlleyOop will be primarily concerned with happenings above the transport layer.
%
DTNs are intended to provide an overlay architecture above the existing 
transport layer and ensure reliable routing during intermittency~\cite{Fall2003}.
%
Building on the knowledge gained from other middleware, SOS hides the complexity of the network stack (session and 
presentation) within the ad hoc manager, message manager, and routing manager,
allowing any mobile application to run at the application layer as depicted in 
Figure~\ref{fig_alleyoop_sys_stack}.
%
Different from other middlewares such as the Haggle Project~\cite{su2007haggle},
a separate instance of the SOS middleware is intended to run within each mobile application 
as opposed to a daemon which often requires devices to be rooted or jailbroken.
%
Designing SOS in this manner allows for the middleware to be integrated within individual 
mobile applications in iOS, enabling the overlaying applications to support opportunistic communication 
without jailbreaking devices along with being compliant with App Store regulations.


% \subsection{Application}\label{alleyoop_subsubsec_alleyoop_application}
% %-----------------------------------------------------------------------------
% Mobile applications serve as an overlay to the SOS middleware. 
% %
% Applications can be of any form such as social networking, medical, or any 
% other type of application that would like to share data opportunistically.
% %
% %To provide a user interface that will attract interest and inspire usage, the 
% %{AlleyOop Social Application} layer is designed using storyboards in Xcode.
% %
% Mobile applications are responsible for providing a user interface 
% to users and storing data to local or online storage systems.  
% %
% The SOS Middleware provides a number of API's for sending/receiving data, 
% surrounding user notification, routing protocol selection, and security and 
% privacy preferences.
% %
% Existing mobile applications can simply add the SOS middleware as a framework 
% and start using the aforementioned API's to send and receive data.
% %
% Applications are responsible providing the data to be sent as well as 
% handling data once it has been received and decrypted.

% \subsection{Routing manager}\label{alleyoop_subsubsec_routing}
% %-----------------------------------------------------------------------------
% The {routing manager} is responsible for leveraging D2D connections to 
% transform any application into a delay tolerant networking application that 
% delivers messages to out of range nodes in the midst of intermittency.
% %
% Routing in SOS is designed for modularity, permitting additional 
% DTN routing schemes to be developed on top of the {message manager} and run 
% seamlessly under the {Application} layer.
% %   
% Designing SOS in this manner allows for a flexible middleware that enables 
% applications to dynamically change based on user preference without the 
% need of modifying hardware or other layers in the software stack.
% %
% Currently, the {routing manager} in SOS has two DTN routing protocols 
% implemented: epidemic routing and interest-based routing.
% %
% Epidemic routing is a simple routing scheme that achieves effectiveness through 
% gratuitous replication and delivery of messages upon node encounters~\cite{Vahdat2000}.
% %
% The IB routing protocol %is available in AlleyOop Social which 
% operates in a similar manner to epidemic routing, except, instead of 
% propagating messages to all users, messages are only propagated to interested 
% users who are subscribed to the publisher of the original message.
% %
% Due to the modular nature of the SOS middleware, additional routing 
% protocols can be added to the {routing manager}.
% %
% Universal methods are available to all protocols in the {routing manager} to 
% facilitate communication between the {message manager} and the 
% {application} layer.
% %
% Both the IB and Epidemic routing protocols are written in less than 100 lines 
% of Swift code and can be found on GitHub\footnote{https://github.com/}. 


% \subsection{Message manager}\label{alleyoop_subsubsec_message_manager}
% %-----------------------------------------------------------------------------
% The {message manager} notifies the respective protocol used in the 
% {routing manager} whenever a new peer has been discovered or lost. 
% %
% Additionally, the {message manager} is responsible for taking action whenever a 
% connection state changes. 
% %
% For example, if the disconnection between two users is lost, the {message manager}
% knows what messages were not transferred.
% %
% Lastly, the {message manager} translates messages between the {routing manager} 
% and {ad hoc manager} in a common format for both layers to interpret.


% \subsection{Ad hoc manager}\label{alleyoop_subsubsec_adhoc_manager}
% %-----------------------------------------------------------------------------
% The {ad hoc manager} manages Apple's multipeer connectivity (MPC) framework, 
% which allows communication between iOS, macOS, and tvOS devices using 
% peer-to-peer WiFi, Bluetooth personal area networks, or infrastructure WiFi networks\footnote{Apple Inc., Multipeer connectivity framework reference, https://developer.apple.com/library/ios/documentation/MultipeerConnectivity/ Reference/MultipeerConnectivityFramework/}.
% %
% To the best of our knowledge, SOS is the first middleware to leverage MPC for D2D
% connectivity.
% %
% The {ad hoc manager} is responsible for viewing discovered peers, establishing 
% D2D connections, encrypting connections, encrypting data from end-to-end, 
% generating keys, validating certificates, as well as signing and verifying 
% data sent and received data.
% %
% %The {Ad Hoc Manager} also handles key generation and retrieval,  
% %generation of certificate signing requests (CSRs), and 
% %storage/retrieval of certificates.
% %
% Apple's documentation on how to use MPC is detailed, but the company does 
% not disclose specific details on how MPC works.
% %
% For example, specifics about the encryption methods MPC uses are not provided.
% %
% Details about how the SOS middleware handles security and privacy are elaborated 
% on in Section~\ref{alleyoop_sec_privacy}.  
%
% The MPC reference states that data transmission occurs in two modes: 
% reliable and unreliable. 
% % 
% Reliable guarantees delivery of messages in the order in which they were sent, retransmitting
% messages if needed.
% %
% Unreliable does not guarantee message delivery in any particular order and drops packets 
% if they cannot be delivered immediately.
% %
% To ensure message delivery in AlleyOop Social, the {Ad Hoc Manager} always sends data in reliable mode.  

%\texttt{\begin{algorithm}
%\caption{Euclid????s algorithm}\label{euclid}
%\begin{algorithmic}[1]
%\Procedure{Euclid}{$a,b$}\Comment{The g.c.d. of a and b}
%\State $r\gets a\bmod b$
%\While{$r\not=0$}\Comment{We have the answer if r is 0}
%\State $a\gets b$
%\State $b\gets r$
%\State $r\gets a\bmod b$
%\EndWhile\label{euclidendwhile}
%\State \textbf{return} $b$\Comment{The gcd is b}
%\EndProcedure
%\end{algorithmic}
%\end{algorithm}}

%\begin{figure}[htbp]
%\centering
%\lstset{language=Haskell, numbers=left, basicstyle=\footnotesize, frame=shadowbox, rulesepcolor=\color{blue}, captionpos=b, breaklines=true, morecomment=[l]{//}}
%\begin{lstlisting}
%//Initialize browser
%MCNearbyServiceBrowser(peer: peer, serviceType: kLAOServiceType)
%
%//Found peer
%func browser(browser: MCNearbyServiceBrowser!, foundPeer peerID: MCPeerID!, withDiscoveryInfo info: [NSObject : AnyObject]!) 
%
%//Lost peer
%func browser(browser: MCNearbyServiceBrowser!, lostPeer peerID: MCPeerID!) {
%
%//Initialize advertiser
%MCNearbyServiceAdvertiser(peer: peer, discoveryInfo: userDiscoveryInfo, serviceType: kLAOServiceType)
%
%//Received connection invitation 
%func advertiser(advertiser: MCNearbyServiceAdvertiser!, didReceiveInvitationFromPeer peerID: MCPeerID!, withContext context: NSData!, invitationHandler: ((Bool, MCSession!) -> Void)!) 
%
%//Initialize session 
%MCSession(peer: peer, securityIdentity: [myIdentity], encryptionPreference: MCEncryptionPreference.Required)
%
%//Session state change
%func session(session: MCSession!, peer peerID: MCPeerID!, didChangeState state: MCSessionState)
%
%//Data received
%func session(session: MCSession!, didReceiveData data: NSData!, fromPeer peerID: MCPeerID!)
%
%//Send data 
%session.sendData(dataToSend, toPeers: peersArray as [AnyObject], withMode: MCSessionSendDataMode.Reliable, error: &error)  
%
%  
%\end{lstlisting}
%
%\caption{Multipeer connectivity functions}
%\label{mpc_standard_functions}
%\end{figure}
  

%
% When a AlleyOop Social peer is found, the {Ad Hoc Manager} notifies the Message 
% Manager, which then notifies the routing protocol being used. 
% %
% The routing protocol then makes the decision 
% of being interested in the particular peer that was discovered. 
%
%An example of how interest-based routing handles a peer in AlleyOop Social is in Figure~\ref{alleyoop_interest_foundPeer}.

%\begin{figure}[htbp]
%\centering
%\lstset{language=Haskell, numbers=left, basicstyle=\footnotesize, frame=shadowbox, rulesepcolor=\color{blue}, captionpos=b, breaklines=true, morecomment=[l]{//}}
%\begin{lstlisting}
%    // MARK: AdHocManager delegate method implementation
%    func foundPeer(peerID: MCPeerID!, discoveryInfo: [NSObject : AnyObject]!){
%            
%        //Check user list to see if there is any new information we are interested in
%        if let peersAdvertisingInfo = discoveryInfo {
%            let peersAdvertisingDictionary = peersAdvertisingInfo as! [String:String]
%            
%            for (objectId, messageNumber) in peersAdvertisingDictionary{
%                
%                //Only go further if this is someone you are subscribed to...
%                if self.nodesImSubscribedTo?[objectId] != nil{
%                
%                    let messageNumberFromPeer = messageNumber.toInt()!
%                    
%                    if let messageNumberIHave = self.advertisingDictionary[objectId]{
%                        if messageNumberIHave.toInt() < messageNumberFromPeer{
%                            
%                            let newInterestedMessageNumber = MessageManager.calculateMessageNumberInterestedIn(messageNumberIHave.toInt()!, numberPeerHas: messageNumberFromPeer)
%                            
%                            //I'm interested in this infomation
%                            if sendToPeerInformationImInterestedIn == nil {
%                                localInformationImInterestedIn = [objectId: String(messageNumberFromPeer)]
%                                sendToPeerInformationImInterestedIn = [objectId:String(newInterestedMessageNumber)]
%                            }else{
%                                localInformationImInterestedIn![objectId] = String(messageNumberFromPeer)
%                                sendToPeerInformationImInterestedIn![objectId] = String(newInterestedMessageNumber)
%                            }
%                            
%                        }else{
%                            println("I'm up-to-date with messages for peer \(peerID.displayName) for user \(objectId)")
%                        }
%                    }
%                }
%            }
%        }
%    }   
%\end{lstlisting}
%\caption{The foundPeer delegate function for interest-based routing}
%\label{alleyoop_interest_foundPeer}
%\end{figure}


% \begin{figure}[htbp]
% \centering
%     \subfloat[All messages from the Internet]{\includegraphics[width=0.23\textwidth, height=2.0in]{app_all}\label{fig_alley_all}}
%     ~
%     \subfloat[Received through DTN routing]{
%     	\includegraphics[width=0.23\textwidth, height=2.0in]{app_all_ooped}\label{fig_alley_ooped}
%     } 
% %     ~
% %     \subfloat[Subscribers]{
% %     	\includegraphics[width=0.145\textwidth, height=2.0in]{app_team}\label{fig_alley_app_team}
% %     }
    
% \caption{AlleyOop Social - viewing messages}
% \label{fig_alley_main}
% \end{figure}




%Throughout a given period of user operation, sanitized data are collected by the app (any user-identifying data is deleted before recording research data) and performance results are provided based on message delivery statistics, locality and evolving social structures.
%The AlleyOop Social architecture consists of three essential components 
%depicted in Figure~\ref{fig_alleyoopArch}.
% 
%Protocols' preferences can be selected with minimal intervention by the end-user  
%and set to a default protocol during initial download. 
%
%The {AlleyOop Social Application} layer allows users to login to the application by
%creating new accounts manually or by seamlessly creating new accounts from existing
%Twitter or Facebook accounts.

%-----------------------------------------------------------------------------
% Once a user is logged in, the application greets the user with the ``AlleyOoped'' news 
% feed, shown in Figure~\ref{fig_alley_ooped}, and displays content from friends the user
% currently follows, as well as the user's own content.
% %
% The content on the ``AlleyOoped'' tab only shows messages that were 
% received by a DTN routing scheme in the {routing manager}. 
% %
% The ``All'' tab in the news feed, shown in Figure~\ref{fig_alley_all}, displays 
% content from the friends a user is currently following.
% %
% ``All'' differs from ``AlleyOoped'' because content in this tab is retrieved 
% from the BaaS if ever the respective device has an Internet connection. 
% %
% Content in the ``All'' tab is not dependent on message delivery from any of the 
% DTN routing protocols. 
% %
% AlleyOop Social allows users to find friends online as well as discover new 
% friends offline who are in the surrounding area.
% %
% Additional features allow the user to view other user profiles, current 
% followers, and messages that have been alley-ooped to other users.
%If a user has not been in communication range with any other AlleyOop Social node 
%that advertised information of interest, then this tab will have no content 
%to show. 
%
%AlleyOop Social has additional settings to allow users 
%to change various parameters such as their screen name, email address,
%and password.    
%
%Optionally, users can change their preferred DTN routing protocol allowing 
%researchers to easily recruit users as test nodes for their designed protocols.
% The ``All'' tab in the news feed, shown in Figure~\ref{fig_alley_all}, displays content from the friends a user is currently following.
% %
% ``All" differs from ``AlleyOoped'' because content in this tab is retrieved from
% the BaaS if ever the respective device happens to be able to connect to the Internet. 
% %
% Content in the ``All'' tab is not dependent on message delivery from any of the DTN 
% routing protocols. 
% %
% Conversely, content shown in the ``AlleyOoped'' tabbed are based solely on messages that 
% were delivered using a DTN routing protocol.  
% %
% The ``AlleyOoped'' and ``All'' tabs provide a convenient way for users to
% understand how their particular movements and social interactions contribute 
% to DTN routing, but also allows users to engage with friends they may never come into 
% contact with. 
%
%-----------------------------------------------------------------------------
% Selecting the ``basketball hoop'' in the bottom menu bar brings the user 
% to ``On Your Team'' the first of three tabs shown in Figure~\ref{fig_alley_app_team}.
% %
% ``On Your Team'' allows the user to see the recent AlleyOop Social users who currently 
% follow the  user.
% %
% The second tab in Figure~\ref{fig_alley_app_team}, ``Ooped By You,'' shows 
% all of the messages the user has passed to others using a particular
% DTN routing protocol discussed in Section~\ref{alleyoop_subsubsec_routing}.
% %
% These messages exclude the user's own messages passed and only refer to 
% the passing of other AlleyOop Social users' messages.
% %
%
% The remaining tab in Figure~\ref{fig_alley_app_team}, ``Ooped For You'' refers to 
% all of the respective user's messages that were passed by other users 
% using a DTN routing protocol.
% %
% Content in the ``Ooped For You'' is only populated when a passing user, and the 
% user that the message originated from have had an Internet connection at some point. 
% %
% Whenever a user passes a message, the passer is responsible for synchronizing the
% passing activity to the BaaS whenever Internet is available.
% %
% The originator of the message can see messages delivered on their behalf by
% synchronizing with the BaaS when Internet is available and checking 
% the ``Ooped For You'' tab.
% %
% Therefore, the ``Ooped For You'' tab visualizes the delivery of messages to 
% out of range nodes using DTN routing protocols even if the originating node 
% never comes into communication range of the recipient node.
% Selecting the ``social button'' on the top left of the ``home screen'' brings the user to 
% ``On The Court,'' the first of two tabs shown in Figure~\ref{fig_alley_on_the_court}.
% % 
% ``On The Court'' allows users to quickly find other AlleyOop Social users in the 
% surrounding area and to follow them if they are of interest. 
% %
% %Additionally, the second tab, Figure~\ref{}, shows all friends from Facebook or 
% %Twitter who currently have AlleyOop Social accounts, but are not currently friends on AlleyOop Social. 
% %
% The ``cloud'' button on the bottom menu bar of Figure~\ref{fig_alley_app_cloud} allows users 
% currently connected to the Internet to search all users using AlleyOop Social and to
% follow them if they are of interest. 
% %  
% Selecting the ``basketball hoop'' in the bottom menu bar brings the user 
% to ``On Your Team'' the first of three tabs shown in Figure~\ref{fig_alley_app_team}.
% %
% ``On Your Team'' allows the user to see the recent AlleyOop Social users who currently 
% follow the  user.
% %
% The second tab in Figure~\ref{fig_alley_app_by_you}, ``Ooped By You,'' shows 
% all of the messages the user has passed to others using a particular
% DTN routing protocol discussed in Section~\ref{alleyoop_subsubsec_routing}.
% %
% These messages exclude the user's own messages passed and only refer to 
% the passing of other AlleyOop Social users' messages.
% %
% The remaining tab in Figure~\ref{fig_alley_app_for}, ``Ooped For You'' refers to 
% all of the respective user's messages that were passed by other users 
% using one of the DTN routing protocols in Section~\ref{alleyoop_subsubsec_routing}.
% %
% Content in the ``Ooped For You'' is only populated when a passing user, and the 
% user that the message originated from have had an Internet connection at some point. 
% %
% Whenever a user passes a message, the passer is responsible for synchronizing the
% passing activity to the BaaS whenever Internet is available.
% %
% The originator of the message can see messages delivered on their behalf by
% synchronizing with the BaaS when Internet is available and checking 
% the ``Ooped For You'' tab.
% %
% Therefore, the ``Ooped For You'' tab visualizes the delivery of messages to 
% out of range nodes using DTN routing protocols even if the originating node 
% never comes into communication range of the recipient node.
% %
% The last menu button is a ``shoe,'' depicted in Figure~\ref{fig_alley_profile}, 
% and represents the respective user's profile.
% %
% The user profile shows the amount of messages that have been created (alleys), the amount of 
% AlleyOop Social users followed, and the amount of followers the
% user has.
% %
% All of the messages shown on this page are messages created specifically by the user. 
% %  
% AlleyOop Social has additional settings to allow users to change various 
% parameters such as their screen name, email address,
% and password. 
% %
% %Optionally, users can change their preferred DTN routing protocol by tapping the protocol of interest at the 
% %bottom of Figure~\ref{fig_alley_app_settings}.   
% %
% Optionally, users can change their preferred DTN routing protocol allowing 
% researchers to easily recruit users as test nodes for their designed protocols.
%

%\begin{figure}[htbp]
%  \begin{center}
%    \centering
%    \mbox{
%      \subfigure[Surrounding AlleyOop Social users]{\includegraphics[scale=0.195]{app_on_the_court}\label{fig_alley_on_the_court}} \quad
%     }
%  	\mbox{
%	  \subfigure[All AlleyOop Social users]{\includegraphics[scale=0.195]{app_cloud}\label{fig_alley_app_cloud}} \quad
%  	}
%  	\mbox{
%	  \subfigure[Settings]{\includegraphics[scale=0.1]{app_settings}\label{fig_alley_app_settings}} \quad
%  	}
%    \caption[AlleyOop Social - Find people and change settings]{AlleyOop Social - Find people and change settings}
%    \label{fig_alley_find}
%  \end{center}
%\end{figure}

% \begin{figure*}
% \centering
% 	%\begin{subfigure}{.32\textwidth}
% 	%\centering
%     \subfloat[Surrounding AlleyOop Social users]{
% 		%\includegraphics[width=1.0in, height=1.5in]{app_on_the_court}
% 		%\caption{Surrounding AlleyOop Social users}
% 		\label{fig_alley_on_the_court}}
% 	%\end{subfigure}
% 	~
% 	%\begin{subfigure}{.32\textwidth}
% 	%\centering
%     \subfloat[All AlleyOop Social users]{
% 		%\includegraphics[width=1.0in, height=1.5in]{app_cloud}
% 		%\caption{All AlleyOop Social users}
% 		\label{fig_alley_app_cloud}}
% 	%\end{subfigure}
% 	~
% 	%\begin{subfigure}{.32\textwidth}
% 	%	\centering
%     \subfloat[Settings]{
% 		%\includegraphics[width=1.0in, height=1.5in]{app_settings}
% 		%\caption{Settings}
% 		\label{fig_alley_app_settings}}
% 	%\end{subfigure}

% \caption{AlleyOop Social - Find people and change settings}
% \label{fig_alley_find}
% \end{figure*}


%\begin{figure}[htbp]
%  \begin{center}
%    \centering
%    \mbox{
%      \subfigure[Users who help you pass]{\includegraphics[scale=0.1]{app_team}\label{fig_alley_app_team}} \quad
%     }
%  	\mbox{
%	  \subfigure[Messages you passed]{\includegraphics[scale=0.1]{app_by_you}\label{fig_alley_app_by_you}} \quad
%  	}
%  	\mbox{
%	  \subfigure[Passed for you]{%\includegraphics[scale=0.1]{app_for}\label{fig_alley_app_for}} \quad
%  	}
%    \caption[AlleyOop Social - Find out who is passing messages]{AlleyOop Social - Find out who is passing messages}
%    \label{fig_alley_net}
%  \end{center}
%\end{figure}

% \begin{figure*}
% \centering
% 	%\begin{subfigure}{.32\textwidth}
% 	%\centering
%     \subfloat[Users who help you pass]{
% 		\includegraphics[width=1.0in, height=1.5in]{app_team}
% 		%\caption{Users who help you pass}
% 		\label{fig_alley_app_team}}
% 	%\end{subfigure}
% 	~
% 	%\begin{subfigure}{.32\textwidth}
% 	%\centering
%     \subfloat[Messages you passed]{
% 		%\includegraphics[width=1.0in, height=1.5in]{app_by_you}
% 		%\caption{Messages you passed}
% 		\label{fig_alley_app_by_you}}
% 	%\end{subfigure}
% 	~
% 	%\begin{subfigure}{.32\textwidth}
% 		%\centering
%     \subfloat[Passed for you]{
% 		%\includegraphics[width=1.0in, height=1.5in]{app_for}
% 		%\caption{Passed for you}
% 		\label{fig_alley_app_for}}
% 	%\end{subfigure}

% \caption{AlleyOop Social - Find out who is passing messages}
% \label{fig_alley_net}
% \end{figure*}



% \subsection{AlleyOop Social architecture}
% The AlleyOop Social architecture consists of the three essential components 
% depicted in Figure~\ref{fig_alleyoopArch}: the operating system, Backend-as-a-Service, and the certificate authority. The role of each of these components is described below:

% \begin{figure*}[htbp]%[t!]
% 	\centering
% 	\includegraphics[width=0.98\textwidth, height=2.85in]{alleyoop_arch}
% 	\caption{AlleyOop Social architecture}
% 	\label{fig_alleyoopArch}
%    %
% \end{figure*}


% \subsubsection{Operating System}\label{alleyoop_subsec_ios}
% %-----------------------------------------------------------------------------
% The operating system provides a range of features and application program 
% interfaces (APIs) which can be leveraged in the development of a delay 
% tolerant mobile social network. 
% %
% Apple iOS was chosen as the operating system of choice for several reasons. 
% %
% First, Apple iOS is a powerful mobile operating system which powers the 
% iPhone, iPad, and iPod. 
% %
% Second, Apple began implementing the Bluetooth Smart stack into iOS devices 
% in its operating system version 5 (iOS 5) in 2011 and has continued to make 
% improvements to the stack up to its current operating system (iOS 10). 
% %
% Bluetooth Smart in iOS enables the use of iBeacon, which provides location 
% awareness for mobile devices\footnote{Apple Inc. https://www.apple.com/ios/}. 
% %This location awareness is leveraged by AlleyOop Social.

% % %-----------------------------------------------------------------------------
% % Third, in iOS 7 Apple introduced the multipeer connectivity (MPC) framework, which allows communication between iOS and OSX devices.
% % %
% % MPC has the ability to work over infrastructure WiFi networks, device-to-device (D2D) 
% % WiFi, and Bluetooth personal area networks.
% % %
% % In MPC, services of nearby devices are advertised and discovered by sending Bonjour TXT 
% % records. These records can be interpreted by devices without establishing connections\footnote{Apple Inc., Multipeer connectivity framework reference, https://developer.apple.com/library/ios/documentation/MultipeerConnectivity/ Reference/MultipeerConnectivityFramework/}.  
% % % 
% % Devices can invite surrounding 
% % peers to pair and connect in D2D sessions to exchange relevant information 
% % ranging from text messages, to files, to streaming video.
% % %
% % MPC allows manual pairing between peers, as well as transparent pairing process
% % that can be achieved through programming. This allows applications to dictate the requirements 
% % of the pairing process without causing user intervention.
% % %
% % Finally, MPC is able to facilitate decrypted and encypted connections between devices~\cite{Diquet2014}%~\footnote{A. Diquet, It just (net)works: The truth about ios? multipeer connectivity framework,? Hack In The Box (2014).}.       
% % %
% % %MPC serves as the underlying middleware of the AlleyOop 
% % %Social app and allows for the discovery of neighboring peers.
% % %each other and facilitate reliable encrypted D2D connections 
% % %over WiFi and Bluetooth. 

% % %\subsubsection{Swift}
% % %In 2014, Apple released a new language called Swift which is interoperable with 
% % %Objective-C and is intended for development of iOS and OSX applications~\cite{wells2015future}.  
% % %%
% % %Swift is a type-safe, modern programming language that incorporates many features
% % %of current object oriented languages as well as scripting languages.
% % %%
% % %Programming in Swift is intended to be similar to scripting languages but provide 
% % %industrial level quality applications~\cite{swift2015}. 
% % %%
% % %The majority of the AlleyOop Social application is written in the Swift langauge with
% % %minimal usage of Objective-C.

% % % \subsubsection{Multipeer connectivity framework}\label{alleyoop_subsec_mpc}
% % % %-----------------------------------------------------------------------------
% % % Apple introduced the MPC in iOS 7 which allows communication
% % % between iOS and OSX devices.
% % % %
% % % MPC has the ability to work over infrastructure WiFi networks as well as device-to-device (D2D) 
% % % WiFi, and Bluetooth personal area networks~\cite{mpc}.
% % % %
% % % Services of nearby devices are advertised and discovered in MPC by sending Bonjour TXT 
% % % records that can be interpreted by devices without establishing connections~\cite{mpc}.  
% % % % 
% % % Devices that are interested in services of neighboring peers can invite surrounding 
% % % peers to pair and connect to ad hoc sessions to exchange relevant information 
% % % ranging from text messages, files, to streaming video.
% % % %
% % % MPC allows manual pairing between peers, but also allows for transparent pairing 
% % % that can be done programmatically, therefore allowing applications to dictate the requirements 
% % % of the pairing process without user intervention.
% % % %
% % % Encrypted connections can be enabled in MPC to secure 
% % % D2D communication~\cite{Diquet2014}.       
% % % %
% % % MPC will serve as the underlying middleware of the AlleyOop 
% % % Social application and allow for neighboring peers to discover 
% % % each other and facilitate reliable encrypted D2D connections 
% % % over WiFi and Bluetooth. 

% \subsubsection{Database and data management using backend-as-a-service (BaaS)}\label{alleyoop_subsec_parse}
% %-----------------------------------------------------------------------------
% To manage local storage on a device as well as cloud storage when the Internet is 
% available, AlleyOop Social leverages a Backend-as-a-Service (BaaS).
% %
% A BaaS comes with a diverse set of APIs, thereby relieving the complexity 
% of designing a database management system and allowing developers to focus on 
% other aspects of application development.
% %
% The BaaS provides push notifications so that developers can target specific 
% users of a mobile application and also encourage user engagement. 
% %
% Data analytics can be captured by the BaaS to measure application usage in real-time.
% %
% For AlleyOop Social additional code was developed to enable the BaaS to be used to provide custom control over real-time data storage as well as interactions via a representational state transfer (RESTful) based APIs.    


% \subsubsection{Certificate authority}\label{alleyoop_subsec_ca}
% %-----------------------------------------------------------------------------
% To establish trust between nodes in AlleyOop Social, a 
% dedicated Certificate Authority (CA) is developed and is 
% powered by nodejs, a popular server-side networking
% environment written in JavaScript~\cite{tilkov2010node}.  
% %
% CAs are popular for PKIs because they serve as trusted 
% nodes that digitally sign certificates for users\cite{perlman1999overview}. 
% %
% AlleyOop Social employs the CA is to generate X.509 certificate fingerprints for AlleyOop 
% Social users from certificate signing requests through openssl commands.
% % 
% %AlleyOop Social currently has one dedicated CA for 
% %securing the current DTN created by the application. 
% %as long as the keys of the CA 
% %are not compromised.  
% %
% All communications with the CA occur through 
% authenticated RESTful API calls written in Javascript, and only 
% occur between the BaaS and the CA.  
% %
% The CA is also equipped with a Mysql database used to store 
% basic public certificate information for each user. 
% %
% The CA is not responsible for generating any public/private key information 
% for users.
% %
% %Figure~\ref{fig_alleyoop_sign_up} depicts how AlleyOop Social uses the CA.

% \begin{figure}[htbp]
% 	\centering
% 	\includegraphics[width=0.495\textwidth, height=3.00in]{Opportunistic_Comm_iOS}
% 	\caption{Leveraging iBeacon for opportunistic communication on iOS. Red, yellow, 
%     and green, represent the three different states iOS transitions an app through. Blue represents when the app is using opportunistic communication.}
% 	\label{fig_opp_comm_ios}
% \end{figure}

% \begin{figure*}[htbp]
% 	\centering
% 	\includegraphics[width=0.9\textwidth, height=2.75in]{alleyoop_sign_up}
% 	\caption{AlleyOop Social sign-up (one-time infrastructure requirement)}
% 	\label{fig_alleyoop_sign_up}
% \end{figure*}

% \subsection{Mitigating middleware issues in mobile applications}
% %-----------------------------------------------------------------------------
% MANET and DTN solutions typically emphasize on how data can be transmitted on 
% mobile devices~\cite{su2007haggle,caporuscio2012ubisoap}. 
% %
% Assuming mobile applications or daemons (Haggle project~\cite{su2007haggle}) 
% can have anytime access to device resources such as the network software stack 
% and CPU is convenient, but also unrealistic in today's non jail-broken and 
% rooted devices. 
% %
% In order to optimize use of opportunistic communication for current and future 
% mobile operating systems, middlewares should be designed to leverage the capabilities 
% as well as operate within confinements of typical mobile application paradigms 
% without being jail-broken or rooted.
% %
% %Mobile developers for iOS and Android are able to develop innovative 
% %solutions, but are typically confined to creating mobile applications.
% %
% %
% With regard to iOS, a mobile application only has full access to a devices 
% resources when the application is in the foreground, and for limited time periods 
% in background.
% %
% If a user switches to a different application or the device transitions to sleep
% mode, iOS will suspend the respective application and force it to relinquish 
% the device's resources.
% %
% This is problematic for mobile applications that rely on  opportunistic 
% communication because it is unrealistic to expect a user to always have a 
% specific application in the foreground.
% %
% In addition, users may encounter each other when their devices are sleep
% and the opportunity to to pass data will be missed.
% %
% To circumvent the aforementioned issues, AlleyOop Social requests additional
% time from the operating system to uses resources whenever a device enters 
% the background.
% %
% In iOS 10, the typical time granted is usually between one (1) and three (3) minutes.
% %
% Afterwards, the mobile application and all ability to opportunistically 
% communicate with other iOS devices are suspended.
% %
% To enable AlleyOop Social to reclaim device resources after three (3) minutes,
% AlleyOop Social attempts to register as an iBeacon application during the 
% initial installation.
% %
% Assuming a user permits the ability, iOS allows mobile devices to receive 
% iBeacons at anytime, even when an application is suspended.
% %
% A limitation is that a mobile application can only transmit as an iBeacon 
% when it is in the foreground.
% %
% This means that if multiple AlleyOop Social users have been in proximity with
% each other, but have not opened the AlleyOop Social application in over 
% 3 minutes, their application can only be reactivated if a surrounding AlleyOop 
% Social user opens their app.
% %
% Assuming at least one user opens the AlleyOop Social app, the users device 
% will begin transmitting as an iBeacon which sets off a chain reaction, 
% triggering all nearby devices to allow AlleyOop Social to run in the background and 
% re-enables their respective opportunistic communication through the SOS middleware.
% %
% To further encourage nearby users to open AlleyOop Social, local notifications 
% are generated whenever the app is in the background and nearby friend is in 
% wireless communication range.
% %
% Figure~\ref{fig_opp_comm_ios} depicts how AlleyOop Social uses iOS 10 to maximize 
% opportunistic communication.
% %
% With regard to Figure~\ref{fig_opp_comm_ios}, technically an app is in the 
% foreground when it is open for the first time.
% %
% The foreground state is shown after the user inputs are stored for simplicity 
% and to depict that users are only asked about application permissions the first 
% time the application is open.




\section{Privacy and Security}\label{alleyoop_sec_privacy}
%-----------------------------------------------------------------------------
In regard to network security there is no ``one-size-fits-all" 
approach~\cite{perlman1999overview}.
%
Security concerns may become exacerbated in delay tolerant and ad hoc 
applications where nodes are vulnerable to attacks such as eavesdropping, 
denial of service, and compromised devices.
%
Providing secure communication that prevents an adversary from accessing and/or 
modifying data is a fundamental requirement of any DTN application~\cite{cabaniss2015multi}.
%
Previous research discusses security in opportunistic applications as a 
proof-of-concept, and makes no claim their implementations are 
secure~\cite{su2007haggle}.
%
As depicted in Figure~\ref{fig_alley_security}, AlleyOop Social introduces a novel, but simple concept and 
implementation of an initial layer of security for opportunistic communication 
and enables the overlaying mobile application to detect the identity of its 
users, send encrypted information, verify the originating source of the 
information being forwarded, and ensure that data have not been 
modified --- all with minimal dependence on centralized infrastructures.
% %
% Additional security can be added to AlleyOop Social by incorporating mechanisms 
% such as distributing CA functionality amongst nodes~\cite{kong2001providing}, 
% or integrate trust measurements within the routing schemes~\cite{kumar2010protect} 
% available in the routing manager discussed in Section~\ref{sec_sos_middleware}. 
% %
% To enable the initial layer of security in the SOS middleware, AlleyOop Social 
% leverages conventional public-key infrastructure (PKI) techniques to create a one-time 
% PKI requirement that occurs during initial download and user-signup for the application.
% %
% AlleyOop Social assumes that users will have Internet connectivity 
% during the initial download and installation of the mobile app.
% %
% After the one-time infrastructure requirement, Internet connectivity is 
% no longer needed for privacy or security. 


\section{Demo Setup}\label{alleyoop_sec_demo}
%-----------------------------------------------------------------------------
During the demonstration attendees will be able to download AlleyOop 
Social on their respective iOS devices via Apple TestFlight.
%
Users can follow friends, post new messages, as well as toggle between DTN
routing schemes inside the application.
%
We will demonstrate both the online and offline modes by disconnecting mobile 
devices from cellular and WiFi networks.
%
Details of what occurs on every mobile device when a user creates an account and 
disseminates messages is depicted in Figures~\ref{fig_alleyoop_sign_up} and \ref{fig_allleyoop_decentralized} respectively.


% \begin{figure*}[htbp]
% 	\centering
% 	\includegraphics[width=0.9\textwidth, height=2.75in]{alleyoop_sign_up}
% 	\caption{AlleyOop Social sign-up (one-time infrastructure requirement)}
% 	\label{fig_alleyoop_sign_up}
% \end{figure*}

%  \begin{figure*}[htbp]
%  	\centering
%  	\includegraphics[width=0.9\textwidth, height=2.5in]{alleyoop_decentralized}
%  	\caption{AlleyOop Social decentralized communication}
%  	\label{fig_allleyoop_decentralized}
%  \end{figure*}

% %-----------------------------------------------------------------------------
% The process of generating keys and receiving X.509 certificates in AlleyOop Social's 
% one-time infrastructure requirement is depicted in 
% Figure~\ref{fig_alleyoop_sign_up}. 
% %
% When a user initiates the sign-up process on their mobile device, a RSA-2048 bit 
% asymmetric private/public-key pair is generated by the respective device.
% % 
% Each user is then provided with a unique user-identifier (a 10-character string
% in AlleyOop Social, but could be different for other applications) from the BaaS
% that represents the user for the duration of an active account.
% %
% The private/public-key pair is then used to generate a certificate signing request 
% (CSR) that contains the user-identifier string in the ``subject'' field of the CSR.
% %
% The CSR is then uploaded to the BaaS through a SSL connection.
% %
% After successful creation of the user, the BaaS, through RESTful API calls, 
% connects to the AlleyOop Social CA and forwards the CSR. %and asks the CA to create a user account on its server 
%  %if one does not already exist. 
%  %
%  %Creation of a user account on the CA is done to keep track of certificates 
%  %created for a particular user.
%  %
%  %
%  %The BaaS then forwards the CSR of the particular installation to the AlleyOop CA
%  %by using an additional RESTful API call. 
%  %
% Using openssl, the AlleyOop Social CA digitally signs the CSR with a RSA-4096 bit private-key and 
% produces a SHA-256 digest of its signature, resulting in a X.509 certificate which 
% encompasses the public-key generated by the originating device, as well as its user
% identifier as the subject of the certificate.
% %
% The AlleyOop Social CA returns the certificate to the BaaS along with the root certificate of the AlleyOop Social CA. 
% %
% The BaaS notifies the new device that its certificates are ready by pushing 
% both the newly generated certificates and the AlleyOop Social CA root certificate, to the respective device.
% %
% When a mobile device has its own certificate as well as the AlleyOop Social CA root certificate, 
% it is now eligible to operate independently of the PKI, communicate securely  
% with other AlleyOop Social enabled devices, and detect modifications to other mobile 
% devices certificates~\cite{kothmayr2013dtls}, independently of the Internet and network infrastructure. 
% %
% The reason for supplying every node with the CA's root certificate is to enable 
% nodes to authenticate and verify AlleyOop Social users without an Internet 
% connection.
% %
% As a note, Individual users can have many devices; therefore, private/public-key 
% pairs, CSRs, and certificates are generated for each installation of the 
% application on a particular device. 
% %
% Since each certificate is embedded with the unique user-identifier in its subject,
% AlleyOop Social users do not need to keep track of public/private key pairs 
% of users with multiple devices.
% %
% Instead, users only need to know the unique user-identifier of the user they 
% are interested in and verify the incoming certificate against their local 
% AlleyOop Social CA certificate.
 


% %-----------------------------------------------------------------------------
% All messages disseminated using a DTN routing protocol from the {routing} manager 
% are sent over encrypted connections as discussed in Section~\ref{alleyoop_subsubsec_adhoc_manager}.
% %
% %Encryption is done, by leveraging the capabilities of MPC.
% %
% As noted in Section~\ref{alleyoop_subsubsec_adhoc_manager}; MPC supports 
% encryption and authentication and is vaguely described in Apple's documentation. 
% %
% In~\cite{Diquet2014}, Diquet investigated the MPC framework using 
% WiFi only and uncovered many details that are not provided in the MPC documentation.
% %
% Diquet's findings suggest encryption required with authentication 
% enabled successfully prevents man-in-the-middle attacks. 
% %
% When using encryption required with authentication enabled, 
% the datagram transport layer security (DTLS) with mutual 
% authentication cypher suite is enabled.
%
%A limitation that Diquet highlights is that though MPC has the perfect 
%forward secrecy (PFS) cipher suites enabled, it is not prioritized, and 
%therefore never used, by MPC.
  
%-----------------------------------------------------------------------------
% Encrypting connections in MPC requires supplying an ``identity'' consisting of a 
% private-key and a X.509 certificate made with the corresponding public-key during 
% initializing~\cite{Diquet2014}. 
% %
% Apple iOS has a limited subset of native functions compared to OSX to accomplish
% key generation, certificate, and identity creation\footnote{Apple Inc., 
% Certificate, Key, and Trust Services Reference, https://developer.apple.com/library/ios/documentation/Security/Reference/ certifkeytrustservices/} %~\cite{iosSecurity}. 
% %
% To create an identity, AlleyOop Social saves the private/public-key pair, along with 
% the returned installation certificate from the AlleyOop Social CA to the respective 
% device's iOS application keychain.
% %
% Once these items are saved, the iOS keychain will automatically bind the certificate 
% to the private-key to create an ``identity''.
% %
% The binding only takes place if the X.509 certificate was created using the corresponding 
% private/public-key pair. 
% %  
% %After the ``identity'' is available, a delegate MPC function has to be implemented to
% %verify and authenticate other users. 
% %
% \cb{If I need more space, remove the beginning of this paragraph}
% To properly evaluate a user as a trusted AlleyOop Social user, the locally stored root 
% certificate from the AlleyOop Social CA mentioned in Section~\ref{alleyoop_sec_privacy}
% is used by each AlleyOop Social device.
% %
% Every peer's X.509 certificate has to pass evaluation against the root certificate  
% before a connection can be established within the AlleyOop Social app.
% %
% Peers who do not pass evaluation will be ignored and are not allowed to connect to AlleyOop Social sessions.
%
%The methods for receiving and evaluating certificates are shown in 
%Figures~\ref{alleyoop_security_receiveCertificate} and~\ref{alleyoop_security_evaluateCertificate}.

%\begin{figure}[htbp]
%\centering
%\lstset{language=Haskell, numbers=left, basicstyle=\footnotesize, frame=shadowbox, rulesepcolor=\color{blue}, captionpos=b, breaklines=true, morecomment=[l]{//}}
%\begin{lstlisting}
%    // MARK: AdHocManager delegate method implementation
%    func session(session: MCSession!, didReceiveCertificate certificate: [AnyObject]!, fromPeer peerID: MCPeerID!, certificateHandler: ((Bool) -> Void)!) {
%            
%            var peerCert = certificate.first as! SecCertificateRef
%            var peerCerts = certificate as! [SecCertificateRef]
%            
%            if let certInformation = AdHocUtility.evaluateTrustAndReturnCertInformation(peerCerts){
%                
%                let peerObjectId = certInformation[kCommunicationsCertificateObjectIdTerm] as! String
%                let peerPublicKey = certInformation[kCommunicationsPublicKey] as! SecKey
%                let peerBlockSize = certInformation[kCommunicationsBlockSize] as! Int
%                
%                self.connectedPeersCertificateInformation[peerID] = [
%                    kConnectedPeerCertObjectId : peerObjectId,
%                    kConnectedPeerCertCertificate : peerCert,
%                    kConnectedPeerCertKeyBlockSize: peerBlockSize,
%                    kConnectedPeerCertPublicKey : peerPublicKey
%                ]
%                certificateHandler(true)
%                            
%             }else {
%                certificateHandler(false)
%             }
%	  }
%                          
%\end{lstlisting}
%\caption{Certificate received from peer}
%\label{alleyoop_security_receiveCertificate}
%\end{figure} 

%\begin{figure}[htbp]
%\centering
%\lstset{language=Haskell, numbers=left, basicstyle=\footnotesize, frame=shadowbox, rulesepcolor=\color{blue}, captionpos=b, breaklines=true, morecomment=[l]{//}}
%\begin{lstlisting}
%    class func evaluateTrustOfCertificate(certificateToBeEvaluated: [SecCertificateRef!]) -> Bool{
%            let policy = SecPolicyCreateBasicX509().takeRetainedValue()
%            var certUnderEvalTrust: Unmanaged<SecTrustRef>?
%            let rootCertificate = findCertificate(kLRootCertificate, objectId: nil)!
%            let certUnderEvalTrustStatus = SecTrustCreateWithCertificates(certificateToBeEvaluated, policy, &certUnderEvalTrust)
%            
%            if certUnderEvalTrustStatus == errSecSuccess {
%                
%                let certUnderEvalTrustRef = certUnderEvalTrust!.takeRetainedValue()
%                let anchorStatus = SecTrustSetAnchorCertificates(certUnderEvalTrustRef, [rootCertificate])
%                var resultTest: SecTrustResultType = 0
%                SecTrustGetTrustResult(certUnderEvalTrustRef, &resultTest)
%                
%                if anchorStatus == errSecSuccess{
%                    println("Successfully set anchor certificate")
%                    var result: SecTrustResultType = 0
%                    let evaluateStatus = SecTrustEvaluate(certUnderEvalTrustRef, &result)
%                    
%                    if evaluateStatus == errSecSuccess{
%                        if Int(result) == kSecTrustResultUnspecified {
%                            println("Certificate is a trusted certificate")
%                            return true
%                        }else if Int(result) == kSecTrustResultRecoverableTrustFailure {   
%                            println("Error: Certificate is not trusted because of kSecTrustResultRecoverableTrustFailure")
%                            return false
%                        }else{
%                            println("Error: Certificate is not trusted")
%                            return false
%                        }   
%                    }else{
%                        println("Error certificate not trusted")
%                        return false
%                    } 
%                }else{
%                    println(anchorStatus)
%                    return false
%                }
%            }else {
%                println("Error: Root certificate status is '\(certUnderEvalTrustStatus)' and certificate being evaluated status is \(certUnderEvalTrustStatus).")
%                return false
%            }
%        }
%                          
%\end{lstlisting}
%\caption{Evaluate certificate received from peer}
%\label{alleyoop_security_evaluateCertificate}
%\end{figure} 

% %-----------------------------------------------------------------------------
% Using the one-time infrastructure is not without limitations.
% %
% The obvious shortfall is the ``one-time'' requirement.
% %
% A fair assumption is that the AlleyOop Social application along with others 
% using the SOS middleware will acquire their mobile applications from the Apple 
% App Store, which currently requires an Internet connection.
% %
% Assuming users sign up shortly after acquiring the application addresses some 
% concerns with the ``one-time'' requirement.
% %
% Additionally, if a connection between a device and the BaaS is somehow 
% compromised, or a malicious device attempts to provide someone elses 
% unique user-identifier during user sign-up, a certificate with the wrong 
% credentials could be generated by the CA.
% %
% To circumvent the aforementioned issue, the BaaS can ask the CA to compare 
% and validate the unique user-identifier provided in the certificate with the 
% unique user-identifier affiliated with the logged in user.
% %
% Other limitations are also prevalent with the current security scheme such as 
% an Internet connection is required to revoke specific user certificates, update 
% CA root certificates, replenish expired certificates, and notify users of known 
% malicious devices. 


% \section{Message Dissemination}\label{alleyoop_sec_dissemination}
% %-----------------------------------------------------------------------------
% After sign-up is complete and a mobile device receives its respective certificate and 
% AlleyOop Social CA root certificate, the user can disseminate messages to other AlleyOop Social users
% using any DTN routing protocol discussed in Section~\ref{alleyoop_subsubsec_routing}.
% %
% Whenever a user creates a message or performs an action such as follow/unfollow 
% of a user, AlleyOop Social performs the following two operations: 1) saves the action to the local database 
% on the mobile device and 2) synchronizes the action with the BaaS when the Internet 
% becomes available.
% %
% Once an action is saved to the local database of the device it can 
% be disseminated using a DTN routing protocol to interested AlleyOop Social users with out the use of Internet. 
% %
% The following sections provide further detail of how messages are disseminated
% after being created by a user in the {AlleyOop Social Application} layer and passed 
% to the {routing manager}.

%  \begin{figure*}[htbp]
%  	\centering
%  	\subfloat[AlleyOop Social message forwarder selection]{\includegraphics[width=0.45\textwidth, height=2.7in]{alleyoop_msg_forwarder_selection}
%  	%\caption{AlleyOop Social message forwarder selection}
%  	\label{fig_alleyoop_msg_forwarder_selection}}
%      ~
%      \subfloat[AlleyOop Social message forwarder dissemination]{\includegraphics[width=0.45\textwidth, height=2.7in]{alleyoop_msg_forwarder_diss}
%  	%\caption{AlleyOop Social message forwarder dissemination}
%  	\label{fig_alleyoop_msg_forwarder_diss}}    
    
%      \caption{AlleyOop Social message forwarder}
%  	\label{fig_alleyoop_msg_forwarder}    
    
%  \end{figure*}

% \subsection{Advertisements and node discovery}\label{alleyoop_subsec_advertise}
% %-----------------------------------------------------------------------------
% Mobile devices roam freely advertising and browsing for basic information in plain-text to 
% assist other AlleyOop Social enabled devices with making the decision of whether to request 
% a connection or not.  
% %
% For example, the epidemic and IB routing protocols discussed in Section~\ref{alleyoop_subsubsec_routing} 
% advertises a plain-text key/value dictionary consisting of \textit{UserID/MessageNumber}. 
% %a: {[YyCVxDcerf: 8, ...:...]}.
% %
% The key field in the dictionary is a 10 byte unique user identification 
% string.
% %
% The value field of the dictionary is the latest \textit{MessageNumber} that 
% the advertising device has for the particular \textit{UserID}.
% %
% A browsing node is now able to quickly decide whether it is interested in
% the \textit{MessageNumber} for the respective \textit{UserID} string and whether it 
% should request a connection from the advertising node.
% %
% Figure~\ref{fig_allleyoop_decentralized} depicts a typical scenario in AlleyOop Social  
% where Bob's device is interested in messages from Alice's device.



% % \begin{figure*}[htbp]
% % 	\centering
% % 	\includegraphics[width=0.85\textwidth, height=2.5in]{alleyoop_msg_forwarder_selection}
% % 	\caption{AlleyOop Social message forwarder selection}
% % 	\label{fig_alleyoop_msg_forwarder_selection}
% % \end{figure*}

% %-----------------------------------------------------------------------------
% Figure~\ref{fig_allleyoop_decentralized} depicts a typical scenario in AlleyOop Social   
% where Bob's device is interested in messages from Alice's device.
% %
% For brevity, Alice and Bob's mobile devices will be associated with their
% names for the rest of this section.
% %
% Once Bob sees Alice's advertisement information in plain-text and decides he is 
% interested, Bob sends Alice an invitation along with the first message 
% number of Alice's message he is interested in.
% %
% Alice understands that Bob is interested in the message numbers between the message 
% number Bob sent and the message number Alice was advertising.
% %
% Alice then accepts the invitation and sends Bob her certificate. 
% %
% Simultaneously, Bob sends Alice his certificate and they receive and evaluate each other's 
% certificate. %based on the methods discussed in Section~\ref{alleyoop_sec_privacy}
% %and shown in Figures~\ref{alleyoop_security_receiveCertificate} and~\ref{alleyoop_security_evaluateCertificate}.
% %
% Once both user pass verification, Alice's device extracts Bob's public-key and user-identifier 
% string from Bob's certificate. 
% %
% Bob's device proceeds to extract Alice's public-key and user-identifier from Alice's 
% certificate, and an encrypted connection is made between the two peers using the corresponding 
% peer's public-key. 
% %
% While connected, Alice signs a SHA256 hash of all of the messages Bob requested with her private-key 
% and encrypts the plain-text messages with Bob's public-key. 
% %
% All of the plain-text messages along with the respective signatures are enqueued and sent to 
% Bob beginning with the first message Bob requested in his invitation. 
% %
% Once received, Bob decrypts the messages with his private-key and verifies all the messages 
% indeed belong to Alice by taking a SHA256 hash of each message and verifying them against Alice's 
% public-key and received signatures.
% %


% \subsection{Forwarder Selection}\label{alleyoop_subsec_forwarder}
% %-----------------------------------------------------------------------------
% Depending on the DTN routing protocol being used in the {Routing} layer
% of the  mobile device, prospective nodes can become message forwarders
% for other users.
% %
% For example, in epidemic and IB routing, a node becomes a message 
% forwarder for a particular user-identifier whenever a new message is requested 
% and received.
% %
% When a node becomes a message forwarder, it follows a similar process to the 
% one outlined in Figure~\ref{fig_allleyoop_decentralized}, with particular 
% differences that are shown in Figures~\ref{fig_alleyoop_msg_forwarder_selection}.
% % 
% For each message Bob receives from Alice, Bob stores the decrypted plain-text 
% message along with the signature of the message.
% %
% After Bob successfully receives all of Alice's messages, his device stores Alice's 
% certificate to his iOS keychain for future retrieval.
% %
% Bob then requests a disconnection and both devices return to advertising in plain-text.
% %



% % \begin{figure*}[htbp]
% % 	\centering
% % 	\includegraphics[width=0.85\textwidth, height=2.5in]{alleyoop_msg_forwarder_diss}
% % 	\caption{AlleyOop Social message forwarder dissemination}
% % 	\label{fig_alleyoop_msg_forwarder_diss}
% % \end{figure*}

% %-----------------------------------------------------------------------------
% Becoming a message forwarder adds additional key/value pairs to a nodes 
% advertising dictionary.
% %
% %If Bob's original advertising dictionary for broadcasting that he is a 
% %passer of his own messages was, {[cN2LoWpOVw: 16]}, before he 
% %became an advertiser for Alice.
% %%
% %Then his new advertising dictionary becomes {[cN2LoWpOVw: 16, YyCVxDcerf: 8]} after 
% %he is designated a message forwarder for Alice's messages.
% Assuming Bob's \textit{UserID} is \textit{cN2LoWpOVw} and his current 
% \textit{MessageNumber} is \textit{16}, Bob's advertising dictionary on his own 
% mobile device would be \textit{[cN2LoWpOVw: 16]}.
% %
% %If Bob's original advertising dictionary which only consisted of Bob being a
% %passer of his own messages was {[cN2LoWpOVw: 16]}.
% %
% Bob's new advertising dictionary after being designated a message forwarder 
% for Alice becomes \textit{[cN2LoWpOVw: 16, YyCVxDcerf: 8]}, assuming 
% \textit{YyCVxDcerf} is Alice's \textit{UserID} and ``8'' is the latest \textit{MessageNumber} of Alice's
% that Bob has received.



% \subsection{Forwarder Dissemination}\label{alleyoop_subsec_diss}
% %-----------------------------------------------------------------------------
% Figure~\ref{fig_alleyoop_msg_forwarder_diss} shows the interaction between 
% Bob and Carol when Carol is interested in Alice's message that Bob is forwarding.
% %
% The process is similar to message dissemination in 
% Figure~\ref{fig_allleyoop_decentralized}, except Bob sends 
% his certificate to Carol to establish an encrypted connection and also
% forwards Alice's certificate.
% %
% Carol verifies both Bob and Alice's certificates against the AlleyOop Social 
% CA root certificate she has stored locally.  
% %
% Bob then sends Alice's plain-text messages encrypted with his private-key to Carol 
% along with the original signatures Alice gave to him during their previous encounter 
% in Figure~\ref{fig_alleyoop_msg_forwarder_selection}.
% %
% Carol then decrypts the messages using Bob's public-key, revealing Alice's
% plain-text messages. 
% %
% Carol takes a SHA256 hash of each Alice's plain-text messages and uses the public-key from Alice's 
% certificate along with the signatures received from Bob to verify each one of Alice's 
% messages received from Bob was not modified and originated from Alice.  

% % \begin{figure*}%[htbp]
% % \centering

% %     \subfloat[Delay]{\includegraphics[width=0.5\textwidth, height=2.0in]{delay_1_hop}\label{fig_alley_delay_1_hop}} 
% %     ~
% %     \subfloat[Delivery]{\includegraphics[width=0.5\textwidth, height=2.0in]{delivery_1_hop}\label{fig_alley_deliv_1_hop}}
% %     %~
% %     %\subfloat[AlleyOop Social map of message creation (green) and message dissemination (red)\cb{Need to fix. Only includes message dissemination points right now}]{\includegraphics[width=0.30\textwidth, height=2.0in]{app_map}\label{fig_app_map}}

% % \caption{AlleyOop Social - results 1 - hop}
% % \label{fig_alley_results_1_hop}
% % \end{figure*}

% \begin{figure*}%[htbp]
% \centering

%     \subfloat[Social relationship directed graph for the ten (10) active users in Gainesville, FL]{\includegraphics[width=0.48\textwidth, height=2.0in]{network_graph}\label{fig_network_graph}} 
%     ~
% 	\subfloat[AlleyOop Social map of ``active user'' message generation (blue) and message dissemination (red) in a $\sim$11km x 8km area]{\includegraphics[width=0.48\textwidth, height=2.0in]{app_map}\label{fig_app_map}} 
    
    
%     \subfloat[Delay]{\includegraphics[width=0.48\textwidth, height=2.0in]{delay_both}\label{fig_alley_delay}} 
%     ~
%     \subfloat[Delivery]{\includegraphics[width=0.48\textwidth, height=2.0in]{delivery_both}\label{fig_alley_deliv}}
%     %~
%     %\subfloat[AlleyOop Social map of message creation (green) and message dissemination (red)\cb{Need to fix. Only includes message dissemination points right now}]{\includegraphics[width=0.30\textwidth, height=2.0in]{app_map}\label{fig_app_map}}

% \caption{AlleyOop Social real world evaluation results}
% \label{fig_alley_results}
% \end{figure*}

% \section{Real World Evaluation}\label{alleyoop_sec_results}
% %-----------------------------------------------------------------------------
% %\input{comm_mag_results}
% The AlleyOop Social application was available for beta testing in Apple TestFlight
% app for $7$ days.
% %
% AlleyOop Social had thirty one ($31$) testers who downloaded the application around 
% the United States.
% %
% %For users who opted-in, the locations of where messages were created and 
% %disseminated can been seen in Figure~\ref{fig_app_map_all}.  
% %
% Due to limited amount of users and a critical mass of users who are socially 
% related to each other, this section will constrain the results to users who 
% passed at least one $1$ D2D message using the IB routing protocol in Gainesville, FL. 
% %
% %Nine ($9$) of the users were undergraduate or graduate students at the University of Florida. %University 
% %of Florida. 
% %
% %One of these student users had access to two devices, which resulted in ten 
% %($10$) active devices in Gainesville, FL.
% %
% Ten devices used AlleyOop Social in a $\sim$11km x 8km area depicted in 
% Figure~\ref{fig_app_map}, resulting in users posting $259$ unique messages.




% \subsection{Social relationships}\label{subsec_social_relation}
% %-----------------------------------------------------------------------------
% Many of the students were friends before the field study and typically interacted 
% during the school week.
% % 
% %AlleyOop Social users posted over $400$ messages ($310$ from active users) and created over $1200$ interactions (message passing and user subscriptions).
% %
% Individual users were given the freedom to choose other users to subscribe to;
% therefore, all users did not follow each other. 
% %
% The digraph $\mathcal{G}(V,E)$ formed by the total nodes who 
% participated $n = |V(\mathcal{G})| = 10$ is depicted in Figure~\ref{fig_network_graph}. 
% %
% A social relationship between a node pair $i,j~\in E$ is an edge
% $e_{i,j}$, meaning that user $i$ follows user $j$.
% %
% The edge $e_{i,j}$ does not necessarily mean the edge $e_{j,i}$ exists because
% some users did not follow each other back as in the case for node $1$ and node $3$
% in Figure~\ref{fig_network_graph}.
% %
% The density of the social relationships is $0.64$ which means that the majority 
% of the possible social relationships were formed naturally by the participating 
% nodes.
% %
% The compactness of $\mathcal{G}$ can be determined by calculating the average 
% shortest path length between all node relationship pairs 
% $\sum_{i\geq j}l(i,j) / \frac{n(n-1)}{2} = 1.3$, along with the maximum shortest 
% path length, otherwise known as the diameter $d$ between any two nodes 
% $d(\mathcal{G}) = \textrm{max}_{i,j\in V}~l(i,j) = 2$.
% %
% The compactness of the social relationship graph reveals that even if a user 
% does not follow another user directly, there is still an indirect follow that is two
% degrees away. 
% %
% The center nodes (6 and 7) of the social relationship graph has a radius of 
% $1$ which reflects the nodes with the smallest eccentricity$_{i,j} = 
% \textrm{max}_{i,j \in V}~l(i,j)$.

% %-----------------------------------------------------------------------------
% Additional features can be determined by translating Figure~\ref{fig_network_graph}
% to a undirected graph.
% %
% This means that if a two-way relationship did not already exist, it will exist 
% in the undirectional graph making $e_{i,j} = e_{j,i}$ for all $i,j\in E$.
% %
% Now the network transitivity is computed to be $T(\mathcal{G}) = 3*\textrm{ number of 
% triangles }/\textrm{ number of connected triads} =  0.80$ which measures the extent
% that a friend $k$ of a friend $j$ is also a friend of $i$.

% \subsection{Message dissemination}\label{subsec_results}
% %-----------------------------------------------------------------------------
% The social relationship graph in Figure~\ref{fig_network_graph} provides an 
% overall understanding of nodes' interests in messages along with providing insight 
% into how nodes may cluster due to who they follow.
% %
% Figure~\ref{fig_network_graph} does not provide any insight on physical node 
% locations or mobility during the evaluation.
% %
% Figure~\ref{fig_app_map} assists with understanding node mobility by showing 
% where users created messages (blue) and passed messages (red) in Gainesville, FL.  
% %
% A total of $967$ messages were disseminated from user-to-user using IB routing 
% in AlleyOop Social.
% %
% The total amount of subscriptions made by the ten (10) active users was $46$. 
% %
% Figure~\ref{fig_alley_delay} provide the delay results for 
% messages disseminated via ``1-hop'' and ``All'' hops. 
% %
% %The delay in message delivery as well as the delivery ratio for are shown in Figures~\ref{fig_alley_delay} and~\ref{fig_alley_deliv} respectively. 
% %
% In regard to ``All'' messages, Figure~\ref{fig_alley_delay} shows that 
% $0.54$ of the messages delivered had a delay of $24$ hours or less, 
% while $0.90$ of the messages had a delay of 80 hours or less. 
% %
% In regard to ``1-hop'' delay, that $0.62$ of the messages delivered had a 
% delay of $24$ hours or less, while $0.93$ of the messages had a delay of 80 
% hours or less for ``1-hop'' messages. 
%
%We attribute the high delay to the lack of density in the evaluation\cb{calculate 2d density}.
%
%Coupling the knowledge of the node density with the knowledge of users going 
%to sleep, the delays in message delivery are reasonable for a real world 
%evaluation.  
%
%The delay and delivery ratios are only determined for users who came in direct contact with another AlleyOop Social user and disseminated at least one message using IB routing.


% \begin{figure}%[htbp]
% 	\centering
% 	\includegraphics[width=.45\textwidth, height=1.75in]{network_graph}
% 	\caption{Social connectivity graph of active users in Gainesville, FL. The center nodes are 2 and 7. The network has a density of 0.64 with the average shortest path being at 1.4}
% 	\label{fig_network_graph}
% \end{figure}

% \begin{figure}[htbp]
% 	\centering
% 	\includegraphics[width=.40\textwidth, height=1.75in]{app_map_all}
% 	\caption{AlleyOop Social map of ``all user'' message creation (blue) and message dissemination (red)}
% 	\label{fig_app_map_all}
% \end{figure}


% %-----------------------------------------------------------------------------
% In regard to message delivery, Figure~\ref{fig_alley_deliv} shows that $0.90$ 
% of the subscriptions had a delivery ratio of $0.84$ for ``All'' messages.
% %
% $0.90$ of the subscriptions had a delivery ratio of $0.89$ for ``1-hop'' messages.  
% %
% Users delivered $0.826$ of the $967$ messages via 1-hop.
% %
% The additional $0.174$ were delivered using 2-hops or more and is depicted in ``All''.
% %
% $9$ out of $10$ active users delivered a portion of their own messages within 
% ``1-hop''.
% %
% The compactness of the social relationships between the nodes 
% discussed in Section~\ref{subsec_social_relation} partially explains why 
% the majority of the messages were delivered within ``1-hop''.
% %
% Note the low density due to real people being able to operate freely in 
% a large city area (88km$^{2}$), which results in the large delay at $0.93$.
% %
% DTN simulations typically model 50 to 100 nodes in a constrained simulation 
% space ranging  between 0.25km$^{2}$ - 4km$^{2}$.
% %
% In addition, node mobility became stationary, limiting interactions between 
% nodes for at least 5-8 hours a day due to users sleeping at night.
% %
% The results at such a low density provide promising insight into delay tolerant social networks and suggest further investigations at higher densities are needed.


% \section{Justification for Delay Tolerant Mobile Social Networking Apps}\label{survey}
% %-----------------------------------------------------------------------------
% Survey data were gathered from 41 respondents in the Summer of 2015 to gauge 
% initial interest in the study and to provide justification for a delay tolerant mobile social networking app.
% %
% Respondents included graduate students as well as undergraduate students in a 
% wireless networking course at the University of Florida.  
% %
% The survey included questions about social media usage 
% (types of accounts, frequency of posts), the respondent's 
% personal mobile device (type of device), as well as questions 
% assessing Internet, WiFi, and Bluetooth usage. 
% %
% General interest was also assessed for a gamified version of 
% the app versus one that facilitates communication without 
% requiring Internet or LTE/3G connection. 
% %
% The number of survey respondents who use mainstream social networking applications 
% is shown in Figure~\ref{fig_survey_social_media}.   
% %  
% Results suggest that the most commonly used form of social media is Facebook (100\% of respondents).
% %
% In terms of privacy, $68\%$ of the respondents who use 
% Facebook and $58\%$ of those who use Instagram elected to have 
% private accounts.
% %
% Those who have Twitter were less concerned about privacy 
% with only $33\%$ of Twitter users maintaining a private account.  


% % \begin{figure}%[htbp]
% % 	\centering
% % 	\includegraphics[width=.40\textwidth, height=1.5in]{app_map}
% % 	\caption{AlleyOop Social map of ``active user'' message creation (blue) and message dissemination (red) in a $\sim$11km x 8km area}
% % 	\label{fig_app_map}
% % \end{figure}

% %-----------------------------------------------------------------------------
% Respondents who took the survey were also asked about the number of times they post
% per day on popular social media sites%(Figure~\ref{fig_survey_avg_postings})
% , as well as 
% the types of posts they make (Figure~\ref{fig_survey_type_postings}). 
% %
% Respondents with social media accounts had the most frequent daily posts on 
% Twitter (3.2 posts per day). The most common content posted by users, 
% irrespective of social media account, was photos. 
% %
% With regard to mobile devices, $69\%$ had an iOS device, $26\%$ had an Android device, and $5\%$
% had neither suggesting that a social networking protocol compatible with iOS devices is most warranted.
% %
% Respondents who answered this question were allowed to select multiple devices, meaning users
% were allowed to have both Android and iOS devices.  




% \begin{figure}
% 	\centering
% 	\includegraphics[width=.49\textwidth, height=1.5in]{app_social_posts}
% 	\caption{Responses for average postings per day}
% 	\label{fig_survey_avg_postings}
% \end{figure}

% \begin{figure}
% 	\centering
% 	\includegraphics[width=.49\textwidth]{app_social_type_of_posts}
% 	\caption{Responses for types of social media posts}
% 	\label{fig_survey_type_postings}
% \end{figure}

% \begin{figure*}
% 	\centering
% 	\subfloat[Responses to social media accounts]{
%     	\includegraphics[width=.45\textwidth, height=1.5in]{app_social_media}
% 		\label{fig_survey_social_media}
%     }
%  	~   
%     \subfloat[Responses for types of social media posts]{
%     	\includegraphics[width=.45\textwidth, height=1.5in]{app_social_type_of_posts}
% 		\label{fig_survey_type_postings}
%     }
    
%     \caption{Survey responses}
% 	\label{fig_survey}
    
% \end{figure*}


% Data were also collected on Internet usage and availability. In general, survey respondents were without Internet access for an average of $9.56$ hours per week ($\sigma = 17.57$; Range: $0 - 84.00$). To examine whether differences in the frequency of social media postings exist based on Internet availability, an independent samples t-test was performed to compare the frequency of posting on social media accounts across respondents with low versus high weekly Internet access. Participants were first stratified into two groups based on the number of hours of weekly access to Internet (low Internet access, high Internet access) using a median split of the hours reported on the survey. Survey responses were compiled for each respondent to create an overall frequency of posting per day across all four social media accounts; this overall frequency was then compared between the low and high Internet access groups. Results of the t-test comparing posting frequency were not significant $t(22) = 1.46$, $p =.16$, but there was a general trend suggesting that persons with a larger number of hours of Internet access ($\mu = 7.06$, $\sigma = 12.55$) had a higher number of daily social media posts in comparison to those who were in the low Internet access group ($\mu = 2.82$, $\sigma = 3.46$).    

% To examine whether interest level in the app differed as a condition of ability to communicate in situations where there is limited Internet availability (e.g., without Internet or 3G/LTE connection), a chi-square test of independence was conducted. Specifically, the chi-square test compared interest level for the app if it is gamified versus interest when it permits communication despite intermittent Internet access. The questions assessing interest were formatted in Likert scale (1 = not interested through 5 = very interested), and were used for chi-square analyses. Interest was grouped into those who are not interested (response options 1-3) versus those who are interested (options 4-5) based on endorsement of the questions. Results of the chi-square test, depicted in Table~\ref{fig_survey_no_internet}, show that the proportion of respondents who expressed interest in the app did increase when communication without Internet access was an option for the app, $\chi^2(1) = 1.35$, $p = .25$. While this was not a statistically significant finding, the current analyses was limited in statistical power due to a limited number of observations (i.e., respondents) per cell. However, with increased interest and participation in the app, it is expected for statistical power to become adequate and for this trend to reach statistical significance. Nevertheless, this finding suggests that the ability to communicate via AlleyOop Social despite intermittent Internet access may be a critical component to application development and a major marketing factor for social media consumers.     
% \begin{table}%[htpb]
% 	\centering
	
%     \begin{tabular}{|l|c|c|c|c|} %{r l l l l}  
% 		\hline
% 		\multicolumn{2}{|l|}{} & \multicolumn{2}{c|}{Communication No Internet} & \\
%         \cline{3-5}
% 		\multicolumn{2}{|l|}{} & Not Interested & Interested & Total \\
% 		\hline
% 		\multirow{2}{*}{\specialcell{Social Media \\ Gamification}} & Not Interested & 7 & 22 & 29\\
% 		\cline{2-5}
%         & Interested & 1 & 11 & 12 \\
% 		\hline
%         Total & & 8 & 33 & 41 \\
% 		\hline
% 	\end{tabular}
 	
%  	\caption{Response frequency table depicting interest in social media application with gamification vs. one that permits communication without Internet}
% 	\label{fig_survey_no_internet}
    
% \end{table}


% \section{Related Work}\label{related_work}
% %-----------------------------------------------------------------------------
% %Various middlewares~\cite{su2007haggle, Juste2013a, dubois2015supporting}, testbeds~\cite{doering2008ibr,paul2015challenges,moraleda2014link}, and mobile applications have been developed to 
% %address the issues of providing deployable delay tolerant networking 
% %applications which can operate with minimal infrastructure and effectively 
% %evaluate DTN routing protocols.
% % various middlewares, testbeds, and 
% %mobile applications have been developed.
% %
% %The rest of Section~\ref{related_work} will highlight some of 
% %the related contributions to deployable delay tolerant and ad hoc applications 
% %and testbeds.
% In recent years, a number of social-aware and social-based routing schemes have
% leveraged social interactions to deliver data using delay tolerant networks 
% (DTNs)~\cite{wei2014survey}. 
% %
% However, related work has primarily evaluated routing protocols in simulation 
% environments, which provide valuable analyses, but are based on synthetic 
% mobility patterns to emulate node movement and tend to use abstract models to 
% emulate or simulate the radio response of real commodity wireless technologies\cite{hui2008phase,Keraenen2009,Baker2013}.
% %
% There are a few studies that have taken on the approach of demonstrating DTNs 
% in realistic environments~\cite{doria2009providing,pentland2004daknet,doering2008ibr}. 
% %
% However, these studies do not consider other significant aspects, such as user 
% security and privacy along with the limitation of operating with only the 
% epidemic routing scheme. 
% %
% Various middlewares~\cite{pietilainen2009mobiclique,helgason2010mobile,skjegstad2012mist,
% dubois2015supporting}, testbeds~\cite{mukhtar2006backup,morgenroth2012bundle,juste2014tincan, moraleda2014link, ben2014demo, paul2015challenges, siby2015method, asadpour2016route}, 
% and mobile applications have been developed to 
% address providing deployable delay tolerant networking applications which can 
% operate with minimal infrastructure and effectively evaluate DTN routing 
% protocols. The purpose of this sections is to provide a brief overview on 
% middlewares and testbeds developed by researchers.

% \subsection{Middlewares}\label{alleyoop_subsec_middlewares}
% %-----------------------------------------------------------------------------
% The Haggle architecture provides seamless network 
% connectivity for dynamic mobile environments, simplifying application 
% logic~\cite{su2007haggle}. 
% %
% Haggle has a flexible architecture that allows for many forwarding algorithms 
% to run simultaneously. 
% %
% Dubois et al. simplified digital content sharing on mobile devices by providing 
% support for self-organizing heterogeneous networks (e.g., 3G/4G, WiFi, 
% Bluetooth, etc.) and pervasive storage~\cite{dubois2015supporting}. 
% %
% Through their work the authors showed how these technologies can be incorporated 
% into mobile content-sharing middleware with some modification to mobile operating
% systems. 
% %
% % MobiClique is a modular mobile social middleware that leverages current social 
% % networks for ad hoc communication~\cite{pietilainen2009mobiclique}.
% % % 
% % Helgason et al~\cite{helgason2010mobile, pajevic2011demo}, proposed a middleware 
% % that allows mobile devices to leverage access points or distribute content 
% % opportunistically.
% %
% The SOS middleware provides seamless network connectivity over Bluetooth, 
% peer-to-peer WiFi, and infrastructure WiFi on iOS devices.
% % 
% Unlike many of the aforementioned middlewares, AlleyOop Social provides 
% opportunistic communication without any modifications such as jail-breaking the 
% devices and does not violate Apple App store policies.
% %
% In addition, SOS abstracts away the complexities of security, enabling 
% researchers to contribute their own DTN routing schemes to AlleyOop Social. 
% % and evaluation of DTN routing protocols.


% \subsection{Testbeds}\label{alleyoop_subsec_testbeds}
% %-----------------------------------------------------------------------------
% % Others researchers have developed DTN test 
% % beds~\cite{doering2008ibr,paul2015challenges,moraleda2014link}, to capture DTN 
% % performance, but these are not designed to capture mobile social ad hoc 
% % networking response and performance. 
% % %
% % Moraleda-Soler et. al.~\cite{moraleda2014link} propose a device-to-device 
% % testbed using Commercial Off-The-Shelf (COTS) parts that can implement 
% % link-aware opportunistic transmission schemes. 
% %
% The authors in~\cite{gardner2011serval} created Serval Mesh, 
% an Android based mobile application that establishes WiFi ad hoc connections to transmit secure 
% text-messages to users.
% %
% Opportunistic Twitter~\cite{ristanovic2012traps} is an application testbed that 
% demonstrates the drawbacks of contact-based simulations in opportunistic networks.
% %
% The work in~\cite{raju2016design} addresses the problem of how to enable 
% effective data query in a Mobile Ad-hoc Social Network (MASON) formed by 
% mobile users connected through wireless communication technology 
% (Bluetooth, WiFi) and who share similar interests. 
% %DTHN-Test~\cite{paul2015challenges}, implement a delay tolerant hybrid network (DTHN) 
% %testbed using COTS such as android devices, Raspberry Pi, and long-range WiFi devices.
% %
% % Finally, in~\cite{Juste2013a}, the authors introduce Litter, a 
% % decentralized mircroblogging service that operates over peer-to-peer 
% % virtual private networks to enable fast, private updates amongst friends 
% % for Linux and Android. 
% %
% In many of the aforementioned testbeds, the respective testbeds require 
% additional COTS technology to facilitate message delivery, %does not consider security and privacy concerns of the users, 
% rooting of an operating system, or not ideal for mobile communication. 
% %
% In addition, many of the testbeds only operate as a MANET, with limited 
% ability to deliver information in an intermittent network.
% %
% AlleyOop Social provides a secure delay tolerant research platform that 
% requires no additional COTS other than mobile iOS devices.
%
%AlleyOop Social also allows the flexibility of adding multiple DTN routing 
%protocols allowing for the evaluation of many protocols.

% Dubois and colleagues \cite{dubois2015supporting} simplified digital content sharing on mobile devices by providing support for self-organizing heterogeneous networks (e.g., 3G/4G, WiFi, Bluetooth, etc.)  and pervasive storage. Through their work they showed how these technologies can be incorporated into mobile content-sharing middleware without any modification to commercially available devices or applications. 
% %
% The Haggle architecture provides seamless network connectivity for dynamic 
% mobile environments, simplifying application logic~\cite{su2007haggle}. 
% %
% Haggle has a flexible architecture that allows for many forwarding algorithms 
% to run simultaneously.
% %  
% %Gently~\cite{musolesi2008writing}, is a social routing protocol that 
% %combines LABEL~\cite{hui2007small} and CAR~\cite{Musolesi2009}, which was
% %implemented on the Haggle middleware.
% %
% %MobiClique is a modular mobile social middleware that leverages current social 
% %networks for ad hoc communication~\cite{pietilainen2009mobiclique}.
% % 
% %Helgason et al~\cite{helgason2010mobile, pajevic2011demo}, proposed a middleware 
% %that allows mobile devices to leverage access points or distribute content 
% %opportunistically.
% %
% %Nordstom et al~\cite{nordstrom2014haggle} introduced a share content system for mobile
% %phones that allow the prioritization of content. 
% %
% %AlleyOop Social provides seamless network connectivity over Bluetooth and WiFi, 
% %similar to the aforementioned middlewares by leveraging the Multipeer Connectivity Framework (MPC)
% %in iOS.
% %

% Moraleda-Soler et al~\cite{moraleda2014link} propose a device-to-device testbed
% using Commercial Off-The-Shelf (COTS) parts that can implement link-aware opportunistic transmission schemes.
% %
% The authors of \cite{asadpour2016route} utilize Delay-Tolerant Networks within Micro Aerial Vehicles (MAVs). The algorithm they developed connects location-aware end-to-end routing with delay-tolerant forwarding, by the inclusion of two predictive heuristics. 
% %
% AlleyOop Social provides seamless network connectivity over Bluetooth and WiFi, 
% similar to the aforementioned middlewares by leveraging the Multipeer Connectivity Framework (MPC) in iOS.
% %
% AlleyOop Social provides a publish-subscribe application layer similar to Twitter 
% that is familiar to end-users, and enables researchers to focus on the implementation 
% and evaluation of DTN routing protocols.
% %
% %Opportunistic Twitter~\cite{ristanovic2012traps} is an application testbed that 
% %demonstrates the drawbacks of contact-based simulations in opportunistic networks.
% %
% %DTHN-Test~\cite{paul2015challenges}, implement a delay tolerant hybrid network (DTHN) 
% %testbed using COTS such as android devices, Raspberry Pi, and long-range WiFi devices.
% % 
% %AlleyOop Social provides a testbed for mobile DTN routing protocols by only requiring iOS devices, and does not require any additional COTS to facilitate message delivery between intermittent nodes.
% %


% %\subsection{Deployed Applications}\label{alleyoop_subsec_related_work}
% %Pentland et al ~\cite{pentland2004daknet}, created DakNet, a wireless network 
% %that leverages existing communications and transportation infrastructure to 
% %extend Internet connectivity through mobile access points.  
% %
% %Backup and Bypass is a DTN-based mobile application which enables ad hoc 
% %communication over Bluetooth and WLAN independent of infrastructure~\cite{mukhtar2006backup}.
% %
% %The Saami Network Connection (SNC) was developed by the authors in~\cite{doria2009providing}.
% %
% %The purpose of SNC is to provide network connectivity for the nomadic Saami people
% %based on DTNs.
% %
% %IBR-DTN~\cite{doering2008ibr}, is a lightweight implementation of the DTN bundle
% %protocol intended to run on smartphones, notebooks, and PCs. 
% %
% %Morgenroth et al ~\cite{morgenroth2012bundle}, implemented the IBR-DTN protocol 
% %for Android devices by creating two mobile applications titled Whisper and Talkie.
% %
% %Whisper allows users to communicate by sending text messages while Talkie allows users 
% %to send recorded messages to each other.
% %
% %The authors in~\cite{gardner2011serval, gardner-stephen_13}, created Serval Mesh, 
% %a mobile application that establishes WiFi ad hoc connections to transmit secure 
% %text-messages to users.
% %
% The work of \cite{raju2016design} addresses the problem of how to enable effective data query in a Mobile Ad-hoc Social Network (MASON) formed by mobile users connected through wireless communication technology (Bluetooth, WiFi) and who share similar interests. Cont2, a social-aware file search method \cite{chenefficient}, exploits both node contents and contact patterns to virtually group common-interest nodes, and exploits nodes? contact frequencies with a community to expedite file searching into a community. 
% %
% Litter is a decentralized mircroblogging service that operates over peer-to-peer virtual
% private networks to enable fast, private updates amongst friends~\cite{StJuste2011,Juste2013}.
% % 
% The authors of \cite{siby2015method} are interested in Delay-Tolerant Networks (DTNs) for distributing multimedia content to micro entrepreneurs in under-served rural areas of South Africa. They developed a network emulator that will imitate public commuter buses equipped with WLAN-enabled devices that provide DTN connectivity, thereby carrying data between urban and rural areas.
% %
% %MOSES is an indoor experience sharing platform for mobile devices that distributes
% %geotagged information to users~\cite{ben2014demo}.
% %
% AlleyOop Social differs from the applications reviewed here because it is a DTN 
% by only requiring iOS devices, and does not require any additional COTS to facilitate message delivery between intermittent nodes.
% %
% The modular design of AlleyOop Social, along with its security and privacy features provide an optimal testing platform for multiple social routing DTN protocols.
% %mobile app that can be deployed in any community that has access to iOS devices 
% %beginning with the iPhone 4s and iPad 2.
% %
% AlleyOop Social not only works in wireless ad hoc environments, but it provides DTN routing between nodes, therefore delivering content when intermittency is prevalent.  

%\subsection{Security}\label{alleyoop_subsec_security}

  
% \section{Summary and Future Work}\label{alleyoop_sec_summary}
% %-----------------------------------------------------------------------------
% In this demo, we introduced AlleyOop Social, a publish-subscribe delay 
% tolerant social networking research platform that allows users to interact, 
% publish messages, and discover others that share common interests without 
% requiring cellular or WiFi infrastructure mode.
% %
% SOS was also introduced and provides a modular middleware for researchers to 
% focus on developing routing schemes, thereby alleviating the researcher of 
% the cumbersome tasks of dealing with security, designing a useful application, 
% and attracting users.
% %
% %Researchers can use AlleyOop Social to measure delay and message delivery, and generate 
% %mobility patterns from realistic nodes.
% %
% %The app is designed in Swift for iOS, thus allowing access to millions of testers 
% %through the Apple App Store.
% %
% %The capabilities of AlleyOop Social were validated by a small-scale field experiment conducted at the University of Florida. %University of Florida.
% %
% Future work entails adding additional routing schemes to the SOS middleware 
% along with simplifying the process for researchers to submit their protocols.
% %
% In addition, user encounters and how they effect application time in the 
% foreground and background will be investigated to further understand how mobile 
% operating systems such as iOS can best be utilized for opportunistic communication.


% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation results for the network.}
%\label{fig_sim}
%\end{figure}

% Note that the IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command,
% and the \label for the overall figure must come after \caption.
% \hfil is used as a separator to get equal spacing.
% Watch out that the combined width of all the subfigures on a 
% line do not exceed the text width or a line break will occur.
%
%\begin{figure*}[!t]
%\centering
%\subfloat[Case I]{\includegraphics[width=2.5in]{box}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{box}%
%\label{fig_second_case}}
%\caption{Simulation results for the network.}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat[]), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.
% Be aware that for subfig.sty to generate the (a), (b), etc., subfigure
% labels, the optional argument to \subfloat must be present. If a
% subcaption is not desired, just leave its contents blank,
% e.g., \subfloat[].


% An example of a floating table. Note that, for IEEE style tables, the
% \caption command should come BEFORE the table and, given that table
% captions serve much like titles, are usually capitalized except for words
% such as a, an, and, as, at, but, by, for, in, nor, of, on, or, the, to
% and up, which are usually not capitalized unless they are the first or
% last word of the caption. Table text will default to \footnotesize as
% the IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that the IEEE does not put floats in the very first column
% - or typically anywhere on the first page for that matter. Also,
% in-text middle ("here") positioning is typically not used, but it
% is allowed and encouraged for Computer Society conferences (but
% not Computer Society journals). Most IEEE journals/conferences use
% top floats exclusively. 
% Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the
% \fnbelowfloat command of the stfloats package.




% conference papers do not normally have an appendix


% use section* for acknowledgment
%\section*{Acknowledgment}


%The authors would like to thank...





% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://mirror.ctan.org/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
\bibliography{dtnreferences}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)





% that's all folks
\end{document}



infocom_demo.bbl
% Generated by IEEEtran.bst, version: 1.13 (2008/09/30)
\begin{thebibliography}{1}
\providecommand{\url}[1]{#1}
\csname url@samestyle\endcsname
\providecommand{\newblock}{\relax}
\providecommand{\bibinfo}[2]{#2}
\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}
\providecommand{\BIBentryALTinterwordstretchfactor}{4}
\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus
\BIBentryALTinterwordstretchfactor\fontdimen3\font minus
  \fontdimen4\font\relax}
\providecommand{\BIBforeignlanguage}[2]{{%
\expandafter\ifx\csname l@#1\endcsname\relax
\typeout{** WARNING: IEEEtran.bst: No hyphenation pattern has been}%
\typeout{** loaded for the language `#1'. Using the pattern for}%
\typeout{** the default language instead.}%
\else
\language=\csname l@#1\endcsname
\fi
#2}}
\providecommand{\BIBdecl}{\relax}
\BIBdecl

\bibitem{faloutsos2010online}
M.~Faloutsos, T.~Karagiannis, and S.-H. Moon, ``Online social networks,''
  \emph{Network, IEEE}, vol.~24, no.~5, pp. 4--5, 2010.

\bibitem{Baker2013}
C.~Baker, J.~Almodovar-Faria, P.~S. Juste, and J.~McNair, ``Low energy socially
  cognizant routing for delay tolerant mobile networks,'' in \emph{Military
  Communications Conference, MILCOM 2013-2013 IEEE}.\hskip 1em plus 0.5em minus
  0.4em\relax IEEE, 2013, pp. 299--304.

\bibitem{su2007haggle}
J.~Su, J.~Scott, P.~Hui, J.~Crowcroft, E.~De~Lara, C.~Diot, A.~Goel, M.~H. Lim,
  and E.~Upton, \emph{Haggle: Seamless networking for mobile
  applications}.\hskip 1em plus 0.5em minus 0.4em\relax Springer, 2007.

\bibitem{Fall2003}
K.~Fall, ``A delay-tolerant network architecture for challenged internets,'' in
  \emph{Proceedings of the 2003 conference on Applications, technologies,
  architectures, and protocols for computer communications}.\hskip 1em plus
  0.5em minus 0.4em\relax ACM, 2003, pp. 27--34.

\bibitem{perlman1999overview}
R.~Perlman, ``An overview of pki trust models,'' \emph{Network, IEEE}, vol.~13,
  no.~6, pp. 38--43, 1999.

\bibitem{cabaniss2015multi}
R.~Cabaniss, V.~Kumar, and S.~Madria, ``Multi-party encryption (mpe): secure
  communications in delay tolerant networks,'' \emph{Wireless Networks},
  vol.~21, no.~4, pp. 1243--1258, 2015.

\end{thebibliography}
