The Case for MUSIC: A Programmable IoT Framework for Mobile Urban Sensing Applications

09/28/2018 ∙ by Shiva R. Iyer, et al. ∙ 0

This vision paper presents the case for MUSIC, a programmable framework for building distributed mobile IoT applications for urban sensing. The Mobile Urban Sensing, Inference and Control (MUSIC) framework is contextualized for scenarios where a distributed collection of static or mobile sensors collectively achieve an urban sensing task. The MUSIC platform is designed for urban-centric sensing applications such as location sensing on mobile phones for road traffic monitoring, air quality sensing and urban quality monitoring using remote cameras. This programmable system, at a high level, consists of several small sensors placed throughout a city on mobile vehicles and a centralized controller that makes decisions on sensing in order to achieve certain well-defined objectives such as improving spatial coverage of sensing and detection of hotspots. The system is programmable in that our framework allows one to create custom smart systems by writing custom control logic for sensing. Our contributions are two-fold -- a backend software stack to enable centralized control of distributed devices and programmability, and algorithms for intelligent control in the presence of practical power and network constraints. We briefly present three different urban sensing applications built on top of the MUSIC stack.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 6

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The vision of smart cities is being largely powered by a broad array of new wireless telemetry applications for addressing urban challenges. Urban-centric wireless telemetry applications such as air quality sensing [3, 5, 17, 4], road quality monitoring [7]

, road traffic delay estimation

[20] and fleet tracking [1] rely on a large number of mobile IoT sensors that are controlled by a cloud controller to collectively achieve a distributed urban sensing task. Similar telemetry applications in other contexts include: smart agriculture [12, 8, 2, 22], smart water networks [11], wildlife monitoring [13], and many others [23].

For many of these applications, especially those in that are applicable in urban contexts, fine-grained sensing is essential thereby placing a minimum need on the number of sensors. For example, a city wide deployment of a fine-grained air quality monitoring system may require 500-1000 sensors.111Extrapolating based on our experiences deploying a small-scale air quality monitoring system in Delhi over a 30 km area. Most urban sensing applications may also require a high frequency of sensing (such as 1 Hz or higher) especially at certain times such as when the quantity being measured is changing rapidly at real time. Applications such as pothole detection and monitoring using accelerometer tracking[7] or location tracking using cellular network signals [21] may require even higher sampling rates.

To manage a large scale of mobile IoT sensors for these applications in an efficient manner, we need smart sensing and control policies to control the granularity of sensing, the granularity of data collection and the granularity of computations. These mobile IoT applications also have a significant impact on the cellular network footprint and the power consumption by the tiny mobile devices. According to [18], the amount of useful data generated by IoT devices in 2021 will be about 85 ZB, but only 7.2 ZB of that will actually be stored or used. Our experiments with air quality monitoring for this work have also shown that it costs approx 30 MB of data per sensor per day in order to obtain fine-grained air quality data at the rate of 1 Hz. For a city-wide deployment, this amounts to at least 15 GB of data per day (which also incurs non-trivial network data costs with a yearly opex more than the capex of deployment). Power consumption by mobile devices are also a problem, which could be reduced if the sensors were turned off when not needed or if the sensors generated only the amount of data that is actually needed.

This paper describes the design of the Mobile Urban Sensing Inference and Control (MUSIC) stack that aims to address many of these challenges outlined above. The MUSIC platform is designed to enable easy development of cloud controlled distributed mobile sensing applications. In MUSIC, a cloud controller can control a distributed collection of mobile devices and sensors using a type of sensing policy and objective that can be easily specified. In this paper, we describe the MUSIC system, consisting of the stack built on top of conventional networking stacks, and show how it can be used in providing flexibility and programmability in three real world sensing applications – spatial coverage mapping for air quality sensing, hotspot detection for road traffic analysis and dirt detection for urban cleanliness monitoring. The MUSIC platform is flexible to work with a diverse array of sensors that can connect to a mobile device, possibly from multiple vendors, and programmable to support custom sensing strategies given an objective sensing function and constraints. The MUSIC platform can deal with three constraints: (a) power-awareness of edge devices; (b) cost-awareness due to network costs that may vary by country and application needs; (c) network awareness to make the application resilient in the face of intermittent connectivity and lack of reliable sensing data.

