ГОСУДАРСТВЕННЫЙ КОМИТЕТ СВЯЗИ, ИНФОРМАТИЗАЦИИ И ТЕЛЕКОММУНИКАЦИОННЫХ ТЕХНОЛОГИЙ РЕСПУБЛИКИ УЗБЕКИСТАН

ТАШКЕНТСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ                                                                                    

  Кафедра

«Сети и системы передачи данных»

Джураев  Р.Х., Умирзаков Б.М., Сайфуллаев А.А. 

«Качество обслуживания в сетях передачи аудио и видео данных»

ЭЛЕКТРОННОЕ УЧЕБНОЕ ПОСОБИЕ

Для бакалавров обучающихся по направлению

5525700-5525500 Телевизионные технологии

Ташкент 2014

ОГЛАВЛЕНИЕ

	Введение...........................................................................................	3
1.	Современное состояние и тенденции развития сетей следующего поколения NGN…………………	4
1.1.	Понятия и основные положения сетей NGN……………………	4
1.2.	Тенденции развития сетей NGN…………………………………	8
1.3.	Архитектура современной модели сети NGN…………………..	11
1.4.	Качество обслуживания в мультисервисных сетях связи……...	16
1.5.	Требования качества обслуживания для передачи голосовых сообщений.....................................................................	17
1.6.	Анализ требований качества обслуживания для передачи данных сети Интернет.....................................................................	19
1.7.	Анализ требований качества обслуживания для передачи видеосообщений..............................................................................	21
1.8.	Требования для трафика интерактивного видео....................................	22
1.9.	Требования для трафика потокового видео..............................................	22
2.	Анализ методов обеспечения качества обслуживания в мультисервисных сетях…………………………………………..	24
2.1.	Международные стандарты QoS, показатели и оценка качества передачи речи в сетях на основе IP……………………	24
2.2.	Объективные методики оценки качества услуг………………...	33
2.7.	Алгоритмы управления очередями пакетов…………………….	42
3.	Анализ механизмов и технологий качества обслуживания……	39
3.1.	Механизмы и технологии Intserv………………………………...	39
3.2.	Механизмы и технологии Diffserv……………………………….	45
3.3.	Механизмы и технологии MPLS…………………………………	50
3.4.	Сравнительный анализ технологий обеспечения качества обслуживания QoS…..……………………………………………	58
4.	Анализ показателей качества услуг и факторов влияющих на качество услуг  IPTV……………………………………………...	64
4.1.	Анализ факторов влияющих на качество услуг IPTV………….	64
4.2.	Качество обслуживания в IPTV………………………………….	66
4.3.	Качество восприятия в IPTV……………………………………..	71
	Список использованной литературы…………………………….	74

ВВЕДЕНИЕ

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

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

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

Анализ документов открытого международного сообщества проектирования (IETF) и рекомендации ITU-Tпоказал, что стандартизированные механизмы носят общий характер и не учитывают особенностей того или иного типа трафика, и тем более нагрузки, возникающей при обеспечении мультимедийных услуг. В последние годы возникла и развивается концепция качества обслуживания (Quality of Service, QoS), применение которой вместе с механизмами и методами обеспечения качества обслуживания в IP-сетях обладает рядом преимуществ. Поэтому для мультисервисной сети задача анализа качества обслуживания, безусловно, является актуальной.

1. СОВРЕМЕННОЕ СОСТОЯНИЕ И ТЕНДЕНЦИИ РАЗВИТИЯ СЕТЕЙ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ NGN

1.1. Понятия и основные положения сетей NGN

В последние 10 лет быстрыми темпами развиваются и получают широкое распространение новые услуги связи, улучшается качество традиционных услуг. При этом для реализации различных услуг требуется соответствующее развитие сетей связи и, в частности, их транспортной инфраструктуры. Мировое телекоммуникационное сообщество пришло к выводу о необходимости создания сетей следующего поколения NGN (Next Generation Networks).

Наряду с этим названием в различных открытых изданиях и технических материалах производителей можно встретить и другие термины, означающие ту же суть: адаптивные сети (Adaptive Networks), мультисервисные сети (Multiservice Networks), интеллектуальные сети (Intelligent Networks) и прочее. Термин NGN чаще всего употребляется в отношении сетей операторов связи, однако ключевой идеей концепции NGN является адаптивность. Производители отрасли в настоящее время активно поддерживают и пропагандируют эту идею, рассматривая ее как качественный скачок в развитии информационных технологий (ИТ) с точки зрения соответствия современным требованиям бизнеса.

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

Однозначного толкования архитектуры и услуг NGN мировое телекоммуникационное сообщество пока не выработало. Так с позиций сетей передачи данных NGN — это сеть Интернет следующего поколения (на базе протокола IPv6). С позиций сетей мобильной связи этому поколению даже присвоен номер 3G. С позиций традиционной телефонии NGN сегодня чаще всего воспринимается как сеть пакетной коммутации под управлением гибкого коммутатора (Softswitch), поддерживающая широкополосный абонентский доступ и мультисервисное обслуживание трафика.

В начале 2004 г. Сектор стандартизации телекоммуникаций Международного союза электросвязи (ITU-T, МСЭ-Т) дал следующее определение сети NGN: «NGN — это, прежде всего, сети с коммутацией пакетов, в которых функции коммутации отделены от функции предоставления услуг, они позволяют предоставлять широкий перечень услуг и добавлять новые по мере их разработки. Также сеть NGN обеспечивает широкополосный доступ и поддерживает механизмы качества обслуживания QoS».

ITU-T так определяет основные характеристики NGN:

· сеть на базе коммутации пакетов, которая имеет разделенные функции управления и переноса информации, в которой функции услуг и приложений отделены от функций сети;

· сеть компонентного построения, где связь между компонентами осуществляется по открытым интерфейсам;

· сеть, поддерживающая широкий спектр услуг, включая услуги в реальном времени и услуги доставки информации (типа электронной почты), в том числе мультимедийные услуги; существует возможность широкополосной сквозной передачи данных в режиме «точка-точка»;

· сеть, обеспечивающая взаимодействие с традиционными сетями связи;

· сеть, обладающая общей мобильностью, т.е. позволяющая отдельному абоненту пользоваться и управлять услугами независимо от технологии доступа и типа используемого терминала и предоставляющая абоненту возможность свободного выбора провайдера услуг.

Интуитивное определение NGN было сформулировано: «Сеть связи следующего поколения (NGN) — концепция построения сетей связи, обеспечивающих предоставление неограниченного набора услуг с гибкими возможностями по их управлению, персонализации и созданию новых услуг за счет унификации сетевых решений, предполагающая реализацию универсальной транспортной сети с распределенной коммутацией, вынесение функций предоставления услуг в оконечные сетевые узлы и интеграцию с традиционными сетями связи».

Сеть следующего поколения принципиально отличается от традиционной сети оператора связи, основная задача которого состоит в продаже каналов связи. В перечень услуг оператора связи следующего поколения входит предоставление более интеллектуального сервиса (передача голосовых сообщений по IP-сетям (VoIP), аренда приложений, хостинг и т.д.). К особенностям сетей NGN относятся:

· поддержка и предоставление широкого спектра услуг и приложений нового типа (на верхних уровнях модели OSI);

· наличие клиентской (пользовательской) и серверной части, а также управление всеми ресурсами, включая клиентские;

· поддержка  мультимедийных  услуг,   которые  требуют  наличия   мультисервисной транспортной среды;

· поддержка разнообразных протоколов и многосвязное взаимодействие (в отличие от наиболее распространенного сейчас взаимодействия «точка-точка»);

· возможность использования сложной многоуровневой адресации;

· выполнение требований к мобильности и гарантиям качества услуг;

· передача на базе пакетной коммутации;

· поддержка многочисленных технологий «последней мили»;

· мобильность;

· неограниченный доступ пользователей к провайдерам различных услуг;

· широкополосные возможности с качеством обслуживания (QoS) «из конца в конец» и прозрачность;

· межсетевое взаимодействие с традиционными сетями через открытые интерфейсы;

· многообразие схем идентификации пользователей, которые могут быть обеспечены при помощи IP-адресации при маршрутизации в IP-сетях;

· конвергенция услуг мобильных и фиксированных сетей связи;

· независимость функциональности при предоставлении услуг от транспортной технологии;

NGN характеризуется, с одной стороны, как практическая реализация концепций Глобальной информационной инфраструктуры, которая в свою очередь является основой Глобального информационного общества (GIS) — общества XXI века. С другой стороны, NGN должна узаконить те изменения в телекоммуникационных сетях, которые произошли или начали осуществляться в последнее время, а также уравновесить права конкурирующих участников рынка связи, создать условия для добросовестной конкуренции.

Главным принципом NGN является конвергенция всех сфер в единую информационную сеть с благоприятными возможностями для передачи мультимедийной информации. NGN предусматривает огромный набор услуг, предоставляемых пользователям. Каждый пользователь должен будет обладать персонифицированным номером/именем независимо от используемых технологий доступа в любом удобном для него месте и в любое время. Он должен иметь возможность соединиться с определенным другим номером/именем или оконечным оборудованием, или приложением (в том числе для управления информацией), пользоваться мультимедийными приложениями в реальном времени с соблюдением гарантированного качества обслуживания «из конца в конец». Пользователю должна быть предоставлена неограниченная мобильность без прерывания сеансов в движении и переходе от одной технологии доступа к другой. Провозглашенный в NGN набор услуг весьма сложен с точки зрения технического и программного обеспечения. Постулируется, что протоколы IP будут основными в единой конвергированной сети, используемыми для предоставления служб NGN конечным пользователям, а также для поддержки традиционных служб. Предусматривается превалирование пакетного режима известных и уже действующих в настоящее время протоколов: для поддержания технологии VoIP — стек Н.323, для установления, модификации вызовов и завершения мультимедийных сессий — SIP, для установления виртуальных путей по меткам — MPLS, для обеспечения классов гарантированного обслуживания RSVP-TE и CR-LDP. Предполагается, что в NGN будет применяться открытое программирование. Упрощенно это означает, что программное обеспечение (ПО) оборудования не будет являться «ноу-хау» фирм производителей, а будет выполняться на традиционных общеизвестных языках или же будут реализованы программы-трансляторы с известных языков, что уменьшит зависимость операторов от поставщиков оборудования.

Операторы смогут на существующем оборудовании путем программирования получать дополнительные услуги, в том числе сейчас еще неизвестные. Для создания открытого ПО клиенты смогут применять уже известные интерфейсы прикладного программирования (Application Programming Interfaces — API), а также использовать приемы технологии Parlay.

Взаимодействие разных сетей предлагается реализовать с помощью медиашлюзов (Media Gateway — МО) и контроллеров медиашлюзов (Media Gateway Controller — MGC), которые получили также другое название — Softswitch. Медиашлюз рассматривается как набор конечных точек, которые можно соединять друг с другом. Контроллеры управляют медиашлюзами при помощи уже известных протоколов MGCP (MG Control Protocol) или более совершенных Megaco/H.248.

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

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

1.2. Тенденции развития сетей NGN

На сегодняшний день развитие сетей и услуг следующего поколения осуществляется с учетом принципов  Глобальной Информационной Инфраструктуры (ГИИ), которая должна обеспечить возможность не дискриминированного доступа к информационным ресурсам каждого пользователя, независимо от того, где он находится («услуга в любом месте») и когда запрашивает услугу («услуга в любое время»); при этом ГИИ будет служить технологической основой информационного общества, формируемого на основе информационной инфраструктуры, представляющей собой совокупность баз данных, средств обработки информации, взаимодействующих сетей связи и терминалов пользователя.

К основным тенденциям современного рынка телекоммуникационных услуг можно отнести:

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

2. Кардинальное изменение сетевых архитектур, отказ от жесткой иерархии, характерной для «классических» телефонных и телеграфных сетей, под воздействием внедрения новых средств связи, принципов передачи и обработки информации, влияния бизнес-среды. Даже в традиционных сетях внедряется гибкая маршрутизация, происходит отказ от жестко установленных путей прохождения трафика. Маршрутизация в современных условиях определяется не формальными правилами, характерными для сетей предыдущих поколений с жесткой логикой функционирования, а требованиями клиента и экономическими соображениями оператора связи. Существенные запасы производительности и пропускной способности позволяют обеспечить высокое качество обслуживания в условиях гибкой маршрутизации.

3. Современные сети связи имеют функционально разделенные уровни транспортной коммутируемой сети и формирования услуг. Логика услуги оказывается вынесенной над сетью связи. Такое разделение, возникшее при появлении концепции интеллектуальной сети, стало доминирующим в сети Интернет и закреплено в архитектуре NGN. Соответственно, для создания и оказания современных услуг на базе телекоммуникационных сетей поставщику услуг совсем не обязательно иметь собственную транспортную телекоммуникационную сеть. Все большую силу набирает направление контент-услуг, которые чаще всего не являются услугами связи в традиционном их понимании. В то же время наличие у оператора сетевой инфраструктуры не гарантирует ему удовлетворение всех потребностей взыскательного пользователя, запросы которого значительно превосходят возможности обычных сетевых устройств. При этом технологически стирается грань между службами, действительно направленными на передачу информации (например, электронная почта), и службами, не имеющими к электросвязи никакого отношения, кроме того, что для доставки информации используется сеть передачи данных (например, поиск информации в www). К тому же разнородные службы интегрируются в едином портале и становятся одновременно доступными в течение одного сеанса связи.

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

