Mobile service, tied to the location of the user, without the involvement of the operator

As you know, in cellular networks there is the possibility of determining the location of the user (subscriber), or rather, the location of his phone. Services based on the user's location are called LBS (Location Based Services). An example of LBS is Mobile Search - services for MTS users, allowing them to find out where children, friends, cars, etc. are located. The accuracy of determining the location, in locations with a large number of base stations (for example, in the city center), can reach 100 meters.

Suppose that you and your friends (colleagues, comrades) decided to create such a service, the main functionality of which will be built around the user's location. You will encounter many problems, some of which will not be easy to solve purely technically. I'm going to talk about an alternative way to solve them, which may be more difficult in some ways, but certainly solved by technical experts.
')


The problem of building such services is that the constant participant in the process is the cellular operator, which provides the service provider (i.e., you) with information about the location of the user (the subscriber of this operator). This means that you need to enter into contracts with the operator, to negotiate interaction with its services, in the end, to pay for this service. In addition, the operator seeks to ensure the user that the service provider does not know to whom he provides this service. The operator, with particular fanaticism, will try to do everything possible so that your service does not know to whom it was he who provided it. The provision of the service may look something like this: the operator gives the service provider a key and location, the supplier applies some logic, and returns the result of the service to the operator. Information about which user (key) was provided with the service is stored by the operator. And even if the operator agrees to give some personal information to the subscriber, it’s all the same, as you understand, an organized group of programmers cannot simply gather, and develop a low-budget start-up based on LBS on my knee due to the problem of concluding any contracts with the operator. It is much easier to conclude an agreement with an aggregator, which, in turn, has entered into an agreement with the operator, and can give some functions to even fourth persons (ie, you), but this only extends the chain between the user and your service and reduces the amount of profit for you, because Now you are sharing not only with the operator, but also with the aggregator. By the way, noticed that I'm talking about profits? Yes, the user, when choosing such a chain, will have to pay money, otherwise, you will have to pay them, because the operator or the aggregator will hardly want to work with you for free. Do not forget that the operator is not one, but there are many of them, and you will have to enter into contracts with each of them if you want to work with subscribers of any networks, which, you see, is much more promising.

There is, however, another way to build this kind of services. If you look at the cellular network, it is a set of base stations. Each base station covers a certain area, location. Each base station has a Cell ID - the so-called cell ID, unique to each base station operator. The subscriber’s phone always knows which cell (base station) it is in (it knows its Cell ID). Since the base stations do not have legs, and, as a rule, are bolted to the roofs of houses, their address is more or less permanent. The inquisitive mind has already concluded that the user can find out the identifier of the cell in which he is now located, and through him the address (~ approximate).


Base stations on the tower

