Сеть NGN города Рязани

Размещено на http://www.allbest.ru/

Аннотация

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

The summary

In the degree project network NGN of city of Ryazan is developed. Are carried out a choice and substantiation of the equipment of a network, the questions of measurement of the basic parameters of a network are decided, all the necessary calculations are carried out, the cost of the project is calculated.

Оглавление

Введение

1. Технико-экономическое обоснование

2. Теоретическая часть

2.1 Особенности построения сетей NGN

2.2 Обзор услуг сетей NGN

2.3 Топология сети

2.4 Архитектура сети

2.5 Особенности построения сети доступа

2.6 Мониторинг и удалённое администрирование

3. Техническая часть

3.1 Разработка структурной схемы сети NGN

3.2 Аппаратура сетей NGN

3.3 Проектирование сети NGN

4. Конструктивно-технологическая часть

5. Экспериментальная часть

6. Экономическая часть

6.1 Календарный план разработки и ленточный график

6.2 Расчет затрат на разработку

6.3 Расчет цены НИР

6.4 Выводы по эффективности предложений

7. Безопасность и экологичность проекта

7.1 Анализ условий труда оператора ПЭВМ

7.2 Требования по обеспечению безопасности оператора ПЭВМ

7.3 Организация рабочего места оператора ПЭВМ

7.4 Обеспечение пожарной безопасности в помещении с ПЭВМ Заключение

Приложение

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

Введение

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

Трафик фиксированных сетей растет с высокой и постоянной скоростью с начала 1980-х годов. Так, мировой трафик Интернет рос в мире в последние годы на 60-80% ежегодно, а число абонентов широкополосных сетей увеличивалось со средней скоростью 60%. Стабильно, темпом 42-43% в год, развивается за последние четыре года и телекоммуникационная отрасль Российской Федерации. Страна вышла в лидеры по темпам развития мобильной связи. В 2003 г. число абонентов сотовых сетей увеличилось в 2 раза и достигло 36,4 млн. человек. Еще быстрее (180% в год) рос трафик Интернет. Объем рынка Интернет-услуг вырос на четверть и достиг 220 млн. долл., а число пользователей Интернет увеличилось до 14 млн. человек.

Потребности общества в новых услугах, рост трафика приводят к изменению идеологии построения сетей примерно каждые 10 лет. Так, в 1980-х годах появились оптические технологии; аналоговые беспроводные сети; широко распространились сети на основе стандарта Х.25. В 1990-х годах активно развивались оптические технологии, основанные на мультиплексировании с разделением и уплотнением по длине волны; разрабатывались и внедрялись мобильные сети 2-го поколения; началось использование Интернет в коммерческих приложениях.

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

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

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

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

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

Уровень управления услугами обеспечивает управление логикой услуг и приложений.

Такое функциональное разделение позволяет унифицировать задачи управления вызовами, отделив их от особенностей применяемых технологий передачи и коммутации. В результате становится возможным использовать одну и ту же логику услуги вне зависимости от типа транспортной сети (IP, ATM и т.д.), а также способа доступа.

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

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

1. Технико-экономическое обоснование

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

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

Сети NGN основываются на единой IP-сети, предоставляющей услуги передачи голоса, видео и данных с гарантированным качеством обслуживания. Главной архитектурной особенностью NGN заключается в том, что передача и маршрутизация пакетов и базовые элементы транспортной инфраструктуры (каналы, маршрутизаторы, коммутаторы, шлюзы) физически и логически отделены от устройств и механизмов управления вызовами и доступом к услугам. Таким образом устройства управления SoftSwich, различные шлюзы, сервера приложений и т.д. могут быть размещены в разных местах, что позволяет существенно снизить затраты на построение сети и транспортировку трафика. В сетях NGN реализуется полномасштабное предоставление услуг пакетной телефонии, голосовой и универсальной почты, IP-Centrex, телеобучения, VPN, передачи данных, видеоконференц-связи и т. д., включая дополнительные информационные сервисы.

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

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

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

2. Теоретическая часть

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

2.1 Принципы построения сетей NGN

Рассмотрим основные элементы сетей NGN.

Рис. 2.1.1

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

SoftSwitch, это не одно из сетевых устройств. Это так же и сетевая архитектура.

Сигнальный шлюз (SG) - обеспечивает доставку к SoftSwitch сигнальной информации, поступающей со стороны ТфОП, и в обратном направлении.