In this vision paper, we specifically aim to demonstrate the case for a MUSIC stack and demonstrate the utility of the stack using real world urban sensing applications. We have early experiences tailoring the MUSIC platform for three applications: air quality monitoring in Delhi, traffic hotspot detection in New York City and road cleanliness detection in Delhi. All these applications have been built using a cloud service and an Android mobile application which can interconnect with in-built, fixed or bluetooth sensors.

2 Related Work

There have been a broad array of works on mobile IoT applications, urban sensing applications, wireless telemetry and specialized IoT applications. However, we are unaware of any generic and programmable platform that can support several distributed sensing applications with flexible sensing policies and programmable objective functions and constraints. We outline some of the key related works.

Smart sensing for specialized applications: In the field of agriculture, there have been works on making irrigation more smart in order to reduce wastage of water. In [12] and [8], the authors implement WSNs for remote sprinklers, along with sensing and control for variable rate irrigation. [22] describes a full-fledged system for smart irrigation where the backend server takes real-time moisture data as input to determine sensing decisions. In the context of urban air quality monitoring, given increasing concern over poor air quality in many parts of the world, there has been a recent surge of commercially available low-cost portable sensors by various vendors [9, 14, 19]. The drawback is that each vendor has its own frontend and backend system that is usually compatible only with its own products. This becomes a challenge when conducting large-scale urban air quality monitoring because it restricts freedom in choosing devices based on its specifications. Likewise, there have also been numerous experimental works on mobile urban air quality monitoring [6, 4, 3, 5, 17]. While all of them contain real-time reporting in some form, we have not found evidence for programmability and extensibility for implementing custom policies.

Similar Architectures: Mobile Fog [10] is a system developed for IoT applications such as vehicle tracking using cameras and traffic monitoring MCEP. While they semonstrate the ability to perform analytics at reduced latency and network bandwidth, there is no specific focus on enabling a flexible programmable stack across applications. Ravel [16] is a system designed to aid ease of development of IoT applications but using the traditional MVC architecture, which calls for user input for control.

3 The MUSIC Programmable Stack

Whereas most smart sensing systems today have available hardcoded policies in them, we envision the ability to program custom policies in the MUSIC platform. The policies would serve primarily to control dynamically the amount of data that is being collected by the sensors on the ground via three means – turning specific sensors off when not needed, varying the sensing or reporting frequency and suggest changes in the spatial position of the sensor. This type of control requires a centralized “controller” that monitors the data from all the sensors and provides continuous feedback.

Figure 1: Layers of the MUSIC Stack

The MUSIC platform is a modular layered stack built over regular communication channels to enable the intelligent and ML-based control. Figure 1

illustrates the stack. The highest layer is responsible for data analytics and visualization based on collected sensing data. The vision of the ML control layer is to support different machine learning and standard optimization algorithms to help in determining the best policies to order to minimize our network, cost and power constraints, translates the policies into commands. The command control layer translates these commands to actionable commands to individual devices over existing communication data channels which is maintained by the data stream layer.

MUSIC is an end-to-end system that consists of a mobile phone application and a backend server-cum-controller. The frontend mobile app is the gateway for sensors to report data. Sensors are either built-in ones in the phone (e.g. accelerometer, GPS or compass) or are external ones that communicate over Bluetooth (e.g. air quality monitors). We emphasize that the gateway does not need to be a mobile phone, but could be a standalone sensor with wireless connection capabilities and general purpose computing hardware. The backend serves to provide access to the data as well as implement control by sending “commands” to the mobile phones, such as START and STOP, based on sensing decisions. The mobile app is adapted from an existing open source project [9] and we used it for air quality monitoring as well as collecting GPS traces, camera and accelerometer readings for traffic and road cleanliness applications. Next, we outline the key properties of many of these layers.

Data Layer

Built over the transport layer, either TCP or UDP, this layer sets the format for data that is sent from the IoT devices to the cloud. There is a master Driver thread, that has a server-side TCP socket opened for incoming connection requests from edge nodes. A new thread is spawned for each new edge node that is connected, called the phone thread, in order to receive data from the node as well as to send control commands.

