Secure User Plane Location (SUPL, pronounced supple) in essence enables applications to directly talk to the AGPS (Assisted Global Positioning System) unit on the mobile phone, without the need to pay the operator for a location dip.  SUPL potentially side-lines the operator out of providing location information; without the need for a costly, complex and power-draining full GPS (Global Positioning System) unit on the phone.  From an operator’s perspective, SUPL is a simple way to avoid the expense of a control plane location solution, instead using user data (IP) so it’s part of the IP stack in the phone, provided they are able to control access to the SUPL API (Application Program Interface) on the phone.

Generally operators view SUPL with suspicion because AGPS chip-sets on the market lack a common SUPL API.  Many AGPS phones lack a SUPL API, one large mobile operator estimates less than one third of their AGPS handset has a usable SUPL API.  The method for an operator to ensure privacy management of SUPL when a customer is using a third party application remains unclear as its a handset issue not network PCE (Privacy Control Entity) issue.  When customers click “yes’ when a widget asks to use their AGPS unit, do they realize that widget is now tracking them?  And when they find out they’re being tracked, who do they complain to?  How do they stop the tracking?  The call will likely be to the operator to whom they’re paying that monthly phone bill, so its’ going to end up being an operator problem.

There is also a lack of agreement on handset APIs for autonomous AGPS, handset initiated AGPS and network initiated AGPS – a major gap.  In some cases the API is chipset defined, in others its handset manufacturer defined, with generally no operator or operator group taking control of the current situation.  Many operators are worried about privacy with SUPL, and many are waiting for the large operators in their market to define the standard.  Hence we have a ‘chicken and egg’ situation with everyone looking at everyone else to solve the problem.  Now with that said, SUPL has had some success in Japan and Korea; however, operators there tend to have far greater control over the value chain, especially handsets.  Also some vertical solutions have appeared, such as the TCS Navigator which uses their own SUPL server, and is described in my Mobile World Congress 2008 Summary weblog article.

It’s also important to realize there is no definitive location technology that works throughout an operator’s network.  GPS and AGPS do not well indoors, hence there is interest in handset based triangulation technologies such as A-FLT (Advanced Forward Link Trilateration) to provide enhanced location information indoors.  So we’re seeing hybrid location technology solutions across CellID, enhanced CellID, AGPS, SUPL, and handset based triangulation.  This complexity in both the handset and network is delaying operators’ decision making on advanced location infrastructure.  So even through LBS services have been a potential for over a decade, we’re still waiting to see them take off.

The problem I’ve described above is similar to that faced by the On Device Portal, discussed in these articles on ODP Evolution and ODP Landscape.  And the solution to both these problems is likely the same.  If operators define a standard secure API for mobile phone browsers to access capabilities on the phone such as the SUPL API, address book, or the many other goodies isolated on the phone (just like you can do with your PC web browser today), then many of these problems would go away.  And it would go a long way down the road in operators opening their networks to the innovation made possible by the millions of developers on the internet, which brings me back to my favorite topic of the Telco API – think of this as the Telco Handset API, the complement of the Telco Network API.