Транспортный шлюз (TG) - на него поступают потоки пользовательской информации со стороны ТфОП, он преобразует эту информацию в пакеты, и передаёт её по протоколу IP в сеть с коммутацией пакетов, причём делает это всё под управлением SoftSwitch.

Шлюз доступа (AG) - служит интерфейсом между IP-сетью и проводной или беспроводной сетью доступа, передаёт сигнальную информацию к SoftSwitch, преобразует пользовательскую информацию и передаёт её либо другому порту этой же IP сети, либо в другую сеть с коммутацией пакетов, либо к транспортному шлюзу, для последующей передачи в ТфОП.

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

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

Цифровая телевизионная станция - обеспечивает приём спутникового цифрового телевидения стандарта DVB и аналогового телевидения, и преобразует его в формат, пригодный для передачи по IP-сети.

STB - приёмник цифрового телевидения.

Основными протоколами сигнализации управления транспортными шлюзами являются MGCP и Megaco/H.248, а основными протоколами сигнализации взаимодействия между коммутаторами SoftSwitch являются SIP-T и BICC.

Для взаимодействия с сетями IP-телефонии используются протоколы SIP и H.323.

IP-телефония.

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

Докоммерческий этап характеризовался научно-исследовательской деятельностью в разных университетах и исследовательских организациях сообщества Интернет. Первая в истории попытка испробовать IP-телефонию была произведена в Т983 году в Кембридже, Массачусетс. В то время были созданы две рабочие группы IEFT: AVT (Audio/Video Transport) - группа транспортировки аудио/видео, которая создала транспортный протокол реального времени RTR и MMUSIC (Multiparty Multimedia Session Control) - группа управления мультимедийным сеансом, спроектировавшая семейство протоколов для мультимедийной конференцсвязи через Интернет, включая самый удачный протокол IP-телефонии - протокол SIP.

Компьютерный этап был начат израильской компанией VocalTec, сумевшей к 1995 году собрать воедино достижения в областях процессоров цифровой обработки сигналов (DSP), кодеков, компьютеров, протоколов маршрутизации. Первоначально продукты VocalTec допускали только соединения PC - PC. Все функции сигнализации и управления реализовались непосредственно в этих PC, а программное обеспечение сеансов связи все еще ориентировалось на нестандартные протоколы разных компаний-производителей. Но уже в июне 1996 года 16-я Исследовательская комиссия Международного союза электросвязи (ITU-T) согласовала версию 1 протокола Н.323, названную стандартом для видеоконференцсвязи с негарантированным качеством обслуживания через локальную вычислительную сеть. Этот первый «зонтичный» стандарт IP-телефонии появился в нужное время и открыл тем самым следующий этап инфокоммуникационных услуг.

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

Да и по мере развития первых сетей IP-телефонии стали проявляться недостатки и ограничения Н.323. Весьма важным ограничением стало то, что шлюз Н.323 обрабатывает сигнализацию, выполняет управление обслуживанием вызова и транскодирование транспортных потоков в едином блоке, что создает проблему масштабируемости при росте трафика. Кроме того, Н.323 не обеспечивает также возможности подключения к ОКС7, что препятствует его «бесшовной» интеграции с существующей телефонной сетью общего пользования. Для того чтобы справиться с этими проблемами, и была разработана концепция декомпозиции шлюза, при которой управление обслуживанием вызова сосредоточено в одном блоке, называемом Softswitch или контроллером транспортного шлюза MGC (Media Gateway Controller), а элементы преобразования транспортных потоков находятся в другом блоке, называемом транспортным шлюзом MG (Media Gateway). Тогда же, в 1998 году, был создан протокол управления шлюзами MGCP (Media Gateway Control Protocol), а после еще двух лет напряженной работы Исследовательской комиссии 16 ITU-T и IETF в июне 2000 появился стандарт управления транспортным шлюзом, названный Н.248 или MEGACO. Сам же мультимедийный трафик переносится по IP-сети, как правило, протоколом RTR.

Протокол RTP.

Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 2.1.2).



Рис. 2.1.2. Уровни протоколов RTP/UDP/IP.

На самом деле уровень, к которому относится RTP, не определяется настолько однозначно, как это показано на рис. 2.1.2. и как это обычно описывается в литературе. С одной стороны, протокол действительно работает поверх UDP реализуется прикладными программами и, по всем признакам, является прикладным протоколом. Но в то же время, RTP предоставляет транспортные услуги независимо от мультимедийных приложений и является, с этой точки зрения, просто транспортным протоколом. RTP--это транспортный протокол, реализованный на прикладном уровне.

Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис. 2.1.3.