There are broadly two types of messages sent by the edge nodes – a KeepAlive message and a data message. The former is a periodic ping-style message that is aimed at informing the backend about the device’s presence as well as the changing IP address of the mobile edge. It contains fields such as time stamp, latitude, longitude and battery life. The full set of fields in a KeepAlive message is shown in listing 3. The second type of message is a data message, which contains data collected by the sensors. The exact set fields in this message depends on the sensor data that is reported. We show two listings below (3 and 3), for camera image data and other sensor data respectively.

[ht] [fontsize=]json ”battery_life” : 95, ”imei” : ”353323062860043”, ”ip” : ”172.16.19.89”, ”isData” : false, ”isImage” : false, ”keep_alive_status” : true, ”latitude” : 40.7348562, ”longitude” : -73.9949165, ”sensors” : [”Accelerometer”, ”Compass”] Fields in KeepAlive message

[ht] [fontsize=]json ”imei” : ”353323062860043”, ”isData” : false, ”isImage” : true, ”latitude” : 40.7348562, ”longitude” : -73.9949165, ”encodedImageString” : ”…” Fields in the JSON (for image data)

[ht] [fontsize=]json ”imei” : ”353323062860043”, ”isData” : true, ”isImage” : false, ”latitude” : 40.7348562, ”longitude” : -73.9949165, ”sensorData” : ”accelerometer” : [ ”sensorName” : ”accelerometer”, ”sensorSessionData” : [ ”measurement_unit” : ”meters per second squared”, ”name” : ”Accelerometer”, ”x” : -0.15322891, ”y” : 3.7828386, ”z” : 8.820239 ] ] Fields in the JSON (for other sensor data)

Sampling Layer for Control Communication

We refer to this as the “sampling” or “control” layer. As figure 1 shows, the sampling layer is built over a transport layer protocol such as TCP. In our implementation thus far, we have used TCP, even though it can be implemented equally over UDP as well. Mobile devices keep separate TCP connections to the cloud for this purpose for the cloud to send commands to the device, such as START and STOP. These commands perform the simple tasks as the names indicate – a START command received by the edge (mobile phone) results in the app starting a new recording session. The particular sensors to be started, as well as the frequency at which the sensors are to report data, are provided as arguments to the command. The STOP likewise causes the current recording session to end. The data collected between a START and a STOP is saved temporarily in the phone until a SEND command is received, at which point the data is sent to the server. Whether the data is compressed or not is indicated by an argument to the command. The message is a simple text JSON as shown in listing 3.

[ht] [fontsize=]json ”messageType” : ”START”, ”sensor” : ””, ”frequency” : … ”messageType” : ”STOP” ”messageType” : ”SEND” Command messages sent by sampling layer

As the communication happens over a cellular network, the IP address associated with the mobile edge would not remain fixed, and therefore the phone periodically sends ping

packets to the server, which serves two purposes – i) it helps to know if the edge is alive as the lack of such packets most probably indicate an edge that died or that is malfunctioning, ii) the server is constantly updated about the IP address of the edge node to send commands to. This type of control is akin to the control in software-defined networks, where the central controller writes rules in the flow tables in the routers. In our application, mobile phones are the nodes that act as middleboxes and the cloud controller sends commands to them. The commands we support are shown in listing

3.

[ht] [fontsize=]java static enum Command START, STOP, SEND, CAPTURE_IMAGE; Commands supported

Command Layer

This is a software layer that converts requests for data by higher layers into messages for the sampling layer. High level requests for data are specified in the form of policies. Each policy includes a list of locations, the list of sensors and individual sensing frequencies. The Driver thread (§3) converts these into the command messages described earlier, replaces the previous policy with the new policy and keeps the new policy going until the next policy is received from the higher layer.

When a new sensor joins the list, the default policy is to repeat in a cycle – sense for 20 seconds at default frequencies, stop and send all the data. So the command cycle is – START (20 seconds), STOP, SEND. The default frequencies vary depending on the sensor type. For accelerometer, we set the default frequency to be 20 Hz and for air quality sensing, 1 Hz. However, the frequency at which data is reported ultimately depends on the fidelity of the sensor. If the instructed frequency is higher than the maximum frequency at which the sensor can sense, then the sensor will sense at its maximum possible frequency.

