Battery Patterns and Forecasting in a Large-scale Smartphone-based Travel Survey Rudi Ball1 , Ajinkya Ghorpade1 , Kalan Nawarathne1 , Rui Baltazar1 , Francisco Camara Pereira1 , Chris Zegras2 , Moshe Ben-Akiva2 1 Singapore-MIT Alliance for Research and Technology(SMART), 2 Massachusetts Institute of Technology(MIT) 1 rudi.ball,ajinkya,kalan,rui,
[email protected], 2 czegras,
[email protected] October 2, 2014 Abstract The Future Mobility Survey (FMS) (Cottrill et al.) is a multi-data smartphone-based survey which has been successfully prototyped in the city of Singapore. More than 1500 participants were surveyed from October 2012 to September 2013. Participants smartphones automatically collected data about their location and activities using the FMS smartphone application, with variants of the application being deployed on both Android and iOS platforms to improve the breadth of the user sample set. High resolution battery sampling polled energy levels every 15 minutes (96 times per day). Preliminary work on the FMS data sets show users whom are both consistent and inconsistent in their battery usage behavior. Patterns illustrate the differing cyclical behavior of some users on weekdays and weekends. We leverage these historic battery usage patterns using varying time-series analyses to forecast charge times, charge durations and estimate battery levels. Thus far, a calibration application has been executed to interpret forecasts and simulate adaptive sampling strategies. For example prioritizing particular sensors over others in specific contexts to improve the accuracy of location information sampled.
1
This paper focuses on smartphone travel survey sampling challenges, the energy patterns exhibited by participants smartphones in the FMS survey, forecasting and adaptation strategies.
1
Introduction
Smartphones are portable pervasive personal communication devices found in both developing and developed countries. About 6.8 billion mobile subscriptions exist worldwide of which smartphone users represent a growing subset1 . Within the domain of data crowdsourcing and surveying, mobile devices (especially smartphones) are becoming an increasingly common method for collecting location-based and user specific data [4, 6, 9, 10, 12]. Smartphones (mobile computers) carry a growing plethora of sensors which can be used to collect data about the devices state, processes, battery usage, position, motion, the local environment, communications as well as users social networks and interactions. Using a combination of these raw sensory inputs we can further infer more complex user behaviours. Smartphones are potentially a highly valuable and accurate source of data from which mobility and activity information can be collected. Crowdsourcing often requires incentivisation for the usage of users device. Users allow a data collector to install an application or logger which collects data (often personal and private information). This application piggybacks on the users device using the resources of the device to sense, store and collect data. A core resource is battery power with a lack of battery making the device unusable by the user. As such, users trade their mobile device’s capabilities in return for useful and insightful information. The crowdsourcing application should seek to avoid burdening the user or using significant resources, such as battery energy. This paper considers the constraints of battery capacity and issues affecting design choices made by crowd-sourcers and data gatherers in their survey requirements and the development of applications. We discuss these challenges using experience gained during the pilot deployment of the Future Mobility Survey (FMS). 1541 FMS participants used smartphones (787 Android devices, 754 iOS devices) to collect and validate more than 22,170 days of data between October 2012 and September 2013. 1
International Telecommunications Union http://www.itu.int/en/ITU-D/Statistics
2
The paper begins by discussing the primary constraints and capabilities of mobile devices and progresses to illustrate the effects of battery provision and platform choice on the FMS survey results. We compare the exposure of smartphone APIs and data collection methods. The FMS is used to highlight the evolving challenges encountered in the development and deployment of a smartphone logging application. Some of the results of the FMS are used as examples in the description of method and solutions used.
2
Aim and Requirements
An ideal smartphone application would be capable of collecting all sensory data at low frequency. Yet, in reality smartphones were not designed for surveying, rather services or user initiated applications were expected to be used when needed. Currently the three major challenges to surveyors are (a) battery capacity, (b) sensor access and (c) data communication. Smartphones carry limited battery provision due to their size and use. Every executed action on a smartphone has some associated energy cost. Surveying applications are required to share battery resources with the phone’s owner in his normal usage of the device - collecting, storing and communicating survey data to surveyors. A surveying application running on a device should seek to (a) minimise resource usage, (b) collect as highly resolute data as possible and (c) avoid impeding the users ’normal’ usage of the device or influence the behaviour of the user. The accessibility of sensor data is platform dependent. Differing platforms have varying restrictions to sensor access but, from the point of view of the survey, the collected sensor data needs to be consistent throughout the population. Finally, data collected should be communicated to the surveyor at a future time using a communications technique available and enabled on the smartphone.
3
Related Work
Several previous works have promoted the usage of mobile phones for the collection of various data [11, 14, 5]. Mobility data was previously considered by Raento et al. [11] for the observation of behavioural patterns. Research projects have also considered smartphone based data collection as a cost effective means of collecting mobility and activity data. Vautin and Walker [14]
3
identified smartphones as being capable of providing a number of solutions within transportation analytics: (i) data collection, via travel activity tracking, mode detection; (ii) information provision, via real-time transit arrival information, transit planning, multi-modal and single-mode trip planning, basic push notifications with updates about service disruptions, and mobile carsharing/carpooling; and (iii) data collection/information provision, via crowdsourced mapping, geolocation based social networking, advanced push notifications, and greenhouse gas emissions tracking. Low cost benefits were obtainable if third-party developers created transportation applications [14]. More recently a number of commercial life-logging applications such as Moves [7] and Saga [1] have entered the tracking domain. Moves and Saga collect information about user activity. Activity data is used to assist the user in health and fitness monitoring, with calculations about steps, distance and energy presented to the user. Moves and Saga uses algorithms that are largely dependent on a variety of sources for the identification of activity locations. The Future Mobility Survey (FMS) is a bridge between these lifelogging and transportation domains, collecting similar data with the aim of constructing higher resolution analyses relating to transportation surveying.
4
Battery Capacities
Since 2008 a variety of smartphones have been released, each with differing specifications and a multitude of platforms (for example iOS, Android, Windows Mobile etc). Figure 1 shows battery capacities for 5024 device types released between January 2005 and May 2014. Increased sizes in form factors have allowed for larger batteries and hence larger battery capacities. Battery technology is positively trending towards larger capacities due to technological advances in battery technology. Since January 2010, Android smartphones have followed a mean capacity of 1702 mAh, while iPhones hold a mean capacity of 1508 mAh. Larger phones typically contain larger batteries. The heterogeneity of smartphones places further challenges to the development of data collection applications. The FMS apps have sought to operate within these bounds focusing on performing well within the 1500 to 1800 mAh range on Android and iOS platforms.
4
Figure 1: The heatmap shows the number of unique device types released and their associated battery capacity (mAh) for the years between January 2005 and May 2014. A total of 5024 devices are compared, filtering for devices with cross diagonal display sizes of between 1.2 and 5.5 inches.
5
Sensor Access
Both Android and iOS platforms were seen to be significantly different from one another in design philosophy. Table 5 shows accessibility to sensor data based on a subset of sensors which can be queried and the mobile operating system used. While it is expected that further sensors will be integrated into the average smartphone, current access to the data from sensors is dependent on the APIs (Application Programming Interfaces) provided to developers by the operating system. This table assumes that the device need not be ‘jailbroken or unlocked to provide access to higher level user permissions. As observed in Table 5, Android presented advantages in sensor access. It was possible to access low level raw data from sensors and from the Operating System. Metadata was often provided with these sensory queries. For instance, it is possible to access satellite information (azimuth, signal strength, altitude and other data) using the Android Location stack. GPS and network positioning could be explicitly specified or determined and var-
5
Sensor Accelerometer* Ambient Temperature Gravity* Gyroscope Light Linear Acceleration* Magnetic Field Orientation* Pressure Proximity Position* Relative Humidity Rotation Vector* Temperature Significant Motion State* Step Detector Battery* Telephony Stack
Android iOS 3 3 1 3 3 6 3 1 1 3 3 3 4 3 3 1 1 1 9 6 1 3 1 1 0 1 1 1 0 6 1 18 -
Table 1: Comparison of Android and iOS APIs for which sensory values can be accessed via standard means and are by default available. Android provides further access to the device state via runtime interfaces such as Execution class (Android). In comparison, iOS does not provide terminal access without jailbreaking the device. Marked (*) sensors are currently used by FMS. ious accuracies shown. In contrast, iOS API access was limited to specific accuracies. Location and position data did not contain provider information such as whether the GPS or GSM network was being used to collect location information. While sensory limitations can be discerned between the operating systems, FMS stop-detection [15] was not affected by the extra sensory limitations. Stop-detection focused on the usage of accelerometer, location (GPS or network provided) and timestamped data. These data were sufficient to provide a significantly accurate dataset.
6
6
The Future Mobility Survey
The Future Mobility Survey (FMS) is a multi-data smartphone-based travel survey which has been successfully prototyped in the city of Singapore. Project pilots and tests were conducted with 1541 participants between October 2012 to September 2013. The combination of Android and iOS apps sought the broadest statistical matching of the Singapore population. FMS participants used their smartphones in combination with an FMS app and a backend to automatically record and collect data about their location and activities.
Figure 2: The FMS Client-Server architecture and processing methodology. Data is collected on smartphones and uploaded to the FMS Backend. After enough data has been collected a stop-detection process analyses and determines draft activities and mobility traces, which are validated by the participant at a later time. Various analytics results are finally generated to interpret the data collected. A client-server architecture was used (Figure 2). Data was processed and stored using a selection of server-side data processing algorithms. These algorithms interpreted and refined collected data samples, reducing sample noise and mapping inferred activities to particular locations (stop-detection) using both heuristic and statistical methods (Figure 3). A ‘validation’ process, conducted after collection and stop detection, provided participants that logged 7
Figure 3: Activity Map for a sample FMS user in Singapore who collected and validated 15 days of data. onto an online web-interface a means of checking and improving the accuracy of data collected. Thus far, the FMS has captured 22,170 user days of sensory data - including rich data sets containing various sensor data. Total data exceeds 221 gigabytes. The FMS used HITS 2012, a paper based survey conducted in Singapore every four years, as a benchmark for performance comparison. HITS collects socio-demographic, activity and mobility data for a typical weekday from participants within households across Singapore. The survey sample size comprises 10,500 households (approximately 1% of total households). A subset of participants took part in both FMS and HITS surveys. A comparison of their data suggested that the FMS is more resolute in data collection, providing higher accuracy to travel times, work durations, travel modes and timing and activity information [2].
7
FMS Pilot Test Results
Several core issues affecting battery usage were observed during the development and operation of the FMS prototype. These issues included (a) process scheduling, (b) sensor usage and (c) the wireless data protocols used to upload data to the FMS server for pre-processing, validation and analy8
sis. Between the platforms, parameter consistency was maintained except for battery sampling and WiFi discovery (Table 7). A low frequency accelerometer polling was required for identifying mobility events and effective stop detection. GPS was duty cycled to reduce battery usage [8]. It should be noted that these settings were not battery sensitive nor adaptive. A reserve feature was built into both iOS and Android apps such that the FMS would pause sampling in cases where battery levels fell below 30% or a user specified threshold. Sensor Android iOS Accelerometer 2 times per second (2Hz) 2Hz GPS Phased Phased 1Hz every 2 to 3 minutes 1Hz every 2 to 3 minutes WiFi SSIDs Every 3 minutes Event-based All proximal routers Connected router GSM 3 minutes 3 minutes Battery Periodic Polling Event-based 5 minutes Table 2: Sampling parameters. Given the requirement of collecting highly resolute data, a core aspect of the FMS app has been its ability to sample in background continuously. Background process scheduling within Android is explicit. Processes are registered with the operating system to wake on a particular time-out or wake on an event. However within iOS, background process handling is dependent on the operating system version and the policy applied systemwide. In our experience, processes operating for longer than 90 seconds are killed, by policy, unless they query location data (iOS 7). This is not controllable. Hence it was required to manually force the iOS operating system to periodically wake such that the FMS application was not shutdown (manual keep-alive). iOS does not support continuous background processes and thus could not manage them efficiently A disadvantage of Android was supporting a heterogeneous set of devices. However, this issue has become less significant since backward compatibility issues have been fixed. Sensor energy usage differed for various chipsets and was often heterogeneous between smartphone manufacturers. For instance, experiments between different manufacturers GPS chips showed differing power profiles. If 9
used consistently, 3G data was of greatest cost, followed by GPS and WiFi respectively. High accuracy positioning using the GPS onboard a device requires significant energy. While manufacturers have attempted to optimise energy use for GPS chipsets an accurate GPS position which relies solely on satellite data was seen to be the most costly method of finding location information. A combination of Assisted GPS reduced energy usage in location finding. In those cases where a location service was used position was found using location beacons - WiFi routers are typically used as beacons as they can provide both unique SSIDs and MAC address codings. With a 2Hz sample rate, accelerometer energy and storage usage was high.
Figure 4: A comparison of FMS participant recharge survivability between Android (red) and iOS (blue). Formatted JSON data entries were batched, encrypted and compressed before upload. We observed that 912 FMS participants (59%) did not use WiFi data connectivity where available. Instead, these users relied on GSM or 3G data networks for data provision and upload. Data collected (especially accelerometer data) was sufficiently large comprising at most 172,800 entries per day. In combination with location, such data was necessary for mode-detection to accurately determine mode changes (for example walking, running, bicycling, car or train usage). GSM network data bundles were 10
Figure 5: FMS users battery charging behaviour comprising 11,042 charging events. A comparison between Android and iOS users. necessary to mitigate the costs of participation and allow for data upload. Due to the foreseen energy overheads of upload. WiFi was used as a primary upload method when available. The FMS applications were compared in their longevity using survival probabilities. The probabilities compared the ‘time to recharge’ or application turn-off (Figure 4). Android operation was typically longer than iOS operation, with re-charging occurring later. A number of behavioural distributions and trends were observed with device charging. Figure 5 shows user charge durations. Smartphones plugin battery levels are represented on the y-axis with their associated x-axis duration. The final charged state or battery level of the device after charging was measured. Charging durations were consistent between Android and iOS users, however iOS is notably seen as discrete as battery levels were event-based in their sampling. A number of outlying end battery levels are observed, where devices were used whilst being charged. Another observed battery charging behaviour was the regular behaviour of some users on weekdays (Figure 6). In these specific cases users are classified as either day or night chargers. The figures show the matched regression functions based on battery levels for hours of the day. These user behaviours were significant as 88% of users charged their devices within 250 meters of
11
Figure 6: Some FMS users exhibited regular charging behaviour for workdays (classified behaviour).
12
home rather than at work or elsewhere. Hence the act of charging might be used to infer location. Furthermore, such data is usable in the prediction of charge times by users. Battery usage was indicated as an issue by some FMS users. The webbased user validation process (requiring at least 5 days of validated data) was sufficiently useful in correcting many of the gaps caused by smartphones pausing sampling, with users correcting the data collected such that it more accurately described their mobility and activity for that specific day.
8
Preliminary Work: Personal Battery Models
As has been observed, battery data exhibited several usage patterns. These patterns can be leveraged to build energy aware applications. An energy aware application will respond to current charge level by adapting its behaviour accordingly. In data collection application like FMS, data collection procedures can be adapted by economically sampling data when the current charge level is low. As noted by [3] and as was observed in figure 5 battery usage trends vary from person to person. In our initial approach we focus on building a personalised model for battery level estimation and definition of data collection profiles to be used for battery usage optimisation. We developed a small Android application to collect battery and system level sensor usage information. The application collected data for one volunteer over a one month period. Battery level, voltage, status of sensors on the smartphone, location of charger and the timestamp were logged by the application every 30 mintues. The FMS application makes use of GPS, Wifi, Accelerometer and 3G sensors on smartphones for estimating user location and to upload sampled data back to servers. The application requires continuous logging of accelerometer data for use in the inference algorithms. Figure 7 depicts the proposed profile manager which monitors the system level parameters and selects appropriate profile based on the estimates and current profile. 6 profiles are defined by the combination of sensors that are on/off - ALL OFF, WiFi ON, 3G ON, GPS ON, GPS ON & WiFi ON, GPS ON & 3G ON. Figure 8 shows the average battery discharge percent per hour for each of the 6 profiles for a given user. The profile manager can be implemented as a priority queue
13
Figure 7: Flow diagram of the profile manager for optimising resource usage to conserve battery. which will prioritise profiles with minimum average battery discharge rate per hour conditioned on the estimates of battery discharge. The estimator module in figure 7 is modelled as a linear function of current battery level(Lt ), current voltage(Vt ), change in battery level since last reading(∆Lt ), ON/OFF status of GPS(Gt ), 3G(Mt ) and WiFi(Wt ) sensors. Lt+∆t = β0 + βL Lt + βV Vt + β∆L ∆Lt + βG Gt + βM Mt + βW Wt +
(1)
where Lt+∆t is estimated battery level after time step ∆t, is the random noise term and β∗ are the corresponding coefficients of the model. We generate estimates of the battery level after 2 time steps or after 60 minutes so ∆t = 60. We applied step wise model selection by Akaike’s Information Criterion (AIC) to our data and the model selection dropped Wt predictor from model which suggests that the WiFi is not a major contributor to the battery consumption for given user. So the equation 1 now becomes Lt+∆t = β0 + βL Lt + βV Vt + β∆L ∆Lt + βG Gt + βM Mt + 14
(2)
Figure 8: Average and median discharge battery percentage per hour. Profile priority choice scheme is based on the minimum average discharge cost (policy).
β0 βL βV βDeltaL βG βM
Estimate Std. Error -28.787634 13.152986 0.919699 0.023712 0.008396 0.003738 -0.349025 0.113053 -2.399888 0.736322 -1.279037 0.383354
t value -2.189 38.787 2.246 -3.087 -3.259 -3.336
Pr(> |t|) 0.028967 *