Рис. 2.1.3. Заголовок VoIP.

Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP-заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2). Ясно, что при такой структуре заголовка возможна максимум еще только одна версия RTP. Следующее за ними поле содержит два бита: бит Р, который указывает, были ли добавлены в конце поля с полезной нагрузкой символы-наполнители (они обычно добавляются, если транспортный протокол или алгоритм кодирования требует использования блоков фиксированного размера), и бит X, который указывает, используется ли расширенный заголовок. Если он используется, то первое слово расширенного заголовка содержит общую длину расширения.

Далее, четыре бита СС определяют число CSRC-полей в конце RTP-заголовка, т.е. число источников, формирующих поток. Маркерный бит М позволяет отмечать то, что стандарт определяет как существенные события, например, начало видеокадра, начало слова в аудиоканале и т.п. За ним следует поле типа данных РТ (7 битов), где указывается код типа полезной нагрузки, определяющий содержимое поля полезной нагрузки - данные приложения (Application Data), например, несжатое 8-битовое аудио МРЗ и т.п. По этому коду приложение может узнать, что нужно делать, чтобы декодировать данные. Остальная часть заголовка фиксированной длины состоит из поля порядкового номера (SequenceNumber), поля метки времени (Time Stamp) для записи момента создания первого слова пакета и поля источника синхронизации SSRC, которое идентифицирует этот источник. В последнем поле можно указывать единственное устройство, имеющее только один сетевой адрес, множественные источники, которые могут представить различные мультимедийные среды (аудио, видео и т.д.), или разные потоки одной и той же среды. Так как источники могут быть на разных устройствах, SSRC-идентификатор выбирается случайным образом, чтобы шанс получать данные сразу от двух источников во время RTP-сеанса был минимальным. Однако определен также и механизм решения конфликтов, если они возникают. За фиксированной частью RTP-заголовка могут следовать еще до 15 отдельных 32-разрядных CSRC-полей, которые идентифицируют источники данных.

RTP поддерживается протоколом управления транспортировкой в реальном времени RTCP (Real-Time Transport Control Protocol), который формирует дополнительные отчеты, содержащие информацию о сеансах связи RTR Напомним, что ни UDP, ни RTP не занимаются обеспечением качества обслуживания QoS (Quality of Service). Протокол RTCP обеспечивает обратную связь с отправителями, а получателям потоков он предоставляет некоторые возможности повышения QoS, информацию о пакетах (потери, задержки, джиттер) и о пользователе (приложении, потоке). Для управления потоком существуют отчеты двух типов - генерируемые отправителями и генерируемые получателями. Например, информация о доле потерянных пакетов и абсолютном количестве потерь позволяет отправителю при получении отчета обнаруживать, что перегрузка канала может заставить получателей не принимать потоки пакетов, которые они ожидали. В этом случае отправитель имеет возможность понизить скорость кодирования, чтобы уменьшить перегрузку и улучшить прием. Отчет отправителя содержит информацию о том, когда был генерирован последний RTP-пакет (она включает в себя как внутреннюю метку, так и реальное время). Эта информация позволяет получателю координировать и синхронизировать множественные потоки, например, видео и аудио. Если поток направляется нескольким получателям, то организуются потоки RTCP-пакетов от каждого из них. При этом будут предприняты шаги для ограничения ширины полосы - обратно пропорционально скорости, с которой генерируются RTCP-отчеты, и числу получателей.

Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Как будет отмечено в следующем параграфе, кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии Ipv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.

Кодеки VoIP.

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

Использование полосы пропускания канала

Скорость передачи, которую предусматривают имеющиеся сегодня узкополосные кодеки, лежит в пределах 1.2-64 Кбит/с. Естественно, что от этого параметра прямо зависит качество воспроизводимой речи. Существует множество подходов к проблеме определения качества. Наиболее широко используемый подход оперирует оценкой MOS (Mean Opinion Score), которая определяется для конкретного кодека как средняя оценка качества большой группой слушателей по пятибалльной шкале. Для прослушивания экспертам предъявляются разные звуковые фрагменты - речь, музыка, речь на фоне различного шума и т.д. Оценки интерпретируют следующим образом:

· 4-5 - высокое качество; аналогично качеству передачи речи в ISDN, или еще выше;

· 3.5-4- качество ТфОП (toll quality); аналогично качеству речи, передаваемой с помощью кодека АДИКМ при скорости 32 Кбит/с. Такое качество обычно обеспечивается в большинстве телефонных разговоров. Мобильные сети обеспечивают качество чуть ниже toll quality;