5. Кардинальные изменения в бизнес-модели оператора новых услуг. Прежде единая бизнес-модель оказания услуг связи, включающая создание оператором сети связи, ее эксплуатацию и оказание на ее базе услуг пользователям, под воздействием технического прогресса и конкуренции постепенно разделяется на две: инфраструктурную — создание и обслуживание телекоммуникационных сетей (включая сети доступа), а также оптовая реализация ресурсов и услуг этих сетей сервис-провайдерам, и сервисную — обеспечение комплексными телекоммуникационными и информационными услугами потребителей (розница) на базе закупаемых на оптовом рынке услуг связной инфраструктуры. Соответственно, все большую значимость для успеха бизнеса приобретает маркетинговая составляющая, рассматривающая услугу не как продукт сети связи, а как объект продажи. Бизнес-модели оператора сети связи и сервис-провайдера услуг связи принципиально различны.

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

7. Изменение статуса инфокоммуникационных услуг. Услуга связи как таковая перестает быть существенной ценностью для пользователя, становясь привычным атрибутом жизни, способом получить доступ ко всему разнообразию контентных информационных услуг.
Например, при доступе в Интернет потребительскую ценность имеют отнюдь не сети связи, образующие российский или глобальный Интернет. Для клиента важны прежде всего сервисы, доступ к которым он получает посредством телекоммуникационной составляющей «сети сетей»: электронная почта, веб, чаты, игры, торговые площадки, поисковые и файлообменные системы и др. И если параметры этого доступа потребителя удовлетворяют, он сосредоточивается на той информации, которую хочет найти в Интернете или обменяться ею с кем-то, не задумываясь о том, что он пользуется передачей данных.

8. Уменьшение роли голосовых услуг. В современных мультисервисных сетях связи голосовые услуги — всего лишь одно из множества приложений, работающих на базе общей транспортной пакетной сети. Это приложение не доминирует ни по объему трафика, ни по доходам. Магистральные волоконно-оптические сети в мире заняты в основном интернет-трафиком, под который выделено уже более 80% задействованной пропускной способности. В современных пакетах услуг Triple Play (голос, видео, данные) доля голосовых услуг, уже, как правило, не зависящая от реально генерируемого трафика и использующая неограниченную схему тарификации (unlimited), в стоимостном выражении обычно не превышает 30%.

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

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

1.3. Архитектура современной модели сети NGN

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

Разработкой новой сетевой архитектуры NGN занимаются несколько организаций (ITU-T, ETSI, International Packet Communications Consortium — IPCC, Multiservice Switching Forum — MSF и др.). Во всех версиях эталонной архитектуры NGN присутствует некоторый элемент управления, который может называться гибким коммутатором (Softswitch), узлом (сервером) управления обслуживанием вызовов, телефонным сервером, Call-агентом или контроллером медиашлюзов MGC.

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

Плоскостная архитектура — краеугольный камень NGN, она позволит повысить эффективность операторской деятельности и предоставить открытые интерфейсы сторонним разработчикам. Но оператору открыть интерфейс к сторонним разработчикам будет непросто технологически, хотя Интернет показывает пример работы в открытой среде.

Рекомендация МСЭ-Т Y.2011 «Базовая архитектура сетей следующего поколения NGN» включает 4 основных функциональных уровня (Рисунок 1.1):

· уровень доступа A (Access) обеспечивает доступ пользователям к ресурсам сети; 

· уровень транспорта Т (Transport) представляет собой основной ресурс сети, обеспечивающий передачу информации от пользователя к пользователю;

· уровень управления С (Control) представляет собой новую концепцию коммутации, основанную на применении технологии компьютерной телефонии и Softswitch;

· уровень услуг S (Service) определяет состав информационного наполнения сети. Здесь находится полезная нагрузка сети в виде услуг по доступу пользователей к информации.

Рис. 1.1. Архитектура современной сети NGN

В модели NGN нашли отражение современные тенденции развития систем связи. В дополнение к уровням транспортной сети и сетей доступа в модели NGN добавлены еще два уровня.

Уровень управления, или, по-другому, уровень коммутации, появился в связи с развитием концепции выделенных систем сигнализации. Эта концепция восходит к системе ОКС №7, в которой впервые в истории развития систем связи предусматривалось разделение речевого и сигнального трафиков. Дальнейшее развитие этой концепции пошло в направлении компьютерной телефонии, которая предусматривала не только создание отдельной выделенной сети сигнализации, но и преобразование сигнальных сообщений выделенными устройствами на основе компьютеров. Недорогие устройства преобразования сигнализации, построенные на основе открытых интерфейсов, могли создаваться относительно небольшими коллективами разработчиков. Это привело к либерализации рынка устройств коммутации и позволило операторам существенно увеличить объем услуг связи. В конце концов развитие компьютерной телефонии привело к концепции Softswitch, а затем к концепции объединения на уровне управления мобильных и проводных сетей — концепции IMS. Ценность уровня коммутации настолько существенна для концепции NGN в целом, что часто под сетями NGN понимаются исключительно технологии Softswitch и IMS, что не совсем справедливо. Обычно такого рода понимание технологии NGN свойственно специалистам в области протоколов сигнализации и систем коммутации. Для них революция NGN сводится по сути к системам Softswitch и IMS. Мы же будем исходить из более широкого понимания концепции NGN на всех четырех уровнях.  Тем более важно в обобщенном понимании NGN вынести проблемы коммутации на отдельный уровень.

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

Следует указать на инженерно-технические ограничения предлагаемой четырехуровневой модели. Для этого еще раз задумаемся над вопросом, зачем вообще создается сеть NGN. Этот вопрос имеет однозначный ответ — для организации доступа пользователям (населению) к информационным ресурсам. Поэтому на рисунке (Рис. 1.1) под моделью SCTA снизу показаны пользователи, а сверху -  информационные ресурсы, доступ к которым им необходим. В таком случае сразу становится понятен механизм работы систем NGN. Вначале пользователь получает канал доступа и выходит в транспортную сеть. Транспортная сеть обеспечивает передачу трафика пользователя и трафика от информационного ресурса. Уровень коммутации позволяет пользователю установить канал взаимодействия между терминалом и ресурсом, а уровень услуг обеспечивает сквозную поддержку соответствующего качества. Другими словами, легко указать «стандартный путь» пользователя для получения услуги «снизу вверх». По вместе с тем можно анализировать связи уровня доступа А с уровнем услуг S, а также связи между уровнями S и Т. между С и А и т.д., обнаружив взаимопроникновение (конвергенцию) уровней модели. Поэтому эта модель скорее не технологическая, а представляет собой удобную классификацию задач NGN и соответствующих им решений.

Фактически в настоящее время существуют два основных подхода к построению сетей NGN:

■  решение на базе гибкого коммутатора (Softswitch);

■  решение на базе мультимедийной IP-подсистемы (IMS).

Эти решения имеют свои достоинства и недостатки. Одной из сильных сторон подхода на базе гибкого коммутатора в настоящее время является его распространенность: в мире существует множество сетей, прошедших по этому пути развития, уже накоплен обширный опытный материал по внедрению softswitch-архитектур. Большое количество поддерживаемых технологий дает возможность оператору подобрать оборудование, наиболее отвечающее его требованиям и позволяющее оптимальным образом взаимодействовать с уже имеющимися сетевыми ресурсами. Softswitch-решения относительно легко масштабировать, начиная с простейшей архитектуры, обслуживающей корпоративный сектор, и заканчивая крупномасштабными проектами межрегионального оператора.

Таким образом, оператор может минимизировать первоначальные вложения в сеть NGN. Эта же особенность позволяет оператору, создающему крупномасштабный проект, использовать новые сетевые ресурсы (и, следовательно, получать прибыль) сразу по мере их установки. Если обобщать перечисленные преимущества, то их можно охарактеризовать одним словом — гибкость, подразумевая под ней адаптацию к любым запросам оператора.

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

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

Подход на базе подсистемы IMS выгодно отличается наличием стандартов, которые дают возможность иметь единообразные и потому способные эффективно взаимодействовать сети. При этом частично сглаживаются проблемы совместимости оборудования, поскольку взаимодействие функциональных модулей регулируется стандартами. Новый подход к предоставлению услуг оказался чрезвычайно удачным и обеспечил роуминг услуг, что должно принести дополнительную прибыль оператору. Использование в проводных сетях NGN и мобильных сетях 3G единообразной системы IMS позволяет видеть в перспективе возможности конвергенции фиксированных и мобильных сетей — идеи, набирающей популярность по всему миру.

Проблемы, которые возникнут при применении подхода IMS, пока не так просто сформулировать, ведь нет достаточного опыта реализации, однако вряд ли стоит надеяться на их отсутствие.

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

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

 
 
 
 
 
 
 
1.4.  Качество обслуживания в мультисервисных сетях связи
 

         Комплексную характеристику степени удовлетворения пользователя предоставляемыми услугами определяют параметры качества обслуживания.          Фактически качество обслуживания (услуги) - это показатель степени удовлетворения потребителей, и поэтому очень важно постоянно контролировать качество обслуживания (услуги) и в особенности рабочие характеристики сети. Качество обслуживания характеризуется совокупностью аспектов обеспеченности вспомогательными услугами, действенности услуги, полноты услуги и других факторов, характерных для данного типа услуги.

         Общие рамки концепции качества обслуживания вместе с терминами и определениями, относящимися к качеству служб электросвязи, изложены в МСЭ-Т E.800 "Термины и определения, относящиеся к качеству обслуживания и функционированию сети, включая надежность". Аспекты обслуживания освещаются в рекомендациях МСЭ-Т серии F.
         Каждый вид услуги обладает определенной совокупностью свойств и характеристик, определяющих степень удовлетворения потребностей потребителя. Предоставляемые услуги должны соответствовать по качеству информации о ней.

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

• Действенность - свойство обслуживания быть предоставленным тогда, когда это необходимо потребителю, и продолжаться без чрезмерного ухудшения в течение требуемого времени (в пределах
  определенных допусков и в заданных условиях).

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

¾ доступность - свойство обслуживания быть предоставленным тогда, когда это необходимо пользователю;

¾ непрерывность - свойство обслуживания, будучи предоставленным продолжаться в течение требуемого времени;

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

• Удобство использования - свойство обслуживания, характеризующее, насколько успешно и легко потребитель может его использовать.
• Обеспеченность - способность предприятия связи предоставлять обслуживание (набор услуг) и помогать потребителю использовать его.
• Безопасность - свойство обслуживания быть защищенным от несанкционированного доступа, злонамеренного и неправильного использования, преднамеренной порчи, человеческих ошибок и стихийных бедствий.

Основные характеристики для QoS определяются следующим образом [ПО]:

- задержка доставки пакета. Этот параметр играет роль в основном при передаче голосовых и видео-сообщений;

- джиттер (разброс) - изменения в задержках при доставке пакета. Джиттер можно мерить несколькими методами. Подсчет джиттера определен в следующих рекомендациях:

• IETF RFC 3550 RTP: A Transport Protocol for Real-Time Applications;

• IETF RFC 3611 RTP Control Protocol Extended Reports (RTCP XR);

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

1.5. Требования качества обслуживания для передачи

голосовых сообщений

Требования QoS для передачи голосовых сообщений более мягкие, чем требования для передачи видеосообщений.

Анализ рекомендаций МСЭ-Т и IETF (Internet Engineering Task Force -открытое международное сообщество проектировщиков) позволяет обобщить требования  к  характеристикам  QoS  при  реализации  передачи голосовых сообщений.

1. Голосовой трафик должен быть промаркирован как DSCP EF, в соответствии с RFC 3246.

2. Сигнализация должна быть промаркирована как CS3 (во время миграции можно использовать AF31).

3. Потери пакетов в магистралях, спроектированных для предоставления VoIP сервиса высокого качества не должны превышать 0,25 процентов.

4. Односторонняя задержка не должна превышать 150 мс, в соответствии смсэ-тап4.

5. Колебания задержки (джиттер) должны быть менее 10 мс. Максимальный джиттер должен быть менее чем бюджет по задержке в сети минус минимальная сетевая задержка. Это типовое значение колебания задержки для VoIP обусловлено бюджетом по задержке, так называемым «mouth-to-ear», в 100 мс. Это достаточно консервативный бюджет по сравнению с G.114, в котором рекомендуется джиттер менее 150 мс. Из этого значения мы вычитаем время распространения по магистрали (30 мс) и задержку кодека (35 мс), что дает нам бюджет для джиггера 35 мс. Эти 35 мс разбиваются на 30 мс на доступе (15 мс вход/выход) и 5 мс на магистрали. То есть в худшем варианте, для адаптивных джиттер-буферов, колебания задержки должны быть менее 10 мс.

6. Для каждого разговора (в зависимости от частоты квантования, кодека и заголовка второго уровня) требуется 21-106 Кбит/с гарантированной приоритетной полосы пропускания.

7. Для трафика сигнализации требуется 150 бит/с (плюс заголовок второго уровня) гарантированной полосы пропускания.

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

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

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

Комбинированные (гибридные) кодеки сочетают в себе технологию вокодерного преобразования/синтеза речи, но оперируют уже с цифровым сигналом посредством специализированных DSP. Кодеки этого типа содержат в себе ИКМ или АДИКМ кодек и реализованный цифровым способом вокодер.

На рис. 1.2 представлена усредненная оценка качества кодирования речи для выше перечисленных типов кодеков.

Рис. 1.2. Усредненная оценка качества кодирования речи

В   таблице   1.1 приведены  данные  об  оценке  качества  голоса  при использовании различных кодеков (в идеальных условиях).