ML Layer for Control

This machine learning (ML) layer for control is the layer that computes application specific policies that need to be implemented based on observations and constraints. The data collection objective usually is to collect as much sensor data as necessary to perform the required analytics and make subsequent decisions. The application layer constraint is typically to ensure a base sampling requirement to achieve the urban sensing objective. The lower-layer constraints in the problem are three-fold: network, cost and power. This layer constantly accesses the data that is received from the edge nodes, runs analytics on them, such as field estimation, forecasting, hotspot detection, etc. and outputs policies, after attempting to satisfy the constraints. As an example, if the input from the ground are GPS traces from several mobile phones placed in cars, and the objective is to detect as many traffic hotspots (road links with high congestion) as possible, then this layer would first map the location reports into road traffic segments/links, then estimate average speeds in those segments based on the movements of the mobile phones, and then estimate future average speeds based on current and historical trends. The road segments with very low forecasted average speeds are potential hotspots. Following this forecasting procedure, a new policy would be generated, such as to increase frequency of sensing in those segments of interest and stop sensing from those segments that exhibit close to free-flow traffic.

4 Applications and Experiences

In this section, we outline three specific applications that support different types of commands and policies generated based on sensing objectives and the constraints. We describe three example objectives here in order to present our case for the MUSIC platform: (a) spatial coverage, for air quality sensing; (b) hotspot detection, for traffic congestion inference; (c) object recognition algorithms, for cleanliness monitoring.

4.1 Spatial Coverage Mapping of Air Quality in Delhi

We have deployed a air quality monitoring platform in Delhi comprising a few sensors (highly polluted city) built on top of the MUSIC platform. When collecting data such as air quality or GPS locations from buses on the roads, our spatial coverage objective is to ensure that the sensors report data is a “coordinated” and intelligent manner so as to avoid excessive data reporting and power consumption. In our formulation, the spatial coverage mapping function takes as input sensor readings from multiple locations over a period of time and computes a mean field for pollution in a locality using sensor interpolation techniques. The problem, then, at every regular interval, is to make a decision for each sensor on whether or not it should sense and at what frequency, so that the constructed field has as low as error as possible while satisfying both the network and power constraints. Using the MUSIC system, this would be achieved by implementing such a function at the ML Layer. The error computed at the ML Layer would then be translated into actual commands to be sent (such as increase sampling frequency) at the Control Layer. Then the commands would be prepared by the Sampling layer, conforming to the lower-level message format expected by the Communication Layer.

A simpler implementation of the spatial coverage mapping function and control for air quality would work as follows. A threshold distance for good separation between two sensors is about 0.5 km, in the case of air quality sensors. This is based on real world sensor placements using our low-cost air quality monitors in Delhi. An example control logic would work simply as follows – monitor pairwise distances of sensors on the ground, and if any pair is closer than 0.5 km, send a STOP command to one of them to stop sensing. Once it crosses the 0.5 km boundary, send a START command again. This can be done easily by maintaining state in the backend. Which sensor we choose to send the command to depends on the current state of that sensor, including their battery levels.

We used this system for real world air quality sensing on roads in the city of Delhi, India. We placed Airbeam air quality sensors [9] in a small region in the city of Delhi. Each sensor is hooked up to a mobile phone that runs our smart sensing app. The default sensing setting is to sense at the maximum frequency possible by the air quality sensor (1 Hz) for about 20 seconds, and then break for another 10 seconds and then restart the cycle. So the command cycle is – START (20 seconds), STOP, SEND. The server waits till all the data is received before sending then next START command. This cycle was able to capture data sufficiently well. Figure 1(a) shows the app in action. We placed 5 such sensors sensors in 5 different locations in a small region in South Delhi in India, as shown in figure 1(b). We aim to extend this to a larger scale deployment.

(a) Sending data on SEND command
(b) Sensor Locations
Figure 2: MUSIC app for air quality

4.2 Road Traffic Hotspot Detection in New York City