· 3-3.5- качество речи, по-прежнему, удовлетворительно, однако его ухудшение явно заметно на слух;

· 2.5-3 - речь разборчива, однако требует концентрации внимания для понимания. Такое качество обычно обеспечивается в системах связи специального применения (например, в вооруженных силах).

В рамках существующих технологий качество ТфОП (toll quality) невозможно обеспечить при скоростях менее 5 Кбит/с. Подавление периодов молчания (VAD, CNG, DTX) При диалоге один его участник говорит, в среднем, только 35 процентов времени. Таким образом, если применить алгоритмы, которые позволяют уменьшить объем информации, передаваемой в периоды молчания, то можно значительно сузить необходимую полосу пропускания. В двустороннем разговоре такие меры позволяют достичь сокращения объема передаваемой информации до 50%, а в децентрализованных многоадресных конференциях (за счет большего количества говорящих) - и более. Нет никакого смысла организовывать многоадресные конференции с числом участников больше 5-6, не подавляя периоды молчания. Технология подавления таких периодов имеет три важные составляющие.

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

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

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

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

Генератор комфортного шума (Comfort Noise Generator - CNG) служит для генерации фонового шума. В момент, когда в речи активного участника беседы начинается период молчания, терминалы слушающих могут просто отключить воспроизведение звука. Однако это было бы неразумно. Если в трубке возникает «гробовая тишина», т.е. фоновый шум (шум улицы и т.д.), который был слышен во время разговора, внезапно исчезает, то слушающему кажется, что соединение по каким-то причинам нарушилось, и он обычно начинает спрашивать, слышит ли его собеседник.

Генератор CNG позволяет избежать таких неприятных эффектов. Простейшие кодеки просто прекращают передачу в период молчания, и декодер генерирует какой-либо шум с уровнем, равным минимальному уровню, отмеченному в период речевой активности. Более совершенные кодеки (G.723.1 Annex A, G. 729 Annex В) имеют возможность предоставлять удаленному декодеру информацию для восстановления шума с параметрами, близкими к фактически наблюдавшимся.

Большинство узкополосных кодеков обрабатывает речевую информацию блоками, называемыми кадрами (frames), и им необходимо производить предварительный анализ отсчетов, следующих непосредственно за отсчетами в блоке, который они в данный момент кодируют.

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

Можно, казалось бы, заключить, что кодеки с меньшим размером кадра лучше в смысле такого важного критерия как минимизация задержки. Если, однако, учесть, что происходит при передаче информации по сети, то мы увидим, что к кадру, сформированному кодеком, добавляется множество дополнительной информации -заголовки IP (20 байтов), UDP (8 байтов), RTP (12 байтов). Для кодека с длительностью кадра 30 мс посылка таких кадров по сети привела бы к передаче избыточной информации со скоростью 10.6 кбит/с, что превышает скорость передачи речевой информации у большинства узкополосных кодеков.

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

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

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

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

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

Влияние потерь кадров на качество воспроизводимой речи зависит от используемого кодека. Если потерян кадр, состоящий из N речевых отсчетов кодека G.711, то на приемном конце будет отмечен пропуск звукового фрагмента длительностью N*125 мкс. Если используется более совершенный узкополосный кодек, то потеря одного кадра может сказаться на воспроизведении нескольких следующих, так как декодеру потребуется время для того, чтобы достичь синхронизации с кодером -потеря кадра длительностью 20 мс может приводить к слышимому эффекту в течение 150 мс и более.

Кодеры типа G.723.1 разработаны так, что они функционируют без существенного ухудшения качества в условиях некоррелированных потерь до 3% кадров, однако при превышении этого порога качество ухудшается катастрофически.

Кодек G.711 - «дедушка» всех цифровых кодеков речевых сигналов, был одобрен ITU-T в 1965 году. Применяемый в нем способ преобразования аналогового сигнала в цифровой с использованием полулогарифмической шкалы был достаточно подробно описан выше. Типичная оценка MOS составляет 4.2. В первую очередь .отметим, что, как и для ТфОП, минимально необходимым для оборудования VoIP является ИКМ-кодирование G.711. Это означает, что любое устройство VoIP должно поддерживать этот тип кодирования.

Рекомендация G.723.1 утверждена ITU-T в ноябре 1995 года. Форум IMTC выбрал кодек G.723.1 как базовый для приложений IP-83 телефонии.

