Передача голоса по беспроводным сетям

Network World, США

ПЕРЕНОС приложений VoIP в беспроводные локальные сети кажется вполне естественным, но скрещивание двух технологий натолкнулось на ряд препятствий. Хотя пакетная передача голоса не требует значительной полосы пропускания, появление во WLAN даже небольшого числа пакетов данных может вызвать значительное ухудшение качества передачи голоса и разрыв соединений — несмотря на использование механизмов QoS.

Таков главный результат первого тестирования функций VoIP в беспроводных устройствах. На протяжении трех месяцев мы изучали качество передачи голоса, поддержку роуминга и механизмы QoS, функциональные возможности беспроводных коммутаторов и точек доступа производства Aruba, Chantry, Cisco и Colubris. К участию в тестировании мы пригласили 18 компаний, но большая их часть, включая Airespace (в январе объявлено о ее приобретении Cisco), Avaya, Enterasys, Extreme, Foundry, Nortel, Proxim и Symbol, отклонили наше предложение.

За пальму первенства разгорелась нешуточная борьба, но победителями всякий раз оказывались коммутаторы A2400 и A800 и точки доступа A61 Aruba. Эти устройства демонстрировали отличные результаты независимо от интенсивности трафика голоса и данных. Изделия других компаний «подкачали» по двум обстоятельствам.

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

Во-вторых, к началу испытаний стандарт 802.11e, определяющий механизмы QoS в сетях WLAN, еще не был ратифицирован. Соответственно во всех тестировавшихся продуктах были реализованы нестандартные методы обеспечения качества обслуживания.

Измеряя качество беспроводного голоса

Мы хотели получить ответ на простой вопрос: как звучит пакетный голос после передачи по беспроводной сети? За помощью мы обратились к молодой компании VeriWave, выпускающей тестовое и измерительное оборудование. Она разработала специальное приложение VoIP over WLAN Analysis Test Suite. Вместе с устройством TestPoint это ПО позволило не только собрать статистику по задержке и ее неравномерности, но и определить значение параметра R (R-value), который введен в спецификации G.107 Международного союза электросвязи (ITU) как показатель качества голоса. Параметр R вычисляется непосредственно по величине задержки, ее неравномерности и доле потерянных пакетов. Эта объективная характеристика хорошо коррелирует с данными субъективного метода MOS (Mean Opinion Score), определяемого стандартом ITU P.80.

При оценке качества голоса использовались до 14 телефонных аппаратов и сервер обработки вызовов по протоколу H.323 от SpectraLink — известного производителя телефонов для сетей 802.11. Количество одновременных голосовых вызовов доходило до семи, а иногда устройства TestPoint отправляли в сеть пакеты данных. Для каждого продукта качество голоса оценивалось как при выключенной, так и при включенной функции QoS (рис. 1).

Голос без QoS

Отключив средства QoS, мы направили все вызовы через одну точку доступа. При передаче голоса производители настоятельно рекомендуют активизировать функцию QoS, и полученные результаты продемонстрировали необходимость в приоритизации голосового трафика. Пока вызов был единственным, все устройства работали отлично, а значения параметра R находились на уровне 78 (табл. 1). Это — едва ли не максимальная величина, которую удается получить при запуске трафика VoIP в беспроводной локальной сети (значение 75 обычно рассматривается как соответствующее качеству голоса в ТфОП).

Но стоило пропустить через одну точку доступа либо коммутатор WLAN шесть-семь вызовов, и ситуация изменилась кардинально — особенно в тех случаях, когда помимо голосовых пакетов в сети присутствовали данные. Впрочем, и без данных мы не смогли протестировать изделие Colubris с семью вызовами и отключенными функциями QoS: ни один из вызовов не прошел.

Настроив TestPoint на генерацию фоновых данных (поток UDP-пакетов интенсивностью 1 Мбит/с), мы получили ужасающие результаты. При шести одновременных вызовах значения параметра R почти для всех систем оказались ниже порога, при котором произносимые слова еще можно разбирать, а установленные соединения не разрываются. И только для изделий Aruba качество голоса оставалось практически столь же высоким, как и без пакетов данных (и это при отключенной функции QoS!).

Оборудование Chantry и Colubris не прошло тест с фоновым трафиком данных при семи одновременных вызовах: как только в сети появлялись данные, соединения разрывались. Это лишний раз подчеркивает необходимость в активизации средств QoS при работе с приложениями VoIP в беспроводной среде.

