Location based services (LBS) are increasingly an essential part of our digital lives. What started as an add-on to help improve Internet services has today become an intrinsic aspect to the delivery of very many services, especially in the mobile context. For example, mobile apps are increasingly using the users’ location to deliver services such as weather, transportation info, traffic, shopping, and many more.
Google Now is a prime example of how location is used today to essentially define the user’s need and (pre-)construct a host of useful information before any query is made. This is quite an evolution from the past paradigm where location was just another filter for the final results.
As well as finding new ways to use location, there are changes in the way the user’s location is obtained and contextualized. A user’s location is today looked at as a continuum of locations, an itinerary, a commute, and a weekend trip routines. Much more additional contextual (meta-)data is attached to the actual location information: weather, school holidays, events, upcoming travel, etc.
Google Now in action
All this sophistication in the way user’s whereabouts are captured leads to ever more relevant ways to present users’ with information they need when they need it. We argue that LBS services have seen an important evolution from a V1 to a V2 (2.0 to be hip!). We can clearly see that LBS is no longer a simple filtering of results based on location, but is is instead an extra dimension that is built in the service itself.
LBS 2.0 is more of a recommender system that intensively relies on data analysis of an array of user’s information (not only location history). While LBS services are evolving very fast, we still think they are in their infancy and future LBS services will (i) be ever more anticipatory of users needs, (ii) use a broader range of information on users.
The mobile phone is at the vanguard of this impressive evolution in the way services are made more relevant to user’s locations. The smartphone is today where most of these innovations are taking place: the fast-paced innovations of the web combined with a users being surprisingly comfortable sharing much of their data – location in particular – has made this a reality.
Unfortunately, location based services in the automotive industry has largely lagged all the advances taking place on mobile. Besides traditional GPS navigation and augmentation with mapping layers and various point of interests, there has been very little interesting innovation. Part of the problem is breathtaking pace of innovation in the internet that has left automotive industry on the sideline, not to mention the inherently long product cycles (resp. less frequent innovation iteration) characterizing the automotive industry. Still, another large part of the problem resides in the understandable carmakers concerns about control, security, and safety. The automotive sector has long been reluctant to open up the car (with its on-board unit, and limitless information feeds from the car) for fear of missing on any value created ………. this mindset echoes the mobile operators and OEMs prior to the launch of smartphones. The good news is that there is a realization from most car makers that it is better to be proactive and embrace the Internet rather than wait and see and let others decide their fate.
There are many interesting initiatives in that regard. Toyota uses the Intune service on smartphones as a selling argument. While intune is still a walled garden it does nonetheless offer some interesting service such as infotainment,extended remote control, and monitoring of the vehicle. Pandora and even Bing search are also offered by some car manufacturers. Nokia’s mapping solution also made it into some cars, albeit with stripped down functionalities. Other more forthcoming initiatives (e.g., Ford Applink) takes a more open approach that allows 3rd party mobile developers to add functionalities.
Despite all these advances in the way of a more connected car, an open OS for cars that work across cars of different makes is still a distant prospect. Ideally, one might think, it may be possible to have an Android for cars – call it Cardroid. In this future, Cardroid will be open to 3rd party developers to create valuable and ever more converged services. Just like what ended up happening in the Android ecosystem, car manufacturers will then mainly compete on “hardware” when it comes to connected aspects of the car – after all, the car makers core competency is integration of auto components, not software. Obviously, this idea is very speculative and worthy of exploring further in its own right – probably in another blog post; however, the point is to provoke new ways to envision the automotive ecosystem and there are reasons why an approach such as this may make sense.
Now that we explored the barriers in the way of a full-blown Internet-connected car, we can circle back to our initial subject, LBS services in a vehicular context, and try to imagine a reasonable future. The build up of existing LBS services business and infrastructures is so advanced that it is hard to imagine a future of the vehicular LBS without the same Internet players. Google Maps and its formidable layers (traffic, business reviews, weather, local businesses, etc) will certainly be in the picture. OpenTable, Foursquare, Yelp, and many other services ought to enter the car; indeed, they are already there (through smartphones) without an official invite. The winner in today’s mobile internet will be the winner in the future vehicular LBS services due to two reasons: (i) it takes a tremendous amount of capital and effort to build a successful consumer Internet service (ii) user’s mindshare is hard to get by in todays over supplied Internet. Both of these factors raise the barriers for any new entrant.
Besides a transparent and frictionless access to Internet LBS services in the car, we see a future that is more symbiotic between car-specific information and Internet information. An example of such a future could be some sort of “Fitbit for cars”: a service that would gather all sorts of information on driver’s habits, places visited, itineraries and Internet activities to ultimately help the driver be more on time, drive more safely, achieve better fuel-efficiency, and be reminded of enjoyable places to visit. Every bit of relevant information from the car can be mined here: speed sensors, temperature monitors, steering wheel, cameras, etc. More important, users won’t have to separate lives: one at the PC/Smartphones and another in the car. The lines between these two spaces will be blurred and users Internet activities within them will be a continuum.
As in the Internet, the future of LBS services is a powerful and integrative recommendation system that suggest places and activities based on multiple inputs eg time of day, people in car, recent interests and, of course, weather!
The CARMESH project’s 2 cents towards the evolution of LBS services is interesting, albeit modest. First, through extensive network/communication architecture design and extensive simulations, the project team is exploring more cost-effective ways to network the car. One of the viable alternatives is IEEE 802.11 and WiFi-based mesh networks. As Wifi is license-free, widespread, and offers high capacity it can be a viable addition to cellular services in realistic scenarios. The CARMESH team is looking at important design issues such as mobility, scalability, quality of service, routing, location/positioning mechanisms, and load balancing.
A second string to the CARMESH bow focuses on developing mobile applications that make the car-Internet convergence a reality. We are exploring how the users Internet activities can be bridged to the car, and vice-versa. An example, would be to allow an easy retrieval of users’ destinations from social networks, calendars, and other Internet services. We are also exploring infotainment services and experimenting with existing car APIs.
Keep following our posts for more!