Кодек G.723.1 производит кадры длительностью 30 мс с продолжительностью предварительного анализа 7.5 мс. Предусмотрено два режима работы: 6.3 Кбит/с (кадр имеет размер 189 битов, дополненных до 24 байтов) и 5.3 Кбит/с (кадр имеет размер 158 битов, дополненных до 20 байтов). Режим работы может меняться динамически от кадра к кадру. Оба режима обязательны для реализации.

Оценка MOS составляет 3.9 в режиме 6.3 Кбит/с и 3.7 в режиме 5.3 Кбит/с.

Кодек специфицирован на основе операций как с плавающей точкой, так и с фиксированной точкой в виде кода на языке С. Реализация кодека на процессоре с фиксированной точкой требует производительности около 16 MIPS.

Кодек G.723.1 имеет детектор речевой активности и обеспечивает генерацию комфортного шума на удаленном конце в период молчания. Эти функции специфицированы в приложении A (Annex А) к рекомендации G.723.1. Параметры фонового шума кодируются очень маленькими кадрами размером 4 байта. Если параметры шума не меняются существенно, передача полностью прекращается.

Кодек G.726. Алгоритм кодирования АДИКМ (рекомендация ITU-TG.726, принятая в 1990 г.) описан выше. Он обеспечивает кодирование цифрового потока G.711 со скоростью 40, 32, 24 или 16 Кбит/с, гарантируя оценки MOS на уровне 4.3 (32 Кбит/с), что часто принимается за эталон уровня качества телефонной связи (toll quality). В приложениях IP-телефонии этот кодек практически не используется, так как он не обеспечивает достаточной устойчивости к потерям информации (см. выше).

Кодек G.728 использует оригинальную технологию с малой задержкой LD-CELP (low delay code excited linear prediction) и гарантирует оценки MOS, аналогичные АДИКМ G.726 при скорости передачи 16 Кбит/с. Данный кодек специально разрабатывался как более совершенная замена АДИКМ для оборудования уплотнения телефонных каналов, при этом было необходимо обеспечить очень малую величину задержки (менее 5 мс), чтобы исключить необходимость применения эхокомпенсаторов Это требование было успешно выполнено учеными Bell JLabs в 1992 году: кодер имеет длительность кадра только 0.625 мс. Реально задержка может достигать 2.5 мс, так как декодер должен поддерживать синхронизацию в рамках структуры из четырех кадров.

Недостатком алгоритма является высокая сложность - около 20 MIPS для кодера и 13 MIPS для декодера - и относительно высокая чувствительность к потерям кадров.

Кодек G.729 очень популярен в приложениях передачи речи по сетям Frame Relay. Он использует технологию CS-ACELP (Conjugate Structure, Algebraic Code Excited Linear Prediction). Кодек использует кадр длительностью 10 мс и обеспечивает скорость передачи 8 Кбит/с. Для кодера необходим предварительный анализ сигнала продолжительностью 5 мс.

Существуют два варианта кодека:

* G.729 (одобрен ITU-T в декабре 1996), требующий около 20 MIPS для кодера и 3 MIPS для декодера.

* Упрощенный вариант G.729A (одобрен ITU-T в ноябре 1995), требующий около 10.5 MIPS для реализации кодера и около 2 MIPS для декодера.

В спецификациях G.729 определены алгоритмы VAD, CNG и DTX. В периоды молчания кодер передает 15-битовые кадры с информацией о фоновом шуме, если только шумовая обстановка изменяется.

В рамках деятельности европейского института ETSI стандартизованы узкополосные кодеки для применения в системах мобильной связи (GSM).

Спецификации кодека GSM Full Rate, известного также как GSM 06.10, утверждены в 1987г. Это первый и, скорее всего, наиболее известный из узкополосных кодеков, применяемый в миллионах мобильных телефонов по всему миру. Обеспечивает хорошее качество и устойчивую работу в условиях фонового шума (оценка MOS порядка 3.7 в условиях без шума). Кодируются кадры длительностью 20 мс, образуя цифровой поток со скоростью 13 Кбит/с. Кодек не требует высокой производительности процессора - необходимо только 4.5 MIPS для дуплексной реализации. Кодек очень важен для некоммерческих проектов в области IP-телефонии, особенно -для проектов, связанных с открытым распространением исходных текстов ПО (open source), благодаря возможности бесплатного лицензирования. Такие проекты сегодня могут использовать только кодеки GSM FR и G.711, а также АДИКМ.