С учётом нормативных документов, где рекомендуется с целью обеспечения приемлемого качества сообщения и минимальных задержек при кодировании декодировании в оборудовании СГС (служба голосовых сообщений) должен использоваться метод адаптивной дифференциальной импульсно-кодовой модуляции АДИКМ со скоростью 32 Кбит/с. Данный метод кодирования должен считаться основным.

Таблица 1.1

Оценка качества голоса при использовании различных кодеков (в идеальных условиях)

Голосовой кодек	Скорость, Кбит/c	MOS – оценка
G.711	64	4.10
G.726	32	3.85
G.728	16	3.61
G.729	8	3.92
G.729a	8	3.70
G.729.1	6.3	3.9

Большинство    кодеков,    используемых    в    IP-телефонии,    описаны рекомендациями семейства «G» стандарта Н.323 (таблица 1.2).

Таблица 1.2. Характеристики кодеков семейства Н.323

Кодек	Тип кодека	Скорость кодирования	Задержка при кодировании
G.711	икм	64 Кбит/с	0,75 мс
G.726	АДИКМ	32 Кбит/с	1 мс
G.728	LD-CELP	16 Кбит/с	От 3 до 5 мс
G.729	CS-ACELP	8 Кбит/с	10 мc
G.726a	CS-ACELP	8 Кбит/с	10 мc
G.723.1	MP-MLQ	6,3 Кбит/с	30 мс
G.723.1	ACELP	5,3 Кбит/с	30 мс

1.6. Анализ требований качества обслуживания для передачи данных сети Интернет

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

Для выполнения требований по качеству обслуживания передачи данных сети Интернет необходимо :

• учитывать требования программного обеспечения к сети;

• выполнить планирование загрузки производственных мощностей, чтобы быть уверенным в адекватности основной пропускной способности;

• использовать не более четырех основных раздельных класса трафика:

- локально-определенный критический класс (для критически важных приложений) - транзакционные и интерактивные приложения с высоким бизнес-приоритетом;

- транзакционный/интерактивный класс - приложения клиент-сервис, приложения по передаче сообщений;

- класс объемный (Bulk) - передача больших файлов, синхронизация и репликация баз данных, электронная почта   (e-mail);

- класс по возможности (Best Effort) - класс по умолчанию для всего не назначенного трафика;

•   минимизировать      число      приложений      использующих      классы
транзакционный/ интерактивный и Объемные приложения.

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

Транзакционный/Интерактивный класс - это комбинация двух схожих типов приложений: транзакционных приложений клиент-сервер и приложений интерактивных сообщений. Требования по времени отклика отличают транзакционные от обычных клиент-серверных приложений.

Класс данных объемный (Bulk) - предназначен для не интерактивных приложений не критичных к потерям пакетов, обычно работающих в фоновом режиме. Такие приложения включают: FTP, синхронизация и репликация баз данных, распространение видеосодержания или другие типы приложений, в которых пользователь не вынужден ждать результатов выполнения операций. Преимущество выделения полосы пропускания для объемного класса трафика (вместо накладывания на них ограничений) заключается в том, что приложения могут динамически использовать свободную полосу пропускания и, таким образом, повышать свою производительность в спокойные периоды времени, что, в свою очередь, снижает вероятность влияния на них перегрузок.

Класс по возможности (Best Effort) - это класс по умолчанию для всего трафика данных сети Интернет. Только в том случае, если приложение было отобрано для особенной обработки, оно будет удалено из класса по умолчанию. Так как многие корпоративные клиенты используют сотни, если не тысячи, приложений данных в своих сетях (большинство из которых и останется в этом классе) требуется выделить адекватную полосу пропускания для класса по умолчанию. В противном случае, приложения, которые попали в этот класс, будут подавлены. Рекомендуется выделять, по крайней мере, 25 процентов полосы пропускания для поддержки класса трафика по возможности.

1.7. Анализ требований качества обслуживания для передачи

видеосообщений

Интеграция вещания телевидения и ассоциирующих с ним сервисы в мультисервисные сети приводят к ряду проблем для сервис провайдеров. Видео (в частности, видео по запросу), вещание многоканального телевидения и HDTV требует больше ресурсов сети, чем голос и данные.

Видео имеет более разнообразные требования QoS, чем данные. Даже самые востребованные приложения передачи данных сети Интернет могут справиться при наличии задержек (джиттеров) и с каким-то процентом потери пакетов. Однако, видео поверх IP (ATM) имеет четкое требование для минимальных потерь пакетов, в диапазоне 10~⁹, которое в практике означает, что пакеты могут быть отброшены только в результате ошибочных битов и перегрузки сети. Существуют два основных типа приложений видео: интерактивное видео (например, видеоконференции) и потоковое видео (например, IP/TV, которое может использовать как одно, так и многоадресную рассылку). 

На основании проведенного анализа рекомендаций МСЭ-Т и IETF обобщим основные требования к характеристикам QoS при реализации передачи видеосообщений. В таблице 1.3 приведены требования к скоростям при разных стандартах передачи видеосообщений.

Таблица 1.3 - Требования к скоростям при разных стандартах передачи видеосообщений

Качество	Метод или стандарт	Скорость передачи, Мбит/с	Компрессия
Качество видеоконференции	H.261	0.1	Да
VCR качество	MPEG-1	1.2	Да
Качество телепередач	MPEG-2	2 до 4	Да
Качество цифрового телевидения
Без компрессии	ITU-R601	166
С компрессией	MPEG-2	3 до 6	Да
С компрессией	H.264/MPEG-4	2 до 4	Да
HDTV
Без компрессии	CD-DA	2000
С компрессией	MPEG-2	25-34	Да
С компрессией	H.264/MPEG-4	15-30	Да

(1) планируется; текущая скорость передачи от 4 до 7 Мбит/с

(2) планируется; текущая скорость передачи от 6 до 10 Мбит/с

1.8. Требования для трафика интерактивного видео

При настройке интерактивного видео (видеоконференций) рекомендуется следующее:

- интерактивный видеотрафик должен быть промаркирован AF41;

- потери должны быть не более 1 %;

- однонаправленная задержка должна быть не более 150 мс;

- колебания задержки должны быть не более 30 мс;

- минимально гарантированная полоса пропускания (LLQ) должна быть равна размеру сессии видеоконференции плюс 20 процентов. (Например, сессия видеоконференции в 384 Кбит/с требует настройки 460 Кбит/с полосы трафика гарантированного приоритета).

Так как видеоконференция включает аудио кодек G.711 для речи, то у нее и соответствующие голосовому трафику требования к потерям, задержке и колебаниям задержки. Однако трафик видеоконференции радикально отличается от трафика голоса. Например, трафик видеоконференций использует переменные размеры пакетов и переменные скорости передачи пакетов. Скорость видеоконференции - это скорость кадрирования видеопотока, но не реальная полоса пропускания, которую требует видеовызов. IP, UDP и RTP заголовки (40 байт на пакет) должны быть дополнительно включены в требования по полосе пропускания (также как и заголовки второго уровня).

1.9. Требования для трафика потокового видео

При настройке потокового видео рекомендуется следующее:

- потоковое видео (одноадресной или многоадресной рассылки) должно быть промаркировано CS4;

- потери должны быть менее 2%;

- задержка должна быть менее 4-5 секунд (в зависимости от возможностей буферизации видеоприложений);

- не существует значительных требований по колебанию задержки;

- требования по гарантиям полосы (CBWFQ) зависят от формата кодирования скорости видеопотока;

- потоковое видео обычно однонаправленное и, поэтому, в удаленных филиалах маршрутизаторы можно не настраивать на поддержку потокового видео в направлении от филиала к центру;

- не важные приложения потокового видео, такие как видео для развлечения, могут быть промаркированы DSCP CS1 и для них требуется минимум гарантий полосы пропускания в очереди CBWFQ (используя класс интернет/scavenger).

Анализ требований к характеристикам качества обслуживания отдельных типов сообщений показал, что при построении мультисервиснои сети доступа для услуг Triple Play необходимо обеспечить следующие требования:

- по рекомендации МСЭ-Т G.114 максимальная задержка не должна превышать 150 мс;

- для качественной передачи голосовых и видео-сообщений рекомендуется, чтобы джиттер не превышал 50 мс (желательно < 30 мс);

- для передачи голосовых и видео данных потеря пакетов не должна превышать 1%, а для передачи данных потеря пакетов должна компенсироваться использованием буферов.

Также из анализа требований к характеристикам качества обслуживания отдельных типов сообщений и документов рекомендаций МСЭ-Т и ETSI определены для мультисервиснои сети доступа при предоставлении услуг Triple Play, следующие необходимые скорости линии связи:

- минимальная скорость передачи видеопотока ТВ стандарта HDTV при использовании сжатия MPEG-4/H.264 для приемлемого качества доставки услуги должна составлять 15 Мбит/с;

- минимальная скорость передачи для голоса должна составлять 16 Кбит/с;

- минимальная скорость для передачи данных должна составлять 128 Кбит/с.

2. АНАЛИЗ МЕТОДОВ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ОБСЛУЖИВАНИЯ В МУЛЬТИСЕРВИСНЫХ СЕТЯХ

2.1. Международные стандарты QoS, показатели и оценка качества передачи речи в сетях на основе IP

Рекомендация ITU-T Е.800

         «Качество обслуживания (Quality of Service, QoS) рассматривается как "суммарный эффект рабочих характеристик обслуживания, который определяет степень удовлетворенности пользователя этой службой".

         Компоненты QoS:

- наличие в службе базовых и дополнительных услуг;

- удобство пользования услугами;

- качество отдельных параметров связи;

- надежность связи;

- безопасность при передаче информации и т. д.

Рекомендация ITU-T G.1000

         Определяет структуру связей между рабочими характеристиками – производительностью, надежностью, потерями, задержкой и др., и характеристиками сети

         Характеристики качества обслуживания (Y.1540)

• Пропускная способность

•  Надежность/Готовность сети/компонентов

•  Задержка пакетов

•  Вариация задержки пакетов (Джиттер)

• Потери пакетов

         Нормы на сетевые рабочие характеристики для служб на основе протокола IP (Y.1541). Таблица 2.1. 6 классов: 0 -лучший, 5 - худший

4 параметра

Таблица 2.1. Нормы на сетевые рабочие характеристики для

служб на основе протокола IP (Y.1541).

         Рассмотрим качество обслуживания на основе сетей IP-телефонии.

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

Категории и классы качества передачи речи.

         В традиционной телефонии применяется несколько наборов критериев, описывающих качество обслуживания. Мы рассмотрим для иллюстрации одну из классификаций, специально разработанную для оценки качества передачи голоса в IP сетях. Она изложена в документе ETSI TS 102 024 – 2, разработанном в рамках проекта TIHPON (Release 5, сентябрь 2003 г.).

В этом документе определяются три класса качества:

• широкополосный (wideband), обеспечивающий пользователям качество лучшее, чем в ТфОП. Он требует использования широкополосных кодеков (обрабатывающих аналоговые сигналы с полосой более 3,1 кГц) и сетей IP, спроектированных в соответствии с требованиями QoS;
• узкополосный (narrowband), обеспечивающий пользователям качество, подобное ТфОП. Он требует использования спроектированных в соответствии с требованиями QoS сетей IP;
• негарантированный (best effort), предоставляющий пригодные для использования услуги, но без гарантий на характеристики соединения. Могут быть периоды значительного ухудшения качества речи и большие задержки из конца в конец, которые отрицательно влияют на общую диалоговую интерактивность. Этот класс качества обеспечивается в сетях IP, разработанных без учёта требований QoS, например, общедоступного Интернета.

         Широкополосный и узкополосный классы обеспечивают гарантии характеристик для 95% всех соединений.

Таблица 2.2. Значения характеристик классов качества

Классы качества передачи речи в соответствии с подходом ETSI
Характеристика	3 (широкополосный)	2 (узкополосный)			1(best effort) негарантированный
		2-H (высокий)	2-M (средний)	2-A (приемлемый)
Общий рейтинг качества передачи (R)	(В настоящее время находится на этапе изучения в международ-ных организациях стандартиза-ции)	> 80	> 70	> 50	> 50 (ориентир)
Относительное качество речи (одностороннее, неинтерактив-ное)	Лучше, чем G.711	Равно или лучше, чем G.726 при 32 Кбит/с	Равно или лучше, чем GSM-FR	Не определено	Не определено
Результирующий общий рейтинг качества передачи (R)	Не применяется	> 86	> 73	> 50	> 50
Задержка из конца в конец, мс	< 100	< 100	< 150	< 400	< 400 (ориентир)

Узкополосный класс делится на три подкласса:

• высокий (high), обеспечивающий качество, эквивалентное тому, которое предоставляется сетями ISDN;
• средний (medium), обеспечивающий качество, эквивалентное тому, которое предоставляется услугами беспроводной мобильной телефонии в условиях хорошей радиосвязи, например в сетях GSM, использующих кодеки EFR, или системами, использующими кодеки по Рекомендации МСЭ-Т G.726 на скорости 32 Кбит/с;
• приемлемый (acceptable), обеспечивающий качество, эквивалентное тому, которое предоставляется обычными услугами беспроводной мобильной телефонии, например в сетях GSM, использующих кодеки FR, или системами, включающими геостационарные спутники.

Каждый из вышеуказанных классов определяется тремя характеристиками:

• общим рейтингом качества передачи (R);
• качеством речи, воспринимаемым слушателем (качество односторонней неинтерактивной передачи речи из конца в конец);
• задержкой из конца в конец (средней односторонней).

Значения этих характеристик для каждого из классов качества приведены в таблице 2.2.

Таблица 2.3. Кодеки, используемые в IP-телефонии

