Как известно, в сетях сотовой связи существует возможность определения местонахождения пользователя (абонента), а точнее, местонахождения его телефона. Сервисы, основанные на определении местоположения пользователя, называются LBS (Location Based Services). Примером LBS может служить Мобильный поиск — сервисы для пользователей МТС, позволяющие узнать, где находятся дети, друзья, машина и т.п. Точность определения местонахождения, в локациях с большим количеством базовых станций (например, в центре города), может достигать 100 метров.
Допустим, что вы и ваши друзья (коллеги, товарищи) решили создать такой сервис, основной функционал которого будет строится вокруг местоположения пользователя. Вы столкнетесь со многими проблемами, часть из которых будет не просто решить чисто технически. Я собираюсь рассказать об альтернативном способе их решения, который в чем-то может быть сложнее, но уж точно решается техническими специалистами.
Проблема построения такого рода сервисов заключается в том, что неизменным участником процесса является оператор сотовой связи, который предоставляет поставщику сервиса (т.е. вам) информацию о местонахождении пользователя (абонента этого оператора). Это означает, что нужно заключать договора с оператором, оговаривать взаимодействие с его сервисами, в конце концов, платить за эту услугу. Кроме того, оператор стремится гарантировать пользователю, что поставщик сервиса не узнает, кому он этот сервис предоставляет. Оператор, с особым фанатизмом, будет стараться сделать все возможное, чтобы ваш сервис не узнал, кому именно он его предоставил. Оказание услуги может выглядеть приблизительно так: оператор отдает поставщику сервиса некий ключ и локацию, поставщик применяет какую-то логику, и возвращает результат сервиса оператору. Информация о том, какому пользователю (ключу) был предоставлен сервис хранится у оператора. И даже если оператор согласится отдавать какую-то персональную информацию абонента, то, все равно, как вы понимаете, организованная группа программистов не сможет просто собраться, и на коленке разработать малобюджетный стартап, основанный на LBS из-за проблемы заключения каких бы то ни было договоров с оператором. Гораздо проще заключить договор с неким аггрегатором, который, в свою очередь, заключил договор с оператором, и может отдавать часть функций еще и четвертым лицам (т.е вам), но это лишь удлиняет цепочку между пользователем и вашим сервисом и уменьшает количество прибыли для вас, т.к. делитесь вы теперь не только с оператором, но и с аггрегатором. Кстати, заметили, что я говорю о прибыли? Да-да, пользователю, при выборе такой цепочки, придется платить деньги, иначе, их придется платить вам, т.к. оператор или аггерегатор едва ли захотят работать с вами бесплатно. Не стоит также забывать, что оператор не один, а их много, и договора заключать придется с каждым из них, если вы хотите работать с абонентами любых сетей, что, согласитесь, гораздо перспективнее.
Существует, однако, и другой способ построения такого рода сервисов. Если посмотреть на сотовую сеть, то она представляет из себя набор базовых станций. Каждая базовая станция покрывает определенный участок, локацию. У каждой базовой станции есть Cell ID — так называемый, идентификатор соты, уникальный для каждой базовой станции оператора. Телефон абонента всегда знает в покрытии какой соты (базовой станции) он находится (он знает ее Cell ID). Так как базовые станции не имеют ног, и, как правило, прикручены к крышам домов, то их адрес более-менее постоянный. Пытливый ум уже сделал вывод, что пользователь может узнать идентификатор соты в которой он сейчас находится, а через него и адрес (~ приблизительный).
Базовые станции на вышке
Следующая проблема заключается в том, (и это, на мой взгляд, самая основная проблема сервиса без привлечения оператора), чтобы узнать сопоставление «Cell ID = адрес». Базой данных «Cell ID = адрес», обладает только оператор сотовой связи, и информация эта — своего рода секрет.
На помощь в составлении базы данных Cell ID могут прийти технологии Web 2.0., а именно — пользователи, которые сами соберут эту базу данных. Можно создать приложения для мобильных телефонов (апплеты), которые будут показывать идентификатор текущей соты, в покрытии которой находится пользователь, а пользователь может ввести адрес, который он видит на углу ближайшего дома. Информация об идентификаторе соты и адресе будет передаваться по GPRS на сервер, а пользователю зачислятся дополнительные очки (карма, если хотите). Можно стимулировать пользователей и подарками, и деньгами, и всем чем угодно. Важно то, что только тысяча пользователей на улицах города способна собрать информацию о базовых станциях своего оператора. Кстати, на западе есть много клубов нетмониторинга, участники которых собирают данные о базовых станциях в своем городе, снабжая новый Cell ID не только адресом, но и фотографией местности. Вот пример такого клуба (http://gsmloc.org). Клуб нетмониторинга есть в достаточно развитом виде в Питере (http://www.netmonitor.ru).
Покрытие территории базовыми станциями
Однако, лучшим решением по формированию базы данных Cell ID, на мой взгляд, будет не привлечение нетмониторщиков, а непосредственный сбор информации о базовых станциях в уже готовом приложении какого-то сервиса. Возьмем, для примера, сервис знакомств. На первом этапе, можно не пытаться определить локацию пользователя по Cell ID, а просить его ввести улицу, на которой он находится. Вместе с информацией об адресе, на сервер будет передан идентификатор базовой станции и идентификатор оператора пользователя. Таким образом, сервис будет оказан, а мы получим адрес очередной соты. Конечно, быстро такая база не соберется, да и возникнет сложность с обработкой информации от пользователей: названия улиц могут быть введены с ошибками, транслитом и т.д. Однако, позже, базу данных можно будет «причесать», и уже не просить пользователя вводить адрес, или, по крайней мере, стараться делать это реже.
Как только база данных будет собрана, и эта база данных будет поддерживаться в более-менее актуальном состоянии (как я и говорил, базовые станции не перемещаются, но сеть все равно «дышит» — меняются идентификаторы, появляются новые базовые станции, исчезают старые), мы получим возможность строить свои собственные Location Based Services, без привлечения оператора. Например, сервис знакомств, о котором я писал выше.
Представьте себе:
Ранняя осень, суббота, яркое солнце и желтые деревья, середина дня, Москва. Михаил, студент второго курса, выходит на улицы города Москвы в районе Театральной и достает свой мобильный телефон. Мишка включает приложение (назовем его «Тебедохр» – это будет рабочим названием), выбирает пункт «Хочу познакомиться» и вводит параметры своей суженой-ряженой. В этот момент, открывает GPRS-сессия, которая передает на сервер идентификатор пользователя, пароль и прочую авторизационную информацию, а так же Cell ID. Сервер, получает Cell ID, и если этот идентификатор есть в базе данных, то происходит определение адреса Миша, а если нет – то сервер попросит Михаила указать свой адрес. Теперь адрес Мишы известен, и все, что осталось серверу, — найти девушку с параметрами, которые указал Михаил. Похожая по описанию девушка находится в примерно одной с ним локации, и тоже не так давно сделала check-in на сервер. Все. Серверу осталось только связать Мишу и его желанную. Передаем анкету Мишы подошедшей девушке, и если она подтверждает, что не против познакомится, их обоих связывают посредством, например, чата. Мише и девушке осталось сделать два шага на встречу друг другу. Это примерная логика работы сервиса. Она может быть и другой, но суть должна быть ясна.
Такой проект вполне по плечу команде из четырех программистов: Crazy c++ программист для платформы Symbian; C# программист для Windows Mobile; Java программист для j2me платформы; PHP(Ruby, Python, Perl, ASP .NET и т.п) программист для серверной части. Кстати, программист под Symbian не обязателен, т.к. j2me приложения прекрасно работают на этой платформе. Работают они и на Windows Mobile, однако внешний вид этих приложений на данной операционной системе оставляет желать лучшего.
Как вы понимаете, можно прикручивать LBS ко всему, что угодно. Поиск ближайшего кафе, кинотеатра, да, туалета, в конце концов. Почему я говорил именно о сервисе знакомств? Если взглянуть на рынок VAS (Value Added Services), то можно увидеть, что наиболее популярные сервисы – это вовсе не заказ мелодий и картинок, а именно сервисы знакомств. Их аудитория действительно обширна, и возможность познакомиться прямо на улице, где до объекта вожделения подать рукой – это заманчивое предложение, на мой взгляд. Что касается заработка на этом, то здесь работает контекстная реклама. Например, если «Кофе-Хауз» заплатил за рекламу, то парочке, «нашедшей друг-друга», можно запросто предложить посидеть в ближайшем кафе, определив его по их местоположению. Вариантов масса. Можно показывать любую рекламу на телефонах пользователей. Можно просить их за деньги поднимать анкеты в топе, как это делают сейчас. Вариантов масса.
Теперь, что касается реализации.
Получение Cell ID на Windows Mobile — есть готовые примеры. Работает не на всех телефонах. Например, на моем Qtek с WM2003 не пошло, хотя с Мегафоном, через раз, таинственно получалось «выцепить» Cell ID. Взял у соседа Qtek с WM5 — собралось и завелось. В форуме, на который я дал ссылку, есть описания моделей, на которых это тестировалось и работает. Используется, соответственно, C# (.NETCF, OpenNETCF (если есть желание)) и C++ для общения с радио-модулем. Что касается C++, то dll уже собранные есть на этом форуме, а также имеются исходные тексты.
Получение Cell ID на Symbian. Есть проект «CellTrack». Есть форум разработчиков, на котором можно скачать примеры и обсудить реализацию. На mobilab.ru есть статья с исходным текстом программы, для получения Cell ID. В отличие от Windows, на Symbian уже все давно работает стабильно.
Получение Cell ID на j2me. Определение Cell ID, доступно для аппаратов, поддерживающих CLDC 1.1, т.к. набор библиотек Location API использует тип float для представления координат. На sun есть статья о LBS и ссылка на спецификацию библиотеки. Если бы ребята разнесли по разным библиотекам определение Cell ID и, собственно, получение координат, то, вероятно, все работало бы прекрасно и на CLDC 1.0. К сожалению, они объединили все в одной библиотеке. Альтернативный вариант – использовать "System.getProperty(«CellID»)", однако, судя по форумам, этот метод работает далеко не на всех моделях.
Что касается серверной части, то тут все четко, и никаких исследований проводить не надо. Мобильный телефон, в нашем случае, — ни что иное, как еще один http-клиент. Что будет принимать запросы телефона и отвечать ему — на любителя. Это может быть linux + apache + nginx + memcached + php5 + mysql5 или что-то иное. Само собой, учитывая специфику, работать придется не только с html+js, но так же разработать веб-сервисы для мобильных телефонов, дополнительный вывод в wml и xhtml(mp). Что касается веб-сервиса, учитывая участие WM устройств, один из протоколов мог бы быть SOAP, т.к. разработать приложение в Visual Studio, использующее SOAP – дело плевое. Что, касается других платформ – это могло бы быть что-то свое, опирающееся, например, на JSON (библиотеки для распаковки есть и для j2me и, само-собой, на c++ для Symbian).
Таким образом, мы видим, что разработать мобильный сервис, основанный на определении местоположения пользователя сотовой связи, без привлечения оператора, вполне себе возможно. Дерзайте!
Мой ХабраДебют =)
Upd.
Пользователь olegi создал сервис, который основан на принципах, которые я описал в этом топике. С этим сервисом вы можете познакомиться тут http://habrahabr.ru/blog/i_am_clever/18819.html
У него же нашел ссылку на большую базу данных базовых станций отечественных операторов. Это значит, что вам не нужно мороки со сбором данных о базовых станциях. Берите готовое и лепите сервисы!
