Заглянуть вперед: какими будут приложения

Говорят, «дорога в ад выстлана благими намерениями». В этом отношении сразу вспоминается история середины 2009 года. После выпуска Apple новой прошивки для iPhone, где для экономии заряда аккумулятора включили функцию «быстрого покоя», сети 3G некоторых операторов оказались «наводнены» сигнальными сообщениями. Стремясь перейти в неактивный режим, iPhone запрашивал RNC (контролер базовых станций) о прекращении соединения и высвобождении сигнальных каналов. Устройство преждевременно просило разъединить, а затем запрашивало обратное соединение с сетью. Как заявили в AT&T, в крупных городах, таких как  Нью-Йорк и Сан-Франциско, работа 3G сети была нарушена.

Вероятно, о чем-то подобном в начале 2010 года заявили и в T-Mobile, приведя в пример некое (не указанное) приложение IM (Instant Messenger) для Android, где часто открывались и закрывались соединения. Пока приложение тестировалось в окружении Wi-Fi, проблем не было. Однако в сети 3G, приложение вызвало тяжелые перегрузки на некоторых (опять неуказанных) узлах, так как трафик сигнальных сообщений значительно увеличился. Впрочем, ради справедливости надо сказать, что заявление от T-Mobile, как собственно и AT&T, прозвучало на фоне борьбы вокруг «сетевого нейтралитета».

Тем не менее, несмотря на шумиху вокруг «как передавать биты», важность правильной разработки приложений, которые будут работать в мобильной сети, все-таки трудно переоценить. Показанные выше примеры – яркое тому доказательство. Но сейчас говоря о конвергенции мобильной и проводной связи, о совмещении технологий доступа на уровне технологий, сервисов, о приложениях часто просто забывают. Недавно целый ряд компаний из мира высоких технологий, Amazon, Google и Apple, догоняя один другого, вывели на рынок свои музыкальные сервисы, названные «облачными». И суть не в том, что в них обыгрывается, теперь и со стороны частного пользователя, раздутая маркетинговая концепция.

Нам важно, что трансляция аудио потоков наглядно показывает пример приложения, когда его работа перестает зависеть от типа сети, мобильной или проводной, в которой ведется сетевой обмен. Надо понимать, что таких приложений будет все больше и больше. Ведь интернет, как заверяют в Google и Mobile Marketing Association (MMA), на мобильном устройстве быстро становится необходим пользователю так же, как и на ПК. По сравнению с сетями 2G/GSM и первых версий 3G/UMTS (R99), в сетях HSPA / HSPA+, не говоря уже о LTE, где пропускная способность возросла, а задержки в передаче пакетов уменьшились, - мобильный широкополосный доступ по своим параметрам «встал» недалеко от проводного.

Тест 3G: Предсказуемые результаты (2Q 2011 года, Москва и Московская область), Mobile-review

Правда, здесь возникает интересный момент. Ведь различия между сетями, проводными и мобильными, даже взяв в пример LTE, несмотря на общую основу, где все «крутиться» вокруг IP, - есть, и они значительны. И дело здесь не только в том, что емкость мобильной сети, ограниченная диапазоном частот, спектральной эффективностью стандарта и размером соты, конечна и легче подвергается перегрузкам. Есть и другие нюансы. Вот и интересно попробовать ответить на вопросы, и если не на все, то хотя бы на некоторые, основные: какие еще нюансы надо учесть при разработке приложений, подразумевая, что работать они будут и в мобильных сетях?

Во-первых, как видно из приведенных примеров с AT&T и T-Mobile, радиочастотная среда – это, по сути, общая среда, где работают и другие приложения или устройства. Следует избегать агрессивной или нестандартной модели поведения приложений. Когда в передаче пакетов возникают потери, необходимо отложить передачу или дождаться ответа. Если приложение будет пытаться «протолкнуть» свои данные, это может усугубить причины отказа и сказаться на работе всей сети в целом или какого-либо ее участка.