The next problem is, (and this, in my opinion, the most basic problem of the service without the involvement of the operator), to find out the mapping "Cell ID = address". The database "Cell ID = address", has only a mobile operator, and this information is a kind of secret.
To help in compiling the Cell ID database, Web 2.0 technologies can come in. Namely, users who will assemble this database themselves. You can create mobile phone applications (applets) that show the identifier of the current cell covered by the user, and the user can enter the address that he sees on the corner of the nearest house. Information about cell ID and address will be transmitted via GPRS to the server, and additional points will be credited to the user (karma, if you wish). You can stimulate users and gifts, and money, and everything. It is important that only a thousand users on the streets of the city is able to collect information about the base stations of its operator. By the way, in the west there are many non- monitoring clubs, whose members collect data on base stations in their city, providing the new Cell ID with not only an address, but also a photograph of the area. Here is an example of such a club ( http://gsmloc.org ). The net monitoring club is in a fairly developed form in St. Petersburg ( http://www.netmonitor.ru ).


Base station coverage

However, the best solution for building the Cell ID database, in my opinion, is not to attract non-monitors, but to directly collect information about base stations in the ready-made application of some service. Take, for example, a dating service. At the first stage, you can not try to determine the location of the user by Cell ID, and ask him to enter the street where he is located. Together with the address information, the base station identifier and the user operator identifier will be transmitted to the server. Thus, the service will be provided, and we get the address of the next cell. Of course, such a base will not be collected quickly, and there will be a difficulty in processing information from users: street names can be entered with errors, transliteration, etc. However, later, the database can be “combed”, and no longer ask the user to enter the address, or at least try to do it less often.

As soon as the database is collected and this database will be maintained in a more or less up-to-date state (as I said, the base stations do not move, but the network still breathes - the identifiers change, new base stations appear, the old ones disappear) we will be able to build our own Location Based Services, without involving an operator. For example, dating service, which I wrote above.

Imagine:
Early autumn, Saturday, bright sun and yellow trees, middle of the day, Moscow. Mikhail, a second-year student, goes to the streets of Moscow in the Teatralnaya area and takes out his mobile phone. The bear includes the application (let's call it “Tebedohr” - this will be the working name), selects the “I want to meet you” item and enters the parameters with your connoisseur. At this moment, the GPRS session opens, which transmits the user ID, password and other authorization information to the server, as well as the Cell ID. The server receives the Cell ID, and if this identifier is in the database, then the address of Misha is determined, and if not, the server will ask Michael to specify his address. Now the address of Misha is known, and all that is left to the server is to find a girl with the parameters that Michael indicated. Similar to the description of the girl is in about the same location with him, and also recently made a check-in to the server. Everything. The server needs only to bind Misha and his desired one. We transfer Misha's profile to the girl who has approached, and if she confirms that she is not against getting acquainted, they are both connected through, for example, chat. Misha and the girl have two steps left to meet each other. This is the approximate logic of the service. It may be different, but the essence should be clear.

Such a project is quite capable of a team of four programmers: Crazy c ++ programmer for the Symbian platform; C # programmer for Windows Mobile; Java programmer for j2me platform; PHP (Ruby, Python, Perl, ASP .NET, etc.) programmer for the server side. By the way, a programmer for Symbian is not necessary, since j2me applications work great on this platform. They also work on Windows Mobile, but the appearance of these applications on this operating system leaves much to be desired.

As you understand, you can fasten LBS to everything, anything. Search for the nearest cafe, cinema, yes, toilet, in the end. Why did I speak about dating service? If you look at the VAS ( Value Added Services ) market, you can see that the most popular services are not the order of melodies and pictures at all, but dating services. Their audience is really extensive, and the opportunity to meet right on the street, where to hand the object of lust is a tempting offer, in my opinion. As for earnings on this, contextual advertising works here. For example, if “Coffee House” paid for advertising, then a couple who “found each other” can easily be offered to sit in the nearest cafe, determining it by their location. There are lots of options. You can show any advertising on users' phones. You can ask them for money to raise profiles in the top, as they do now. There are lots of options.

Now for the implementation.

Getting Cell ID on Windows Mobile - there are ready examples. Does not work on all phones. For example, on my Qtek with WM2003 it did not go, although with a Megaphone, through time, it was mysteriously turned out to "pull out" Cell ID. I took Qtek from my neighbor with WM5 - it was assembled and started. In the forum to which I gave the link, there are descriptions of the models on which it was tested and works. Used, respectively, C # (.NETCF, OpenNETCF (if desired)) and C ++ to communicate with the radio module. As for C ++, the dll already compiled is on this forum, and there are source codes.

Getting Cell ID on Symbian. There is a project "CellTrack". There is a developer forum where you can download examples and discuss implementation. On mobilab.ru there is an article with the source code of the program, to obtain the Cell ID. Unlike Windows, on Symbian everything has been stable for a long time.

Getting Cell ID on j2me. Cell ID detection is available for devices supporting CLDC 1.1, since The Location API library set uses the float type to represent coordinates. On sun there is an article about LBS and a link to the library specification. If the guys smashed Cell ID definition and, in fact, getting coordinates, in different libraries, then everything would probably work fine on CLDC 1.0. Unfortunately, they combined everything in one library. The alternative is to use " System.getProperty (" CellID ") ", however, judging by the forums, this method does not work on all models.

As for the server part, then everything is clear, and no research is needed. A mobile phone, in our case, is nothing more than another http client. What will take phone requests and respond to him - an amateur. This could be linux + apache + nginx + memcached + php5 + mysql5 or something else. Of course, given the specifics, we will have to work not only with html + js, but also develop web services for mobile phones, additional output in wml and xhtml (mp). As for the web service, given the participation of WM devices, one of the protocols could be SOAP, since Developing an application in Visual Studio using SOAP is a trifling matter. As for other platforms, it could be something of its own, based, for example, on JSON (there are libraries for unpacking for j2me and, of course, for c ++ for Symbian).

Thus, we see that it is quite possible for you to develop a mobile service based on determining the location of a cellular user, without engaging an operator. Dare!

My HabraDebut =)

Upd.
The user olegi has created a service that is based on the principles that I described in this topic. You can get acquainted with this service here http://habrahabr.ru/blog/i_am_clever/18819.html

He also found a link to a large database of base stations of domestic operators. This means that you do not need hassle with collecting data about base stations. Take ready and sculpt services!