Placeholder Image

字幕列表 影片播放

  • >>

  • YOUSSEF: Hello everyone and thank you for coming. I'm Moustafa Youssef from Egypt-Japan

  • University of Science and Technology. And today, I'm going to share with you our recent

  • result on the Location--Locationoid project where we target an accurate and energy-efficient

  • localization for GSM phones in general and for the Android platform in particular. So,

  • as we all know, location-based services has been gaining momentum recently, and application

  • rangees from finding the nearest pharmacy to, "My--are there any of my friends near

  • by now? Is there anyone interested in playing Chess now?" and so on. And the applications--the

  • list of applications keep increasing everyday. And there are commercial services that are

  • being offered in a larger scale like Google Latitude and Places, Facebook Places and they

  • keep coming everyday as I said. However, whenever we talk about localization for cell phone,

  • we need to keep in mind the energy consumption of the localization technology we are using,

  • because of course if your localization algorithms leads to depleting the battery very fast no

  • one will be willing to use it because energy is a very scarce resource on mobile phones.

  • Currently, the most commonly used and known technique for cell phone localization is the

  • GPS. However, GPS, as we all know, requires--is an energy hungry device. It require--it consumes

  • a lot of energy as I would go and define later in my talk today, and it doesn't work in every

  • place. So, for example, it doesn't work in the indoor environments, it doesn't work in

  • areas with tall buildings because it require line of sight to the satellites. And at the

  • same time, the recent applications, like navigation for example in Google phones, Android-based

  • phones, and Nokia phones and other popular phone--cell phones requires that you do your

  • localization very frequently. So, for example, in order to track your car you need to get

  • the GPS location very frequently and this can lead to killing the battery very fast

  • on your cell phone. So the problem we are trying to target is how to do localization

  • on cell phones with high accuracy but at the same time you should be able to do it in an

  • energy efficient manner so that you conserve the energy on your cell phone. So the Locationoid

  • project, what we--has different components. One of them, for example, is to perform GSM-based

  • localization using GSM network, not using GPS so that you are not using the energy hungry

  • GPS device. Another component is to do power-profiling for the different location components on the

  • Android OS so that we can quantify how much energy each component takes when it's running.

  • And once we do this profiling, we propose an energy efficient technique for obtaining

  • the cell phone location using the internal sensor. It is not using the GSM network nor

  • using the GPS, but depending on the internal sensors, mainly the accelerometer and the

  • compass. Finally, what we do in this project is that we propose a bar management layer

  • that runs on the--on top of the location provider in the Android system that can combine all

  • these components together to obtain, as I said, accurate and energy efficient localization

  • system. So in the rest of my talk, I have two main components. The first one is CellSense

  • where we try to obtain an accurate location estimate in GSM network using Probabilistic

  • RSSI's fingerprinting techniques. And in the second part, we propose GAC, which is a hybrid

  • GPS/Accelerometer/Compass technique, that uses the internal sensors to obtain the cell

  • phone location with minimum energy. And the final I will conclude my talk. So the first

  • part of my talk is about CellSense: A Probabilistic RSSI-based GSM Localization System. And if

  • we try to compare the GPS localization to GSM localization we can see that GPS is an

  • energy hungry device, doesn't work in all areas. As I said, it doesn't work indoors,

  • for example. And it is not available in all cell phones, it's just--it's only available

  • on high-end cell phones. On the other hand, GSM-based localization systems consumes minimal

  • energy or if any on top of the standard phone operation. Since your phone is already connected

  • to the GSM network and it's performing the standard GSM protocol, if you do localization

  • using the GSM signal you are consuming minimal amount of power in addition to the standard

  • GSM operation. So this is good. And it works everywhere GSM signal is available. So when

  • you are indoor you can obtain a GSM signal. Your localization technique can work in indoor

  • environments. And finally, GSM Standard, according to Wikipedia, is available on 80% to 85% of

  • the cell phones in the world. So again, you have a very large coverage in terms of devices.

  • So it's attractive. So if you focus on GSM-based localization, the current techniques that

  • are being deployed on cell phones or handset-based techniques are mainly Cell-ID based techniques

  • or RSSI-Based. By Cell-ID based, what we mean is that if you have your cell phone and you

  • can hear from a cell tower, the system estimates your location as the location of the cell

  • tower you are associated with. This provides an efficient way of obtaining your location.

  • However, it's a very coarse-grained accuracy because on the average, your accuracy will

  • be half of the coverage range of the cell tower. If you have more than one cell tower,

  • like here we have three cell towers, your estimated location will be the center of mass

  • of all the cell towers you can hear from. So, as we said, this provides an efficient

  • way of obtaining your location but it's a very coarse-grained accuracy. Recently, there

  • have been techniques that uses RSSI that receives the signals strength to estimate the cell

  • phone location. However, since RSSI is a very complex function of distance we can not use

  • a propagation model to estimate our location. Typically, what's being done is you use what

  • we call an RF fingerprint. An RF fingerprint is basically you tabulate the characteristics

  • of the signal strengths at different locations in the area of interest. So, for example,

  • if I want to do a cell phone localization in Mountain View I go to different locations

  • in Mountain View and collect signal strengths to information at different location and I

  • store this information in what we call an RF fingerprint. It's a database of signal

  • strengths characteristics at different locations. During an online phase, the tracking phase,

  • I am standing at an unknown location and I am receiving a signal strength's vector from

  • different cell towers and I'm trying to find the location in the fingerprints that I stored

  • in offline phase that is closest to where I received signal strengths. You can imagine

  • of course that using an RF fingerprint is a time-consuming process because you have

  • to do--go to different locations and stand there to collect the signal strengths. However,

  • this is typically done in a process that's called wardriving where you ride your car

  • and you have a cell phone with GPS that's connected to a computer and you are collecting

  • the location information and signal strengths information at the same time. And many of

  • the current commercial systems like StreetView under My Location from Google currently have

  • cars that roams the streets. So in order, for example, to get the pictures of the screen--as--the

  • streets in the Google Map application, and while you are doing this you can piggyback

  • your radio map construction in the same process. So it is not something that you had to do

  • particularly for localization, you can do it for other applications, too. So our wardriving

  • overhead is very minimal here, too. So currently, there are up to my knowledge, there are two

  • main techniques for using RSSI localization in GSM networks. One is deterministic fingerprinting.

  • And by this, what I mean is that the red dots represent the locations where you have the

  • fingerprint, so at each of these locations you stand and collect the signal strength's

  • characteristics. And here I assume you have only one cell tower, and the characteristics

  • that is stored in the radio map in deterministic techniques it's average signal is--signal

  • strength from this cell tower. So you stand at this location, you collect a number of

  • samples and you store in your radio map's average signal strengths you hear it from

  • this cell tower. The red dot represents an unknown location. You are currently standing

  • at this yellow dot and you want to know which of the red dots I am standing at currently.

  • So in order now to do that, deterministic fingerprinting techniques, what they do is

  • they calculate and locate the distance between the unknown location, the signal strengths

  • at the unknown location and the signal strengths stored in the radio map, and they return the

  • closest location in the radio map in terms of signal strengths as the estimated location.

  • So in this example, the closest location is -32 to -28 and it's returned it as your estimated

  • location. We believe that deterministic fingerprinting techniques provide coarse-grained accuracy

  • and that's why we proposed probabilistic techniques that can help enhance the accuracy of localization

  • as I will talk in the next part of my talk. There have been also proposals using probabilistic

  • techniques before what is called the Gaussian processes, and the idea here, their goal was

  • to reduce the fingerprint construction overheads. So instead of collecting 1,000 samples, for

  • example, you collect only 100 and then you try to interpolate these 100 samples to obtain

  • more samples. So you are reducing the number of points you need to collect and in order

  • to do that you assume a Gaussian process model and a propagation model to obtain the remaining

  • of the samples. You could imagine, in order to do these interpolations, your computation

  • overhead will be very high. And actually I believe that there is no actual reduction

  • in terms of the overhead. Why? Because in order to collect 100 samples you will need

  • to drive--do the wardriving anywhere, anyway. So if you will do the wardriving, it doesn't

  • matter if you collect 100 samples or 1,000 samples because you already drove the streets.

  • So it doesn't save much in terms of fingerprint size. So our approach is to use probabilistic

  • fingerprinting and hopefully we can obtain more accurate localization. And instead of

  • storing in the radio maps, the red dots, the average signal strengths, we need to store

  • the entire signal strengths histogram. So that gives you more information about the

  • signal strengths behavior. And using this extra information you can obtain more accurate

  • localization. However, the challenge here, in order to obtain a signal strengths histogram,

  • you need to stand at each location for a certain amount of time so that you can collect enough

  • samples to construct your histogram. So by this you are complicating the radio map construction

  • process because instead of driving continuously by your car you will have to stop at each

  • location. So this will increase your time significantly. So what we proposed in CellSense

  • is how can we reduce this overhead in terms of constructing the radio map. So I'll talk

  • about the two phases which is the offline phase, constructing the radio map, and then

  • the tracking phase, estimating the location once you have your radio map in place. So

  • in order to solve the overhead of the construction of the radio map, we use gridding approach.

  • So your area of interest is divided into a grid where each cell represents a virtual

  • location. So that--yeah, here the--again, the red dots represents the fingerprints location

  • where you collected these dots with continuous driving by the car--your car. You don't have

  • to stop at each point you continuously drive and based on your sample grid you will obtain

  • these red dots. However, we construct the histogram not for each dot but for each cell.

  • So we use the points within each cell to construct the histogram of this cell and then we use

  • the center of mass of this cell as the radio map location. So we reduce the problem, and

  • instead of using each red dot, you're using the grid cell. Of course, we have a barometer

  • here which is the grid cell length, how large your grid size should be. And by this barometer,

  • we can control the accuracy of the system and to trade it off with the scalability of

  • the system, because the larger your cell size, the less your grid--number of grid cells and,

  • hence, is the better your scalability but your accuracy will decrease. And we'll quantify

  • this later in the evaluation section. So this is the offline phase. What we do is we divide

  • the area into grid cell and construct a histogram for each cell. During the tracking phase,

  • you are standing at unknown location, L, and you will find--you are receiving a signal

  • strength vector of Q dimension, where Q is the number of cell towers you can hear. In

  • the GSM standards you can hear up to seven cell towers so each component represents the

  • signal strength from one sand bell from a cell tower. And what we want to find is the

  • location, L, in the radio maps that maximizes the probability of this, L giving the received

  • signal strength vector S. Using vision-inversion, you can find that the probability of L will

  • give you an S, equals the probability of--not equal--the locations that maximizes the probability

  • of L in given S is the same location that maximizes the probability of S to give an

  • L. And I remind you, the probability of S to give an L is what we store in the radio

  • map. So this information on the right-hand side can be obtained from the constructed

  • radio map. Assuming the cell towers are independent, you can obtain this by multiplying the individual

  • components. And in order to enhance our accuracy--the technique--the accuracy for our techniques

  • better, what we do is that we use more than one sample. So instead of using just one sample

  • before estimation, we use N sample at one time for estimation. You have more information

  • so you should expect to get a better accuracy, and in this case, you multiply the samples

  • and the cell towers. We have also approach to processing the step where we average--instead

  • of determining the most probable location, we return the average of the top K most probable

  • locations, and then we'd see also that this enhances our location estimation process.

  • So how well did we before? In order to test our systems--our system, we experimented with

  • two different test beds, one in the Smart Village in Cairo which is a typical rural

  • area, and another in Alexandria which is a typical urban area. We have two datasets;

  • one for testing and then an independent one for training for the areas--for the two different

  • test beds. And of course in the rural area, you can notice that the density of cell towers

  • is less than the density of cell towers in the urban area. This figure shows the median

  • error as we change the grid cell size. So as expected, as you increase the grid cell

  • size what happens is that your localization accuracy decreases since your size of the

  • grid size increase. However, if you look at 400 meter grid size, you can see the accuracy

  • is comparable to very low size grid sizes. So this is good news that you can have relatively

  • large cell sizes but at the same time you can obtain good accuracy. In terms of the

  • number of samples you use concurrently to estimate your location, you can see as we

  • increase the number of samples we use in the location estimates your accuracy trend is

  • enhancing. But at the same time, you're required to wait more samples in order to get these

  • N samples. So your latency will increase so you'll have a tradeoff between latency and

  • the accuracy of location estimation. This is the last barometer which is how many locations

  • you average as opposed to processing the steps when instead of returning the most probable

  • location. You return the K most probable--the average of the most K probable locations.

  • And again, as you see, as you increase the value of K, your accuracy--median error decreases

  • and your accuracy is enhanced. Comparing our technique to other techniques, we have here--we

  • compare our techniques in CellSense, which is the red curve, with the deterministic fingerprinting

  • techniques, the blue curve, and the Gaussian processes, the green curve, and with Google

  • My Location technique, which is the purple curve. For Google, what we do is that we send

  • the query, the cell tower to using the Google EDI to the servers and we obtain the location

  • estimates. The other two techniques, we implemented--as we implemented our system. We can see from

  • the figures, this is the CDF of distance error which gives you the probability of--that your

  • location will be less than a certain error. So you can see the median error at 0.5 for

  • our technique. It's better than the other techniques with at least 23.8%. This is--this

  • was in the rural areas. For the urban areas, we have even better accuracy. We can achieve

  • up to 86.4% better than any of the other techniques. This table summarizes the results in number--I'm

  • not sure if it's clear. In terms of running the time, we are slightly more than the determined

  • estimating techniques of probalistiic printing techniques that gives about 76 milliseconds

  • per location estimate and our techniques takes about 90 milliseconds per location estimates.

  • Google My Location, of course, since it's Cell-ID based, it doesn't do any--a lot of

  • processing, so it's about 12 milliseconds to obtain your location estimates. So as we

  • said, you have a tradeoff between time and accuracy. So in conclusion, we--CellSense

  • is a probabilistic fingerprint-based GSM localization technique that uses gridding to reduce the

  • fingerprint construction overheads and to scale the system. And its accuracy is better

  • than any of the current techniques for GSM localization by at least 23.8% in rural areas

  • and 68.--86.4% in urban areas. I now switch gears to another localization system which

  • we developed within the context of this project which is GAC: A Hybrid GPS/Accelerometer/Compass

  • Localization Scheme. This technique doesn't use GSM for localization but instead uses

  • the accelerometer and the compass available in smartphones in order to do localization

  • combined with the GPS. So the motivation for this work is that many of today's smartphones

  • contains accelerometer and a compass and it's mainly used for screen auto-rotation. So if

  • you rotate your phone, the--this rotation action is detected by the accelerometer so

  • the accelerometer is continuously running. It's used for gaming control and for other--many

  • other applications like flip to silent; you flip your phone in order to silent--silence

  • it. And whenever people talk about localization techniques, they usually focus on the accuracy

  • of the localization technique and they ignore the dimension of energy consumption. However,

  • if you think about it, at some applications, I don't need very high accuracy of localization.

  • So, for example, it's for me, it's--if I need just to know that I am in Mountain View I'd

  • be happy with a one kilometer accuracy. I don't need meter accuracy. One kilometer would

  • be very fine for me. So can I leverage this coarse-grained accuracy to reduce the energy

  • consumption of my localization technique? And this is what we are trying to target here.

  • We are trying to study this tradeoff and give control to the application developer so that

  • he can choose whether he needs accurate localization or an energy-efficient localization. The GAC

  • Approach, simply the overall idea is that it obtains an initial position estimate using

  • GPS and then it turns off the GPS and switches to the accelerometer and the compass to estimate

  • the location. And from time to time it synchronizes back with the GPS because of the accumulation

  • of error. So instead of using the GPS continuously, you are duty cycling it with low--very low

  • duty cycle to enhance your energy consumption. So in the--this part of the talk, I'll start

  • by talking about the Android power profiling for the different location components in the

  • Android phone, and then I talk about our proposed hybrid technique, and finally, I'll talk about

  • power-aware location--power management layer in the location platform, and then finally,

  • I will conclude. So in order to profile the power consumption of the different location

  • components, we did it on an Android Dream G1 phone and we used a Monsoon power monitoring

  • device. And the way it works is that you replace the battery of your cell phone with the battery

  • that comes with the device, and you connect it to the device and you have an application

  • running on your computer that tells you the current drain from the battery so that you

  • can, when you are running different components, you can know which component is using which

  • amount of current. And since voltage is constant, you can use the current as an indication of

  • the power consumption. The battery that is used to provide 1150 milliampere per hour.

  • This is the capacity the battery. For the GPS, we can see this is the typical curve

  • you get from your power monitoring device when you turn it on. It's almost consumes

  • an average of about 140 milliampere per hour--sorry--100 milliampere. For the accelerometer and the

  • compass, the chip that comes on the HTC Dream phone combine the accelerometer and the compass

  • on the same chip. This means that if you are querying the compass or you are querying the

  • accelerometer both of them are running and you are almost consuming the same amount of

  • power, and you have a 3D accelerometer from this chip. The Android over API provides four

  • different data rates for querying the Android accelerometer. And this is a typical curve

  • you can get from--when the accelerometer is running in the user interface mode. You can

  • see it consumes about 40 or 45 average current during its operation. We'll confide this more

  • in numbers later. So these are the different four modes of operation. You have the normal

  • data mode where you can have four samples per second up to the fastest mode where you

  • can have up to 50 samples per second. And the power consumption is not linear in the

  • number of samples you collect. And our hypothesis for that is that you have two modes of operation,

  • slow and fast, and that's why it is not linear. However, we didn't have access to the data

  • sheet of the accelerometer and the compass chip to confirm our hypothesis for that. Comparing

  • the different techniques, you can see that GPS consumes about 140 milliampere when it's

  • running. Compared to the normal mode of operation of the accelerometer it's more than an order

  • of magnitude, more power consumption, which gives you an idea that if you run the GPS,

  • for example, it consumes 11.73 of the battery in one hour, which means that your battery

  • you can run for eight or nine hours. If you use the accelerometer in the normal mode,

  • your battery would run to 100 hours. So it's significant saving in energy if you can't

  • turn off the GPS and depend on the accelerometer for your location estimates. As another advantage,

  • I'm telling you that the accelerometer is already running all the time in the background

  • so that the operating system can detect the auto-orientation of the phone--that you change

  • the orientation of the phone. So again, if you base your estimate on the accelerometer

  • in the normal mode you are not consuming any more energy than the standard phone operation.

  • So are getting it for zero energy consumption in addition to the standard phone operation.

  • So this is an extra advantage. So we'll talk about how we leverage this in our estimation.

  • As we mentioned, the basic--you have this state machine of the--very simple state machine

  • of the GAC operation. You have a synchronization state and the estimation state. In the synchronization

  • state, you obtain a GPS location estimate and you also calculate the current speed from

  • the GPS and calculate the offset between the accelerometer--speed estimated from the accelerometer

  • and the speed and estimated from the GPS for correction. I'll show it to you in the demo.

  • Once you obtain this information you obtain a fix, or after a certain amount of time you

  • switch to the estimation process where you switch off the GPS and base all your estimates

  • on the accelerometer and compass only. And from the accelerometer and the compass you

  • obtain the displacement and direction and you combine them to obtain your new estimates.

  • And periodically, from time to time, you switch back to synchronization state to compensate

  • for the accumulated error and distributes forever until your localization is done. In

  • order to obtain the position estimate, you use a standard Newton Laws to obtain the position

  • estimates of the accelerometer and the compass. I will not go into the details, the only thing

  • I need to highlight here is that we need to take the curvature of Earth into account.

  • So the--the Earth--the Earth is like a sphere, you cannot use Euclidean distance in order

  • to calculate your location. And instead, we use the Vincenty's formula which is an accurate

  • to millimeter accuracy on the Earth's ellipsoids in order to obtain the location estimates,

  • okay? In order to evaluate our system, we have two different test beds, one in highways

  • and the other in inside cities, and we study the effect of change and synchronization period

  • on accuracy and we compare our system with EnLoc. EnLoc is similar to our system with

  • the exception that it doesn't use accelerometer or compass. So the way it works is that it

  • obtains a GPS fix, it estimates the current speed and the direction, and that's--it assumes

  • that these speed and direction will be fixed until the next synchronization points it doesn't

  • use the accelerometer and compass in between. So we compare our system with this very simple

  • technique using linear prediction. In order to evaluate our system, we had a debugging

  • tool based on Google Maps where we draw the GPS traces and the estimated traces. And I

  • can show you an actual demo from it. So what we are seeing here is the debugging tool.

  • It gives you information like the total trip distance on the top, then the trip duration,

  • your average speed, your error at the final points of the trace, your route mean square

  • error, and your maximum error, and you can control the synchronization frequency in second.

  • Currently, it's set--as you can see here, the current value is 10 seconds so this means

  • that every 10 seconds you turn on your GPS to synchronize with it. And you can change

  • it up to 102 minutes so that--to see the effects. And down here, you can see the trace. This

  • is a highway in Alexandria City. The green ticks represents the GPS trace which is taken

  • the ground truth and these yellow and red ticks represents our estimated location. The

  • yellow dots represent the synchronization periods; the period you turn on the GPS. And

  • then you--after the yellow dots ticks finishes--finish, your GPS is completely turned on and you are

  • only using the accelerometer and the compass for estimating the location. And it's 10 seconds,

  • that's why it's short, we'll change it now to see the effect. You can see, for example,

  • if I'm synchronizing every 10 seconds, my estimate is very accurate to some extent.

  • My route mean square error is six meters. If I increase it, for example, to 60 synchronization

  • every minute instead of every second, I synchronize it to every minute, you can see the error

  • accumulation here.

  • So again, you have the same--you turn the GPS for the same period and the red period

  • is where the GPS is completely turned off. You have a lot of duty cycles so your energy

  • consumption is much less, but at the same time you are not synchronizing with the GPS

  • more frequently so you have more accumulation of error. I remind you here we are not using

  • any heuristics instead of the localization system. So I'm not using the street map to

  • match the estimated location to--I can slap it to the street. I'm not doing this here.

  • We can of course enhance this, but we are doing this here. Of course, you can click

  • on any points and give you more information. If you click on the point it tells you when

  • it was collected from the start of the trace [INDISTINCT] estimated speed, you can see

  • that the GPS is below 16.5 and the hourly estimated speed from the accelerometer was

  • 16.6; very close. It gives you the X and Y acceleration. It gives you the GPS altitude

  • and the accuracy of the GPS. We have other figures, too. This is the same point I clicked

  • on only a different figure. The blue curve gives you as estimated GPS speed and the red

  • curve gives you the estimated speed using the accelerometer and the compass or GAC in

  • general. And you can see there is a drift in the middle and that's the cause of the

  • drift from the actual position. And at this point, there was a synchronization with the

  • GPS that's why the accuracy was snapped again to the accurate--the estimated location. We

  • have our--this is for the accelerometer for the compass. The blue curve is the direction

  • estimated from the GPS. The red curve is the direction estimated from the compass. And

  • you can see there is an offset between the two. In order to correct for this was--what

  • we do is that during synchronization periods, we calculate this offset and then we remove

  • it from the estimated direction. So during this period we estimate this offset and we

  • subtract the offset from this curve which gives you the orange curve on top of the blue

  • curve. We have other figures, that's the accelerometer reading and the difference from--true acceleration

  • and estimated acceleration. You can see it's within plus or negative .2 meter squared per

  • seconds. Let's go back and see numbers. This is the debugging tool were to give us the

  • numbers accuracy and so on. In terms of our consumption, what we see here is comparison

  • between the different techniques for different synchronization periods on the X axis in seconds.

  • And the Y axis gives us the milliampere per hour consumption of different techniques.

  • You can see that the GPS, if you leave it on all the time, it consumes as we said about

  • 140 milliampere per hour. For our technique, comparing our technique to the EnLoc, EnLoc

  • is slightly better than our technique in terms of energy. And the reason for that, as we

  • said, EnLoc doesn't use the accelerometer and the compass and our technique uses the

  • accelerometer. So the difference between the blue curve and the green curve is the power

  • consumption of the accelerometer and the compass. However, as I mentioned, since the accelerometer

  • is running all the time in the background to detect the change in the orientation of

  • the phone we are not using any extra power consumption on top of the standard operation.

  • If you take this into account and remove it, we find that our technique consumes the same

  • amount of energy as the EnLoc technique. So we are consuming the same amount of energy

  • and you can see that the saving in power consumption is exponential compared to the GPS. As you

  • increase your synchronization time you're saving in power consumption decreases exponentially

  • so this is significant saving. In terms of accuracy, this shows the accuracy for highways.

  • Let's focus first on the green and the blue curves. The green curve is our technique root

  • mean square error and the blue curve is the EnLoc linear predictor root mean square error.

  • You can see that for short synchronization period are 250 seconds, there is no difference

  • between the two techniques. However, as you increase your synchronization period beyond

  • that, EnLoc is actually--gives better accuracy than our technique. And the reason for that

  • is that here we are on the highways where you are usually moving in a straight line.

  • So the assumption if EnLoc is accurate, we are using the accelerometer and the compass,

  • but we are not synchronizing frequently enough so we have accumulation of error that decreases

  • our accuracy. So as we see--as I said in small synchronization period, we have the same accuracy,

  • but if you want to move to higher synchronization period EnLoc will be better for you if you

  • are using the highway. The main advantage of our technique appears in intra-city driving.

  • So here, we are driving inside the city and again, the green curve is our technique and

  • the blue curve is EnLoc technique, and you can see that we are significantly better than

  • in terms of accuracy, EnLoc, even for small synchronization period. And the reason here

  • is that the EnLoc assumption of moving in a straight line is no longer valid because

  • within a city you are changing directions, making turns and so on, and also you are changing

  • the acceleration. EnLoc assumes that the acceleration would be fixed until the next synchronization

  • point which is not true when you are moving inside the city. You are accelerating and

  • de-accelerating because of the traffic. The nice thing here is that the red curve gives

  • you the power consumption. So what you can see is that we are saving exponentially in

  • terms of energy but we are losing linear in terms of accuracy. So you can benefit significantly

  • in terms of energy consumption with very little loss in accuracy using our technique. So I'll

  • talk briefly on the power-aware management layer in the location platform. Currently,

  • in order to obtain your location estimate what you have to do is construct a location

  • listener, you register it with the location provider and you specify whether you need

  • to use GPS or network-based provider, and when you are done, you un-register your listener

  • and that's it. However, the developer doesn't have control over the accuracy or energy he

  • is requiring. All he can say is that, "I need my location update," for example, "every 10

  • seconds," or whatever. It doesn't--he cannot say that, "I need my accuracy to within one

  • kilometer or 10 meters," or whatever. He give it in terms power or energy budget. He cannot

  • say that, "I need an accurate location so that my battery can last for 10 hours or for

  • one day," for example. The developer doesn't have control over this. It would be ideal

  • if we can extend the location provider of the Android a rating system so that we can

  • give this ABI to the developer so that he can have all the old ABI and the new ABI that

  • gives him control or her over the energy accuracy tradeoff that we presented in the previous

  • technique. So this is what we are proposing; to have a power management layer where the

  • application requests the location accuracy and the energy or synchronization frequency

  • and the power management layer will determine the best location provider to use and how

  • long it should use and how frequently it should report the accuracy. To give you an idea about

  • the saving, this figure shows the accuracy of the GPS chip when the GPS is turned on

  • for 60 seconds, and this is done periodically. You can see that you start with very coarse-grained

  • accuracy when you have a cold start and your accuracy drops exponentially and then it saturates

  • at the end. So at the end, you are consuming--you have--you're almost having the same accuracy

  • but you are consuming power with no enhancement in accuracy. It would be better if I can stop.

  • I say, "I don't want any more accuracy since this accuracy is good enough for me," and

  • then switch off the GPS chip to enhance your energy efficiency. This is the same curve,

  • it was running it for 10 seconds. And as I said, if I am good with 250 accuracy, so why

  • not turn off the chip to save energy. So, in summary, what we provided in the second

  • part of my talk is power profiling for the GPS, and the accelerometer, and the compass

  • on the HTC Dream Android-powered mobile phones. We showed that GPS consumes an order of magnitude

  • energy more than the accelerometer and the compass and we proposed the hybrid GPS accelerometer

  • or compass-based scheme that uses the accelerometer very infrequently in order to do synchronization

  • and then depends on the accelerometer and the compass to reduce the energy consumption.

  • We showed that our technique can give exponential saving in energy with linear loss in accuracy,

  • which is very promising. And our scheme doesn't lead to improvement--significant improvement

  • in highways when you are having--over EnLoc when you are having long synchronization period.

  • However, it has significant improvement inside cities where you have large number of turns

  • and accelerations and de-accelerations. Currently, we are working on perform a complete power

  • profiling for the Android platform of the different components so that we are taking

  • the operating system overhead into account also in the power management layer. And we

  • are also thinking of integrating the power profiling results into the Android emulator

  • so that when developers are working on the emulator on the Android phones they can have

  • a sense of how long the battery will last when you are using this component or this

  • technique on your phone. We are also experimenting using Kalman filters on the other statistical

  • techniques to further enhance the accuracy and also experimenting with dynamically adapting

  • the synchronization bid. And instead of having a fixed synchronization period, how can we

  • adaptively change it based on the accuracy so that we can further enhance the energy

  • consumption. I would like to acknowledge Google for their support for this research and this

  • concludes my talk. Questions? >> Can you talk more about how can you handle

  • the different orientations? >> YOUSSEF: Can you raise your...

  • >> [INDISTINCT] >> YOUSSEF: Yes. So in order to do this experiment

  • we assumed that the orientation--the phone is fixed, it can maybe on the dashboard of

  • the car or on your bicycle. So the question was, "Can you talk more about how can you

  • handle the different orientations?" The Android phones come with an orientation sensor at

  • the same time so you can experiment with taking this reading in order to detect its orientation

  • of the phone and then reorient it to the standard coordinates and use it. Once it's oriented,

  • you can use the same technique without any modifications. However, our initial results

  • on that shows that you have very large amount of noise. It is not that accurate. But again,

  • if you assume that mostly when you are driving, you will not be carrying the phone in your

  • hand it will be fixed to some orientation on the dashboard. So, for example, you can

  • do an initial calibration when you start your calibration--system and then use it from there.

  • Other questions? >> [INDISTINCT]

  • >> YOUSSEF: Very interesting question. The question is, "We said that EnLoc is better

  • in highways than our technique and then we are better in intra-cities. So did you thought

  • about switching between the two techniques based on the driving better?" Yes. And that's

  • why I didn't include it the current work. One way of course is combining both techniques.

  • So, for example, you can detect it from the movement better from the accelerometer that

  • the user is driving with a constant speed or he is not making a large number of turns

  • and based on this, you can say I am on the highway. So in this case, I can switch completely

  • to EnLoc and disable the accelerometer and the compass, it will give me better accuracy

  • and it will save me more energy. So this is a very good idea. Yeah. Other questions?

  • >> [INDISTINCT] >> YOUSSEF: I have one or two towers?

  • >> Yes. [INDISTINCT] >> YOUSSEF: The question here is that, "In

  • the first technique where we are doing RSSI-based GSM localization, if you have an area with

  • a sparse radio map, so as far as cell tower dynasty, you have say two cell towers and

  • you will have many locations with similar fingerprints, meaning the signal strengths

  • of these locations would be the same. So how would you do--would you select one of them

  • randomly or you select the top most?" The brand threshold which is, K, which is supposed

  • to process the step, what it does is that it returns to you the average of the top most

  • K locations. So on this case, if you have two locations similar to fingerprint, what

  • it will does, it will give you to use a center of mass of these similar locations and it

  • will be weighted by the probability. So in order to taking that--the average, it's a

  • weighted average we're using as the probability. So the location with the highest probability

  • will have more weight than the location with a low probability. So in this case, you are

  • taking the weighted average as center of mass--actually, it's the center of mass of all location taking

  • weight as the probability of the location. Of course, your localization accuracy will

  • not be as good as when you have seven towers. But in this case--this is the best you can

  • do. Okay, actually this is--I was talking with the--another group in the morning about

  • the same idea which was how can you do localization with [INDISTINCT] low end phones where you

  • get information only actually from one cell tower, not two. So if you have a low end in

  • the phone, usually it will give you just as that information from the associated cell

  • tower. So if you are doing this, how can I enhance the accuracy based on this? And one

  • technique is what you are talking about is taking the history information into account

  • so that I can get a better estimate. So I'm not just taking this sample; I'm taking the

  • history of sample with me to better enhance the accuracy.

  • >> So, can we have [INDISTINCT] >> YOUSSEF: Right. Actually, in the [INDISTINCT]

  • assumption is usually taking for mathematical feasibility and tractability, yeah.

  • >> How much [INDISTINCT] >> YOUSSEF: Actually, we haven't experimented

  • with taking correlation into account. Actually, in our previous work in Wi-Fi based on the

  • localization, we had to work for taking correlation between samples from the same access point.

  • Actually, you can go with the assumptions that samples from different cell towers are

  • independent. But if you--when we talked about using N samples at the same time, we assume

  • that samples who are from the same tower are independent, but actually they are very highly

  • correlated. So you use the--modeled this before using auto-regression and we obtained better

  • results when we take correlation into account. But it will take you more processing overheads

  • in order to remove this correlation. So it's... >> [INDISTINCT]

  • >> YOUSSEF: Can also... >> [INDISTINCT]

  • >> YOUSSEF: And do a collection like what happened in the assisted GPS, for example.

  • Yeah, that's variable, too. Very good question. Sure.

  • >> [INDISTINCT] >> YOUSSEF: Right. That's a good question.

  • The question is, "Did you try to use different phones in your experiment or you just used

  • one phone?" Because when you use different phones each one has a different receiver sensitivity

  • so the radio map constructed by one would be different from the radio map constructed

  • from the other. Actually, what we did is that all the phones we used were G1 phones but

  • we used different G1 phones. So at least from the same model we tried different phones and

  • all of them of course gave similar results. We tried with Nexus1 phones, but we didn't

  • have concrete results--figure graph. We just had it in a demo that we can walk and give

  • us similar accuracy. What we did also is we tried different service providers. So not

  • just one service provider, we tried with--Egypt has three major providers, we tried with the

  • three of them and they gave us comparable results of course depending on the cell tower

  • dynasty. What we're also planning to do is to do automatic mapping between different

  • phones. So even if there is a difference between phones in terms of the receiver sensitivity

  • and the antenna that and so on, can we have an automatic way of taking the radio map constructed

  • by one phone and to map it automatically to another phone. This is something that we are

  • looking into now, too. That is a very good question. [INDISTINCT]

  • >> [INDISTINCT] does that have any effect on the [INDISTINCT]

  • >> YOUSSEF: In which technique? >> [INDISTINCT]

  • >> YOUSSEF: The first technique, of course. In Egypt, we didn't have any significant tall

  • buildings that can affect the reception. As I said, we are taking GPS as a [INDISTINCT].

  • So for this, we are assuming it has zero error. So, no, the answer, we didn't try any kind

  • of [INDISTINCT] or so on. If you have a data that we can use for evaluation, it would be

  • great to look into it. Thanks. You have another question?

  • >> We have another question [INDISTINCT] it looks like the way you access [INDISTINCT]

  • >> YOUSSEF: The way we do it is that... >> [INDISTINCT]

  • >> YOUSSEF: On the streets. >> On the streets?

  • >> YOUSSEF: Yes. >> So, have you tried actually doing any [INDISTINCT]

  • have you tried actually walking with [INDISTINCT] >> YOUSSEF: Again, not formally so we don't

  • have figures for this but we do it on the demo. So, you'll be inside the building that

  • would give you a location better than the--we had actually a demo--of course, it is not

  • calibrated here, but while we can show we have a demo where it can shows our four techniques

  • I'm comparing with and you can see the estimated location using all the techniques and it will

  • have the same accuracy. But we didn't have an exact numbers that your accuracy degrades

  • by this amount when you are doing this. Sure. >> [INDISTINCT] if you feel like you wanted

  • to power the [INDISTINCT] actually beside the use of the particular parts [INDISTINCT]

  • so it looks like it wouldn't have been [INDISTINCT] what enable to turn the application based

  • on the [INDISTINCT] >> YOUSSEF: Good question. The question is,

  • "When I talked about the power management layer on top of the location provider we said

  • that I'll give the application, developer and API to specify his accuracy and energy

  • consumption requirements." So the question was, "What if you have conflicting the applications?

  • Each one of them requesting a different criteria that conflict the other power management layer?"

  • This is a very good question just on--from the top of my head. In the worst case, you

  • will be working with the least of them. So in this case you are not doing any worst than

  • the current API, but if you can do better you will do better. Something similar that

  • you introduced in the latest API is that, if I remember scheduling the events instead

  • of waking up randomly, you combine applications that wake up at the same period of time and

  • make them all wake at the same time. So if you want to say, "I need to wake every 10

  • seconds," and you are spaced apart every second, actually you will be waking up every second--every

  • 10 seconds. So what you can do is that you align them together so that you can obtain

  • same thing. So maybe it's something along these lines can be used as a location provider

  • too. But actually it's an interesting problem that needs more thoughts about it, you know.

  • Any questions? >> How long does it take this [INDISTINCT]

  • >> YOUSSEF: It depends on many factors, including are you indoors, outdoors, have a clear line

  • of sight to satellites or not, is it a cold start or normal start and so on. So there

  • are a lot of factors in our technique. If you remember the state machine whose saying,

  • obtain a fix or timeout. So this timeout is used that if you're fix takes a lot of times

  • then you will timeout and the move to the estimation INDISTINCT] so that you don't consume

  • a lot of energy waiting for a GPS fix. And hopefully when you come later to the synchronization

  • state, you will start from--not from the beginning from some point so that you will enhance the--take

  • shorter time in order to obtain the next fix. >> So is this kind of part of the [INDISTINCT]

  • >> YOUSSEF: Its fixed as I said from the demo as you saw the synchronization period was

  • fixed at. We fixed it at some time. When you increase it, it's a start as the time I will

  • showing you as XX is a start of the synchronization period. And that's the time you stay in synchronization

  • period is fixed regardless of the synchronization period. Okay.

  • >> And you have the sort of [INDISTINCT] >> YOUSSEF: For what?

  • >> Intercity driving. >> YOUSSEF: You need the Intercity driving.

  • >> Yeah. The error [INDISTINCT] >> YOUSSEF: This one?

  • >> [INDISTINCT] >> YOUSSEF: Oh, I don't think I have that,

  • because all of them are highway. You talk about this?

  • >> Yeah. >> YOUSSEF: I fail when I--all the dataset

  • I have here is for the highways. Sorry for that.

  • >> Does the [INDISTINCT] >> Does what?

  • >> Does the [INDISTINCT] >> YOUSSEF: Actually, there's a better way

  • when you take it more from the compass. So, when you make a turn a compass will give you

  • a better estimate of the direction. So, you just take that from [INDISTINCT] to estimate

  • the displacement, how much you move along this direction. That's why we combine both.

  • Actually, in the slides--here this is from Intercity driving, but I don't have the data

  • with me. So, this is within city. But it is a static. It is not--I cannot change the parameters.

  • Okay. >> [INDISTINCT]

  • >> YOUSSEF: Inside what? >> Inside a car.

  • >> YOUSSEF: A car. >> Yeah. [INDISTINCT]

  • >> YOUSSEF: Because of the magnetic field? >> Yeah. [INDISTINCT]

  • >> YOUSSEF: So, the question is, "If you use the compass inside the car, there is a magnetic

  • field that may affect the accuracy of the compass."

  • >> [INDISTINCT] >> YOUSSEF: Right. And actually, we are showing

  • it here. We do have it and in order to reduce it we do some averaging and filtering on the

  • accelometer, the compass reading. And that's why maybe, it was--this was one of the reasons

  • for this figure I was talking about, this is the reading from the compass from an actual

  • experiments inside the car. And the blue curve is the estimated direction from the GPS. The

  • red curve is the raw data you get from the compass reading from the phone, and the orange

  • curve is the corrected figure taking, to offset into account the initial offset into account.

  • So if you just used it--actually, the red curve is an averaging of the raw data. And

  • then on top of this we do more processing to obtain the orange curve. So, yes, it's

  • noisy but we try to reduce the noise by some processing on top of that. Any more questions?

  • Okay. Thank you very much for your time.

>>

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B1 中級 美國腔

Locationoid。安卓平臺的精準節能定位供應商 (Locationoid: An Accurate Energy-Efficient Location Provider for the Android Platform)

  • 42 5
    shggg 發佈於 2021 年 01 月 14 日
影片單字