Во-вторых, параметры передачи в мобильной связи нестабильны и сильно зависят от доступных радио и сетевых ресурсов. Даже в пределах одной соты при перемещении терминала пропускная способность и задержки в сети LTE могут быстро изменяться, в зависимости от соотношения сигнал/шум и соответственно выбранной для потока данных в MIMO-канале по алгоритму PARC (Per-Antenna Rate Control) схемы кодирования (вид модуляции, скорость кодирования и числа расширяющих кодов). Чем дальше от базовой станции и ближе к краю соты, тем хуже соотношение сигнал/шум, а значит, будет применена менее требовательная к параметрам схема и тем скорость передачи будет меньше.

Вдобавок, в то время как LTE обеспечивает высокие скорости передачи и низкую задержку, в ближайшее время его покрытие будет носить «очаговый» характер и сосуществовать с сетями 3G, или даже 2G. Тем более у нас в России надеяться на плотное покрытие сетями 3G с HSPA+ от «большой тройки» (Вымпелком, МТС и Мегафон) явно в ближайшем будущем не приходится. Выходя за пределы сети LTE или HSPA+ (если терминал многорежимный), параметры доступа изменятся, и хорошо, если принимающей сетью будет EDGE, а не вообще только GPRS, без «всяких» там надстроек.

При этом при переходе, хэндовере, из одной сети в другую возможно большая задержка, связанная с передачей соединения. К примеру, при переходе от LTE к CDMA, задержки бывают и до пяти секунд (!), в зависимости от того, работают ли обе сети в одном диапазоне частот. Кстати, обратный переход от CDMA к LTE мог занимать до двух минут. Такое признание сделала компания Verizon, обнаружив проблему в драйверах USB-модема LG введя свою сеть LTE в эксплуатацию.

МТС: Зона обслуживания сетей 3G/UMTS и 2G/GSM в Краснодарском крае, июнь 2011 года

Понятно, что очевидное решение, как снизить ущерб от нестабильности параметров доступа, лежит в преждевременном упреждающем кэшировании данных, или в терминологии видео или аудио потоков – буферизации. Вот только вероятно другим типам приложениям, когда кэшированием обойтись трудно или нельзя, стоит по возможности контролировать параметры сетевого окружения. Ведь в зависимости от пропускной способности и задержек приложения могут менять свой алгоритм.

Погодный сервис может отказаться от загрузки объемных метеокарт. Программа навигации может перейти только на карты с векторной графикой, запретив на время растровые, спутниковые. Почтовый клиент, обнаружив «быструю» сеть, получит полные сообщения, а в «медленной» только заголовки. Приложение IM при передаче Вам файла, если скорость передачи низкая, отправит его на сервер, а потом, когда параметры доступа улучшатся, переместит его на мобильный терминал.

Как видите, применений много. Это не говоря уже о Windows, антивирусах и ряда других программ, которые «видя» положение триггера, в мобильной или проводной сети ведется работа, могут принять решение «обновиться», или отложить этот процесс. Согласитесь, было бы удобно для пользователя, чтобы Windows за обновлениями «лез» только из проводной сети. Правда, пока это мечты. Сейчас определить тип сети по скорости передачи и времени задержки не всегда возможно, так как одни и те же значения могут говорить, что устройство находится в «перегруженной» проводной сети, или в «недогруженной» сети LTE.

Естественно, можно указать и третий нюанс, и четвертый, и пятый. Указанными в статье двумя пунктами все тонкости не заканчиваются. Как вариант, стоило бы рассмотреть нюанс с размером и частотой запросов в приложениях, работающих в сетях GSM с GPRS/EDGE, где в силу сетевых ограничений и частых ошибок в передаче лучше запрашивать «меньше, но чаще». И в сетях LTE, где можно и даже нужно увеличивать объем запросов.

Впрочем, давайте остановимся, а другие нюансы оставим на усмотрение тех, кто будет писать приложения, программистов. Пускай это будет их «головная боль», … ну или тех, кто будет потом «отлавливать» незадачливых «быдлокодеров», то есть их творения, эксплуатируя свои сети.