Влияние оконечного оборудования и сети на показатели качества речи

         Общее качество передачи речи определяется факторами, зависящими как от сети, так и от оконечного оборудования.

Таблица 2.4. Основные параметры, влияющие на качество передачи речи

Основные параметры качества передачи речи и их связь с терминальным оборудованием и/или сетью
Параметр	Связан с
	терминальным оборудованием	сетью
Тип кодека	Да	Нет
Потери пакетов	Нет ^1	Да
Задержка	Да ^2	Да ^3
Вариации задержки	Нет ^4	Да ^5

Основные параметры, влияющие на качество передачи речи из конца в конец, и их отношение к терминальному оборудованию и/или сети приведены в таблице 2.4.

         Примечания.

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

2. Обусловлена кодированием/пакетизацией речи и компенсацией джиттера.

3. Обусловлена маршрутизацией/распространением в сети.

4. Предполагается, что вся вариация задержки включена в задержку в терминале.

5. Вариация задержки вносится сетью, но компенсируются терминалом.

         В соответствии с Рекомендацией МСЭ-Т I.380/Y.1540 основными параметрами, характеризующими качество обслуживания (QoS) в сетях IP, являются:

• задержка переноса пакетов;
• вариация задержки пакетов (джиттер);
• коэффициент потери пакетов;
• коэффициент ошибок по пакетам.

         Последний параметр зависит в основном от используемых на физическом уровне сети систем передачи, и проблем с ним, как правило, не возникает. Механизмы обеспечения QoS в сетях IP направлены на улучшение первых трех из указанных параметров. Именно они и являются основными характеристиками транспортной сети, определяющими качество передачи речи (рис. 2.1). Эти же параметры, как правило, используются и в соглашениях об уровне обслуживания (Service Level Agreement — SLA), предлагаемых ведущими операторами своим клиентам.

Рис. 2.1. Взаимовлияние факторов, определяющих качество передачи речи

Рис.2.2. Показатели качества обслуживания, учитываемые при передачи речевого трафика, и механизмы их формирования

Параметры доставки пакетов IP.

1. Задержка доставки пакета IP (IP packet transfer delay, IPTD) – ITU-T Y.1540

         Параметр IPTD определяется как время (t2 – t1) между двумя событиями – вводом пакета во входную точку сети в момент t1 и выводом пакета из выходной точки сети в момент t2, где

(t2 > t1)

и

(t2 > t1) <= Tmax.

         В общем, параметр IPTD определяется как время доставки пакета между источником и получателем для всех пакетов - как успешно переданных, так и для пакетов, пораженных ошибками.

Рис.2.3. Классификации задержек

Источники задержки

· Пакетизация – зависит от типа трафика

· Распространение сигнала – не зависит от типа трафика

· Транспортировка (обработка в узлах сети) - зависит от типа трафика

· Задержка в приемном буфере - зависит от типа трафика.

2. Вариация задержки пакета IP (IP packet delay variation, IPDV)

         Параметр IPDV, v_k, для IP-пакета с индексом k, определяется между двумя точками сети (входной и выходной) как разность между абсолютной величиной задержки x_k при доставке пакета с индексом k, и определенной эталонной (или опорной) величиной задержки доставки пакета IP, d_1,2, для тех же самых сетевых точек:

v_k = x_k - d_1,2.

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

Рис.2.4. Вариация задержки (джиттер).

3. Коэффициент потери пакетов IP (IP packet loss ratio, IPLR)

Коэффициент IPLR определяется как отношение суммарного числа потерянных пакетов к общему числу принятых пакетов в выбранном наборе переданных и принятых пакетов.

         Потери пакетов в сетях IP возникают в том случае, когда значение задержек при передаче пакетов превышает нормированное значение, определенное выше как Tmax.

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

4. Коэффициент ошибок пакетов IP (IP packet error ratio, IPER)

         Коэффициент IPER определяется как суммарное число пакетов, принятых с ошибками, к сумме успешно принятых пакетов и пакетов, принятых с ошибками.

Рис.2.5. Влияние на задержку пакетов большого размера

Субъективные методики оценки качества услуг

         Наиболее широко используемая  методика субъективной оценки качества  описана в Рекомендации ITU-T P.800  и известна как методика MOS (Mean Opinion Score). В соответствии с методикой MOS качество речи, получаемое при прохождении сигнала от говорящего (источник) через систему связи к слушающему (приемник), оценивается как арифметическое среднее от всех оценок, выставляемых экспертами после прослушивания тестируемого тракта передачи.

         Экспертные оценки определяются в соответствии со следующей пятибалльной шкалой: 5 – отлично, 4 – хорошо, 3 – приемлемо, 2 – плохо, 1 – неприемлемо.

         Оценки 3,5 балла и выше соответствуют стандартному и высокому телефонному качеству, 3,0…3,5 - приемлемому, 2,5…3,0 - синтезированному звуку. Для передачи речи с хорошим качеством целесообразно ориентироваться на значения MOS не ниже 3,5 баллов.

         Естественно, что эта модель не учитывает ряд явлений, типичных для сетей передачи данных и влияющих на качество речи в системах VoIP. В модели MOS отсутствует возможность количественно учесть влияющие на качество речи факторы.

В частности, не учитываются:

• сквозная (end-to-end) задержка между говорящим по телефону и слушающим

• влияние вариации задержки (джиттера)

• влияние потерь пакетов.

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

2.2. Объективные методики оценки качества услуг

ITU-T в 1998 г. стандартизовал Е-модель (Рекомендация G.107), применение объективных оценок качества, базирующихся на измерении физических характеристик терминалов и сетей.

         Е-модель является адекватной для использования в задачах оценки качества речи в пакетных сетях, поскольку учитывает искажения, типичные для передачи данных. После создания Е-модели было проведено большое число испытаний с субъективными оценками, в которых менялся уровень воздействия искажающих сетевых факторов. Данные этих тестов были использованы в Е-модели для вычисления объективных оценок. Результатом вычислений в соответствии с Е-моделью является число, называемое R-фактором. Значения R-фактора однозначно сопоставляются с оценками MOS

Е-модель

         В соответствии с Е-моделью R-фактор определяется в диапазоне значений от 0 до 100, где 100 соответствует самому высокому уровню качества. При расчете R-фактора учитываются 20 параметров. В состав этих параметров входят:

• однонаправленная задержка,

• коэффициент потери пакетов,

• потери данных из-за переполнения буфера джиттера,

• искажения, вносимые при преобразовании аналогового сигнала в цифровой и последующем сжатии (обработка сигнала в кодеках),

• влияние эхо и др.

Значение R определяется по следующей формуле:

R = Ro - ls - ld - le + A,

где

• Ro = 93,2 – исходное значение R-фактора;

• ls - искажения, вносимые кодеками;

• ld - искажения за счет суммарной сквозной задержки в сети;

• le - искажения, вносимые оборудованием, включая и потери пакетов;

• A – так называемый фактор преимущества.

         С учетом искажений, которые имеют место при преобразовании реальной речи в электрический сигнал (и обратно), теоретическое значение R-фактора (без искажений) уменьшается до величины, равной 93,2, которая соответствует оценке MOS, равной 4,4.

         Таким образом, при использовании Е-модели оценка 4,4 в системе MOS является максимально возможной оценкой качества речи в сети без искажений. Величина R-фактора меняется от 0 до 93,2, что соответствует изменению оценок MOS от 1 до 4,4.

Таблица 2.5. Оценка QoS на основе R-фактора и оценок MOS

Значение R-фактора	Категория качества и оценка пользователя	Значение оценки MOS
90<R<100	Самая высокая	4,34 – 4,50
80<R<90	Высокая	4,03 – 4,34
70<R<80	Средняя (часть пользователей оценивает качество как неудовлетворительное)	3,60 – 4,03
60<R<70	Низкая (большинство пользователей оценивает качество как неудовлетворительное)	3,10 – 3,60
50<R<60	Плохая (не рекомендуется)	2,58 – 3,10

Примечание: соединения с R-фактором ниже 50 не рекомендованы для использования.

Рис. 2.6. Зависимость между оценками MOS и R-фактором

Метод PSQM-Perceptual Speech Quality Measurement

Кроме субъективных методов имеется также автоматический метод измерения качества передачи речи, названный PSQM (Perceptual Speech Quality Measurement). Этот метод основан на сравнении эталонного речевого сигнала и сигнала, поступающего из кодека или IP-сети. Метод PSQM может быть использован для сравнительной оценки качества работы различных речевых кодеков или сетей, но он также не позволяет учитывать влияние отдельных параметров IP-сети на качество передачи речи.

Метод ICPIF-Calculated Planning Impairment Factor

Наиболее удобным для оценки качества работы реальных сетей IP-телефонии является метод “рассчитываемого планируемого параметра ухудшения” ICPIF (Calculated Planning Impairment Factor). Основная идея метода состоит в расчете величин различных параметров ухудшения качества передачи речи на каждом участке соединения в сети связи и сложения этих величин для получения общего параметра. Существуют различные факторы ухудшения качества передачи речи в сетях связи (шум, задержка, эхо и т.д.).

         Величина общего параметра ухудшения Itot определяется по формуле:

Itot = Io + Iq + Idte + Idd + Ie,

где Io- параметр ухудшения качества, обусловленный неоптимальным уровнем громкости и/или высоким шумом в канале;

Iq-параметр ухудшения качества, обусловленный шумами квантования в ИКМ;

Idte- параметр ухудшения качества, обусловленный акустическим эхо;

Idd- параметр ухудшения качества, обусловленный передачей речи на большое расстояние (задержки);

Ie- параметр ухудшения качества, обусловленный специальными устройствами, в частности низкочастотными кодеками.

         Для сравнения различных сетей IP-телефонии можно не учитывать параметры Io и Iq, а значение Idte принять равным нулю. Зависимость величины параметра Idd от задержки передачи речевого сигнала в сети приведены в рекомендации G.113.

Таблица 2.6. Зависимость параметра Idd от задержки речевого сигнала в сети

         Параметр Ie используется для оценки качества работы сложных устройств обработки речевых сигналов, например низкочастотных кодеков. В рекомендации G.113 каждый тип кодека характеризуется специфическим параметром Кi для оценки ухудшения качества передачи речи. Когда в соединении IP-телефонии используется несколько различных кодеков, то общая величина параметра ухудшения определяется суммированием индивидуальных значений параметра Кi для каждого кодека.

Таблица 2.7. Величины параметра Ki для некоторых наиболее распространенных кодеков, часть из которых применяется в IP-телефонии

2.3. Алгоритмы управления очередями пакетов

FIFO – элементарная очередь с последовательным прохождением пакетов, работающая по принципу "первым пришел – первым ушел" (first-in first-out – FIFO). По сути, здесь нет никакой приоритезации.

Рис.2.7. Очереди пакетов

Priority Queuing (PQ) обеспечивает безусловный приоритет одних пакетов над другими. Всего 4 очереди: high, medium, normal и low. Обработка ведется последовательно (от high до low), начиная с высокоприоритетной очереди, и до ее полной очистки не переходит к менее приоритетным очередям. Таким образом, возможна монополизация канала высокоприоритетными очередями. Трафик, приоритет которого явно не указан, попадет в очередь по умолчанию (default).

         Custom Queuing (CQ) обеспечивает настраиваемые очереди. Предусматривается управление долей полосы пропускания канала для каждой очереди. Поддерживается 17 очередей. Системная 0 очередь зарезервирована для управляющих высокоприоритетных пакетов (маршрутизация и т.п.) и пользователю недоступна.

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

         Weighted Fair Queuing (WFQ) (взвешенные справедливые очереди) автоматически разбивают трафик на потоки (flows). По умолчанию их число равно 256, но может быть изменено. Если потоков больше, чем очередей, то в одну очередь помещается несколько потоков. Принадлежность пакета к потоку (классификация) определяется на основе ToS, IP-адреса источника, IP-адреса назначения, порта источника и порта назначения (протокол IP). Каждый поток использует отдельную очередь.

Рис.2.8. Управление очередями пакетов

         Обработчик WFQ (scheduler) обеспечивает равномерное (fair – справедливое) разделение полосы между существующими потоками. Для этого доступная полоса делится на число потоков, и каждый получает равную часть. Кроме того, каждый поток получает свой вес (weight), с некоторым коэффициентом обратно пропорциональный IP-приоритету (TOS). Вес потока также учитывается обработчиком.

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

         Weighted Random Early Detection – WRED (взвешенный алгоритм произвольного раннего обнаружения) предоставляет различные уровни обслуживания пакетов в зависимости от вероятности их отбрасывания и обеспечивает избирательную установку параметров механизма RED на основании значения поля IP-приоритета. Другими словами, алгоритм WRED предусматривает возможность более интенсивного отбрасывания пакетов, принадлежащих определенным типам трафика, и менее интенсивного отбрасывания всех остальных пакетов.

         Class Based Weighted Fair Queuing (CBWFQ) соответствует механизму обслуживания очередей на основе классов. Весь трафик разбивается на 64 класса на основании следующих параметров: входной интерфейс, лист доступа (access list), протокол, значение DSCP, метка MPLS QoS.

         Общая пропускная способность выходного интерфейса распределяется по классам. Выделяемую каждому классу полосу пропускания можно определять как в абсолютном значении (bandwidth в kbit/s) или в процентах (bandwidth percent) относительно установленного значения на интерфейсе.

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

         Low Latency Queuing (LLQ) – очередность с низкой задержкой. LLQ можно рассматривать как механизм CBWFQ с приоритетной очередью PQ (LLQ = PQ + CBWFQ).

         PQ в LLQ позволяет обеспечить обслуживание чувствительного к задержке трафика. LLQ рекомендуется в случае наличия голосового (VoIP) трафика. Кроме того, он хорошо работает с видеоконференциями.