Включаем QoS

Мы воспользовались теми же пятью сценариями тестирования, которые применялись при отключенных функциях QoS: единственный вызов без передачи данных и шесть-семь одновременных вызовов с фоновыми UDP-потоками и без них. И снова лишь система Aruba продемонстрировала стабильно высокие результаты: даже в самой тяжелой ситуации (семь вызовов плюс трафик данных) качество голоса оставалось близким к таковому в ТфОП. При включенных средствах QoS различие в результатах самых сложных и простейших тестов было минимальным.

Механизмы QoS в устройствах других производителей практически не защищают голосовые потоки при наличии в сети трафика данных. Правда, когда трафик данных отсутствовал, улучшение качества голоса было ощутимым. Стоило активизировать функции QoS и убрать из сети поток данных, как качество голоса вплотную приблизилось к показателю ТфОП даже при семи одновременных вызовах. Но включив генерацию данных, мы получили для устройства CN1250 фирмы Colubris значение R ниже 70 уже при шести вызовах. Для коммутатора Chantry BeaconMaster данный показатель составил около 60.

Кроме того, мы попытались субъективно оценить качество голоса. При наличии в сети трафика данных в трубке отчетливо распознавалось эхо, сигнал пропадал, да и общее качество воспроизведения голоса было низким. Когда же мы перешли к семи звонкам, для изделий Chantry, Cisco и Colubris ситуация ухудшилась еще больше. Коммутатор BeaconMaster вообще не прошел тест: все семь вызовов были разорваны, как только в сети появились данные. Для коммутатора WLSM компании Cisco значения параметра R составило примерно 50, а это минимальный уровень, при котором в речевом потоке можно хоть что-то распознать. К тому же три из семи соединений были разорваны. Точка доступа CN1250 производства Colubris прошла тест, но число пропущенных голосовых пакетов оказалось настолько малым, что тестовое ПО не смогло вычислить значение R.

Кстати, рекомендуемая компанией SpectraLink максимальная плотность звонков составляет шесть одновременных вызовов на точку доступа, а не семь, как в наших тестах. Производители могут обвинить нас в намеренном моделировании сетевых перегрузок, но с таким аргументом можно согласиться лишь отчасти. Во-первых, у продуктов Chantry и Colubris проблемы возникли уже при шести вызовах при наличии в сети трафика данных. Во-вторых, в тех же условиях устройства Aruba прекрасно справлялись и с семью вызовами. В-третьих, даже в самом сложном тесте мы и близко не подошли к максимальной пропускной способности WLAN. Суммарная интенсивность трафика (голос + данные) всякий раз была ниже 3 Мбит/с, а этого явно недостаточно для насыщения беспроводного канала по пропускной способности.

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

Задержки и их флуктуации

Задержка передачи и ее флуктуации — ключевые параметры для любого приложения, но они приобретают особое значение при передаче голоса и видео. Стоит им достичь 50—70 мс, и качество голоса начинает заметно падать (рис. 2). При шести одновременных вызовах и наличии данных средняя задержка передачи у всех устройств не превышала 50 мс, но пиковые значения этой величины и амплитуда ее флуктуаций у продуктов Cisco (шесть вызовов) и Colubris (семь вызовов) зашкаливали за 250 мс.

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

Удвоение точек доступа

Мы повторили тесты с двумя точками доступа, подключив к каждой из них половину всех телефонов. Теперь параметр R оказался намного выше, и это неудивительно: на каждую точку доступа пришлась половина прежней нагрузки. Средняя задержка также возросла, ведь на пути трафика появился дополнительный сетевой узел (рис. 3).

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

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

Рискните использовать роуминг

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

Для инициации роуминга мы отключали питание одной из точек доступа. Это вызвало возражения компаний Chantry и Colubris. Представители первой заявили, что функции роуминга разрабатывались в предположении о физическом перемещении пользователя от одной точки доступа к другой и не рассчитаны на случаи отключения питания. К сожалению, ограниченная площадь тестовой лаборатории не позволила разнести две беспроводные зоны на необходимое расстояние, а использование устройства TestPoint как источника эфирных помех ничем не лучше отключения питания. При этом сбой в сети электропитания — вполне реальная, хотя и редко возникающая ситуация. Если по какой-то причине точка доступа выходит из строя, сеть должна прозрачно переключить всех пользователей на ближайшее устройство.