Существуют также спецификации кодеков GSM Half Rate, принятые в 1994 году, и GSM Enhanced Full Rate, принятые в 1995 году. Характеристики этих кодеков превосходят характеристики исходного варианта, описанного выше, однако алгоритмы требуют большей производительности процессора (до 30 MIPS). В приложениях IP-телефонии они, по разным причинам, распространения пока не получили.

Рассмотрение кодеков было бы неполным, если бы, наряду со специфицированными ITU-T и ETSI, не были упомянуты и т.н. нестандартные кодеки.

Сегодня в приложениях VoIP, кроме кодеков, прошедших процедуры международной стандартизации в ITU-T и ETSI, в продуктах ряда фирм-производителей применяются также нестандартные внутрифирменные алгоритмы. Такие алгоритмы часто лицензируются для использования в продуктах других компаний. В качестве примеров можно назвать такие кодеки, как Lucent/Elemedia SX7003P, имеющий очень хорошие характеристики при умеренной вычислительной сложности, и Voxware RT24, который предусматривает сверхнизкую (2.4 Кбит/с) скорость передачи информации при сохранении достаточно хорошего качества речи (оценка MOS около 3.2).

Передача сигналов DTMF

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

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

Когда пользователю ТфОП нужно ввести какую-то дополнительную информацию в удаленную систему при уже установленном соединении (например, номер дебитной карты или номер пункта меню автоинформатора), необходимо обеспечить возможность надежной передачи DTMF-сигналов через сеть IP-телефонии. В случаях, когда система, взаимодействующая с пользователем, просто задает вопрос и ждет ввода, длительность и момент передачи сигнала не важны. В других случаях система зачитывает пользователю список и просит его нажать, например, кнопку «#», как только он услышит нужную информацию; здесь ситуация более сложная, и необходима более точная привязка ко времени.

Существуют два основных метода передачи сигналов DTMF по сетям IP-телефонии.

· Обязательный метод. Специальное сообщение протокола Н.245 (Userlnputlndication) может содержать символы цифр и «*», «#». В данном случае используется надежное ТСР-соединение, так что информация не может быть потеряна. Однако из-за особенностей TCP могут иметь место значительные задержки;

· Нестандартный метод, предложенный Форумом VoIP. Он может быть применен в терминалах H.323v2 при использовании процедуры fastStart и отсутствии канала Н.245. Для передачи сигналов DTMF открывается специальная RTP-сессия, в которой передаются кодированные значения принятых цифр, а также данные об амплитуде и длительности сигналов. Может быть использована та же сессия, что и для речи, но со специальным типом полезной нагрузки. Использование RTP позволяет привязать DTMF- сигналы к реальному времени, что является важным преимуществом данного метода.

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

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

Сценарии IP-телефонии.

Сети Н.323.

Первый в истории подход к построению сетей IP-телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации Н.323. Сети на базе протоколов Н.323 ориентировались на интеграцию с телефонными сетями и вначале рассматривались как сети ISDN, наложенные на IP-сети.

Рекомендация Н.323 включает в себя довольно сложный набор протоколов, который предназначен не просто для передачи речевой информации по IP-сетям с коммутацией пакетов, а обеспечивает работу мультимедийных приложений в сетях с не гарантированным качеством обслуживания. Речевой трафик - это только одно из приложений Н.323, наряду с видео и данными. Протокол RAS (Registration, Admission, Status), входящий в семейство протоколов Н.323, обеспечивает контроль использования сетевых ресурсов и поддерживает аутентификацию пользователей и начисление платы за услуги. Основными устройствами сети Н.323 являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit.

Входящий в состав Н.323 протокол Н.225.0 (Q.931) специфицирует процедуры установления, поддержания и разрушения соединения, а в качестве транспортного протокола использует протокол TCP. По протоколу Н.245 происходит обмен между участниками соединения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упакованная в пакеты RTP/UDP/IP, которые рассмотрены выше и представлены на рис. 2.1.2.

Еще одна важная проблема - качество обслуживания в сетях Н.323. Оконечное устройство, запрашивающее у привратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы. Рекомендация Н.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVR К сожалению, этот протокол используется отнюдь не повсеместно, что оставляет сети Н.323 без основного механизма обеспечения гарантированного качества обслуживания. Это - общая проблема сетей IP-телефонии, характерная не только для сетей Н.323.

SIP-сеть.

