2003 vs. 2005

Long-awaited next generation broadband wireless networks are by and large in place, powerful location-ready devices that run on these networks are available, and wireless location is now available and accessible to the larger developer community.  The collective LBS ecosystem has arranged the required technology infrastructure piece-parts in order, sensible partnerships have formed, business models are maturing, and energetic developer communities are primed.  After several lethargic years of stinted growth fueled by post dot-bomb hangovers, U.S. location-based application adoption and usage is booming at unprecedented rates within small-to-mid sized business markets, while deployments have gained initial momentum in the consumer marketplace.  The current atmosphere and outlook is positive, creativity abounds, and clever new applications are emerging across the application spectrum.

Build It and They Will Come

Value-chain enablers and developers must be credited for recent successes in the industry; these individuals have worked diligently to sort out business models, arrange sales channels, and build sales engagement policies within larger partner-networks.  Specific successes include the development of partner channels, revenue share pricing arrangements, back office ‘on-behalf-of’ billing, developer support programs, branding agreements, end-user target marketing, and of course—general availability and open business philosophies.  Technical kudos go to wireless location technology advancements in IP-based A-GPS location in the user plane and recent exposure of XML APIs for wireless location in the control plane.  A few thought leaders I talk with regularly assert that in order for LBS apps to secure the ‘ubiquitous’ status industry talking-heads often speak of, an open access environment must exist—I agree, and I am personally sold on the ‘build it and they will come’ credo.  In the case of wireless location availability through these two different but equally valuable architectures, the bold leap to open up access to developer communities has proven constructive. 

Over 75 Case-in-Point Examples

In documenting application areas evolving in the wireless location space over the last two years, I’ve tallied over 75 commercial applications across the business horizontal and consumer markets in North America alone. About 50 of these applications run on NEXTEL and use the IP-based A-GPS user plane location access method offered by way of J2ME through Motorola’s freely-available published iDEN SDK.  The most valuable fact of note is that NEXTEL, who have the most mature and successful developer community at this stage of market development, are presumably generating revenue from these 50 point-solution applications.  What’s more, is there are likely hundreds more applications developed for non-commercial internal uses within the enterprise; these are presently unquantifiable as they are not for resale, nor are they publicly marketed or advertised.  The sheer amount of applications begs the question “why so successful?”  Is it because NEXTEL traditionally serves a customer base that already understands the value of location, and how to use it?  Is it because they built a developer-friendly habitat?  Is it because they have aggressively embraced LBS and dedicated marketing energy and campaigns behind applications?  Is it because they deployed superior location determining technology? 

Some contend NEXTEL’s success is due to their user plane location architecture implementation, which offers real-time location access over an all-IP connection independent of the wireless signaling layer.  Without delving into too much wireless systems-engineering jargon, this simply means location is inexpensive for the carrier to produce because location requests bypass the circuit-switched network which was originally designed to handle voice calls, manage call handoff, and balance load and capacity.  Instead, user plane architectures build off of next-generation architecture in which application requests tunnel under the circuit-switched signaling network over a secure IP connection to acquire aiding ephemeris data from the A-GPS server.  With location produced less expensive and provided through a looser controlled environment, the offering is well suited to accommodate many developers.  From this perspective, NEXTEL’s success is perhaps based on their user plane deployment and the J2ME SDK, which allows any developer to build applications without software overheads while also accessing free location data from the handset.  The only surcharge or tax manifests themselves in the form of payments for additional data-packets needed to transfer location data over the wireless network to geospatial application servers for processing.  While the user plane location architectures deserve some credit for NEXTEL’s success, there are several other factors contributing to NEXTEL’s ongoing achievements—specifically in the domains of business development, marketing, and sales support.
 
User Plane “Versus” Control Plane? 

While user plane location architectures offer location access over an all-IP connection independent of the circuit-switched wireless signaling layer, control plane location architectures exploit the capabilities of the circuit-switched network and the signaling layer to extract location from inside and through the wireless intelligent network.  The location architecture for the control plane was originally designed in the late 90s to solve voice-centric wireless location problems and enable applications to invasively ping devices through network-initiated location queries.  Although some argue that one method is better than the other, I hold an impartial bias.  Both user plane and control plane have equal utility and value depending on: the specific application type, the frequency of location updates required, whether location push or pull methods are needed, what purpose the application serves, who the intended end-user is, and who is billed.
  
Application Uses of Control Plane Location 

E911 was first wireless location-based application launched in 1996.  At that time, wireless location systems were specifically designed to solve E911 voice-call routing problems to closest serving PSAPs.  Location architectures designed for E911 use the circuit-switched network in the control plane for location determination and voice-call routing—they will likely continue to use the circuit-switched network until VoIP networks supplement them.  Location within the control plane is more expensive to produce because it uses the same intelligent network infrastructure handling millions of simultaneous voice calls.  On the whole, there are several technical and business advantages to control plane location architectures and their location access methods—both for enterprise users and B2C developers.    