Протестировать точку доступа CN1250 от Colubris при отключенном питании нам вообще не удалось. Поддержка мобильности в ней реализована средствами протокола Mobile IP, а он требует, чтобы домашний агент (станция, через которую клиент первый раз получает параметры протокола IP) всегда оставался активным. Как только точка доступа, обслуживающая домашнего агента, отключается, роуминг перестает поддерживаться. (Компания Cisco также обеспечивает поддержку протокола Mobile IP, но он не использовался в тестировавшемся оборудовании.) Нам пришлось испытывать функции роуминга CN1250 при отключенном радиоинтерфейсе на первой точке доступа: это должно было привести к переводу клиентов на обслуживание соседним устройством.

Решение Colubris требует наличия еще и третьей точки доступа, выступающей в роли гостевого агента. Именно он отправляет домашнему агенту информацию о роумерах. Мы воспользовались третьим устройством CN1250 со снятыми антеннами, ведь гостевой агент не обязан устанавливать беспроводные соединения.

Как и прежде, мы тестировали функции роуминга с одним, шестью и семью вызовами, с фоновым трафиком данных и без него. С продуктом Cisco роуминг единственного вызова осуществился за 0,433 с, да и остальные системы показали результат примерно 0,5 с (рис. 4). Такая задержка не останется незамеченной для человеческого уха, как и всякое иное событие продолжительностью не менее 70 мс. В остальном качество голоса оказалось на высоте.

Победителем в роуминговых испытаниях вышла компания Aruba: среднее время хэндовера изменялось в интервале от 0,5 с для единственного вызова до секунды с небольшим — для семи вызовов с сопутствующей передачей пакетов данных. Конечно, такую задержку заметит каждый, но быстродействие роуминга у оборудования Aruba оказалось намного более высоким, чем у остальных изделий. В силу ограниченности времени мы протестировали продукты Cisco только с семью одновременными вызовами. Среднее время хэндовера возросло с 0,433 с до 1,053 с без трафика данных и до 4,324 с при наличии фонового трафика.

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

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

Новые средства тестирования компании VeriWave позволили разграничить роуминг на канальном и прикладном уровнях стека протоколов 802.11. Результат оказался поразительным: во многих случаях задержки в несколько десятков миллисекунд при роуминге на канальном уровне приводили к задержкам не менее 10 с на уровне прикладном. Это удивило даже технических представителей фирм — участниц тестирования и очередной раз свидетельствовало о важности строгого следования стандартам 802.11.

Удаленный роуминг

Коммутаторы WLAN могут управлять удаленными точками доступа, поэтому мы решили оценить задержки роуминга и качество голоса в распределенной конфигурации. Что произойдет, если коммутатор расположен в Бостоне, а две точки доступа, между которыми осуществляется роуминг, — в Лос-Анджелесе?

На этот раз мы использовали генератор/анализатор трафика AX/4000 производства Spirent Communications. Он вносил в передачу трафика 100-миллисекундную задержку, примерно соответствующую суммарной задержке при обмене трафиком между Бостоном и Лос-Анджелесом. Тест удалось провести только с продуктами Cisco и Aruba. Устройство BeaconMaster не смогло поддерживать шесть-семь вызовов, а решение Colubris вообще не содержало беспроводного коммутатора.

Тесты на удаленный роуминг проводились только с семью одновременными вызовами. Без трафика данных время локального и удаленного роуминга оказалось практически одинаковым (рис. 5). Добавление данных привело к тому, что для оборудования Aruba время хэндовера возросло с 1 в локальной конфигурации до 3,5 с в удаленной, а для продуктов Cisco эффект оказался обратным. Мы не нашли логичного объяснения этому факту, но он подтверждает заявления Cisco о способности точек доступа предварительно идентифицировать клиентов, а соответственно о возможности избежать снижения производительности в удаленной конфигурации.

Рис. 5. Удаленный роуминг при включенных средствах QoS

Вместо резюме

Не исключено, что изделия, которые будут поддерживать стандарт 802.11e на средства QoS, смогут более эффективно приоритизировать трафик, чем участники наших испытаний. Все производители признали, что перенос технологии VoIP в беспроводные сети только начался, и до совершенства еще далеко. Сетевые менеджеры, намеренные внедрить средства VoIP в сетях WLAN уже сейчас, могут выбрать один из трех вариантов: сильно ограничить число одновременных вызовов, никогда не передавать по сети данные либо сделать ставку на оборудование (вроде выпускаемого Aruba), которое своевременно обрабатывает чувствительный к задержкам трафик.

