In this post, we present a broad-brush, 10,000 foot level survey of developments in the Location Based Services domain. This post is a work in progress. There are several other ideas that merit coverage here including privacy and security concerns, other means of tracking user location, and leading edge location services application scenarios.
As mobile Internet devices become more prevalent, there is a larger pull for mobility characteristics to be blended into the end-user experience. Earlier, people would log into the nearest computer and find directions to the nearest ATM, restaurant, or POI (Point Of Interest) by providing their current geographical location. Later, they graduated to providing their location (i.e. the location of their computer) once, which the computer would "register" (either using cookies or by saving with the user profile on the application website) and send out seamlessly to applications that needed this information to provide value-added services.
This in turn gradually led to more "sophisticated" usage scenarios where applications would recognize the geographic location of the RAS (remote access server) or other IP address pool from which the user's computer was assigned an address and divine the user's location from that (though due to idiosyncracies of how some ISP networks are set up and the details of the underlying infrastructure used - DSL vs. Cable, with head-end locations etc, this can sometimes lead to embarrassing errors).
As Location Based Services (or LBS for short henceforth) evolved further, cellular networks employed technologies that factored in the time difference of arrival of signals from the handset, or the angle of arrival of the signal from a handset or combinations thereof to determine the location of a handset in 3-dimensional space relative to a network of stationary cell-phone towers. During this time, acronyms like PDEs (Position Determining Equipment), MPCs (Mobile Positioning Centers), GMLCs, TDOA (Time Difference Of Arrival), EFLT, AFLT, .... (and others too numerous to mention, and perhaps not all worth even googling for anymore) were widely prevalent. But once GPS-capable hardware became available in handsets, LBS really took off in a big way.
Aside: Note how the above describe scenarios where there are sets of mobile handsets that communicate with each other via a network of stationary nodes (cell towers). Of course, more ad-hoc implementations of a set of mobile handsets that talk directly to each other in true peer-to-peer fashion (like CB radios or walkie-talkies) or the kinds of networks covered under IETF MANET standards also exist, though for simplicity we ignore them here since location in such systems can get much more complicated. <end of Aside>
Some issues persisted even with GPS. A common problem in large metropolitan areas is that of an "urban canyon". This happens when between tall buildings, say in NYC, or within buildings where surrounded by sky-scrapers, there is limited access to satellites, so one has to revert to the older ways of determining location (see para 1 above for example) to be able to provide value-added services to consumers.
As Wifi proliferated, methods akin to those from the second paragraph above were employed at Wifi hotspots to determine the relative strengths of signals from different hotspots (if these were part of a single larger infrastructure network), and then used as a basis to compute the possible location of the mobile client. This alleviated to some extent, the problems with urban canyons, since hybrid technologies could now be employed to effectively location enable applications in areas where such coverage would previously not have been possible. Hybrid as in, use GPS where GPS is available, else, if a Wifi capability existed on the handset and Wifi networks were also located in the vicinity, utilize those to get either the fix, or improve the accuracy of a fix obtained by other methods. Once this base location capability was available, service logic could be overlaid atop this.
This is where we are today. I guess what matters more than the technologies used to support location data is the applications that reside atop the stack. Once can deploy some very useful or even some very "cool" (even if unuseful) applications today, all thanks to location. Examples include geocaching, location-based games, automated mobile tourist guides, of course, GPS-enabled driving directions, and even research projects like "street stories" (yes, this was very cool in 2002).
As mobile Internet devices become more prevalent, there is a larger pull for mobility characteristics to be blended into the end-user experience. Earlier, people would log into the nearest computer and find directions to the nearest ATM, restaurant, or POI (Point Of Interest) by providing their current geographical location. Later, they graduated to providing their location (i.e. the location of their computer) once, which the computer would "register" (either using cookies or by saving with the user profile on the application website) and send out seamlessly to applications that needed this information to provide value-added services.
This in turn gradually led to more "sophisticated" usage scenarios where applications would recognize the geographic location of the RAS (remote access server) or other IP address pool from which the user's computer was assigned an address and divine the user's location from that (though due to idiosyncracies of how some ISP networks are set up and the details of the underlying infrastructure used - DSL vs. Cable, with head-end locations etc, this can sometimes lead to embarrassing errors).
As Location Based Services (or LBS for short henceforth) evolved further, cellular networks employed technologies that factored in the time difference of arrival of signals from the handset, or the angle of arrival of the signal from a handset or combinations thereof to determine the location of a handset in 3-dimensional space relative to a network of stationary cell-phone towers. During this time, acronyms like PDEs (Position Determining Equipment), MPCs (Mobile Positioning Centers), GMLCs, TDOA (Time Difference Of Arrival), EFLT, AFLT, .... (and others too numerous to mention, and perhaps not all worth even googling for anymore) were widely prevalent. But once GPS-capable hardware became available in handsets, LBS really took off in a big way.
Aside: Note how the above describe scenarios where there are sets of mobile handsets that communicate with each other via a network of stationary nodes (cell towers). Of course, more ad-hoc implementations of a set of mobile handsets that talk directly to each other in true peer-to-peer fashion (like CB radios or walkie-talkies) or the kinds of networks covered under IETF MANET standards also exist, though for simplicity we ignore them here since location in such systems can get much more complicated. <end of Aside>
Some issues persisted even with GPS. A common problem in large metropolitan areas is that of an "urban canyon". This happens when between tall buildings, say in NYC, or within buildings where surrounded by sky-scrapers, there is limited access to satellites, so one has to revert to the older ways of determining location (see para 1 above for example) to be able to provide value-added services to consumers.
As Wifi proliferated, methods akin to those from the second paragraph above were employed at Wifi hotspots to determine the relative strengths of signals from different hotspots (if these were part of a single larger infrastructure network), and then used as a basis to compute the possible location of the mobile client. This alleviated to some extent, the problems with urban canyons, since hybrid technologies could now be employed to effectively location enable applications in areas where such coverage would previously not have been possible. Hybrid as in, use GPS where GPS is available, else, if a Wifi capability existed on the handset and Wifi networks were also located in the vicinity, utilize those to get either the fix, or improve the accuracy of a fix obtained by other methods. Once this base location capability was available, service logic could be overlaid atop this.
This is where we are today. I guess what matters more than the technologies used to support location data is the applications that reside atop the stack. Once can deploy some very useful or even some very "cool" (even if unuseful) applications today, all thanks to location. Examples include geocaching, location-based games, automated mobile tourist guides, of course, GPS-enabled driving directions, and even research projects like "street stories" (yes, this was very cool in 2002).
