Location: A Way to Improve Revenue from Existing VAS

Location-based services (LBS) in mobile networks is a well known subject. Typically, this discussion has been centered on services where location is in the fore front. This paper is not about applications specifically designed as an LBS; it is about improving the performance of existing applications via the integration of the location vector.

It is no secret that early projections on the contribution of VAS revenue in overall mobile operator earnings have not been met. Indeed, some mobile network operators have reduced their investment in the VAS area. As Peer-to-Peer (P2P) SMS has generally come to be regarded as a core network service, the rest of VAS, generally speaking, has not been performing up to expectations. Nevertheless, mobile network operators (MNOs) realize that VAS fulfills an important aspect of their service portfolio. Without any VAS, a mobile network is a well understood communication infrastructure of voice, messaging and data access service. The inclusion of VAS adds color and keeps alive the possibility that the MNO brand will deliver a “surprise” in addition to delivering the bread-and-butter services that we cannot live without. Of course, “services we cannot live without” remind us of utility companies and there are many MNO’s whose strategy choices repel that word.

MNO’s that choose to differentiate themselves with new and surprising services rather than focus entirely on the delivery efficiency of core services will always be active in the VAS area. It will not be their entire strategy but it will be a component they will not neglect. However, given the less-than-glorifying performance of the overall VAS business, MNO’s are challenged to find ways to improve their return on VAS services. Many of these applications are quite different from each other and are sourced from different vendors. Trying to improve the appeal of each service by a considerable percentage will therefore require a case-by-case study of each. Unfortunately, the effort for each case study may not be justified by the projected results in improvements from each VAS application. It would be instrumental if a single method could be applied across all existing VAS applications as a way to improve their appeal to subscribers. Adding the element of location could be that method.

Location-based services are  frequently perceived as location focused services. That perception creates a tendency to ignore existing VAS where location is not part of the application. MNOs should consider aiding existing applications with location information. This could be referred to as location-aided services. Consider a matrimony application, a dating service, a mobile instant message application, a mobile personal health application, a fortune-telling service or any other knowledge-based application. These are existing applications in many MNO networks and they are not natively designed as an LBS. Such applications have varying degrees of success and they are all different from each other. One worthy method that would increase the uptake of these services is to enrich all of these applications with the integration of the location vector.

The MNO would work as follows:

1. Deploy a middleware infrastructure that optimizes the collection of information from the network and the sharing of it with the VAS applications.
2. Ask its VAS partners to use the Web-Services based simple API to convey location information into application logic. Application logic has to be improved to take advantage of awareness of subscriber location.
3. Have its marketing and operations teams to set rules on which application can get location information and under what terms (see below for these terms). Operations teams will set rules to protect network resources and marketing teams will set rules according to the business case for each application.

A location middleware platform should deliver the following benefits to an MNO:

1. Fetch location from a GMLC or Cell-ID based location from HLR.
2. Cache location information within the middleware and protect the network from repetitive queries that originate from different VAS applications for the same MSISDN. Set time-to-live (TTL) parameters for location records.
3. Enable the MNO to decide which applications are allowed to use HLR vs. GMLC based location information depending on their business case.
4. Enable the MNO to decide transaction-per-second (TPS) levels for each application based on their business case.
5. Enable the MNO to decide TTL level per application based on the business case of an application.
6. Insert Opaque ID management in the interface to the VAS applications to hide MSISDN information where needed.
7. Manage privacy management for location sharing consent on the HLR on behalf of an array of applications.
8. Integrate with map content and GIS servers and offer map services to upstream applications.
9. Integrate with MNO charging servers to execute optional charging events on behalf of applications.
10. Generate technical and marketing reports on the utility of location from different VAS applications for the benefit of the MNO and partners.

The result from such a project commonly benefacting all of the MNO’s VAS will be applications that are more relevant, more surprising, more useful to your subscribers for some of your VAS and indifferent for the rest. However, this is a project not repeated for each VAS on a case-by-case basis. It is a blanket solution to observe measurable increases in the entire VAS group. As a result, in the long tail view, indifference by some applications to location awareness will be made up for by uplifts in others hence a justifiable overall effort. Clearly, the lifetime cost of the location middleware deployment project has to be justified against results from the existing VAS. MNOs will see that the more VAS they integrate location with, the more justifiable this project will become from a financial viewpoint. This goes back to finding uplifts in performance via location awareness and outweighing the indifference from other applications.

Subscribers will see chat applications where location is an optional element to their interaction with friends, a dating application that prompts their friend is now within 500 meters, a fortune-telling service that alerts a nearby body of water is influencing their fortune or a personal health application that invites to a nearby fitness center.

This is not the only method to try and uplift all VAS applications via a common approach but the choices are limited in blanket solutions. Adding the location vector to existing VAS may make the difference.