Разнообразие архитектур

Хотя оборудование WLAN, поддерживающее передачу голоса, выпускается около двух лет, соответствующий рыночный сегмент все еще находится в стадии становления. Как показало предыдущее тестирование беспроводных коммутаторов (см. Сети, 2003, №20-21, статья «Коммутаторы беспроводных локальных сетей»), эти устройства сильно различаются по архитектуре и возможностям.

Продукты Aruba, Chantry и Cisco являются коммутаторами WLAN. Это означает, что функции идентификации пользователей и управления частотным спектром возлагаются на обычный коммутатор Ethernet, а не на точки доступа. Коммутатор не только контролирует доступ к проводной сети, но и динамически регулирует мощность излучаемых радиосигналов.

Предлагаемый Cisco модуль Wireless LAN Services Module (WLSM) для устройств Catalyst 6500, по сути, представляет собой коммутатор WLAN внутри обычного коммутатора. Помимо функций контроля над доступом, реализованных также в изделиях Aruba и Chantry, он осуществляет коммутацию, маршрутизацию, управление безопасностью и контентом (за них отвечают другие модули в составе Catalyst 6500). Неудивительно, что по возможностям маршрутизации IP-трафика это устройство заметно превосходит конкурирующие продукты. В то время как BeaconMaster от Chantry поддерживает протокол OSPF, а CN1250 фирмы Colubris — протокол RIP, изделие Cisco способно работать с любым из основных протоколов маршрутизации.

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

Ни один из испытывавшихся коммутаторов не требует непосредственного подключения точек доступа. Одно такое устройство может использоваться для управления десятками, а то и сотнями точек доступа, установленных даже в территориально разнесенных офисах компании. Представители Aruba утверждают, что коммутатор A2400 в состоянии поддерживать 50 точек доступа, а более дорогая модель A5000 — 256. Коммутатор Chantry способен обслуживать максимум 200 точек доступа, а продукт Cisco — 300.

Основное архитектурное различие между этими продуктами заключается в механизмах распределения трафика между точками доступа и коммутаторами. Aruba и Cisco предусмотрели формирование туннелей Generic Routing Encapsulation (GRE) между точками доступа и коммутаторами, но структуры данных, передаваемых по таким туннелям, не совпадают. В результате анализатор протоколов, который может расшифровать трафик, переданный оборудованием Aruba, не в состоянии прочитать потоки, генерируемые устройствами Cisco. В коммутаторе BeaconMaster реализована инкапсуляция IP-in-IP, а точка доступа CN1250 вообще не поддерживает инкапсуляцию.

Разные транспортные механизмы порождают проблемы совместимости и производительности. Aruba и Chantry утверждают, что их коммутаторы способны взаимодействовать с точками доступа других фирм, но функциональность такого решения окажется ограниченной. Инкапсуляция увеличивает долю служебной информации в передаваемых пакетах, что может привести к фрагментации последних. В то же время инкапсуляция крайне полезна для управления роумингом, поскольку позволяет сохранить за клиентским устройством IP-адрес и регистрационные данные в процессе его перемещения от одной точки доступа к другой.

Все компании, за исключением Chantry, заявили о реализации поддержки будущего стандарта 802.11e Wireless Media Enhancements, но пока используемые механизмы QoS остаются патентованными. Как показывает тестирование, заказчикам лучше дождаться окончательного утверждения этого стандарта, появления на рынке и всеобъемлющего тестирования поддерживающих его продуктов.

Если не считать точек доступа Colubris CN1250, все устройства способны выделять полосу пропускания отдельным рабочим группам. Эта функция важна для проведения границы между сотрудниками и гостевыми пользователями корпоративной сети. А изделия Aruba и Cisco могут даже выделять часть полосы пропускания индивидуальным пользователям.

Существенные различия наблюдаются и в области цен, но ориентироваться только на них было бы ошибкой. Самое дешевое оборудование (1800 долл.) предлагает Colubris. Правда, пользователям придется раскошелиться еще и на коммутатор или маршрутизатор стороннего производителя. Стоимость коммутаторов Aruba и Chantry в тестировавшейся конфигурации — примерно 9 тыс. долл., а устройства Cisco — без малого 52 тыс. долл., но в последнюю цифру включена стоимость шасси магистрального коммутатора для корпоративных сетей и модуля управления. Аргумент производителя в пользу такого решения сводится к тому, что многие организации уже используют коммутаторы Catalyst 6500 в качестве ядра корпоративной сети, поэтому логично возложить на них и управление беспроводным оборудованием. Но даже с учетом дополнительных компонентов решение Cisco Systems остается очень дорогим: сам модуль WLSM как минимум вдвое дороже других протестированных систем.

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