3.  АНАЛИЗ МЕХАНИЗМОВ И ТЕХНОЛОГИЙ КАЧЕСТВА ОБСЛУЖИВАНИЯ

3.1.  Механизмы и технологии IntServ

Резервирование ресурсов

         Протокол сигнализации Resource reSerVation Protocol (RSVP) обеспечивает управление резервированием сетевых ресурсов в IP-сети для реализации интегрированных сервисов (Integrated Services, IntServ). Первоначальная его спецификация, разработанная сотрудниками Университета шт. Южная Каролина и компании Xerox, была опубликована консорциумом IETF в 1997 году (RFC 2205). Около трех лет назад появилась обновленная версия RSVP (RFC 2750). Архитектура IntServ впервые описана в 1994 году в документе RFC 1633.

         Протокол RSVP предусматривает два принципиально различных типа сервисов — гарантированный (IntServ Guaranteed) и с контролируемой сетевой нагрузкой (IntServ Controlled). В первом случае речь идет об эмуляции выделенного виртуального канала в IP-сети: потоку гарантируется доступность запрошенной полосы пропускания и одновременно задаются жесткие границы для величины суммарной задержки. Сервис IntServ Guaranteed можно воспринимать как формирование сети коммутации каналов, наложенной на сеть коммутации пакетов. Второй случай аналогичен сервису best effort в условиях незагруженной сети; конкретные диапазоны задержек и других параметров передачи не устанавливаются.

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

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

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

         RSVP не определяет содержание спецификации потока, он просто передает запрос. Спецификация потока включает обычно класс услуг, Rspec (R означает резерв) и Tspec (Т означает трафик). Два других параметра представляют собой набор чисел. Параметр Rspec определяет требуемое качество услуг, а параметр Tspec описывает поток данных. Содержимое Rspec и Tspec прозрачно для RSVP.

Рис.3.1. Протокол RSVP

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

         Собственно резервирование ресурсов инициируется получателем, который после приема сообщения PATH отправляет в обратном направлении (источнику) запрос RESV. Помимо характеристик трафика, полученных от источника, этот запрос содержит спецификации потока (тип сервиса и ряд вспомогательных параметров) и фильтра (транспортный протокол и номер порта). Две последние спецификации играют роль дескриптора потока.

Рис.3.2. Маршрутизация в IntServ

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

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

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

         Выбор режима определяется спецификацией фильтра. Для фиксированного фильтра (Fixed Filter, FF) используется индивидуальное резервирование: каждому отправителю соответствует отдельный запрос RESV, а общая емкость выделенных ресурсов определяется совокупностью запросов к явно заданному набору отправителей. (Если несколько получателей ожидают трафик от одного и того же отправителя, их запросы объединяются, а ресурсы выделяются на разделяемой основе.) Спецификация фильтра с явным указанием отправителей применяется и для разделяемого резервирования (Shared Explicit, SE), только потоки от источников, перечисленных в запросе RESV, используют одни и те же ресурсы. Неявная спецификация (Wildcard Filter, WF) предполагает, что по единому виртуальному каналу будет передаваться трафик от всех отправителей.

         Фильтры SE и WF подходят для обработки многоадресного трафика, например при проведении аудиоконференций. Применение FF предпочтительнее для передачи видеосигналов.

Рис. 3.3. Прохождение пакетов на примере одного сеанса на одном маршрутизаторе

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

Рис. 3.4. Распространение данных в многоадресной группе

         Основная сложность RSVP связана с многоадресной рассылкой. Пример многоадресной конфигурации приведен на рис. 3.4. Эта конфигурация состоит из четырех маршрутизаторов. Канал между двумя любыми маршрутизаторами, изображаемый линией, может представлять собой как прямой канал, так и подсеть. Три хоста - G1, G2 и G3 - входят в одну группу и получают дейтаграммы с соответствующим групповым адресом. Данные по этому адресу передаются двумя хостами - S1 и S2. Красная линия соответствует дереву маршрутизации для S1 и данной группы, а синия линия для S2 и данной группы. Линии со стрелками указывают направление передачи пакетов от S1 (красная) и от S2 (синяя).

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

Рис.3.5. Объединение сообщений RESV

         Рис.3.5 показывает поток сообщений Resv. Обратите внимание - сообщения объединяются, следовательно, только одно сообщение передается вверх по любой ветви комбинированного дерева доставки. Однако эти сообщения должны периодически рассылаться вновь для продления срока резервирования ресурсов.

         Сообщение Path используется для распространения информации об обратном маршруте. Всеми современными протоколами многоадресной маршрутизации поддерживается только прямой маршрут в виде дерева распространения (вниз от отправителя). Но сообщения Resv должны передаваться в обратном направлении через все промежуточные маршрутизаторы всем хостам-отправителям.

         Так как протокол маршрутизации не предоставляет информации об обратном маршруте, она передается RSVP в сообщениях Path. Любой хост, желающий стать отправителем, посылает сообщение Path всем членам группы. По пути каждый маршрутизатор и каждый хост-адресат переходит в состояние path, указывающее, что пакеты для этого отправителя должны пересылаться на транзитный узел, с которого данный пакет получен. Рис. 3.2 показывает, что пакеты Path передаются по тем же самым путям, что и пакеты данных.

         Следует отметить несколько принципиальных особенностей механизма резервирования ресурсов в рамках RSVP, отличающих его от других протоколов:

• сам по себе протокол RSVP не отвечает за транспортировку или маршрутизацию данных, а лишь управляет этими процессами, а потому может функционировать параллельно с TCP или UDP;
• RSVP ориентирован только на полудуплексную передачу, и для двустороннего обмена требуется устанавливать два самостоятельных сеанса RSVP;
• каждый маршрутизатор выделяет ресурсы на ограниченный промежуток времени (soft reservation), в течение которого получатель должен успеть обновить свой запрос RESV. Процедура периодического обновления полезна для оперативного реагирования на изменения маршрутов и состава групп многоадресной рассылки;
• при передаче трафика через несколько сетей на его пути могут встретиться устройства, не поддерживающие RSVP. Протокол применим и в этом случае (вариант с туннелированием), хотя вне доменов RSVP можно рассчитывать только сервис best effort;
• ключевая роль получателей в резервировании ресурсов позволяет выделять последние для многоадресного трафика даже в том случае, когда спецификации, поступающие от разных получателей, различны. Для их обработки используется схема «вложения» запросов в узлах тиражирования трафика.

         С точки зрения поддержки на уровне приложений и сетевых устройств протокол RSVP является, пожалуй, самым сложным из всех аналогичных технологий. Радикальное отступление от принципа best effort позволяет достичь наивысшего уровня сервиса в плане гарантированности параметров передачи, степени детализации при описании запрашиваемых ресурсов и качества обратной связи с приложениями. Применение архитектуры IntServ и протокола RSVP оказывается идеальным выбором для поддержки приложений реального времени, но в других случаях обеспечиваемый уровень QoS становится ненужным, а «цена» (излишняя сложность конкретных реализаций) — неоправданно высокой. Это обстоятельство обусловило появление не столь изощренных методов поддержки QoS в глобальной сетевой среде, одним из которых является DiffServ.

3.2.  Механизмы и технологии DiffServ

Дифференцированные услуги

         Разработка технологии Differentiated Services (DiffServ) стала попыткой преодолеть недостатки, присущие протоколу RSVP, прежде всего его плохую масштабируемость. В самом деле, в крупной сети число потоков огромно, и для каждого из них сетевые узлы должны хранить спецификации потока, запроса и фильтра, а также ряд дополнительных сведений. Обработка этой информации способна привести к снижению общей производительности маршрутизаторов. Кроме того, использование упомянутого механизма «мягкого» резервирования ресурсов означает, что в сети постоянно циркулирует несметное число сообщений PATH и RESV.

         Технология DiffServ предлагает простой и вследствие этого довольно грубый метод приоритизации трафика в соответствии с требованиями различных приложений. Ее основы были изложены в 1998—1999 годах в документах RFC 2474, 2475, 2597 и 2598.

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

         Но механизмы DiffServ ограничиваются только установлением соответствия между услугами и различными уровнями «чувствительности» к задержкам и потерям, т. е. не имеют дела с точными значениями или гарантиями. Они не рассчитаны на обеспечение того или иного уровня обслуживания. Вместо этого они стараются обеспечить относительное упорядочивание агрегированных потоков, так что с одним агрегированным потоком будут «обращаться лучше», чем с другим, в зависимости от правил обслуживания, определенных для каждого агрегированного потока.

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

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

         Масштабируемость архитектуры DiffServ достигается за счет объединения классификационных признаков трафика. DiffServ подразумевает отнесение пакетов к тому или иному классу обслуживания (так называемому агрегатору поведения, BA) с помощью маркеров — кодовых слов (DiffServ Code Point, DSCP), помещаемых в заголовки каждого IP-пакета. Все операции маркировки пакетов и кондиционирования трафика (то есть его фильтрации и формирования) по-прежнему реализуются на границе между сетями клиента и провайдера, а магистральным устройствам остается лишь дифференцированно обслуживать небольшое число классов трафика.

         Множество характеристик канала, таких, как пропускная способность, задержка, вариация задержки и/или потери, могут контролироваться и настраиваться с помощью следующих компонентов.

         Соглашение об уровне сервиса (Service Level Agreement, SLA). Дифференцированное обслуживание распространяется за границу домена DiffServ благодаря заключению SLA между сетью, из которой приходит трафик, и доменом DiffServ, в который трафик направляется. SLA может определять классификацию пакетов и правила перемаркировки; оно также может устанавливать профили трафика и действия, выполняемые с потоками, соответствующими или не соответствующими заданному профилю. Кроме того, SLA предусматривает (прямо или косвенно) соглашение о кондиционировании трафика (Traffic Conditioning Agreement, TCA) между доменами.

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

Модификация трафика

         Кондиционирование трафика включает такие операции, как измерение, формирование, профилирование и/или перемаркировка, чтобы гарантировать, что трафик, попадающий в домен DiffServ, удовлетворяет правилам, определенным в соглашении TCA в соответствии с политикой выделения ресурсов домена (см. Рис3.6). Контролер определяет, соответствуют ли параметры трафика его профилю. Результаты проверки для конкретного пакета (например, соответствие пакета профилю) могут использоваться для инициирования операций маркировки, отбрасывания или формирования.

         Маркировщики пакетов присваивают полю DiffServ пакета конкретное кодовое значение (codepoint), включая маркированный пакет в конкретный агрегированный поток. Формирователи задерживают некоторые или все пакеты в потоке, чтобы обеспечить соответствие потока его профилю. Формирователь обычно имеет буфер ограниченного размера, так что пакеты могут быть отброшены из-за нехватки в буфере места для размещения задержанных пакетов. Отбраковщики удаляют некоторые или все пакеты в потоке, чтобы обеспечить его соответствие профилю, — этот процесс называется приведением потока в соответствие с требованиями политики, или профилированием. При выходе пакетов из модуля кондиционирования трафика пограничного узла DiffServ поле Differentiated Services Codepoint (DSCP) каждого пакета должно иметь соответствующее значение.

Рис.3.6. Механизм работы DiffServ

         На этом схематическом изображении классификатора пакетов и модуля согласования трафика контролер определяет соответствие потока трафика определенному профилю. Маркировщик пакетов использует поле Differentiated Services (DiffServ) для отнесения пакета к одному из агрегированных потоков DiffServ. Формирователь задерживает пакеты для выравнивания потока в соответствии с профилем, а отбраковщик удаляет пакеты для обеспечения соответствия потока профилю.

         Приоритет вкупе с методом обслуживания пакета маршрутизатором называется типом локального поведения (Per Hop Behavior, PHB). Собственно, аббревиатурой PHB обозначается набор процедур, которые должны быть использованы для отправки потока пакетов с одним и тем же DSCP на выходной интерфейс маршрутизатора. Очевидно, что различия между типами локального поведения будут существенны, когда потоки, относящиеся к разным классам обслуживания, начнут конкурировать за ограниченные ресурсы (буферное пространство маршрутизатора, пропускную способность выходного канала). Поддержка определенных типов PHB или их групп в узлах сети реализуется путем применения различных алгоритмов управления очередями и буферным пространством.

         Двумя основными типами локального поведения являются Expedited Forwarding (EF) и Assured Forwarding (AF).

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

         Тип локального поведения Assured Forwarding ориентирован на передачу IP-трафика с определенными количественными показателями качества обслуживания. Он может использоваться для организации VPN на базе сети передачи данных оператора. Если интенсивность трафика не превышает порогового значения, определенного в спецификации кондиционирования, его обработка с высокой вероятностью будет соответствовать заявленному агрегатору поведения. Однако, в отличие от EF, в данном случае трафик, чьи параметры выходят за установленные границы, не будет отброшен, а получит меньший уровень QoS (например, возрастет задержка или доля отброшенных пакетов). Принципиальном моментом является сохранение первоначального порядка следования пакетов в потоке. Очевидно, что приоритет трафика AF должен быть ниже, чем у трафика EF, но выше, чем у трафика, обслуживаемого по принципу best effort.

         В рамках AF предусмотрено четыре класса сервиса и для каждого из них — три значения вероятности потерь пакетов. Получающаяся 12-уровневая схема достаточно гибка с точки зрения приоритизации трафика, особенно если учесть, что при возникновении перегрузки для сервисов AF можно задействовать ресурсы, отведенные под другие классы (если отнесенный к ним трафик отсутствует). А поскольку в спецификациях типов поведения AF параметры задержки передачи и ее флуктуаций не фигурируют, метод обслуживания AF допустимо применять к потокам с изменяющейся скоростью (например, в случае предоставления услуг «аудио/видео по запросу»).

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

