Mobile Sensing Revolution keynote by Hari Balakrishnan
Last week I was in Boston to attend International conference on Parallel and Distributed Processing Systems (IPDPS), and I will post some of my notes from this conference here.
Coincidentally, Distributed Computing in Sensor Systems (DCOSS) was also being held at Boston at the same dates with IPDPS, and I could only reserve my room at the DCOSS hotel instead of the IPDPS hotel. Since the DCOSS keynote on mobile sensing by Hari Balakrishnan sounded more interesting to me than the IPDPS first day keynote, I decided to sneak in to the DCOSS room and attend that keynote instead. Hari's talk had two parts. He spent most of his time on the first part, and had to rush through the second part.
Smartphones are truly mobile devices, and as a result they move through different environments and experience different network conditions. Even during a slow walk, signal-to-noise-ratio (SNR) changes drastically with time, and the bit-error-rate (BER) varies 5-6 orders of magnitude within this time interval. So there is a huge volatility of the network connection stemming from mobility. The question is: How do we deal with these rapidly changing networking conditions?
This is not a new problem. The way 802.11 deals with this is by using bit rate adaptation. To this end, 802.11 measures the wireless channel at the device (the packet loss rate, SNR, or BER), and determines the best bit rate and switches to that at the wireless access point (WAP) for communicating to that device. But the problem with this is, for smartphones, which are truly mobile devices, these measurements are quickly outdated.
So, how do we measure and determine the best bit rate for smartphones? Hari's idea is to use sensors on the smartphone to solve/alleviate this problem. Smartphone has several very good sensors including accelerometer, compass, gyroscope, GPS, light sensor, microphone, and even a barometer. We can use the readings from these sensors to tell which way the device is oriented, its position, direction, and speed, and use these hints to adapt to the different mobility modes accordingly. For example, the accelerometer can detect walking and this can help improve rate adaptation at the MAC layer. The compass can detect heading and this can help improve AP association at the network layer. The gps can detect speed and this can help improve vehicular routing at the network level. The smartphone can also use hints (sensor readings) from neighboring smartphones as part of a mobility hint protocol. You can also easily build a crowdsourced network quality/connection monitoring service.
Hari's group focused on detecting movement and built the "rapidsample" service for quick movement detection on the Android. Using rapidsample your device can move into an aggressive mode upon detection of movement in order to address/alleviate the movement-induced network problems. Rapidsample can reliably detect movement within 10-100ms on commodity Android devices by considering accelaration, magnitude, and variance. Rapidsample is able to get pretty low-energy sensor readings from the accelerometer on the Android. When I mentioned to Hari about our findings about costly accelerometers on Android, he said that this cost is due to the inefficient Java implementation of the drivers on the Android. Hari's group has custom implemented their accelerometer sensing in C to achieve energy-efficiency and low latency.
Using the sensor-augmented protocols (by employing rapidsample), they were able to achieve 40-60% higher throughput for a 50% mobile user. And for the access point selection problem for android for VOIP, they were able to achieve 40% fewer handoff disruptions without any change on the WAP part. Finally, they were able to achieve 20 times reduction in probe bandwidth as well thanks to rapidsample. Some limitations of their current work are that 1) while accelerometer and compass are cheap to use GPS is not, and 2) calibration across different device types is needed (while the movement hint required no calibration, the walking hint did).
Hari is working with insurance companies for assessing driver safety, by computing driver risk with real data from smartphone apps. Smartphones are key to mass adoption of this idea, so they built an Android background app for this. Their app is on the Android app store for people to try.
Their app uses only WAP based localization to keep a low-energy profile. As a result they claim that the app running in the background can span upto 50 hours of battery lifetime. The problem is that the WAP signals can be pretty sparse, so they had to develop a trajectory mapping algorithm that employs a hidden markov model to use both previous and future location information from the users. This trajectory mapping algorithm works on the cloud and can be pretty computationally intensive. For example a Houston-Chicago drive had recorded only 40 WAPs along the way and the trajectory mapping algorithm took 1 hour to compute the trajectory taken by the car.
Their app collected 2 million total miles in tests so far. They found that user mileage is very important, and certain combinations of accelerometer and speed is problematic, which they capture as a colored risk There is no ground truth to claim that the app makes the drivers safer drivers, but Hari claims that looking to the accelerometer logs you can see better driving habits (since the drivers are incentivized to get a discount on their insurance premium).
They found that most of the users don't care to plug in their smartphones to the car for recharging as they see this as a burden. So Hari's number 1 wish for the future smartphones is to include lower-power (virtually zero-power) sensors. This can be done by a better design of the hardware and software. As Hari puts it, you want the sensors to run continuously and put the sensor data into a buffer and when the CPU wakes up it can get the data from the buffer.
Coincidentally, Distributed Computing in Sensor Systems (DCOSS) was also being held at Boston at the same dates with IPDPS, and I could only reserve my room at the DCOSS hotel instead of the IPDPS hotel. Since the DCOSS keynote on mobile sensing by Hari Balakrishnan sounded more interesting to me than the IPDPS first day keynote, I decided to sneak in to the DCOSS room and attend that keynote instead. Hari's talk had two parts. He spent most of his time on the first part, and had to rush through the second part.
How can sensors improve networks?
The crossover happened this year: smartphone & tablets accessing the Internet overtook PCs & laptops accessing the Internet. Smartphone adoption rate is 7 times the rate of growth of world population, and there are more people using smartphones than people that have access to electrics, in-house toilet, or toothbrush.Smartphones are truly mobile devices, and as a result they move through different environments and experience different network conditions. Even during a slow walk, signal-to-noise-ratio (SNR) changes drastically with time, and the bit-error-rate (BER) varies 5-6 orders of magnitude within this time interval. So there is a huge volatility of the network connection stemming from mobility. The question is: How do we deal with these rapidly changing networking conditions?
This is not a new problem. The way 802.11 deals with this is by using bit rate adaptation. To this end, 802.11 measures the wireless channel at the device (the packet loss rate, SNR, or BER), and determines the best bit rate and switches to that at the wireless access point (WAP) for communicating to that device. But the problem with this is, for smartphones, which are truly mobile devices, these measurements are quickly outdated.
So, how do we measure and determine the best bit rate for smartphones? Hari's idea is to use sensors on the smartphone to solve/alleviate this problem. Smartphone has several very good sensors including accelerometer, compass, gyroscope, GPS, light sensor, microphone, and even a barometer. We can use the readings from these sensors to tell which way the device is oriented, its position, direction, and speed, and use these hints to adapt to the different mobility modes accordingly. For example, the accelerometer can detect walking and this can help improve rate adaptation at the MAC layer. The compass can detect heading and this can help improve AP association at the network layer. The gps can detect speed and this can help improve vehicular routing at the network level. The smartphone can also use hints (sensor readings) from neighboring smartphones as part of a mobility hint protocol. You can also easily build a crowdsourced network quality/connection monitoring service.
Hari's group focused on detecting movement and built the "rapidsample" service for quick movement detection on the Android. Using rapidsample your device can move into an aggressive mode upon detection of movement in order to address/alleviate the movement-induced network problems. Rapidsample can reliably detect movement within 10-100ms on commodity Android devices by considering accelaration, magnitude, and variance. Rapidsample is able to get pretty low-energy sensor readings from the accelerometer on the Android. When I mentioned to Hari about our findings about costly accelerometers on Android, he said that this cost is due to the inefficient Java implementation of the drivers on the Android. Hari's group has custom implemented their accelerometer sensing in C to achieve energy-efficiency and low latency.
Using the sensor-augmented protocols (by employing rapidsample), they were able to achieve 40-60% higher throughput for a 50% mobile user. And for the access point selection problem for android for VOIP, they were able to achieve 40% fewer handoff disruptions without any change on the WAP part. Finally, they were able to achieve 20 times reduction in probe bandwidth as well thanks to rapidsample. Some limitations of their current work are that 1) while accelerometer and compass are cheap to use GPS is not, and 2) calibration across different device types is needed (while the movement hint required no calibration, the walking hint did).
Mobile sensing with driver safety
Today we still face severe road transportation challenges. There are 10 million accident/year in US which results in 35K deaths annually. Insurance companies offer incentives (upto 15% of the premium) via usage-based insurance (UBI) for safer driving. But UBI is implemented today using embedded devices which makes for a difficult deployment and maintenance.Hari is working with insurance companies for assessing driver safety, by computing driver risk with real data from smartphone apps. Smartphones are key to mass adoption of this idea, so they built an Android background app for this. Their app is on the Android app store for people to try.
Their app uses only WAP based localization to keep a low-energy profile. As a result they claim that the app running in the background can span upto 50 hours of battery lifetime. The problem is that the WAP signals can be pretty sparse, so they had to develop a trajectory mapping algorithm that employs a hidden markov model to use both previous and future location information from the users. This trajectory mapping algorithm works on the cloud and can be pretty computationally intensive. For example a Houston-Chicago drive had recorded only 40 WAPs along the way and the trajectory mapping algorithm took 1 hour to compute the trajectory taken by the car.
Their app collected 2 million total miles in tests so far. They found that user mileage is very important, and certain combinations of accelerometer and speed is problematic, which they capture as a colored risk There is no ground truth to claim that the app makes the drivers safer drivers, but Hari claims that looking to the accelerometer logs you can see better driving habits (since the drivers are incentivized to get a discount on their insurance premium).
They found that most of the users don't care to plug in their smartphones to the car for recharging as they see this as a burden. So Hari's number 1 wish for the future smartphones is to include lower-power (virtually zero-power) sensors. This can be done by a better design of the hardware and software. As Hari puts it, you want the sensors to run continuously and put the sensor data into a buffer and when the CPU wakes up it can get the data from the buffer.
Comments
Hari's group had several interesting project related to vehicular sensing:
http://cartel.csail.mit.edu/doku.php