The Fog Makes Sense: Enabling Social Sensing Services With Limited Internet Connectivity
Ruben Mayer, Harshit Gupta, Enrique Saurez, Umakishore Ramachandran
TThe Fog Makes Sense: Enabling Social Sensing Services WithLimited Internet Connectivity ∗ Ruben Mayer
Institute for Parallel and Distributed SystemsUniversity of StuttgartStuttgart, [email protected]
Harshit Gupta, Enrique SaurezUmakishore Ramachandran
Georgia Institute of TechnologyAtlanta, Georgia, USAharshitg,esaurez,[email protected]
ABSTRACT
Social sensing services use humans as sensor carriers, sensor opera-tors and sensors themselves in order to provide situation-awarenessto applications. This promises to provide a multitude of benefitsto the users, for example in the management of natural disastersor in community empowerment. However, current social sensingservices depend on Internet connectivity since the services are de-ployed on central Cloud platforms. In many circumstances, Internetconnectivity is constrained, for instance when a natural disastercauses Internet outages or when people do not have Internet accessdue to economical reasons. In this paper, we propose the emergingFog Computing infrastructure to become a key-enabler of socialsensing services in situations of constrained Internet connectivity.To this end, we develop a generic architecture and API of Fog-enabled social sensing services. We exemplify the usage of theproposed social sensing architecture on a number of concrete usecases from two different scenarios.
CCS CONCEPTS • Computer systems organization → Distributed architectures;
Sensor networks;
KEYWORDS
Social Sensing, Fog Computing, Situation Awareness
ACM Reference format:
Ruben Mayer, Harshit Gupta, Enrique Saurez, and Umakishore Ramachan-dran. 2017. The Fog Makes Sense: Enabling Social Sensing Services WithLimited Internet Connectivity. In
Proceedings of The 2nd International Work-shop on Social Sensing, Pittsburgh, PA, USA, April 21 2017 (SocialSens’17), ∗ (c) Authors 2017. This is the author’s version of the work. It is posted here foryour personal use. Not for redistribution. The definitive version is published in theProceedings of the 2nd International Workshop on Social Sensing, SocialSens’17,http://dx.doi.org/10.1145/3055601.3055614Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected]. SocialSens’17, Pittsburgh, PA, USA © 2017 Copyright held by the owner/author(s). Publication rights licensed to ACM.978-1-4503-4977-2/17/04...$$15.00DOI: http://dx.doi.org/10.1145/3055601.3055614
Situation-aware applications use data streams from sensors to pro-vide useful services to users or other applications. With the prolif-eration of sensors deployed in the surrounding world, e.g., throughthe Internet of Things, the potential of such applications is reachingnew dimensions. Recently, research focus has been expanded fromtraditional fixed sensor deployments toward social sensing [1]. Thiscomprises passive sensors provided by human carriers in SmartPhones, active human sensor operators taking pictures or videosand even humans operating as sensors themselves, e.g., providinglive information in tweets and postings. Recently, new applicationshave been proposed which use the social sensing infrastructure toinfer situations that are not detectable from traditional sensors.
An important application field of social sensing is in helping peopleto deal with natural disasters. There are applications that help infinding friends and family in the aftermath of a natural disaster[19]. Furthermore, social media can provide access to relevant andtimely information to individuals in affected regions [17]. Providingreal-time information to disaster-affected people about the situa-tion in the area can help them take mitigative actions, for instancemoving contents located in a flood-prone ground floor to upperfloor [2] to reduce the loss caused by the disaster. Social mediahas been an effective way of sharing this sort of crowd-sourcedinformation and can be more accurate and meaningful than gov-ernment predictions. Many proposals envision disaster-strickenpeople to perform social sensing tasks, like providing informationabout the level of inundation of roads in the event of a flood ortsunami. Such unstructured information would be mined by a so-cial sensing application to extract relevant details and create a mapof the affected area with important information. These maps canbe used by government agencies to perform rescue operations [8].Users can upload pictures of people with them, and social sensingapplications apply face recognition algorithms on the pictures andlet the friends and family of detected individuals know that theyare safe.In rural or economically under-served regions, social sensinghelps in understanding socioeconomic processes [11] which canempower communities to better utilize their social capital andenable self-organized governance. Public transportation in suchregions leave much to be desired due to lack of consistency inschedules and infrastrual support, forcing passengers to wait for Social capital refers to the features of social organizations that facilitate coordinationand cooperation for mutual benefit. a r X i v : . [ c s . D C ] M a r ocialSens’17, April 21 2017, Pittsburgh, PA, USA Ruben Mayer, Harshit Gupta, Enrique Saurez, and Umakishore Ramachandran F F F ... Cloud Social Sensors Fog interrupted connection social sensing service deployment Fog node social sensor Figure 1: System Model long periods of time. In well-served communities, infrastructualsupport (e.g., kiosks at bus stops operating on GPS data) providetimely information for the passengers. Social sensing services insuch under-served regions could help gather information, e.g., whenthe bus is going to arrive and share with others even in the absenceof infrastructural support.
While the discussed applications are very effective in utilizing socialsensing information, they rely on Internet connectivity of the socialsensors, the situation inference applications, and the users that areinterested in the detected situations. This is mainly the case becausethe social sensing service is hosted in a central (cloud) data center.However, Internet connectivity cannot be taken for granted onany of the layers of a social sensing application. Internet outagescan affect large areas in case of emergencies, natural disasters, orhacker attacks on the Internet infrastructure [13]. Furthermore,rural regions might not be connected to the Internet at all, or theinhabitants of a rural or an under-served urban region cannot af-ford Internet connectivity for economical reasons. Social sensingapplications can be of a huge benefit in exactly such situationsand circumstances. All of those benefits are tightly coupled to theInternet connectivity; without the Internet, social sensing servicesare not available.In recent years, a new trend has emerged in computing infrastruc-tures that can help in overcoming the Internet dependency of socialsensing services.
Fog Computing , also known as Edge Computing, isthe approach of adding computational resources toward the edge ofthe Internet [5]. While it was initially intended to improve networklatency between sensors, applications, and users [10], we proposeFog Computing to become a central enabler of decentralized, localsocial sensing services that can also operate when Internet connec-tivity is constrained. This way, social sensing services can becomemore robust to Internet outages. Furthermore, communities thatdid not benefit from the first wave of cloud-based social sensingservices can leapfrog those and directly use Fog-based services.However, today’s social sensing services are not capable of us-ing the Fog infrastructure to provide local services when Internetconnectivity is impaired. It is not enough to just run a centralizedsocial sensing service on a number of Fog nodes in parallel. Instead,the social sensing service has to become a distributed service ca-pable of discovering available Fog nodes and building a networkthat aggregates and shares information between social sensors thatare connected to different Fog nodes. In this regard, it needs to be Device ComputationalCapabilities ContainersSupported? ConnectivityRouters Low Yes WiFi, LAN µ Computers Medium Yes WiFi, LANDrones High Yes WiFi, 4G
Figure 2: Overview of Fog Devices. able to deal with the volatile nature of Fog and sensor connectivity.To this end, the architecture of social sensing services needs to beadapted to fully utilize the opportunities of the Fog infrastructure.
In this paper, we give an overview of evolving Fog-based computinginfrastructures. Based on that, we propose a generic architecture forFog-based social sensing services. Using two concrete case studies,we demonstrate how existing cloud-based social sensing servicescan be adapted to use the Fog-based architecture. We conclude thatutilizing Fog-based computing architectures is a promising path tomore robustness and democratization of social sensing services.
In the following, we give an overview of the emerging Fog Com-puting architecture. We point out that the Fog infrastructure canbe completely heterogeneous. Social sensing on Fog has to be ableto cope with the heterogeneity provided in the available resources.Figure 1 shows a model of the Fog Computing architecture. Onthe top layer, the traditional Cloud data center is depicted, beingdeployed in the core of the network and only reachable via Internetconnections. Such data centers are characterized by using stan-dardized, off-the-shelf computing resources, and a virtualizationlayer that allows for an effective utilization of the resources anda pay-as-you-go business model. In the middle layer, a number ofheterogeneous Fog nodes are geographically distributed deployedat the edge of the network. This means, that Fog nodes can belocally reachable by connected devices nearby, even if the Internetis not available. On the bottom layer, geographically distributedsocial sensors are connected to their close-by Fog nodes, eitherdirectly or by using other social sensors as relays.As there is a heterogeneity of use cases for Fog computing, thereare many different notions of a Fog node. In the following, we pro-vide an overview of current proposals and products (cf. Figure 2).With the advent of computationally stronger network equipment,especially routers, it has been proposed that computations are al-ready performed in the network. For instance, Cisco offers theirIOx platforms on hardened routers [6] that are capable of perform-ing data processing tasks. On a higher layer, mini-computers likeRaspberry Pi have gained popularity, as they provide acceptablecomputation performance for a very low price. Additionally, theenergy efficiency and miniaturization of those devices allow themto run in environments that were not specifically designed to hostcomputers, i.e., outside of data centers. Mini-computers can evenbe deployed on drones [9] and provide a completely new level of“mobile computing”. A swarm of drones can build an ad-hoc net-work, a so-called Flying Ad-Hoc Network (FANET) [21], and this nabling Social Sensing Services With Limited Internet Connectivity SocialSens’17, April 21 2017, Pittsburgh, PA, USA
Sensor Comp.
Fog Component Fog Component
P2P Network VANET / FANET ...
Sensor Comp. Sensor Comp. Sensor Comp. Sensor Comp. Sensor Comp. Sensor Comp. ... ... Cloud Component
MANET ...
Figure 3: Generic Software Architecture. way provide Fog computing in an area that lacks any infrastructure.Generally, the deployment of Fog services can be facilitated byusing recent lightweight container technology like Docker [4].The social sensors can be smart sensors that perform the sensing,but also filtering and aggregation. In the scenarios described, typi-cally the smart sensors would be connected to smart phones whichhave certain computational capabilities to do the filtering and aggre-gation. This reduces the communication overhead between socialsensors and Fog nodes, and also reduces computational overheadon the Fog nodes.
Here, we analyze how social sensing services can exploit the Foginfrastructure. They should be able to operate on local informationprovided on a single Fog node, but also capable of sharing infor-mation and collaborating with social sensing services running onneighboring Fog nodes that are reachable. Finally, if the Cloud isreachable, the social sensing services on the different Fog nodesshould be able to share global information via the Cloud.We propose a generic software architecture for social sensingapplications that is capable of exploiting the Fog infrastructure (cf.Figure 3). It consists of three components: (i) A central manage-ment components placed in the Cloud infrastructure (the
CloudComponent ), (ii) A data processing component placed in the Foginfrastructure (the
Fog Component ) and (iii) a social sensing com-ponent deployed on the users’ devices (the
Sensor Component ). Inthe following, we detail the tasks of the components and providean API on all the components for the developers of social sensingservices.
The Cloud Component is, first of all,responsible for the deployment and management of the Social Sens-ing Service artifacts (program code, meta-data, settings, etc.) on theFog Components, when an Internet connection is available. Thismeans that the Cloud Component sends software updates to theFog Components—which can be forwarded to the Sensor Compo-nents from there—and also gathers status information from the FogComponents. This can, e.g., help in deciding where to deploy moreFog Components. Furthermore, the Cloud Component can obtaina global view of the sensed data, which can be useful for offlineanalysis, e.g., in the aftermath of a natural disaster.
The Fog Component is responsible forquerying reachable social sensors for data. Such data queries canbe formulated in state-of-the-art Stream Processing or ComplexEvent Processing query languages, such as CQL [3] or Tesla [7].This allows for defining continuous queries that employ windows, aggregation functions and event patterns on the data streams. Thisway, the Sensor Components can aggregate and filter the senseddata before transferring it to the Fog nodes. Besides traditional con-tinuous queries, queries can also ask for one-time manual sensing,e.g., querying a person to take photos of a specific scene or providefeedback about the number of persons in the vicinity.The results of the sensing queries are further aggregated in theFog Component. Data streams from different social sensors needto be correlated so that an overall picture of the situation can bederived [14]. Furthermore, the comparison of information fromdifferent sources can improve the information quality [17].Besides querying and aggregating sensor data from the socialsensors in its vicinity, the Fog Component manages the sharingof information between different Fog nodes that are connected toeach other over the network. This can be achieved with a peer-to-peer based communication network. Furthermore, if an Internetconnection is available at a Fog node, local data can be streamedto the cloud for further analysis. Note that in latency-tolerantapplications, mobile Fog nodes can serve as “data mules” that collectsensor data from an area that is disconnected from the Internet,transport that data to an area where the Fog node has Internetconnectivity and forward the data to the cloud from there. This canbe useful for retrieving sensor data from remote areas.
The Sensor Component gathers theraw social sensing data, performs the queries from the Fog Compo-nent on that data and returns the results back.It should be noted that not all Sensor Components might beable to directly connect to a Fog Component. This can be due totheir physical distance to the next Fog Component, or due to devicelimitations (e.g., supporting the communication requirements ofthe Fog Components). For instance, if the Fog Components allrequire 4G connectivity, some of the Sensor Components might notbe able to directly connect to any Fog Components at all. Still, suchSensor Components could connect to other Sensor Componentsin their proximity, for instance, using WiFi networking. Then, aSensor Component with direct access to a Fog Component servesas a communication relay between the other Sensor Componentsand the Fog. Such a network can, for instance, be realized withmethods from Mobile Ad-Hoc Networks (MANETs). A similar ideawas presented by Yusuf, et al [20] with the micrograph middleware.It shows how to handle discovery and manage these distributedand isolated communities for social networks.Note that as the Sensor Components can be disconnected fromthe Fog at any time, e.g., because the Fog Component goes down,continuous queries on the Sensor Components should be soft state ,i.e., employ a time-out mechanism; when the connection to the Foglayer is interrupted for a long time, the sensing is stopped to saveenergy on the social sensing devices.
We propose basic APIs for the Cloud,Fog and Sensor Components (cf. Figure 4). Designers of socialsensing services can use those APIs in order to design their sys-tem. These APIs are based on a reliable and delay-tolerant publish-subscribe middleware [18], which allows information disseminationbetween nodes in a dynamic network, which is exactly the casewith social sensing. ocialSens’17, April 21 2017, Pittsburgh, PA, USA Ruben Mayer, Harshit Gupta, Enrique Saurez, and Umakishore Ramachandran
Compo-nent Primitive ParametersCloud publish topic, message subscribe topic, message handlerFog on sensor connection sensor node on fog connection fog node on cloud connection cloud node query specific sensor sensor node, query query all sensors no. of answers, query publish topic, message subscribe topic, message handlerSensor on specific query fog node, queryon general query fog node, query publish topic, message subscribe topic, message handler
Figure 4: Programming API for Social Sensing Services.
API of the Cloud Component. publish : Cloud component can publish to a specific topic, whichserves as the medium of sending message to fog nodes. subscribe : Cloud Component can subscribe to messages pub-lished to the specified topic by a connected Fog Component, andspecify a handler function to be called when such a message arrives.
API of the Fog Component. on sensor connection:
Called when a sensor connects to theFog node. The corresponding Sensor Component is registered inthe Fog Component, so that future queries can be directed to thatSensor Component. In the registration process, context informationof the sensor is exchanged, e.g., the location, and whether otherneighboring Sensor Components are reachable by the connectingSensor Component. query specific sensor:
Primitive for querying a specific SensorComponent. The query can be a continuous query formulated in aStream Processing or a Complex Event Processing query language,but also a one-time query that requires manual action by the socialsensor, e.g., taking a photo of a specific scene or reporting howmany persons are in the social sensor’s vicinity. query all sensors:
Primitive for broadcasting a query to sensorcomponents, expecting to get a specific number of query responses,without needing to specify which specific Sensor Componentsshould receive that query. This is useful to achieve a high-fidelityview of the situation by aggregating multiple responses. publish:
The Fog Component can publish a message to a specifictopic to convey information to peer fog nodes or the cloud service. subscribe:
The Fog Component can subscribe to messages pub-lished to the specified topic, and specify a handler function to becalled when such a message arrives.
API of the Sensor Component. on specific query:
Handler called when Sensor Component re-ceives a query. If it is a continuous query, it installs the query,processes the sensed data accordingly and publishes results to thegiven topic. If it is a one-time query that requires manual action bythe social sensor, it starts the appropriate routine, e.g., a messageon the display of a smart phone.
1. MARK_SELF_OK2. OK : phone
Figure 5: Schematic of Family Safety application (membersof a family are distinguished by using blue color). on general query:
The Sensor Component receives a query thatrequires a given number of answers. The Sensor Component usesbroadcast or multicast protocols, e.g., gossiping, to disseminate thequery to an appropriate number of other Sensor Components. publish:
Sensor components can publish to a specific topic, whichserves as the medium of returning query results to fog nodes. subscribe:
Sensor Component can subscribe to messages pub-lished to the specified topic by a connected Fog Component, andspecify a handler function to be called when such a message arrives.To create a Fog-enabled social sensing service, the Cloud Com-ponent, Fog Component and Sensor Component can implementthe proposed API. In the next section, we give concrete examplesof how the proposed API can be used in practice.
In this section, we discuss a couple of use cases to illustrate howsocial sensing services can be adapted to the proposed Fog infras-tructure. We show that existing services could benefit from thedeployment in the Fog by providing local services to their users inthe face of Internet connectivity problems.
Social sensing services deployed on the Fog can help to gather anddisseminate local knowledge among the affected people. Owingto the relatively local nature of the information pertaining to adisaster-prone area, Fog Computing is destined for providing therequired connectivity to affected people and emergency responseteams so that they can help mitigate the adverse effects.
Recall theuse case that a person wants to check whether his family membersin a disaster-stricken area are OK. We have discussed that theInternet connectivity can be interrupted, so that his family memberscannot access cloud services like Facebook Safety Check . In sucha situation, a Fog-enabled Safety Check Service can enable disaster-struck people to ascertain the safety of their family members, asshown in Figure 5.A user interested in knowing whether his family members areokay starts the Sensor Component of the safety check service onhis smartphone. The Sensor Component (SC) collects the list ofphone numbers belonging to the user’s family members.Whenever a Fog Component (FC) is able to connect to a SC, itqueries that SC with a specific query asking to mark itself OK. Upon nabling Social Sensing Services With Limited Internet Connectivity SocialSens’17, April 21 2017, Pittsburgh, PA, USA receiving this query, the SC displays an alert on the smartphone’sscreen asking the user to mark himself OK. Then, the SC publishesthe user’s phone number to its local FC, so that the FC can knowabout this user’s safe situation.All FCs subscribe to the topic named OK , to which both SCs andpeer FCs publish. The pub/sub system is the medium of disseminat-ing information of safe users over the area. When an FC receives anew safe phone number, it publishes it on the topic “OK” so thatit may be received by SCs and peer FCs. SCs also subscribe to thetopic OK so that they receive information about the people whoare safe. If an SC receives a safe phone number and it belongs toone of the user’s family members, she is alerted of their safety. Algorithm 1
Fog component: Family Safety application procedure
Initsubscribe(OK, on ok callback )safeList ← {} (cid:46)
People this node knows are OK end procedureprocedure on ok callback( p ) if p (cid:60) sa f eList then publish( OK , p ) (cid:46) publish phone sa f eList ← sa f eList ∪ { p } end ifend procedureprocedure on sensor connection ( sensor ) query speci f ic sensor ( sensor , MARK SELF OK ) end procedureAlgorithm 2 Sensor component: Family Safety application procedure
Initsubscribe(OK, on ok callback )family ← GetFamily() end procedureprocedure on ok callback( phone if phone ∈ f amily then (cid:46) if recv. phone end ifend procedureprocedure on speci f ic query ( type ) if type == MARK SELF OK then
DISPLAY(Mark yourself OK) if user marked OK then (cid:46) if user marks himself OKpublish( OK , phone end ifend ifend procedure Suppose that an emergency response team wants to get informationabout the distribution of individuals in an area struck by a hurricane.To this end, it needs aggregated information about the sectorsin which the persons are located. Based on this, the emergencyresponse deduces where to go first to help or evacuate people.The emergency response team installs a continuous query on theFog Component of the area they plan to go to, querying for detailed information of how many Sensor Components are connected inwhich area. The continuous query is installed on the Fog Compo-nent using the primitive query all sensors( ∞ , pos query) . Asa result, all connected Sensor Components report their position.This data is used for building a density map of persons in specificsectors, which is returned to the emergency response team. Using Fog Computing,social sensing services can learn about the transportation infras-tructure: density of users in a bus, the variability of the service,predicted time tables, and other metrics. When facing intermittentInternet connectivity, Fog nodes can provide local connectivityto the users. To this end, each bus carries a small Fog comput-ing device. Passengers in the bus can connect with their smartphones as social sensors, so that the Fog Component on the busreceives sensor data from the smart phones. For instance, the FogComponent can query the destination of the passengers (using the query all sensors( ∞ , destination query) primitive), so thatan optimal bus route is calculated.Buses can share information with each other when they are closeenough to build a vehicular ad-hoc network (VANET) [12]. To thisend, they use the publish primitive. Reliable and delay-tolerantpublish/subscribe ensures that buses can also share informationwith the cloud when an Internet connection is available. The sharedinformation can concern, e.g., road and traffic conditions, so that thebus driver can benefit from the knowledge available in other busesas well. Passengers in the bus can connect to the Fog Component toreceive information on the expected arrival time at their destination,by subscribing to the appropriate topic.If passengers do not have smart phones that can carry SensorComponents of the system, installed Sensor Components on-sitecan provide them a basic service. For instance, a “call a bus” buttoncan be installed at a bus stop. If a passenger needs a bus ride, shecan press the button; the social sensing service will contact busesthat are close-by via the Fog infrastructure and adapt the routesuch that the next bus will visit the queried bus stop. Such simplesensors are cheap enough to be deployed in rural and economicallyunder-served areas in a large number. Additionally, the informationobtained can be used by local governments to improve the serviceand to ask other authorities for services that adapt better to thecommunities that are being served. In remote regions, itis difficult to monitor installed infrastructure, such as street lightingand solar panels, for failures. Employing them with sensors thatsense the infrastructure status promises to facilitate the monitoring.Such sensors are available for a very low price. However, in ruralareas, there might not be Internet connectivity to read the senseddata remotely. Even if Internet connectivity is available, providingthe sensors with an Internet connection increases their price, foracquisition as well as operation.To this end, the idea of “data mules” has been proposed. Peo-ple or moving objects such as buses can serve as a data mule tocollect sensor data and upload it to the Cloud as soon as Internetconnectivity is available. This has been proposed in order to deliver ocialSens’17, April 21 2017, Pittsburgh, PA, USA Ruben Mayer, Harshit Gupta, Enrique Saurez, and Umakishore Ramachandran emails to remote regions [16]. However, it is not directly applica-ble to sensor data, which might have much larger scales. Whenthere is a lot of data to be sensed, the storage of micro-computerscould be over-utilized. Furthermore, the Internet connection, whenavailable, could still have a very low bandwidth, so that the uploadof Gigabytes of data is infeasible. Extending the simple data muleconcept to a mobile Sensor Component can help to handle thisissue. The Sensor Components execute aggregation and filteringoperations, so that the amount of data transmitted is much lower.
The Fog infrastructure poses a large range of technical challenges onthe implementation. For example, if the Fog nodes are installed ondrones, different communication protocols are used and couplingbetween them is required. Additionally, the network protocolsneed to be latency-tolerant; each node needs to be able to queuemessages until a connection is reestablished.Handling geo-distributed resources is challenging. Part of thecomplexity is defining the type of algorithm to deploy on the nodesbased on the available capabilities. This has to be added to theprocess of deploying applications to nodes with limited Internetconnectivity and untrusted infrastructure.Common distributed systems issues also arise in the context ofFog social sensing. Fog resources might have lower availability anddependability than servers in cloud data-centers. One of the mainchallenges is that protocols and middleware need to be distributedand energy-efficient, e.g., discovering other peers and fog nodeswithout a central entity and with limited energy. Load balancing isanother common issue. For example, the region of a disaster mayrequire more resources such as networking and computing. Howcan the Fog infrastructure be organized to meet different resourcedemands? Mobility of Fog nodes could be used to dynamicallybalance the pressure on each Fog node.There also exist social sensing specific challenges. Social sensingcan bring disinformation and inaccuracy [17]. The identity of theusers and correctness of the information cannot be guaranteed [15].These errors are not necessarily intended, but caused by mistakesand misunderstandings. Fog computing itself enhances the sharingof information within the region responsible for a given Fog node.However the question arises, is there more we can do to providereliable information sharing? For example, an intuitive idea is togather the information from different social sensors and eliminateoutliers. A further question is how to route the information to theintended receivers. Simple flooding will lead to each user receivingtoo much information and bringing pressure to the network infras-tructure. When the Fog nodes are mobile, this issue becomes morechallenging due to non-deterministic connectivity.
In this paper, we have extended the vision of Fog Computing to-ward providing social sensing services in situations when Internetconnectivity is limited. We have outlined the basic design principlesof such a Fog-enabled social sensing service, and have proposed ageneric API that social sensing services can employ in order to usethe Fog infrastructure. A Fog-based social sensing platform could help in the transitionof existing cloud-based social sensing services to the Fog. Such amiddleware needs to provide basic building blocks for the devel-opers of a social sensing service, and also include mechanisms fordeployment, communication management, and many other tech-nical details. It is imaginable that cloud-based services could betransformed toward the Fog platform in a semi-automatic manner.This way, many of the existing useful cloud-based services couldbenefit from the emerging Fog infrastructure.
REFERENCES [1] Charu C Aggarwal and Tarek Abdelzaher. 2013. Social sensing. In
Managingand mining sensor data . Springer, 237–297.[2] Maura C Allaire. 2016. Disaster loss and social media: Can online informationincrease flood resilience?
Water Resources Research
52, 9 (2016), 7408–7423.[3] Arvind Arasu, Shivnath Babu, and Jennifer Widom. 2006. The CQL ContinuousQuery Language: Semantic Foundations and Query Execution.
The VLDB Journal
15, 2 (June 2006), 121–142.[4] Paolo Bellavista and Alessandro Zanni. 2017. Feasibility of Fog ComputingDeployment Based on Docker Containerization over RaspberryPi. In
Proceedingsof the 18th International Conference on Distributed Computing and Networking(ICDCN ’17) . ACM, Article 16, 10 pages.[5] Flavio Bonomi, Rodolfo Milito, Preethi Natarajan, and Jiang Zhu. 2014. Fogcomputing: A platform for internet of things and analytics. In
Big Data andInternet of Things: A Roadmap for Smart Environments . Springer, 169–186.[6] Cisco. 2017. Cisco DevNet: IOx. https://developer.cisco.com/site/iox/. (2017).[Online; accessed 19-January-2017].[7] Gianpaolo Cugola and Alessandro Margara. 2010. TESLA: A Formally DefinedEvent Specification Language. In
Proceedings of the Fourth ACM InternationalConference on Distributed Event-Based Systems (DEBS ’10) . ACM, 50–61.[8] Dirk Eilander, Patricia Trambauer, Jurjen Wagemaker, and Arnejan van Loenen.2016. Harvesting social media for generation of near real-time flood maps.
Procedia Engineering
154 (2016), 176–183.[9] Y. Gu, M. Zhou, S. Fu, and Y. Wan. 2015. Airborne WiFi networks through direc-tional antennae: An experimental study. In . 1314–1319.[10] Kirak Hong, David Lillethun, Umakishore Ramachandran, Beate Ottenw¨alder,and Boris Koldehofe. 2013. Mobile Fog: A Programming Model for Large-scaleApplications on the Internet of Things. In
Proceedings of the Second ACM SIG-COMM Workshop on Mobile Cloud Computing (MCC ’13) . ACM, 15–20.[11] Yu Liu, Xi Liu, Song Gao, Li Gong, Chaogui Kang, Ye Zhi, Guanghua Chi, and LiShi. 2015. Social Sensing: A New Approach to Understanding Our SocioeconomicEnvironments.
Annals of the Association of American Geographers
Intelligent Vehicles Symposium, 2003. Proceedings. IEEE .IEEE, 156–161.[13] B.S. Manoj and Alexandra Hubenko Baker. 2007. Communication Challenges inEmergency Response.
Commun. ACM
50, 3 (March 2007), 51–53.[14] Ruben Mayer, Boris Koldehofe, and Kurt Rothermel. 2015. Predictable Low-Latency Event Detection With Parallel Complex Event Processing.
IEEE Internetof Things Journal
2, 4 (Aug 2015), 274–286.[15] Raina M Merchant, Stacy Elmer, and Nicole Lurie. 2011. Integrating social mediainto emergency-preparedness efforts.
New England Journal of Medicine
Computer
37, 1 (Jan 2004), 78–83.[17] Tomer Simon, Avishay Goldberg, and Bruria Adini. 2015. Socializing in emergen-cies - A review of the use of social media in emergency situations.
InternationalJournal of Information Management
35, 5 (2015), 609 – 619.[18] Magnus Skjegstad, Frank T Johnsen, Trude H Bloebaum, and Torleiv Maseng.2012. Mist: A reliable and delay-tolerant publish/subscribe solution for dy-namic networks. In
New Technologies, Mobility and Security (NTMS), 2012 5thInternational Conference on . IEEE, 1–8.[19] R. Stiegler, S. Tilley, and T. Parveen. 2011. Finding family and friends in theaftermath of a disaster using federated queries on social networks and websites.In . 21–26.[20] L. Yusuf and U. Ramachandran. 2012. Community Membership Management forTransient Social Networks. In . 1–7.[21] lker Bekmezci, Ozgur Koray Sahingoz, and amil Temel. 2013. Flying Ad-HocNetworks (FANETs): A survey.