3.3. Механизмы и технологии MPLS

         Технология многопротокольной коммутации по меткам (MultiProtocol Label Switching, MPLS) возникла во второй половине 90-х годов в попытке выработать единый стандарт на базе множества патентованных алгоритмов многоуровневой коммутации. Она чем-то схожа с DiffServ, поскольку здесь также используется маркировка пакетов на входе в сеть MPLS, а их передача напоминает транспортировку трафика по виртуальному каналу в сетях ATM или frame relay. Существенное различие между этими технологиями заключается в том, что в сети MPLS присвоение меток нацелено на определение следующего узла на пути следования пакетов, тогда как в DiffServ во главу угла ставится приоритизация трафика.

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

         Соответствующая рабочая группа в составе IETF была создана в самом начале 1997 года, а через два с лишним года увидели свет первые спецификации, определявшие принципы построения частных сетей BGP/MPLS VPN (RFC 2547). Число регламентирующих документов постоянно возрастает: на сегодняшний день функционирование сетей MPLS и смежные вопросы описаны в полусотне спецификаций.

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

Рис.3.7. Схема коммутации MPLS

         Сеть MPLS делится на две функционально различные области — ядро и граничную область. Ядро образуют устройства, минимальным требованием к которым является поддержка MPLS и участие в процессе маршрутизации трафика для того протокола, который коммутируется с помощью MPLS. Маршрутизаторы ядра занимаются только коммутацией. Все функции классификации пакетов по различным FEC, а также реализацию таких дополнительных сервисов, как фильтрация, явная маршрутизация, выравнивание нагрузки и управление трафиком, берут на себя граничные LSR. В результате интенсивные вычисления приходятся на граничную область, а высокопроизводительная коммутация выполняется в ядре, что позволяет оптимизировать конфигурацию устройств MPLS в зависимости от их местоположения в сети.

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

         В качестве транспортного механизма, дополняющего традиционные функции маршрутизации, используется уже упоминавшийся алгоритм замены меток. Первоначальная маркировка пакетов осуществляется граничным маршрутизатором при их поступлении в сеть. Метка занимает первые 20 бит в 4-байтовом заголовке MPLS, который в передаваемом пакете размещается между заголовками протоколов второго и третьего уровней. Совокупность пакетов с одинаковыми метками образует класс эквивалентности (Forwarding Equivalence Class, FEC), аналогичный паре VPI/VCI в сетях асинхронной передачи или идентификатору DLCI в среде frame relay. Пакеты, относящиеся к конкретному FEC, в сети MPLS передаются по одному пути (Label Switched Path, LSP), хотя их адресаты могут различаться.

Рис.3.8. Маршрутизация в модели MPLS

         Специальная маркировка пакетов позволяет маршрутизатору, поддерживающему коммутацию по меткам (Label Switching Router, LSR), не анализировать заголовок сетевого уровня. Ориентируясь на значение метки и номер входного порта, на который поступил пакет, он сопоставляет с ним новую (выходную) метку и номер выходного интерфейса. После замены входной метки MPLS на выходную пакет отправляется дальше в сеть. Аналогичная операция выполняется и последним (граничным) маршрутизатором — с той лишь разницей, что он просто удаляет метку MPLS, и последующая транспортировка осуществляется средствами обычной маршрутизации.

         Работоспособность этого алгоритма зависит от наличия в каждом маршрутизаторе LSR таблиц соответствия между парой «входной интерфейс, входная метка» и тройкой «префикс адреса получателя, выходной интерфейс, выходная метка» (префикс используется на стадии формирования таблиц). Однозначность такого соответствия приводит к тому, что первоначальная метка MPLS полностью определяет путь следования пакета.

         Из сказанного ясно, что ключевую роль в функционировании сети и ее динамической перенастройке с учетом изменяющихся условий должны играть протоколы распределения меток (Label Distibution Protocol, LDP). Такое распределение всегда производится в направлении от источника к получателю и может осуществляться спонтанно или по требованию. Спецификации MPLS допускают применение для этих целей различных протоколов, исходя из особенностей установленного MPLS-оборудования и политики администрирования, однако наиболее перспективными среди них на сегодняшний день являются Constraint-based Routing Label Distribution Protocol (CR-LDP) и RSVP-TE.

Рис.3.9. Протокол LDP

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

         RSVP-TE представляет собой расширение протокола RSVP, допускающее различные варианты настройки и администрирования маршрутов LSP, — распределение меток по требованию, формирование явных путей LSP и выделение для них сетевых ресурсов, реконфигурирование существующих LSP-туннелей, диагностику путей LSP и т. д.

         Коммутируемый по меткам тракт – это последовательность MPLS-маршрутизаторов. Набор пакетов, передаваемый по LSP, относится к одному FEC, и каждый маршрутизатор LSR в LSP-туннеле назначает для него свою метку. LSP-туннель создается внутри LSP-тракта. Следует отметить, что зачастую начало и конец туннеля не совпадают с началом и концом LSP-тракта. Как правило, туннель короче. Для каждого туннеля подсчитывается число пропущенных пакетов и байт. Иногда поток данных может быть настолько велик, что для него создается несколько LSP-туннелей между отправителем и получателем. В одном LSP может быть создано несколько LSP-туннелей с различными точками приема и передачи, а в каждом туннеле могут быть созданы LSP-туннели другого уровня. В этом проявляется иерархичность структуры MPLS. Возможны два варианта создания туннелей: по принципу hop-by-hop, который предполагает, что каждый маршрутизатор самостоятельно выбирает дальнейший путь следования пакета, или по принципу явной маршрутизации, в котором маршрутизаторы передают пакет в соответствии с указаниями, полученными от верхнего в данном тракте LSR. Таким образом, в первом случае маршрут следования пакетов определяется случайным образом, а в случае явной  маршрутизации он известен заранее. В сети MPLS может существовать набор маршрутизаторов, которые являются входными для конкретного FEC, тогда считается, что для этого FEC существует LSP-туннель с разными точками входа и выхода. Если для некоторых из этих LSP выходным является один и тот же LER, то можно говорить о дереве LSP, корнем которого служит данный выходной маршрутизатор. LSP можно рассматривать как тракт, создаваемый путем сцепления одного и более участков маршрута, который позволяет пересылать пакет, заменяя на каждом узле сети MPLS входящую метку исходящей меткой (так называемый алгоритм перестановки меток). Таким образом, тракт сети MPLS можно рассматривать как туннель, для создания которого в IP-пакет вставляется заголовок – метка, о котором речь шла ранее. LSP устанавливаются либо перед передачей данных (с управлением от программы), либо при обнаружении определенного потока данных (управляемые данными LSP). На сегодняшний день применение туннелирования реализовано во многих технологиях. Образование в виртуальном тракте туннелей, по которым проходят другие виртуальные тракты, основывается на инкапсуляции передаваемых пакетов в пакеты, следующие по этому тракту к данному адресу назначения.

         Независимо от выбранного протокола при описании маршрутов LSP администратор может придерживаться различных сценариев. Самой простой заключается в явном указании маршрута, соединяющего отправителя с адресатом. Он полезен для транспортировки трафика по пути, отличному от выбираемого обычными протоколами маршрутизации. Другой вариант — упомянутая выше маршрутизация с учетом ограничений, накладываемых на процесс передачи пакетов. Маршрутизаторы могут вычислять путь LSP заранее (что эквивалентно его явному заданию) либо динамически с учетом изменяющихся сетевых условий. Еще одна возможность — резервирование ресурсов всеми узлами, через которые проходит LSP, для обеспечения требуемого качества сервиса.

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

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

         Внедрение технологии MPLS поможет операторам контролировать операционные расходы и стоимость предоставляемых услуг, поднять качество базовых сервисов и разработать услуги нового поколения. Тремя основными вариантами применения MPLS на сегодняшний день являются оптимизация передачи трафика, поддержка различных классов обслуживания (Class of Service, CoS) и организация сетей VPN.

         Оптимизированная маршрутизация (в английском варианте — traffic engineering) позволяет передавать потоки данных не по кратчайшему пути, определяемому протоколами группы IGP, а по наименее загруженному. Технология MPLS оказывается при этом как нельзя кстати благодаря возможностям явного указания путей LSP (с учетом требований к полосе пропускания), сбора статистики по отдельным маршрутам LSP для выявления узких мест и планирования сетевой нагрузки, взаимодействия с различными сетевыми протоколами.

         Использование MPLS для поддержки QoS допустимо рассматривать как логичное продолжение оптимизированной передачи данных. Не последнюю роль здесь играет сочетание двух технологий — MPLS и DiffServ, ведь именно последняя позволяет разбивать трафик на множество классов обслуживания. Поддержка QoS может быть реализована с применением одного из двух механизмов:

• трафик, передаваемый по конкретному пути LSP, помещается в очередь выходного интерфейса маршрутизатора на основе значения приоритета в заголовке MPLS;
• для каждой пары граничных маршрутизаторов LSR устанавливается несколько путей, по которым транспортируются потоки с разными приоритетами.

Рис.3.10. Пример совместного использования MPLS и DiffServ

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

         Напомним, что технология VPN позволяет сымитировать в среде Internet защищенную распределенную корпоративную сеть. Традиционный подход к построению VPN базируется на шифровании данных и инкапсуляции (туннелировании) трафика для его передачи в среде IP. Для этих целей используются различные протоколы (GRE, PPTP, L2TP, IPSec), но все они имеют общие недостатки.

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

         Во-вторых, наложенные туннели снижают эффективность использования ресурсов сети. В конфигурации с центральным концентратором (hub and spoke) все потоки должны передаваться через один узел, который обязан сначала дешифровать и извлечь данные для определения пути их дальнейшего следования, а потом выполнить шифрование и инкапсуляцию повторно. К тому же от работоспособности концентратора начинает зависеть вся сеть. В полносвязной (fully meshed) конфигурации этот недостаток отсутствует, зато с увеличением числа узлов резко возрастает необходимое число туннелей, которое должно поддерживаться клиентскими устройствами. В обоих случаях масштабируемость сети оказывается сильно ограниченной.

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

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

         В описанной ситуации протокол MPLS является настоящей палочкой-выручалочкой. Сеть MPLS VPN состоит из клиентских граничных маршрутизаторов (Customer Edge, CE), подключаемых к граничным маршрутизаторам сервис-провайдера (Provider Edge, PE). Ядро сети образуют внутренние маршрутизаторы (P), отделенные от клиентского оборудования устройствами PE. В среде MPLS VPN узлы PE и P играют роль маршрутизаторов LSR. При этом клиентские устройства к обеспечению функциональности VPN никакого отношения не имеют и могут подключаться к опорной сети по каналам T1/E1, frame relay, DSL, ATM и т. д. Они должны поддерживать только IP, но никак не MPLS, IPSec или иные VPN-протоколы. Такое разделение функций позволяет для формирования виртуальной частной сети использовать недорогое клиентское оборудование.

         В сети MPLS VPN нет необходимости применять средства шифрования: благодаря самому принципу ее организации уровень защищенности оказывается практически таким же, как при передаче трафика по виртуальным соединениям в среде ATM или frame relay. Отпадает нужда и в инкапсуляции пакетов. В результате возрастает производительность, а суммарная задержка передачи оказывается даже меньшей, чем в IP-сети без MPLS-коммутации.

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

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

3.4. Сравнительный анализ технологий обеспечения качества обслуживания QoS

IntServ определяет два класса по обеспечению гарантированного уровня обслуживания в пакетных сетях, а именно: класс контролируемой загрузки (controlled-load) и класс гарантированного обслуживания (guaranteed QoS). На основе данной модели (в зависимости от класса обслуживания) для определенного типа трафика может быть предоставлена необходимая полоса пропускания в канале связи, а также обеспечиваться минимальная задержка при передаче пакетов или минимальный уровень их потерь.

Основными компонентами модели IntServ являются следующие функциональные составляющие:

• модуль резервирования ресурсов (flow resource reservation);

• модуль управления доступом (flow admission control);

• классификатор трафика (packet classifier) и диспетчер очередей (packet scheduler).

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

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

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

         1. Увеличивается время установления соединения, что особенно нежелательно при функционировании такого протокола, как, например, Н.323 (стандарт мультимедийных приложений). Это связано с тем, что протокол работает в два этапа: сначала служебные пакеты RSVP обрабатываются маршрутизаторами на пути от речевого шлюза источника до речевого шлюза назначения (сообщение Path), а затем, если шлюз назначения готов принять речевой поток, они должны обработать служебные пакеты "резервирования", следующие от речевого шлю за назначения к шлюзу источника (сообщение Resv).

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

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

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

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

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

• обеспечивает единое понимание того, как должен обрабатываться трафик определенного класса;

• позволяет разделить весь трафик на относительно небольшое число классов и не анализировать каждый информационный поток отдельно;

• нет необходимости в организации предварительного соединения и в резервировании ресурсов;

• не требуется высокая производительность сетевого оборудования;

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

Недостатки модели DiffServ:

• в условиях однородного трафика (например, только голосового) принцип применения приоритетов теряет смысл, и сеть начинает работать в режиме Best Effort Service;