Более популярный сегодня подход к построению сетей IP-телефонии был предложен рабочей группой IETF с музыкальным названием MMUSIC в документе RFC 2543. Положенный в его основу протокол SIP (Session Initiation Protocol) рассматривается в следующей главе книги и является частью разработанной IETF глобальной архитектуры мультимедиа. Эта архитектура включает в себя также протокол резервирования ресурсов RSVP (Resource Reservation Protocol), рассмотренные выше в этой главе транспортный протокол реального времени RTP (Real-Time Transport Protocol; RFC 1889) и протокол передачи потоков в реальном времени RTSP (Real-Time Streaming Protocol; RFC 2326), протокол описания параметров связи SDP (Session Description Protocol; RFC 2327), а также протокол уведомления о связи SAP (Session Announcement Protocol). Сразу же подчеркнем, что функции протокола SIP не зависят ни от одного из этих протоколов.

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

Сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации. Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя - клиент UAC (User Agent Client) и агент пользователя - сервер UAS (User Agent Server). Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и передает обратно ответы, т.е. выступает в качестве вызываемой стороны. Кроме того, существует два типа сетевых серверов SIP: прокси-серверы (серверы-посредники) и серверы переадресации. Серверы SIP могут работать как в режиме с сохранением данных о состояниях текущих соединений (statefull), так и в режиме без сохранения таких данных (stateless). Сервер SIP, функционирующий в режиме stateless, может обслужить сколь угодно большое количество пользователей, в отличие от привратника Н.323, который может одновременно работать с ограниченным количеством пользователей.

Управление шлюзами MGCP и MEGACO.

Третий подход к построению сетей IP-телефонии, основанный на использовании протокола MGCP, также предложен комитетом IETF - его рабочей группой MEGACO. При разработке этого протокола рабочая группа MEGACO опиралась на сетевую архитектуру, аналогичную рассмотренной в главах 1 и 2 содержащую следующие представленные на рис. 2.1.4 функциональные блоки:

· транспортный шлюз MG (Media Gateway), выполняющий функции преобразования речевой информации, которая поступает от ТфОП, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP (кодирование и упаковку речевой информации в пакеты RTP/UDP/IR а также обратное преобразование);

· контроллер шлюзов MGC (Media Gateway Controller, Softswitch, Call Agent), который выполняет функции управления шлюзами;

· шлюз сигнализации SG (Signaling Gateway), который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к контроллеру шлюзов и перенос сигнальной информации в обратном направлении.

Рис 2.1.4. Архитектура VoIP сети на базе протокола MGCP.

Таким образом, весь интеллект функционально распределенного шлюза сосредоточен в Softswitch (MGC, Call Agent), который, к тому же, вместе со шлюзом сигнализации, выполняет функции транзитного STP или оконечного SP пункта сети сигнализации ОКС7.

Но перед этим, чтобы оправдать само название параграфа, рассмотрим сценарии установления и разрушения соединения с использованием протоколов MGCP и ОКС7 (рис. 2.1.5).



Рис. 2.1.5. Пример установления и разрушения соединения IP-телефонии.

Пример на рис. 1.1.5 охватывает взаимодействие протокола MGCP с протоколом ОКС7. Отметим, что протокол MGCP является master/slave-протоколом, т.е. Softswitch здесь является ведущим, а шлюз - ведомым устройством, которое должно выполнять все команды, поступающие от Softswitch. Благодаря этому шлюзы не должны быть интеллектуальными устройствами, требуют меньшей производительности процессоров и, следовательно, становятся менее дорогими. Кроме того, очень быстро вводятся новые протоколы сигнализации или дополнительные услуги, так как эти изменения затрагивают только Softswitch, а не сами шлюзы.

1. От телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения в виде сообщения IAM протокола ISUP [12]. Для простоты на 1.1.5 шлюз сигнализации SG1 совмещен с транспортным шлюзом TGW1. Шлюз SG1 передает сообщение IAM к контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к АТС-Б через шлюз TGW2.

2. Далее контроллер резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnection. Отметим, что порт шлюза TGW1 может только принимать информацию (режим recvonly), так как он еще не осведомлен о том, по какому адресу и каким образом ему следует передавать информацию.

3. В ответе на эту команду шлюз TGW1 передает описание параметров сеанса связи.

4. Приняв ответ шлюза TGW1, контроллер передает команду CRCX второму шлюзу TGW2 с целью резервировать порт в этом шлюзе.

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

6. Далее контроллер шлюзов передает сообщение IAM к АТС-Б.

7. На сообщение IAM станция АТС-Б отвечает подтверждением АСМ, которое немедленно пересылается к станции АТС-А.

