Контроль качества услуг, предоставляемых операторами фиксированной связи

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

Организация контроля качества услуг

При заключении контракта на предоставле-ние услуги клиенту провайдер оговаривает в нем качество обслуживания в своей зоне ответственности, то есть на магистрали между SAPклиента (PE-PE). При этом SLA на магистрали не является достаточным для гарантии отсутствия проблемы на стороне сети. Проблемы с модулем/интерфейсом в сторону клиентских подключений или программные дефекты (например, неправильная отработка QoS на клиентском интерфейсе) невозможно диагностировать с помощью аппаратных тестов.

Возможны следующие варианты организации тестирования клиентских подключений:

• -    активный опрос с PE-маршрутизатора клиентского устройства CE (remote ping);

• -    мониторинг производительности политик QoS на интерфейсе клиента;

• -    baseline мониторинг: вычисление отклонения пользовательского трафика от средней активности за предыдущие периоды мониторинга;

• -    установка аппаратного тестера на стороне клиента, который будет проверять сквозное качество услуги.

Активный опрос по ICMPпозволяет контролировать доступность услуги и параметры задержки и потерь на «последней миле». Это позволяет провайдеру определять до обращения клиента проблемы с подключением и быстро диагностировать, в чьей зоне ответственности она имеет место. Следует учитывать, что вероятность недоступности «последней мили» по вине оператора крайне мала и этот подход приведет к множеству ложных проблемных оповещений, которые придется отрабатывать службе эксплуатации оператора. Например, заказчик перезагрузил или выключил CPE, сбой в сети провайдера «последней мили» или регламентные работы, о которых оператор не был предупрежден.

Мониторинг производительности политик QoS дополняет решение анализом работы QoS на интерфейсе оператора, при этом не позволяет гарантировать QoS на «последней миле». Контроль работы политик QoS на клиентском подключении для оборудования Cisco возможен с помощью мониторинга производительности Cisco MIB Class Based QoS.

Мониторинг отклонения трафика на интерфейсе абонента от рассчитанного за предыдущие интервалы шаблона предлагается вести для обнаружения аппаратно-программных проблем на PE-устройстве и DDoS атак.

Средние значения для каждого интервала времени вычисляются на основе результатов измерения активности пользователя в течение заданного количества дней. Baseline-мониторинг предлагается вести для метрики Input/Output bandwidth Utilization (см. рис. 1).

Рис. 1. Мониторинг Baseline

Этот метод,как и RPING,также не лишен недостатка ложного срабатывания политик.Любые проблемы «последней мили» и с CPE заказчика будут приводить к обнулению счетчиков трафика.

Установка измерителей у клиента связана с материальными затратами и дополнительными обязательствами оператора. Это решение выгодно использовать в составе пакета услуг managed CPE. Услуга «управляемый CPE» наиболее актуальна для клиентов, потребляющих значительные объемы трафика. Оператор «последней мили» не имеет средств мониторинга качества SLA и/или не предоставляет соответствующей статистики.В этом случае cред-ством для сквозного мониторинга качества является установка программного или аппаратного пробника на стороне абонента.

Контроль качества VPN-услуг

Заказчик,купивший услугу VPN,получает доступ к отчетам по ключевым индикаторам качества/ производительности магистрали и индикаторам производительности своего подключения (Service Access Point – SAP).KPI/KQIподсистемы тестирования предоставляются только для точек подключения сервиса в зоне ответственности ММТС-Поволжье.Если VPN проходит через несколько провайдеров,предоставле- ние этого параметра зависит от наличия партнерского SLA.В KQIпо магистрали будут входить следующие показатели из подсистемы тестирования для SAPза-казчика:

• -    доступность магистрали (SА%)между SAP;

• -    экспертная оценкакачества (MOS)передачи голосового трафика между SAP;

• -    процент потери пакетов (IPPacket Loss Ratio – IPLR) на магистрали между SAP;

• -    задержка (IPPacket Transfer Delay – IPTD)на магистрали между SAP;

• -    вариация задержки (IPPacket Delay Variation– IPDV)между SAP.

Контроль качества доступа в Internet

Предполагается,что услуга Internet будет предо-ставлятьсявнутри VPN.ПользователюуслугиInternet предлагается предоставить параметры производительности магистрали для класса Standart между SAP и всеми точками присутствия Internet-VPN(тестер на PE в точке подключения сервиса – тестеры на остальных PE-Internet),включая точки обмена Internet-трафика с операторами-партнерами.

Например,при топологии сети,показанной на рис.2,заказчик «Субпровайдер X» получает результаты тестов QoS на магистрали для трех точек присутствия VPN-Internet:субпровайдер Y,оператор-партнер А и оператор-партнер Б.

Контроль качества услуги VPN с управляемым CPE

Услуга подразумевает увеличение зоны ответственности оператора до абонентского устройства заказчика и наличие у заказчика подсистемы тестирования (аппаратного тестера в каждой точке присутствия VPN).Все проблемы,связанные с «последней милей»,оператор решает самостоятельно.Собран-ные данные по метрикам обрабатываются на сервере управления SLA провайдера.

Субпровайдер Y

Рис. 2. Пример топологии сети

От набора тестов будет зависеть стоимость обслуживания подсистемы тестирования заказчика.Паке-ты тестов могут быть следующими:

• -    тестирование всех точек SAPна соответствие SLA (сбор, обработка и отчетность статистики по метрикам QoS происходит аналогично подсистеме тестирования на магистрали); предлагается, так

же, как и на магистрали, использовать активные RTP-тесты;

• -    тестированияInternet-сервисовзаказчика(DNS, HTTP,SMTP,POPи прочее);

• -    тестирование видеосервисов (для провайдеров IPTV и заказчиков,широко использующих ВКС).

Сквозной SLA

Рис. 3. Тест качества сквозного SLA

Помимо отчетов,получаемых при пользовании стандартной услугой VPN, заказчику будут доступны следующие KPI/KQI:

• -    доступность услуг (SА%) между SAP;

• -    экспертная оценка качества (MOS)передачи голосового трафика между SAP;

• -    процент потери пакетов (IPPacket Loss Ratio – IPLR)между SAP;

• -    задержка(IPPacket Transfer Delay –IPTD)меж-ду SAP;

• -    вариация задержки (IPPacket Delay Variation – IPDV) между SAP;

• -    производительность арендуемого канала (Throughput).Тестирование производительности услуги производится только на этапе активации и в случае жалоб клиентов на качество «последних миль».

Для целей быстрого нахождения проблемного участка, ведущего к деградации сервиса, предлагается также внедрить механизм запуска автоматического тестирования качества «последних миль» (SLA «последних миль») при обнаружении нарушения сквозного SLA (см. рис. 3).

Определение метрик, собираемых с ресурсов (KPI)

Для каждой точки подключения VPNпредостав-ляется отчетность по следующим метрикам:

• -    входящая скорость на интерфейсах Input Rate bps;

• -    исходящая скорость на интерфейсах Output Rate bps;

• -    процент утилизации входящей полосы пропускания на интерфейсе (Inbound BandwidthUtilization %)от доступной по трафик-контракту;

• -    процентутилизацииисходящейполосыпропус-кания на интерфейсе (Outbound Bandwidth Utilization %);

• -    входящий процент ошибок на интерфейсе Inbound Loss %;

• -    исходящий процент ошибок на интерфейсе Outbound Loss %;

• -    входящий процент отбросов пакетов на интерфейсе Inbound Drops %;

• -    исходящий процент отбросов пакетов на интерфейсе Outbound Drops %;

• -    для SAP,находящихся на PE-маршрутизаторах Cisco;

• -    разрешенная скорость по классам обслуживания (Conformed Rate bps);

• -    скорость отброса трафика, превышающего контракт (Violated Rate bps);

• -    процент отбросов пакетов по классам обслуживания вследствие превышения трафик-контракта;

• -    другие параметры (набор метрик зависит от применяемой политики QoS).

Политики клиентского SLA для подсистемы тестирования

Клиентский SLA зависит от производительности сетевой инфраструктуры в конкретном регионе, архитектуры VPN(full-mesh,hub-and-spoke), есть ли транзитные операторы на пути предоставления услуги и других факторов, не позволяющих предоставления единого SLA для всех заказчиков/на-правлений.При этом критичность нарушения SLA на одной из SAPможет быть гораздо выше, чем на других направлениях (например:архитектура VPN hub-n-spoke и нарушение SLA в головном офисе).

При гарантировании провайдером общего SLA не зависимо от количества точек присутствия VPN общее время нарушения SLA для данной точки присутствия VPN будет равно сумме нарушений по всем соседним с ней SAP.

Класс качества RealTime:

^L SAp(Tjplr realtime"*" TlPTD realtime + Tipov realtime "*" TmOS realtime ) < 45 Ш1П , класс качества Premium:

Z SAP (TlPLR premium "*" TlPTD premium) <  45 min , класс качества Standart:

Z SAP (TlPLR standart "*" T[ptd standart ) < 45 min, где TIPLR – общее время нарушения порога по метрике IPLR за месяц для соответствующего класса; TIPTD – общее время нарушения порога по метрике IPTD за месяц для соответствующего класса; TIPDV – общее время нарушения порога по метрике IPDV за месяц для соответствующего класса; TMOS – общее время нарушения порога по метрике MOS за месяц для соответствующего класса.

Общая формула вычисления процента недоступности сервиса VPN в данной точке присутствия будет рассчитываться по формуле:

2 ^T^SOF, SUA% =5АеЦ------ ^SPPuc/ive

*100,

где T_{SAP_active} – время активности SAP, T _i – сумма интервалов всех нарушений SLA по классу сервиса, см. вышеприведенные формулы; SDF _i – фактор деградации сервиса в i -ом промежутке времени.

Ввиду сложности соблюдения SLA при данной схеме расчета предлагается на первом этапе развертывания системы предоставлять независимый SLA для каждого направления (простой сервиса 45 мин. по каждому направлению SAP-SAP). Предполагается также однородность магистрального сегмента с общим SLA для всех точек присутствия и архитектурой VPN – full-mesh.

Суточное время активности сервиса предлагается сделать зависящим от типа клиентов:

• -    для клиентов, работающих преимущественно днем, оно будет с 8:00 до 20:00, TSAP_active будет равен 12 час;

• -    для клиентов, требующих круглосуточное удовлетворение SLA,T_{SAP_active} будет равен 24 час.

При расчете ежемесячной доступности сервисов TSAP_active будет умножаться на количество рабочих дней в месяце для обычных клиентов и на общее количество дней для VIP-клиентов.

Выводы

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