• отдельные внутренние маршрутизаторы могут неадекватно отреагировать на значения битов в поле ToS или даже изменить их;

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

         Одной из реализаций модели DiffServ является технология многопротокольной коммутации на основе меток (Multiprotocol Label Switching - MPLS), которая на сегодняшний день стала одной из основных для построения крупных сетей операторов, предоставляющих услуги с обеспечением качества обслуживания. Данная технология предназначена для ускорения коммутации пакетов в транспортных сетях. Основное ее отличие от ранее рассмотренных в том, что MPLS изначально не является технологией обеспечения качества и становится таковой только при использовании протокола RSVP-TE.

         На границе сети MPLS маршрутизаторы помечают пакеты специальными метками, определяющими дальнейший маршрут следования пакета к месту назначения. В результате анализируются не адреса IP, а короткие цифровые метки, что существенно снижает сетевую задержку и требования к производительности маршрутизаторов. Для корректного взаимодействия их между собой и обмена информацией о создаваемых метках используются протоколы распределения меток (LDP, CR-LDP, RSVP-TE и др.).

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

         Технология MPLS характеризуется высокой масштабируемостью и рассматривается в качестве наиболее перспективной для передачи IР-трафика.

Преимущества технологии MPLS:

• выбор маршрута на основе анализа IP-адреса;

• ускоренная коммутация (сокращает время поиска в таблицах);

• гибкая поддержка QoS, интегрированных сервисов и виртуальных частных сетей;

• эффективное использование явного маршрута;

• сохранение инвестиций в уже установленное АТМ-оборудование;

• разделение функциональности между ядром и граничной областью сети.

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

         Корпоративную сеть можно строить, используя услуги, гарантирующие определенный уровень QoS, которые предлагают операторы связи на основе технологии MPLS. Тем не менее, несмотря на значительные преимущества технологии с точки зрения обеспечения QoS, дополнительная гарантия доставки пакетов может создать проблемы в области масштабируемости. К тому же эта технология внедрена пока еще очень немногими операторами, что ограничивает возможности использования данного варианта. Поэтому в настоящий момент для построения корпоративных мультисервисных сетей, объединяющих небольшое число точек подключения на основе выделенных каналов связи, отсутствует технология, которая в полной мере, с учетом соотношения цена/качество, обеспечивала бы возможности по предоставлению необходимого уровня QoS.

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

         Интегро-дифференцированное обслуживание (Integrated Services Operation over Diffserv Networks). Опубликованный в 2000 г. стандарт RFC2998 описывает принт типы организации взаимодействия IntServ/RSVP и DiffServ для предоставления QoS от источника получателю. Слабые места одной модели компенсируются соответствующими решениями другой. С одной стороны, плохо масштабируемая IntServ на магистральных участках сети может быть заменена на более простую DiffServ. С другой, с помощью RSVP решается вопрос с неопределенностью получаемого сервиса в DiffServ-сети.

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

Рис.3.11. Модель интегро-дифференцированного обслуживания

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

• DiffServ-регион не поддерживает RSVP-сигнализацию, и ресурсы выделяются на статической основе;

•  обработка RSVP-сообщений производится в DiffServ-регионе.

         В первом случае совместная работа основана на статическом соглашении клиента с оператором SLS (спецификация уровня сервиса). В простейшей ситуации описывается значение пропускной способности в DiffServ-сети, получаемое трафиком пользователя: Тх (отправитель) генерирует сообщения Path, которые направляются к узлу Rx (получатель) через DiffServ-регион.

Таблица 3.1

Сравнительные характеристики обеспечения QoS

При прохождении через DiffServ-регион содержимое RSVP-сообщений игнорируется, и они пересылаются как обычный пакет с данными. При получении узлом Rx сообщения Path генерируется запрос на резервирование RESV, который затем направляется обратно к узлу Тх. При успешной обработке запроса каждым совместимым RSVP-маршрутизатором и прохождении через DiffServ-регион сообщение RESV достигает маршрутизатора Erl, который на основании SLS производит сравнение ресурсов, запрашиваемых в сообщении RESV, и ресурсов, доступных в DiffServ-регионе. Если Erl подтверждает запрос, информация RESV отсылается далее по направлению к узлу Тх. В ином случае сообщение отвергается, и узлу Rx отправляется оповещение об ошибке. В полученном узлом Тх сообщении могут содержаться данные о маркировании соответствующим кодом пакетов, адресуемых в узел Rx. Значение кода определяется по умолчанию или из сообщения RESV.

         Второй вариант предполагает, что пограничные маршрутизаторы в DiffServ-регионе (например, маршрутизатор Brl) поддерживают протокол RSVP. Отметим, что, несмотря на поддержку RSVP-сигнализации, обрабатываются только агрегированные потоки, а не единичные, как в сети IntServ/RSVP. Порядок обмена RSVP-сообщениями такой же, как и в предыдущем случае. Однако благодаря поддержке RSVP в DiffServ-регионе блок управления доступом является частью DiffServ-сети. В результате маршрутизатор Brl имеет возможность непосредственно обработать RSVP-запрос, исходя из доступности ресурсов. Сравнительные характеристики обеспечения QoS представлены в таблице 3.1

4. АНАЛИЗ ПОКАЗАТЕЛЕЙ КАЧЕСТВА УСЛУГ И ФАКТОРОВ ВЛИЯЮЩИХ НА КАЧЕСТВО УСЛУГ  IPTV

4.1. Анализ факторов влияющих на качество услуг IPTV

На данный момент IPTV или в более широком смысле — видеопотоки — привнесли в сети телекоммуникаций много нового. Действительно, IPTV, в первую очередь, создает принципиально новую модель трафика для сетей телекоммуникаций, потоки трафика IPTV в уникастинговом и мультикастинговом режимах характеризуются высокой степенью самоподобия. Параметр Херста для трафика IPTV, как правило, больше 0,6.  Кроме того, в NGN трафик IPTV является составляющей мультисервисного трафика, включающего также трафик речи и данных. В результате многочисленных исследований было установлено, что трафик видео данных с достаточной для практики степенью точности аппроксимируется дискретным пачечным Марковским процессом.

Субъективная оценка качества видео изображения на основе методики среднего субъективного мнения (Mean Opinion Score, MOS) аналогична оценке качества передачи речи и рассчитывается как среднее из субъективных оценок зрителей. Аналогично значениям при оценке качества передачи речи принимается пяти-бальная шкала от 1 до 5, в которой 5 соответствует наибольшей степени удовлетворенности пользователя услугой. На сегодняшний день получение оценки MOS для видео контента не является обычной практикой на действующих сетях и поэтому для обеспечения параметров качества видео услуг необходимо применять объективные метрики качества видео изображения (VQM), которые рассчитываются алгоритмически и могут быть использованы при автоматическом тестировании и анализе. Данные методы используют такие метрики при оценке качества как минимальная среднеквадратичная ошибка (Mean Square Error, MSE) и пиковое значение отношения сигнал/шум (Peak Signal-to-Noise Ratio, PSNR), которые достаточно просто рассчитать.

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

Определение качества услуг возможно лишь в сравнении исходного качества услуг, передаваемого поставщиком услуг, с качеством услуг, получаемого на оборудовании пользователя (Рис.4.1 ).

 Рис 4.1 .  Параметры влияющие на качество услуг IPTV

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

- доля потерянных пакетов (Packet Loss Ration, PLR);

- задержка при доставке пакетов;

- вариация задержки;

- количество пакетов, полученных с ошибкой;

- количество поврежденных пакетов;

- коэффициент ошибок (Bit-Error Ratio, BER);

- потеря фреймов синхронизации (Loss Of Frame, LOF);

- потеря сигнала (Loss Of Signal, LOS);

- доля времени без ошибок (Error-Free Seconds, EFS).

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

- количество ошибок, связанных с остановившимся видео изображением (застывших видео моментов), при предоставлении услуг телевизионного вещания и VoD;

- количество ошибок, связанных с пропущенными видео изображениями, при предоставлении услуг телевизионного вещания и VoD;

- задержка при присоединении и отключении от группы многоадресной рассылки;

- задержка при переключении между телевизионными каналами;

- задержка после выбора функции «Воспроизведение»;

- задержка при выборе функции «Быстрая перемотка вперед», «Пауза», «Обратная перемотка»;

- индекс качества при предоставлении услуг телевизионного вещания и VoD.

4.2. Качество обслуживания в IPTV

Качество обслуживания (Quality of Service) QoS определяет способность сети предоставлять лучшее обслуживание выбранного сетевого трафика с помощью различных основных технологий.

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

Качество обслуживания (QoS) исключительно важно при оценивании архитектуры IPTV, так как передача видео по IP очень чувствительна к потере пакетов. И хотя потеря одного или нескольких последовательных пакетов незначительно скажется на восприятии зрителем ТВ, если потеря длится более секунды, это заметно снизит качество изображения. ТВ-приставки имеют ограниченную функциональность для борьбы с потерями видеокадров. Многие из ТВ-приставок (STB), например, позволяют избежать видимых артефактов из-за перерыва в сети с помощью схем прямого исправления ошибок, которые скрывают отсутствующую информацию, или путем повторной передачи недостающей информации. Оба этих метода технически достаточно сложные. Джиттер также является важным параметром, который следует учитывать, поскольку у ТВ-приставок (STB) ограничена емкость для компенсации джиттера. И хотя абсолютная задержка не столь важна при передаче видео (если она постоянна во времени), помощь в обеспечении контроля задержек от начала до конца является основным атрибутом для проекта передачи видео через IP-сеть.

Рассмотрим параметры характеризующие качество обслуживания QOS в IP-сети.

1.  Термин полоса пропускания (bandwidth) используется для описания номинальной пропускной способности среды передачи информации, протокола или соединения. Этот термин достаточно эффективно определяет “ширину канала”, требующуюся приложению для взаимодействия по сети.

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

2. Уровень потери пакетов (packetloss) определяет количество пакетов, отбрасываемых сетью во время передачи. Основными причинами потери пакетов являются перегрузка сети и повреждение пакетов во время передачи по линии связи. Чаще всего отбрасывание пакетов происходит в местах перегрузки, где число поступающих пакетов намного превышает верхнюю границу размера выходной очереди. Кроме того, отбрасывание пакетов может быть вызвано недостаточным размером входного буфера. Как правило, уровень пакетов выражается как доля отброшенных пакетов за определенный интервал времени. Некоторые приложения (напр. IPTV, Видеоконференция, VoIP и др.) не способны нормально функционировать или же функционируют крайне неэффективно в случае потери пакетов.

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

Потери пакетов имеют значительное влияние на качество (QoS) IPTV они могут возникать по многим причинам, включая неожиданные внешние воздействия (например, импульсные помехи, молнии, переходные помехи от других DSL линий, изменения конфигурации системы и/или превышение пропускной способности сети).

Потери пакетов IPTV приводят к пикселизации или ухудшению разрешения, замиранию кадра и/или зависанию IPTV приставки. Степень влияния потерь зависит от типа видеокадра, с которым это случилось. С помощью процесса видеосжатия IPTV создаются три типа кадра: I кадры, P кадры и B кадры (т.е. внутренние кадры (intra), предсказанные кадры (predicted) и дважды предсказанные кадры (bipredictive)).

Рис.4.2. MPEG GOP: I-кадры, P-кадры и B-кадры

I-кадры выступают в роли основных (опорных) кадров для всех кадров в группе изображений (GOP). Поэтому потеря части или одного целого кадра распространяется по кадрам и даже может повлиять на все кадры в GOP (обычная длительность 0.51 с). Аналогично кадры P и B могут быть связаны с другими кадрами и возможно получение сходного эффекта, который, однако, не столь продолжителен как в случае с I-кадром. Более гибкий механизм предсказания изображений H.264 может значительно ухудшить данное явление.

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

Требования к потерям пакетов определяются исходя из двух параметров: продолжительность потери и время между потерями. Продолжительность потери определяет длительность ошибки, время между потерями показывает время между потерями пакетов. Рекомендации DSL форума TR-126 определяют желаемое значение времени между потерями как одна ошибка в час для телевидения стандартного качества (SD) и одна ошибка за четыре часа для телевидения высокой четкости (HD), с продолжительностью потери в 16 мс. 

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

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

3. Задержка пакета (packetdelay) или латентность (latency) – это время прохождения пакета от отправителя к получателю. Задержка припередачи пакета на каждом переходе состоит из задержки распространения, задержки сериализации и задержки коммутации. Ниже приведены определения каждого из названных выше типов задержки.

· Задержка распространения (propagationdelay). Время, которое требуется переданному биту информации для достижения принимающего устройства на другом конце канала. Эта величина довольно существенна, поскольку в наилучшем случае скорость передачи информации соизмерима со скоростью света. Обратите внимание, что задержка распространения зависит от расстояния и используемой среды передачи информации, а не от полосы пропускания.

· Задержка сериализации (serialization delay).Время, которое требуется устройству на передачу пакета при заданной ширине полосы пропускания. Задержка сериализации зависит как от ширины полосы пропускания канала передачи информации, так и от размера передаваемого пакета.

· Задержка коммутации (switching delay).Время, которое требуется устройству, получившему пакет, для начала его передачи следующему устройству. Как правило, это значение меньше 10 нс.

Рис.4.3.Задержка при передаче пакета – сумма задержек на каждом переходе

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

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

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

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

Рис.4.4. Вариация задержки – колебание задержки при передаче пакетов

При получении пакетов предпочтительно получать их с постоянной скоростью, при этом система IPTV максимально может допускать 50 мс величину отклонений (джиттера), однако слишком большие отклонения приведут к потере пакетов.

Классы QoS