Hotspots are interesting because they point to highly localized points of unusual activity, which may be a source for a larger problem. For instance, a highly localized activity such as a road accident or construction work on a particular road segment would exhibit ripple effects that result in traffic congestion in farther parts of the city. In our formulation, the hotspot detection function is a function that takes as input recent historical readings from an array of sensors and outputs a boolean array, indicating whether or not each sensor is located in a hotspot. Assuming that no two sensors in a neighborhood are co-located, we define a hotspot location as one that exhibits an unusually higher or lower average reading than the others.

In the MUSIC system, just as in the case of the spatial coverage function, the hotspot detection function would be implemented in the ML Layer. When any hotspots are detected (i.e. if there are 1s in the boolean array output), then a request for higher frequency data is sent. This is then translated into appropriate commands by the Control Layer. In an application to monitor road traffic congestion, GPS readings are recorded from mobile vehicles. With an array of location traces (as (lat,lon) coordinates) along with timestamps from several mobile vehicles over a period of time, average vehicular traversal speeds can be computed for each road segment or link. A traffic hotspot may be defined arbitrarily, but let us say we call it a road segment a hotspot if there is a sudden drop in vehicle speed in that segment over a sustained period of time. A simple policy to maximize likelihood of detecting hotspots while being network- and power-aware, then, is to keep sensing at a certain frequency to begin with, reduce it as the speed on the segment approaches the free-flow traffic speed, and increase frequency of sensing whenever there is a dip in the speed. If the frequency drops below a certain threshold, then the camera may be activated in order to capture images so that the situation may be assessed more accurately.

We have tested a version of our MUSIC platform for traffic congestion detection with a small number of mobile vehicles. To demonstrate the potential of this application, we have worked on congestion and hotspot detection using open GPS traces in New York City, using city bus mobility trace data from the NYC MTA [15]

. The data was available for three months for all the buses in the city. One can imagine a setting where all these buses are supported and controlled by a MUSIC traffic application. To detect congestion hotspots, we adopted an approach as follows – divide roads into segments defined by the portion between two consecutive bus stops on any bus route, determine average bus traverse speed in every segment in every 10 minute interval for 3 months and use the first two-thirds of the resulting timeseries data to train a predictive model to forecast average speeds in neighboring segments. We built a graph neural network to achieve the predictive task. Figure 

2(b) shows the speed trend on a single day on a single segment, with the dotted line showing our model prediction. Figure 2(a) illustrates some sample segments from the dataset. We have obtained clearance from a transportation board to perform a larger scale rollout of the MUSIC traffic application in a large city in a developing country.

(a) Road segments in Upper East Side in New York City
(b) Prediction of average link speeds at future times

4.3 Urban Cleanliness Monitoring in Delhi

Urban spaces (both indoor and outdoor) in many large cities are dirty. The dirt detection application aims to demonstrate how the camera of a distributed collection of mobile phones can be used as a sensor for dirt detection in conjunction with image processing algorithms at the back-end to detect “dirty items on the road”.

We developed a application to detect dirt, dust and indications of lack of cleanliness in urban spaces. Using deep neural networks, a prototype was implemented successfully to detect dirt patches in hospital rooms in the city of Delhi, India. We are currently working on extending this work for wider cases such as roadscape photos. Figure 3 shows an image taken with our application, triggered by the CAPTURE_IMAGE command, with the blue circle showing the manual annotation for training the system. With our understanding that such algorithms can be developed feasibly, these algorithms can then be integrated into our backend so that they be used for making decisions on sensing in the backend. In the same example, if more than a threshold amount of dirt is detected, then sensing of other sensors can be started, such as PM concentration or dust concentration or humidity and so on. This application is to primarily demonstrate an alternative setting where the sampling frequency can be controlled based on the output of the cleanliness detection algorithms to determine the areas that require to be sampled more than others. This application has been tested in indoor and outdoor contexts in Delhi and we plan to deploy it at scale in the future.

Figure 3: Sidewalk in Delhi showing litter

5 Conclusion

In this paper, we have presented MUSIC, a programmable end-to-end platform for various urban sensing and telemetry applications.We presented the MUSIC stack in detail that enables us to implement the intelligence in the system via centralized control and determining application specific sensing policies to meet specific urban sensing objectives subject to network, power and cost constraints. We showed early experiences of the system for three applications – spatial coverage mapping for urban air quality, road traffic congestion detection and dirt detection in urban spaces.

Acknowledgements

