Анатомия пиков сигнализации: Viber, Microsoft Exchange и предустановленные приложения

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

Первым звоночком, свидетельствующим о надвигающихся неприятностях, обычно становятся аварийные сигналы о перегрузке центрального процессора (CPU Overload), поступающие от разных узлов мобильной сети. В этот момент весь центр управления и эксплуатации сети (Network Operations Center) приходит в смятение и поминает Всевышнего, прося о том, чтобы всплеск оказался непродолжительным и не превысил максимально возможной пиковой нагрузки. Ведь если это все же случится, всем потребителям будет отказано в доступе к сервисам. К тому же поиск первопричины — это очень нелегкое дело. Проблема может быть связана с приложениями, на работу которых центр не оказывает никакого влияния, да и разрешить ее без серьезной сетевой аналитики и помощи разработчиков приложений и устройств не так-то просто. Именно поэтому в отчете Alcatel-Lucent Mobile Apps Rankings столько внимания уделялось сигнализации, а на конференции LTE World 2014 этой теме даже был посвящен целый день.

Существует три вида всплесков сигнализации: микропики, которые продолжаются в течение нескольких секунд; продолжительные пики, измеряемые минутами или часами; внезапный устойчивый рост, когда трафик сигнализации в какой-то момент резко увеличивается и продолжает нарастать в течение нескольких недель и месяцев. Примером последнего может послужить 60-процентный скачок трафика сигнализации в «Фейсбуке», произошедший в ноябре 2012 года. Ниже приведены другие примеры, зафиксированные в гетерогенной сети с помощью инструментария Wireless Network Guardian (WNG) и демонстрирующие возникновение и исчезновение пиков сигнализации в диапазоне от 36 до 92%.

МИКРОПИКИ: SAMSUNG, GOOGLE И ПРЕДУСТАНОВЛЕННЫЕ ПРИЛОЖЕНИЯ

В данном случае короткие всплески сигнализации были зафиксированы на всех сервисных шлюзах (Serving Gateway, SGW) шесть раз в течение суток: в 00:00, 1:30, 6:30, 8:00, 12:30 и 18:30. Что примечательно, эти всплески постепенно нарастали — от едва заметных 8% до ясно различимых скачков величиной 44% (см. Рисунок 1).

Рисунок 1. Сигнализация на SGW: причиной скачков на 44%, фиксировавшихся шесть раз в сутки, были особенности работы предустановленного приложения.

В один «прекрасный» день шлюз не выдержал очередного пика: несколько блейд-модулей отключились из-за перегрузки, вызвав сбой сигнализации (см. Рисунок 2) и частичный отказ сервиса. До выяснения причины аварии и восстановления работоспособности трафик был временно перенаправлен на резервный шлюз SGW повышенной мощности.

Рисунок 2. Сбой сигнализации на SGW из-за предустановленного приложения.

Проведенный с помощью WNG анализ сузил круг поисков: подозрения пали на смартфоны Samsung S4 с установленной ОС Android 4.2/4.3, которые пытались обратиться к серверу Google.com. Получив эту информацию, специалисты Samsung установили, что всплески сигнализации генерировало одно из предустановленных приложений, которое связывалось с Google API для определения местоположения пользователя и загрузки местных новостей. На устройства с Android 4.4 это приложение уже не устанавливалось. Казалось бы, для устранения проблемы достаточно удалить ее источник. Однако избавиться от предустановленных приложений не так просто, вместо этого пришлось загружать на тестовые устройства ряд обновлений, чтобы пошагово восстановить нормальную работоспособность.

ПРОДОЛЖИТЕЛЬНЫЕ ПИКИ: ОСТАНОВКА МЕССЕНДЖЕРА VIBER

29 апреля контроллеры радиосети (RNC) были буквально «затоплены» запросами, о чем можно было судить по аварийным сигналам перегрузки ЦП. Пик сигнализации соотносился с мессенджером Viber — судя по трафику, серверы Viber не отвечали. Но почему же сбой этого приложения оказал столь значительное влияние на ресурсы сигнализации? Выяснилось, что все дело в обработчике отказов в обслуживании Viber: приложение продолжало повторять попытки установления соединения с сервером, и чем больше пользователей не могли соединиться, тем сильнее нарастал поток сигнализации (см. Рисунок 3).

Рисунок 3. 92-процентный всплеск сигнализации на GGSN из-за простоя Viber в течение 4,5 ч.

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

МИКРОПИКИ: MICROSOFT EXCHANGE И IOS

Следующий пример — кратковременные перебои, во время которых ежедневно возникающий пик сигнализации превышал максимальную пиковую емкость. Всплеск сигнализации на 36% наблюдался каждый день в полночь, но причина его была непонятна (см. Рисунок 4). С помощью WNG удалось сузить круг поисков: сигнализация исходила от устройств, пытавшихся установить соединение с сервером Microsoft Exchange. Взаимодействие длилось менее одной секунды, в нем участвовали только устройства iPhone, причем в основном с iOS 6.1. Получив эту информацию, операторы обратились в Apple, где им помогли определить первопричину. Она была устранена в обновленных версиях iOS.

Рисунок 4. Полночные 36-процентные микропики сигнализации на SGW, вызванные приложением Microsoft Exchange на базе iOS.

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

Джози Лудиадис — директор подразделения сетевой аналитики в компании Alcatel-Lucent.