При обработке голосового трафика трудно переоценить важность сокращения задержки передачи пакетов и ее флуктуаций. Некоторые механизмы QoS ставят во главу угла полосу пропускания: если трафик данного типа занимает больше отведенной ему полосы, часть его пакетов попросту отбрасываются. Для обработки голоса такой подход явно не подходит. Даже схемы «строгой приоритизации» (которые позволяют обслуживать этот тип трафика независимо от других классов) корректны лишь при условии, что пакеты с наивысшим приоритетом поступают на обработку раньше других. Однако обеспечить подобную очередность в сетях 802.11 совсем не просто. Разработанные IEEE протоколы порождают значительный объем служебного трафика и требуют подтверждений получения каждого пакета данных. В то же время беспроводные телефоны производства SpectraLink генерируют трафик с частотой 1 кадр в 30 мс и перестают нормально работать, если в сети теряются четыре-пять пакетов подряд. В результате своевременность доставки максимального объема трафика по WLAN является критически важной, но в наших тестах лишь продукты Aruba справились с этой задачей.

Дело не в полосе пропускания. Даже в самых сложных испытаниях суммарная интенсивность трафика голоса и данных в тестовой сети не превышала 3 Мбит/с. Если учесть, что в более ранних тестах оборудование тех же производителей справлялось с беспроводным трафиком объемом без малого 6 Мбит/с, то их сетования на перегруженность сети попросту несостоятельны. Испытания продемонстрировали важность своевременной обработки высокоприоритетного трафика, а не бездумного наращивания пропускной способности.

Точка доступа — не суперкомпьютер. Типичная «тонкая» точка доступа имеет центральный процессор с довольно скромным быстродействием, ограниченный объем ОЗУ и микропрограммные средства. Этого недостаточно, чтобы гарантировать своевременную доставку трафика. Производителям коммутаторов стоит акцентироваться на точных механизмах планирования обслуживания (как поступила Aruba), уменьшить число одновременных вызовов в целях повышения производительности либо вообще выпускать оборудование для «голосовых» сетей WLAN без поддержки клиентов, генерирующих трафик данных. Правда, последний вариант мало кому из заказчиков придется по душе.

Процедура тестирования

Среда тестирования состояла из двух точек доступа, соответствующих стандарту 802.11b, а также (опционально) беспроводного коммутатора или маршрутизатора, к которым они были подключены. В ходе тестирования использовались максимум 14 телефонов WLAN и голосовой шлюз SVP Server H.323 производства SpectraLink, а также тестовое и измерительное оборудование фирмы VeriWave. Наконец, для создания помех при испытаниях функций роуминга применялся генератор шумов компании Spirent Communications.

Для оценки базовых характеристик тестируемых продуктов мы задействовали единственную точку доступа с отключенными средствами QoS. После инициации одного вызова на протяжении 30 с оценивалось качество голоса, т.е. вычислялся параметр R по среднему и максимальному значениям задержки и ее флуктуаций. Поскольку терминалы SpectraLink основаны на кодеках G.711, занимаемая вызовами полоса пропускания остается постоянной вне зависимости от уровня помех. Порождаемая вызовом интенсивность трафика довольно мала (134 Кбит/с в двух направлениях в одном канале 802.11b), поэтому проводить тесты с одним вызовом при наличии фоновых данных не имеет особого смысла.

Для проверки функций роуминга все телефоны устанавливали связь с одной точкой доступа, после чего инициировались вызовы. Затем мы включали питание второй точки доступа и следили за тем, чтобы ни один из терминалов раньше времени не переключился на нее. И лишь после этого первая точка доступа отключалась, что заставляло все телефоны устанавливать соединения со второй точкой.

Тестовое оборудование фирмы VeriWave позволяло измерить время переключения на прикладном уровне. Фактически оно равнялось интервалу между последним пакетом, относившимся к данному вызову и зафиксированным на первой точке доступа, и первым пакетом, поступившим от другого телефона на вторую точку. Таким образом, измерения на прикладном уровне охватывали не только процесс формирования соединений с новой точкой доступа, но и повторную синхронизацию с сервером обработки вызовов SpectraLink.