We acknowledge the contributions of graduate students Zal Bhathena, Hongtao Cheng, Wesley Painter, Wenliang Zhao and Joseph Zuhusky (alphabetical order) to the frontend and backend code, which were implemented as part of their project in the course ”Foundations of Networking”. We acknowledge the collaboration with the research team at Evidence for Policy Design (EPoD) India at IFMR in Delhi for our urban air quality monitoring experiments. The code for this project was adapted from that of the AirCasting project [9] which is open-source until GNU GPL, and the authors thank the developers.

References

  • Sam [2015] Samsara. https://www.samsara.com, 2015.
  • Ahmed and Ladhake [2011] V. Ahmed and S. A. Ladhake. Innovative cost effective approach for cell phone based remote controlled embedded system for irrigation. In 2011 International Conference on Communication Systems and Network Technologies, pages 419–422, June 2011. doi: 10.1109/CSNT.2011.93.
  • Bigazzi and Figliozzi [2015] Alexander Y. Bigazzi and Miguel A. Figliozzi. Roadway determinants of bicyclist exposure to volatile organic compounds and carbon monoxide. Transportation Research Part D: Transport and Environment, 41:13 – 23, 2015. ISSN 1361-9209. doi: https://doi.org/10.1016/j.trd.2015.09.008. URL http://www.sciencedirect.com/science/article/pii/S1361920915001327.
  • Devarakonda et al. [2013] Srinivas Devarakonda, Parveen Sevusu, Hongzhang Liu, Ruilin Liu, Liviu Iftode, and Badri Nath. Real-time air quality monitoring through mobile sensing in metropolitan areas. In Proceedings of the 2Nd ACM SIGKDD International Workshop on Urban Computing, UrbComp ’13, pages 15:1–15:8, New York, NY, USA, 2013. ACM. ISBN 978-1-4503-2331-4. doi: 10.1145/2505821.2505834. URL http://doi.acm.org/10.1145/2505821.2505834.
  • Dong et al. [2015] W. Dong, G. Guan, Y. Chen, K. Guo, and Y. Gao. Mosaic: Towards city scale sensing with mobile sensor networks. In 2015 IEEE 21st International Conference on Parallel and Distributed Systems (ICPADS), pages 29–36, Dec 2015. doi: 10.1109/ICPADS.2015.12.
  • Dutta et al. [2009] Prabal Dutta, Paul M. Aoki, Neil Kumar, Alan Mainwaring, Chris Myers, Wesley Willett, and Allison Woodruff. Common sense: Participatory urban sensing using a network of handheld air quality monitors. In Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems, SenSys ’09, pages 349–350, New York, NY, USA, 2009. ACM. ISBN 978-1-60558-519-2. doi: 10.1145/1644038.1644095. URL http://doi.acm.org/10.1145/1644038.1644095.
  • Eriksson et al. [2008] Jakob Eriksson, Lewis Girod, Bret Hull, Ryan Newton, Samuel Madden, and Hari Balakrishnan. The pothole patrol: Using a mobile sensor network for road surface monitoring. In Proceedings of the 6th International Conference on Mobile Systems, Applications, and Services, MobiSys ’08, pages 29–39, New York, NY, USA, 2008. ACM. ISBN 978-1-60558-139-2. doi: 10.1145/1378600.1378605. URL http://doi.acm.org/10.1145/1378600.1378605.
  • Goumopoulos et al. [2014] Christos Goumopoulos, Brendan O’Flynn, and Achilles Kameas. Automated zone-specific irrigation with wireless sensor/actuator network and adaptable decision support. Computers and Electronics in Agriculture, 105:20 – 33, 2014. ISSN 0168-1699. doi: https://doi.org/10.1016/j.compag.2014.03.012. URL http://www.sciencedirect.com/science/article/pii/S0168169914000829.
  • [9] HabitatMap. Aircasting. aircasting.org.
  • Hong et al. [2013] Kirak Hong, David Lillethun, Umakishore Ramachandran, Beate Ottenwälder, and Boris Koldehofe. Mobile fog: A programming model for large-scale applications on the internet of things. In Proceedings of the second ACM SIGCOMM workshop on Mobile cloud computing, pages 15–20. ACM, 2013. doi: 10.1145/2491266.2491270.
  • Kartakis et al. [2015] Sokratis Kartakis, Edo Abraham, and Julie A. McCann. Waterbox: A testbed for monitoring and controlling smart water networks. In Proceedings of the 1st ACM International Workshop on Cyber-Physical Systems for Smart Water Networks, CySWater’15, pages 8:1–8:6, New York, NY, USA, 2015. ACM. ISBN 978-1-4503-3485-3. doi: 10.1145/2738935.2738939.
  • Kim et al. [2008] Y. Kim, R. G. Evans, and W. M. Iversen. Remote sensing and control of an irrigation system using a distributed wireless sensor network. IEEE Transactions on Instrumentation and Measurement, 57(7):1379–1387, July 2008. ISSN 0018-9456. doi: 10.1109/TIM.2008.917198.
  • Kumar and Hancke [2015] A. Kumar and G. P. Hancke. A zigbee-based animal health monitoring system. IEEE Sensors Journal, 15(1):610–617, Jan 2015. ISSN 1530-437X. doi: 10.1109/JSEN.2014.2349073.
  • [14] Airveda Technologies Pvt Ltd. Airveda. airveda.com.
  • [15] NYC MTA. Mta bus time historical data. http://web.mta.info/developers/MTA-Bus-Time-historical-data.html.
  • Riliskis et al. [2015] Laurynas Riliskis, James Hong, and Philip Levis. Ravel: Programming IoT Applications as Distributed Models, Views, and Controllers. In Proceedings of the he 2015 International Workshop on Internet of Things towards Applications (IoT-App’15), November 2015. doi: 10.1145/2820975.2820977.
  • Shi et al. [2016] Yuan Shi, Kevin Ka-Lun Lau, and Edward Ng. Developing street-level pm2.5 and pm10 land use regression models in high-density hong kong with urban morphological factors. Environmental Science & Technology, 50(15):8178–8187, 2016. doi: 10.1021/acs.est.6b01807. URL https://doi.org/10.1021/acs.est.6b01807. PMID: 27381187.
  • Systems [2018] Cisco Systems. Cisco global cloud index: Forecast and methodology, 2016-2021 white paper. 2018. URL https://www.cisco.com/c/en/us/solutions/collateral/service-provider/global-cloud-index-gci/white-paper-c11-738085.html.
  • [19] Kaiterra Technologies. Laser egg. kaiterra.com.
  • Thiagarajan et al. [2009] Arvind Thiagarajan, Lenin Ravindranath, Katrina LaCurts, Samuel Madden, Hari Balakrishnan, Sivan Toledo, and Jakob Eriksson. Vtrack: Accurate, energy-aware road traffic delay estimation using mobile phones. In Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems, SenSys ’09, pages 85–98, New York, NY, USA, 2009. ACM. ISBN 978-1-60558-519-2. doi: 10.1145/1644038.1644048. URL http://doi.acm.org/10.1145/1644038.1644048.
  • Thiagarajan et al. [2011] Arvind Thiagarajan, Lenin Ravindranath, Hari Balakrishnan, Samuel Madden, and Lewis Girod. Accurate, low-energy trajectory mapping for mobile devices. In Proceedings of the 8th USENIX Conference on Networked Systems Design and Implementation, NSDI’11, pages 267–280, Berkeley, CA, USA, 2011. USENIX Association. URL http://dl.acm.org/citation.cfm?id=1972457.1972485.
  • Xiao et al. [2010] Kehui Xiao, Deqin Xiao, and Xiwen Luo. Smart water-saving irrigation system in precision agriculture based on wireless sensor network. Transactions of the Chinese Society of Agricultural Engineering, 26(11):170–175, 2010. ISSN 1002-6819. doi: http://dx.doi.org/10.3969/j.issn.1002-6819.2010.11.030. URL https://www.ingentaconnect.com/content/tcsae/tcsae/2010/00000026/00000011/art00030.
  • Xiaoli and Daoe [2011] Xu Xiaoli and Qiao Daoe. Remote monitoring and control of photovoltaic system using wireless sensor network. In 2011 International Conference on Electric Information and Control Engineering, pages 633–638, April 2011. doi: 10.1109/ICEICE.2011.5778367.