8. После того как вызываемый абонент примет вызов, АТС-Б передает к контроллеру шлюзов сообщение ANM.

9. Далее контроллер заменяет в шлюзе TGW1 режим «recvonly» на полнодуплексный режим.

10. Шлюз TGW1 выполняет и подтверждает изменение режима.

11. Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения.

12. Завершение разговорной фазы происходит следующим образом. В нашем случае вызвавший абонент дает отбой первым. АТС-А передает через шлюз сигнализации сообщение REL к контроллеру шлюзов.

13. Приняв сообщение REL, контроллер шлюзов разрушает соединение с вызывавшим абонентом.

14. Шлюз подтверждает разрушение соединения и передает к контроллеру собранные за время соединения статистические данные.

15. Далее контроллер шлюзов передает сообщение RLC к АТС-А с целью подтвердить разъединение.

16. Параллельно контроллер разрушает соединение с вызванной стороной.

17. Шлюз TGW2 подтверждает разрушение соединения и передает к контроллеру собранные за время соединения статистические данные.

18. После приема ответа на команду DLCX контроллер может начинать процедуру разрушения соединения с АТС-Б, которая должна подтвердить разъединение, после чего соединение считается разрушенным.

Отметим, что в приведенном сценарии использован протокол MGCP, что обусловлено следующим. Рабочая группа MEGACO комитета IETF усовершенствовала процедуры управления шлюзами, в результате чего был разработан протокол MEGACO с более широкими, чем у MGCP, функциональными возможностями.

Параллельно с этим Международный союз электросвязи ITU-T в версии 4 рекомендации Н.323 ввел принцип декомпозиции шлюзов, согласно которому управление функциональными блоками распределенного шлюза производится контроллером шлюза MGC при помощи протокола MEGACO, который в рекомендации Н.248 назван Gateway Control Protocol.

В технической литературе этот протокол обычно именуется Megaco/Н.248 или просто Н.248. Сообщения протокола Megaco отличаются от сообщений протокола MGCP, но процедуры установления и разрушения соединений с использованием обоих протоколов идентичны. По этой причине в этом и следующем (рис. 2.1.6) сценарии использован протокол MGCP.

Общеканальная сигнализация

Шлюз сигнализации должен принимать поступающие из ТфОП пакеты трех нижних уровней системы сигнализации ОКС7 (уровней подсистемы переноса сообщений МТР) и передавать сигнальные сообщения верхнего, пользовательского, уровня к контроллеру шлюзов. Шлюз сигнализации должен также уметь передавать по IP-сети приходящие из ТфОП сигнальные сообщения Q.931.

Для этих целей рабочая группа Sigtran комитета IETF разработала эффективный механизм передачи сигнальной информацииОКС7 по IP-сетям. По целому ряду причин пришлось отказаться от использования для этой цели протокола TCP, вместо которого рабочая группа Sigtran разработала протокол транспортировки информации с управлением потоками SCTP (Stream Control Transport Protocol), имеющий ряд преимуществ перед TCP, основным из которых является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения.

В качестве продолжения сценария из предыдущего раздела на рис. 3.5 приведен второй пример, охватывающий взаимодействие протокола MGCP с протоколами ОКС7 и DSS1.

1. С телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения (сообщение IAM). На рис. 3.5 шлюз сигнализации SG1 также совмещен с транспортным шлюзом TGW1. Шлюз SG1 передает сообщение IAM к контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к оконечному устройству вызываемого пользователя - терминалу Н.323.

2. Далее контроллер шлюзов резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnection. И в этом примере порт шлюза TGW1 может пока только принимать информацию (режим «recvonly»).

3. В ответе на принятую команду шлюз TGW1 передает описание параметров связи.

4. Приняв ответ от шлюза TGW1, контроллер передает к привратнику сети Н.323 сообщение ARQ с alias-адресом вызываемого абонента.

5. В ответ на сообщение ARQ привратник передает сообщение ACF с указанием транспортного адреса своего сигнального канала.

6. Далее контроллер передает запрос соединения SETUP на транспортный адрес сигнального канала привратника, при этом используется процедура Fast Start. Привратник пересылает сообщение SETUP к вызываемому терминалу.

7. Вызываемый терминал передает запрос допуска к ресурсам ceTnARQ.

8. В ответ на запрос ARQ привратник передает подтверждение запроса ACF.

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

10. Контроллер преобразует сообщение ALERTING в сообщение АСМ, которое немедленно пересылается к АТС-А.

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