Каждое приложение требует определенные значение параметров качества (QoS) для IP-сетей. В рекомендации ITU-TY.1541 QoS был разделен на шесть классов (от 0-лучший до 5-худший) и были нормированы 4 параметра IP-сетей. Нормы на сетевые рабочие характеристики для служб на основе протокола IP (Y.1541) представлены в таблице 4.1.

Таблица 4.1

Определения классов сетевого QoS протокола IP и требования к рабочим характеристикам сети

IPTV трафик не предъявляет жестких требований к задержке а максимальное значение джиттера пакетов не должно превышать 50 мс. Отсюда можно сделать следующий вывод: для предоставления услуги IPTV, IP-сеть должна соответствовать классу 0 или 1.

4.3. Качество восприятия в IPTV

На данный момент научно-исследовательские группы ITU-T определяют качество восприятия QoE (Quality of Experience) основным фактором, влияющим на выбор абонента. IPTV QoE представляет собой степень удовлетворённости пользователей от предоставляемых им видео сервисов. Восприятие абонентами качества систем IPTV должно быть равноценным или даже превосходить современные кабельные или спутниковые ТВ сервисы, в противном же случае Провайдеры Услуг подвергаются риску сокращения своей абонентской базы. Данный фактор определяется не только параметрами сети или качеством предоставляемого контента, но также удобством использования системы и ожиданиям пользователя. Для использования в системах мониторинга параметр QoE должен вычисляться с использованием измеряемых параметров, однако на данный момент не существует математической модели, которая бы учитывала субъективные параметры, влияющие на QoE в системе IPTV.

Качество восприятия (QoE) – это общий показатель качества приложения или сервиса, воспринимаемый субъективно конечным пользователем. Это означает, что QoE является более сложным понятием по сравнению с качеством обслуживания QoS (QualityofService). QoE включает влияние всех возможных факторов от источника до конечного пользователя. Кроме того, на данный параметр также влияют время ожидания каждого пользователя и содержание контента.

Факторы, влияющие на качество восприятия

В организациях стандартизации (ETSI, ITU) рассматриваются следующие факторы, влияющие на качество восприятия:

1. Качество передачи данных (минимальная скорость передачи данных, максимальный уровень потери пакетов);

2. Функции интерактивного контроля (время переключения, возможность выбора метаданных, электронное телевизионный гид, время отклика, доступность);

3. Доступность для восприятия (дактилология, чтение по губам, качество контента -такие, как качество видео и звука).

Так как качество восприятия определяется «субъективно конечным пользователем», различия в личностном восприятии и предпочтении приведут к тому, что параметры качества восприятия, полученные от разных людей, могут отличаться. Таким образом, измерения QoE, как правило, проводятся с использованием данных группы пользователей. QoE требования для видео и аудио контента, первоначально могут быть определены при помощи субъективной шкалы абонентского обслуживания, таких как MOS (MeanOpinionScore) или DSCQS (TheDouble-StimulusContinuousQuality-Scalemethod). Поскольку такие исследования субъективных показателей качества восприятия являются трудоемким и дорогостоящим процессом, то необходимо на основании исследований, проведенных для калибровки шкалы QoE, найти способ оценки QoE при использовании объективных измерений.

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

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

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

Согласно рекомендации ITU-TG.1080, на QoE влияют следующие параметры (рис.4.5): объективные (параметры качества обслуживания QoS); субъективные (человеческий фактор).

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

По заданномуQoS можно принципиально оценить ожидаемое QoE и, наоборот, при необходимости обеспечить определенное QoE, можно принципиально оценить требуемые сетевые характеристики. Чтобы обеспечить надлежащее качество полученной абонентом услуги, QoE параметры необходимо рассматривать для каждого из сервисов. Эти параметры необходимо учитывать на стадии проектирования системы на каждом уровне модели OSI.

Рис.4.5.Факторы, влияющие на качество восприятия

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

Список использованной литературы

1. Л. Клейнрок «Теория массового обслуживания», перевод с английского – М.: Машиностроение, 1979 г.

2. Л. Клейнрок «Вычислительные сети с очередями», перевод с английского – М.: Мир. 1979 г.

3.  А. Кучерявый, Л. Гильченок, В. Пяттаев «Принципы построения инфокоммуникацинной сети» – журнал «Электросвязь», №11, 2003 г.

4. Б. Гольдштейн, О. Орлов, А. Ошев, Н. Соколов «Модернизация сетей доступа в эпоху NGN» – журнал «Вестник связи», №6, 2003 г.

5. А. Гольдштейн, Б. Гольдштейн «Softswitch» – СПб.: БХВ-Санкт Петербург, 2006 г.

6. А. Гольдштейн «Проблемы перехода к мультисервисным сетям» –  журнал «Вестник связи», №12, 2002 г.

7. Голъдштейн А.Б. Механизм эффективного туннелирования в сети MPLS // Вестник связи; 2004, №2.

8. Лагутин В.С. Современные технологии передачи данных. Электросвязь,  № 8, 2001

9. Джураев Р.Х., Джаббаров Ш.Ю., Умирзаков Б.М. Технологии передачи данных. Учебное пособие - Ташкент 2008 г.

10.  Принципы организации дистанционного диагностирования цифровых систем. Методические указания к практическим занятиям по курсу ТДЦС. – Ташкент 2003 г.

11. Симонина О.А. Повышение QoS пакетной передачи речи путем сглаживания эффектов потерь в кодеках ІР-телефонии // Всероссийская конференция «Сети связи следующего поколения»: сб. тр. СПб: «Петеркон», 2003. С. 171-174.

12.Симонина О.А., Галкин A.M. Метод расчета характеристик IP-ориентированных мультисервисных сетей с учетом свойств самоподобия трафика // Труды учебных заведений связи / СПбГУТ. СПб. 2005. № 172. С. 6-Ю.

13. Алиев Т.И., УП. Основы моделирования дискретных систем – Санкт-Петербург 2009 г.

14. Гиттик Ю. Новые услуги на основе MPLS. – Сети и системы связи – 2004.-№6

15. Гольштейн А.Б. Еще раз о Softswitch или сравнение реализаций трехранной пирамиды. - Вестн6. Иванова А.Б. Контроль качества в телекоммуникация связи. – 2003.№9

16. Джагацпанян Г.Г. Анализ требований качества обслуживания для услуги Triple Play// «Московская отраслевая научно-техническая конференция» Технологии информационного общества: Тез. Докл. – М.: МТУСИ, 2007. – С.41.

17. Передача дискретных сообщений./Под ред. Шувалова В.П.. – М.: Радио и связь, 1990.

18. Коган А.В. ІР-телефония как наиболее перспективный метод передачи информации // Электросвязь, 2000, №10, с. 3-6.

19. Л. Варакин «Инфокоммуникация будущего» – журнал «Электросвязь», №11, 2003 г.

20. И. Бакланов «Несколько слов про NGN...» – журнал «CONNECT», № 5, 2005 г.

21. Н. Ефимова «Пути перехода к сетям NGN в России» – журнал «Электросвязь», №6, 2004 г.

22. Н. Соколов «Выбор технологии коммутации для сетей следующего поколения» – журнал «Мобильные системы», №7, 2004 г.

23. В. Олифер, Н. Олифер «Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 3-е издание» – СПб.: Питер, 2006 г.

24. Г. Конахович, В. Чуприн «Сети передачи пакетных данных» – К.: МК-Пресс, 2006 г.

25. С. Макаренко «Анализ математического аппарата расчета качества обслуживания информационно-вычислительной сети на сетевом уровне эталонной модели взаимодействия открытых систем» – Сборник докладов VII Всероссийской конференции молодых ученых по математическому моделированию и информационным технологиям, 2006 г.

26. Д. Филлипс, А. Гарсиа-Диас «Методы анализа сетей» – М.: Мир, 1984 г.

27. О. Авен, Н. Гурин, Я. Коган «Оценка качества и оптимизация вычислительных систем» – М.: Наука, Главная редакция физико-математической литературы, 1992 г.

28. И. Мизин, В. Богатырев, А. Кулешов «Сети коммутации пакетов» – М.: Радио и связь, 1986 г.

29. Г. Фрэнк, И. Фриш «Сети связи и потоки», перевод с английского – М.: Связь, 1988 г.

30. Д. Бертсекас, Р. Галлагер «Сети передачи данных» – М.: Мир, 1999 г.

31. Д. Дэвис, Д. Барбер, У. Прайс «Вычислительные сети и сетевые протоколы» – М.: Мир, 1982 г.

32. В. Лазарев, Ю. Лазарев «Динамическое управление потоками информации в сетях связи» – M.: Радио и связь, 1993 г.

33. М. Гаранин, В. Журавлев, С. Кунегин «Системы и сети передачи информации: Учебное пособие для вузов» – М.: Радио и связь, 2001 г.

34. А. Кофман, Р. Крюон «Массовое обслуживание (теория и приложения)», перевод с французского – М.: Мир, 1965 г.

35. П. Будко, В. Федоренко «Управление в сетях связи. Математические модели и методы оптимизации» – М.: Издательство физико-математической литературы, 2003 г.

36. С. Пороцкий «Моделирование алгоритма маршрутизации транспортной АТМ сети» – журнал «Электросвязь» №10, 2000 г.

37. С. Турко «Оптимизация пропускной способности звеньев Ш-ЦСИС при ограниченных сетевых ресурсах» – журнал «Электросвязь», №2, 2002 г.

38. И. Пасечников «Методология анализа и синтеза предельно нагруженных информационных сетей» – М.: Издательство Машиностроение-1, 2004 г.

39. С. Турко,  Л. Фомин,  П. Будко,  Н. Гахова, А. Ватага «Об оптимальном использовании сглаживающего влияния буферов на параметры трафика Ш-ЦСИС» – журнал «Электросвязь», №10, 2002 г.

40. Б. Цыбаков «Модель телетрафика на основе самоподобного случайного процесса» – журнал «Радиотехника», №5, 1999 г.

41. А. Иванов «Разработка и исследование алгоритмов прогнозирования и управления очередями в компьютерных сетях», автореферат диссертации к.т.н.: 05.13.01, Санкт-Петербургский государственный технический университет – СПб.: СпбГТУ, 2001 г.

42. С. Ермаков, В. Мелос «Математический эксперимент с моделями сложных стохастических систем» – СПб.: СПбГУ, 1992 г.

43. Л. Заде «Основы нового подхода к анализу сложных систем и процессов принятия решений» – М.: Знания, 1974 г.

44. Р. Белман, Л. Заде «Принятие решений в расплывчатых условиях» – М.: Мир, 1976 г.

45. В. Заборовский «Методы и средства исследования процессов в высокоскоростных компьютерных сетях»: автореферат диссертации д.т.н.: 05.13.01, Санкт-Петербургский государственный технический университет – СПб.: СПбГУТ, 1999 г.

46. Э. Такеда «Связность расплывчатых графов» – М.: Мир, 1976 г.

47. В. Петров «Структура телетрафика и алгоритм обеспечения качества обслуживания при влиянии эффекта самоподобия»: диссертации к.т.н.: 05.12.13, Московский энергетический институт – М., 2004 г.

48. В. Столлингс «Современные компьютерные сети» – СПб: Питер, 2003 г.

49. А. Иванов «Разработка и исследование алгоритмов прогнозирования и управления очередями в компьютерных сетях»: автореферат диссертации к.т.н.: 05.13.01, Санкт-Петербургский государственный технический университет – СПб.: СпбГТУ, 2001 г.

50. А. Городецкий, В. Заборовский «Информатика. Фрактальные процессы в компьютерных сетях: учебное пособие» – СПб.: СПбГТУ, 2000 г.

51. ITU-T Recommendation Y.2011 «Next Generation Networks – Frameworks and functional architecture models»

52. ITU-T Recommendation Y.101 «Global Information Infrastructure terminology: Terms and definitions»

53. ITU-T Recommendation Y.2001 «General overview of NGN»

54. E. Hitchcock «The Distribution of a Product from Several Sources to Numerous Localities» – Journal of Mathematics and Physics, №20, 1971

55. T. Koopmans «Optimum Utilization of the Transportation System, Proceedings of the International Statistical Conference» – Washington, 1977

56. B. Tsybakov, N. Georganas «Self-similar processes in communications networks» – IEEE Transaction Information Theory, vol.44, 1998

57. J. Beran «Prediction of 0-1-events for short- anf long- memory time series» – IEEE Transaction Information Theory, vol.51, 1999

58. Almeida V., de Oliveira A. On the Fractal Nature of WWW and Its Application to Cache Modeling II Anais do XXIII Seminario Integrado de Software e Hardware do XVI Congresso da SBC, Recife, Agosto de 1996, Brasil 1996.

59. Altman E., Jimenez T. NS for Beginners II Lecture Notes, Sept 2002 Univ. de Los Andes, Merida, Venezuela.

60. Bolot J.-C, Fosse-Parisis S., Towsley D. Adaptive FEC-Based Error Control for Interactive Audio in the Internet II In Proceedings IEEE INFOCOM, New York, NY, March 1999.

61. Интернет ресурсы  http://www.infanata.org/

62. Интернет ресурсы  http://www.twirpx.com

63. Интернет ресурсы   http://fledex.uz/

64. Интернет ресурсы  http://www.prolan.ru/ - LAN/Журнал сетевых решений. Декабрь 1998. Сергей Юдицкий, Владислав Борисенко, Олег Овчинников.

65. Интернет ресурсы  http://www.ua.all-biz.info

66. Интернет ресурсы  http://revolution.allbest.ru/

67. Интернет ресурсы  http://www.lanquest.com
68. Интернет ресурсы  http://www.data.com