Control plane location architectures are well designed for taking ‘geographic snapshots’ of many mobile resources carrying several different lightweight devices (figure 1 - right).  Distinct advantages include the ability to initiate network-based location queries independent of end-user device intervention, the ability to locate devices regardless of their in-use or available state, smart-client operating system independence, and little-to-no device battery power consumption.  Control plane location access methods fit particularly well within larger enterprise IT applications such as field service automation, fleet management/dispatch, and sales force automation.  These applications typically depend on several other integrated IT systems including call center systems, corporate email servers, CRM systems, etc., and use these systems in conjunction with wireless location and geospatial servers to enhance larger capabilities of the application in support of automated business information flows and real-time communications.  With these applications, communications to and from the field is often the most important capability of the application.  In this context, location is used as a feature to enhance communications by triggering inbound or outbound notifications based on business conditions or observations defined by geographic zones.  In these application scenarios, the control plane location architecture provides network-initiated mechanisms to locate devices at regularly polled temporal intervals independent of mobile end-user intervention, and subsequently compare the updated locations against other automated business-intelligence processes.  The application does not rely on the device user to intervene or initiate action, as all decisions and control are managed and maintained by server-side back office processes.   

Control plane location architectures are equally well suited for mobile locator ‘child finder’ or ‘buddy finders’ at the consumer-end of the application spectrum (see figure 2 - right).  These applications operate most efficiently by updating location ‘snapshots’ upon request in real-time, rather than accessing pushed location-updates from databases where last-known locations have been posted.  They also provide B2C developers with a means to empower end-users to decide when they want to locate another user.  This capability in turn supports flexible billing options to either charge users requesting location of another, or charge users granting privacy permission to other requestors. 

Application Uses of User Plane Location 

User plane location architectures are designed to enable rapid-fix location updates.  In user plane location architectures application intelligence usually resides within the mobile client rather than server-side. Distinct advantages include the ability to quickly update location locally on the device with minimal network costs, ability to use location locally within a smart client application, and inexpensively push location to servers for processing—all possible through secure IP connections independent of the circuit-switched network. 

User plane location access methods fit particularly well within user-initiated device centric applications such as navigation, gaming, high-frequency location polling for tracking, photomarking, geocaching, and other applications that make use of user-generated content.  These applications typically require advanced application logic client-side and access location and aiding data at the end-user level through BREW, J2ME, or Windows Mobile smart-clients. 

For enterprise applications, user plane location access methods commonly use smart client capabilities to acquire location locally, access aiding data over IP if needed, and finally push location data to server-side databases where geospatial servers add context in the form of addresses, maps, nearby points or people, relevant zones and routes.  The sky is the limit once location is processed server-side—information can be disseminated across multiple channels back to the originating device, to desktops, the Web, and to other devices—all in support of larger enterprise IT automated decision processes. 

Things get quite interesting on the consumer application side within the user plane, particularly around user-generated content applications such as photomarking, geocaching, and other ‘one-click’ data collection applications.  Perhaps you have heard about an award-winning LBS application called BiM Active developed by Bones in Motion?  They recently won the grand prize in the NAVTEQ LBS Challenge II developers contest.  BiM Active allows users to capture details on any outdoor fitness activity with simple GPS-enabled mobile phones.  The app collects GPS data locally, pushes collected data to a server, processes the data server-side, and offers Web and wireless interfaces to view the information—a flow well-suited for user plane architectures and access methods.    

The guys at Bones in Motion were nice enough to let me borrow one of their demo phones this past spring.  I’m personally not into running or cycling, but show me mountain ‘steeps and deeps’ and I’m in heaven on my snowboard.  The BiM Active application is device-centric, so to run the application, users launch the application locally through an intuitive user interface listing a series of menu options that the user must select (see figure 3 - right).  Once the app acquires a GPS fix, close the clamshell and go. 

On April 7, I ran the app for an hour at Bear Mountain while laying down tight s-carves on a cool and sunny SoCal day.  I managed to spin off a couple of kickers as well which is a bonus when the season is nearing its end (figure 4 - left).  At the end of the first hour, I flipped open the phone, clicked ‘stop’, then ‘upload’, and that was it—super simple and easy to use.  The location data was then pushed over-the-air to the BiM Active Web server where Bones in Motion applies their magic to make nice ArcWeb Services maps, elevation and pace charts, and calculate other metrics like calories burned.  I could have downloaded maps and charts then and there on the phone, but I chose to log in to the secure BiM Active web site to look at my boarding runs when I got down the mountain (figure 5 - right).  After reviewing the session details, I posted the entry into my BiM Active blog.  I’ll likely post more runs next season, but for now I’m sharing two sneak preview sessions at http://jspinney.bimjournals.com.  
                              
It’s Just Location

The preceding application examples show that there are unique pros and cons offered by user plane and control plane architectures and their location access methods.  Each is valuable and equal when assessed at the application level.  Some applications may be better off using control plane, while other applications make better use of user plane.  Again, everything depends on the application type, the frequency of location updates required, what purpose the application serves, and who the intended end-user is.  At the network level, the control plane versus user plane superiority debate is best left in the capable hands of engineering circles within the wireless communications industry.  That said I might paraphrase Todd Thayer, Location Technology Program Manager at Nokia.  At CTIA Wireless 2004 he and I shared a panel with others from SiRF, TruePosition, and Vodafone.  Todd opened his presentation saying “you all hear about control plane this, user plane that.  Who cares!  It’s just location.”  Well said.