IP-телефония и традиционные телефонные сети

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

IntServ определяет три класса обслуживания для IP-сетей:

- по мере возможности - то, что сейчас предлагает Internet;

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

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

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

Дифференцированное обслуживание предлагает более простой и масштабируемый метод QoS для приложений реального времени. Одним из ключевых моментов в работе над DiffServ является переопределение 8-битного поля «Тип сервиса» в заголовке IPv4. Названное «Дифференцированным обслуживанием» (DS, приложение), это поле может содержать информацию, на основании которой узлы вдоль маршрута определяют, как им следует обрабатывать пакеты и передавать их следующему маршрутизатору.

В настоящее время только 6 из 8 бит в поле DS были определены, и только одно назначение было стандартизовано. Это назначение известно как принятое по умолчанию - Default и оно определяет класс обслуживания по мере возможности. Другое предполагаемое назначение, срочная отправка (Expedited Forwarding, EF), должно обеспечить сокращение задержек и потерь пакетов.

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

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

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

3.1.5 Обеспечение качества IP-телефонии на базе MPLS

Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект IETF под названием «Многопротокольная коммутация меток» (Multiprotocol Label Switching, MPLS).

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

IP-коммутация поддерживает различные уровни QoS и может использовать ATM, имеющий многочисленные встроенные средства поддержки QoS, и RSVP.

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

Если DiffServ задействует заголовок DS, уже имеющийся в пакетах IPv4, то MPLS (приложение) использует 32-разрядную информационную метку, добавляемую к каждому IP-пакету. Эта метка, добавляемая при входе в сеть с поддержкой MPLS, сообщает каждому маршрутизатору вдоль пути следования, как надо обрабатывать пакет. В частности, она содержит информацию о требуемом для данного пакета уровне QoS.

В отличие от поля DS, метка MPLS изначально не является частью пакета IP. Скорее, она добавляется при поступлении пакета в сеть и удаляется при выходе пакета из сети MPLS.

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

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

По сути, MPLS привносит коммутацию каналов, какую мы имеем в ATM, в мир пакетных сетей, связанных с IP. На практике MPLS можно использовать для доставки IP-трафика по сетям IP.

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

А ввиду того, что MPLS предполагает включение дополнительных меток и использование маршрутизаторов/коммутаторов, способных интерпретировать данную информацию, он, вероятно, найдет применение исключительно внутри корпоративных сетей или базовой сети оператора, где требуется высокий уровень QoS для 1Р-трафика.

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

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

3.2 Общие принципы сигнализации в сетях IP-телефонии

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

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

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

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

В системах IP-телефонии процедуры управления вызовами выполняются протоколами сигнализации, а непосредственная маршрутизация трафика через IP-сеть обеспечивается протоколами: OSPF или ВGР (резервирование сетевых ресурсов возможно, например, при помощи протокола RSVP). Таким образом, архитектура сети IP-телефонии предусматривает разделение плоскостей управления и передачи пользовательской информации, что является наиболее благоприятным условием для внедрения новых услуг (демонстрационный лист 4).

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

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

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

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

Приложение может представлять собой телефонный шлюз.

В общем случае для установления соединения между вызываемым и вызывающим абонентом шлюзы IP-телефонии должны:

- найти gatekeeper, на котором возможна регистрация оконечного устройства;

- зарегистрировать свой мнемонический адрес на gatekeeper;

- указать требуемую полосу пропускания;

- передать запрос на установление соединения;

- установить соединение;

- в процессе вызова управлять параметрами соединения;

- разъединить соединение.

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

3.3 Межсетевое взаимодействие

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

В третьей версии рекомендаций Н.323 появилось приложение G к Н.225. В нем описан метод взаимодействия административных доменов с помощью объекта, называемого «пограничным элементом» (Border Element). Этот функциональный элемент поддерживает открытый доступ к административному домену для доведения вызова до входящего в этот домен узла или предоставления других услуг, требующих установления мультимедиасвязи с его узлами.

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

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

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

S1: Обмен информацией разрешения запроса между терминалом и gatekeeper 1.

S2: Обмен информацией разрешения запроса между gatekeeper 1 и сервером авторизации.

S3: Обмен информацией разрешения запроса между gatekeeper 1 и шлюзом.

S4: Обмен информацией разрешения запроса между шлюзом и его gatekeeper.

S5: Обмен информацией разрешения запроса между gatekeeper 2 и сервер от третьего лица.

S6: Обмен информацией разрешения запроса между gatekeeper 1 и gatekeeper 2.

Следует особо отметить, что реализация передачи сигнальной информации между различными административными доменами в сети IP-телефонии требует обеспечения соответствующей степени защиты информации [8].

3.4 Построение сети доступа для новых групп пользователей

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

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

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

В структуре пользователей можно выделить незначительное число абонентов, готовых использовать максимальное количество предоставляемых услуг. Удельная доля дохода этих абонентов самая высокая. Как правило, среди операторов ведётся борьба именно за эту часть пользователей. Скорее всего, это корпоративные пользователи, потребляющие весь спектр услуг «Triple Play». Несомненно, для организации обслуживания данного сектора придётся организовать широкополосный доступ. По оценкам аналитической группы J'son & Partners, на сегодняшний день использование широкополосного доступа в офисе наблюдается почти в 85% случаев.

3.4.1 Расчёт производительности узла доступа

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

Доля абонентов группы 1 составляет ₁ 80%. Это традиционные абоненты, совершающие в среднем f₁ = 5 вызовов в час средней длительностью t₁ = 2 минуты.

Доля абонентов группы 2, использующих голосовые сервисы и сервисы передачи данных, составляет ₂ 15%. Нагрузка, создаваемая этими абонентами, складывается из двух составляющих: телефония и интернет. Параметры телефонной нагрузки совпадают с аналогичными параметрами для группы 1, f₂ = f₁ = 5 вызовов в час, t₂ = t₁ = 2 минуты. Объём переданных данных в час наибольшей нагрузки ограничивается 10 Мбайт.

Доля абонентов группы 3, приносящих наибольших удельный доход, составляет ₃ 5%. Структура трафика для этих пользователей складывается следующим образом: телефония, интернет, видео. Параметры трафика телефонии совпадают с аналогичными параметрами для группы 2, т.е. f₃ = f₂ = f₁ = 5 вызовов в час, t₃ = t₂ = t₁ = 2 минуты. При расчёте трафика передачи данных необходимо учесть, что пользователи этой группы, как правило, активнее используют ftp и пиринговые сети. Допустим, что они потребляют до 100 Мбайт трафика. Время просмотра видео в час наибольшей нагрузки достигает 60 минут.

Определим число IP-пакетов, генерируемых каждой группой в час наибольшей нагрузки, при условии, что мультисервисный узел доступа обслуживает N = 4000 абонентов.

3.4.2 Расчёт числа пакетов от первой группы (телефония)

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

Наилучшее качество речи обеспечивает кодек G.711. Длительность дейтаграммы T_PDU равна 20 мс, согласно рекомендации RFC 1889. При этом в секунду передаётся:

n₁ = 1/ TPDU, кадров, (3.1)

n₁ = 1/0,02 = 50, кадров в секунду

Размер пакетизированных данных:



h = v·T_PDU, (3.2)

где v - скорость кодирования, байт/с; h - размер пакетизированных данных; T_PDU - длительность одной речевой выборки (длительность пакета).

При использовании кодека G.711 скорость кодирования:

v = 64000/8 = 8000, байт/с,

h = 8000· 0,020 = 160, байт

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

Ip - 20, байт,

UDP - 8, байт,

RTP - 12, байт.

Суммарный размер пакета - 160 + 20 + 8 +12 = 200 байт.

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

N₁ = n₁· t₁·f₁·₁·N, (3.3)

где N₁ - число пакетов, генерируемое первой группой пользователей в час наибольшей нагрузки; n₁ - число пакетов, генерируемых в секунду одним абонентом при использовании кодека G.711; t₁ - средняя длительность разговора в секундах для первой группы абонентов; f₁ - число вызовов в час наибольшей нагрузки для первой группы абонентов; ₁ - доля пользователей группы 1 в общей структуре абонентов; N - общее число пользователей.

3.4.3 Расчёт числа пакетов от второй группы (телефония и интернет)

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

N_{2_т} = n₁· t₂· f₂·₂· N, 3.4)

где N_{2_т} - число пакетов, генерируемое второй группой пользователей в час наибольшей нагрузки при использовании голосовых сервисов; n₁ - число пакетов, генерируемых в секунду одним абонентом при использовании кодека G.711; t₂ - средняя длительность разговора в секундах для второй группы абонентов; f₂ - число вызовов в час наибольшей нагрузки для второй группы абонентов; ₂ - доля пользователей группы 2 в общей структуре абонентов; N - общее число пользователей.

Для расчёта числа пакетов, генерируемых второй группой пользователей при использовании сервисов передачи данных, необходимо задаться размером пакетов. При построении сети NGN, как правило, на одном или нескольких участках сети на уровне звена данных используется та или иная разновидность технологии Ethernet, поэтому использовать пакеты, превышающие максимальную длину поля данных Ethernet, не имеет смысла. Очень длинный пакет рано или поздно будет фрагментирован, что приведёт, во-первых, к излишней нагрузке на коммутаторы, и, во-вторых, к возможным перезапросам в случае потерь. Кроме того, использование пакетов большого размера затрудняет обеспечение качества обслуживания и на магистральной сети, и в сети доступа. Более того, как правило, корпоративные пользователи устанавливают на границе своей сети файервол, который, иногда, ограничивает максимальный размер кадра. Поэтому для расчёта выберем одинаковые размеры пакетов и при передаче данных, и при передаче голосового трафика - полезная нагрузка 160 байт. При передаче данных вместо протоколов RTP и UDP используется TCP, вносящий точно такую же избыточность (20 байт).

Для расчёта числа пакетов в час наибольшей нагрузки необходимо задаться объёмом переданных данных. Предположим, что абоненты второй группы относятся к интернет-сёрферам, т.е. в основном просматривают веб-страницы. Средний объём данных, переданных за час при таком способе подключения, составит около V₂ = 10 Мбайт = 80 Мбит. Число пакетов, переданных в ЧНН, будет равно

N_{2_д} = ₂· N ·V₂/h, (3.5)

где N_{2_д} - количество пакетов, генерируемых в час наибольшей нагрузки абонентами второй группы при использовании сервисов передачи данных; ₂ - доля пользователей группы 2 в общей структуре абонентов; h - размер поля данных пакета; N - общее число пользователей.

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

N₂ = N_{2_т} + N_{2_д} (3.6)

3.4.4 Расчёт числа пакетов от третьей группы абонентов (triple play)

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

N_{3_т} = n₁· t_{3_т}· f₃· ₃· N, (3.7)

где N_{3_т} - число пакетов, генерируемое третьей группой пользователей в час наибольшей нагрузки при использовании голосовых сервисов; n₁ - число пакетов, генерируемых в секунду одним абонентом при использовании кодека G.711; t₃ - средняя длительность разговора в секундах; f₃ - число вызовов в час наибольшей нагрузки; ₃ - доля пользователей группы 3 в общей структуре абонентов; N - общее число пользователей.

Предположим, что абоненты третьей группы относятся к «активным» пользователям интернета, т.е., используют не только http, но и ftp, а также прибегают к услугам пиринговых сетей. Объём переданных и принятых данных данных при таком использовании интернета составляет до V₃ = 100 Мбайт = 800 Мбит.

Число пакетов, переданных в ЧНН, будет равно:

N_{3_д} = ₃· N · V₃/h (3.8)

Для расчёта числа пакетов, генерируемых пользователями видео-услуг, воспользуемся соображениями относительно размера пакета, приведёнными в предыдущем пункте. Размер пакета не должен превосходить 200 байт (вместе с накладными расходами).

Одной из наиболее перспективных и динамически развивающихся услуг является IPTV - передача каналов телевещания с помощью протокола IP. При организации данного сервиса для каждого пользователя в транзитной сети доступа не требуется выделения индивидуальной полосы пропускания. До мультисервисного узла доходит определённое количество каналов, которые распределяются между заказчиками услуги, причём существует возможность организации широковещательной рассылки. Допустим, что в мультисервисной сети предоставляется возможность просмотра K_tv = 40 каналов вещания. Для обеспечения удовлетворительного качества скорость кодирования должна быть порядка 2 Мбит/с.

Итак, при скорости передачи v = 2048000 бит/с и размере полезной нагрузки пакета h = 160 байт = 1280 бит число пакетов, возникающих при трансляции одного канала, равно:



n₃ = v/h, (3.9)

n₃ = 2048000/1280 = 1600, пакетов в секунду

Количество пакетов, генерируемых 40 каналами в ЧНН, составит:

N_{3_В} = K_tv · n₃ · t_{3_В} · 60, (3.10)

где N_{3_В} - число пакетов, генерируемое третьей группой пользователей в час наибольшей нагрузки при использовании видео-сервисов сервисов; n₃ - число пакетов, генерируемых в секунду одним абонентом при использовании просмотре видео, сжатого по стандарту MPEG2; K_tv - число каналов вещания, организуемых в мультисервисной сети; t_{3_В} - среднее время просмотра каналов в ЧНН, мин.

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

N₃ = N_{3_т} + N_{3_д} + N_{3_В}

3.4.5 Требования к производительности мультисервисного узла доступа

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

Суммарное число пакетов, которое должен обработать мультисервисный узел доступа, будет равно:

N_У = N₁ + N₂ + N₃ = n₁· t₁·f₁·₁·N + (n₁· t₂· f₂· ₂· N + ₂· N · V₂/h) +

+ (n₁· t₃·f3·₃· N + ₃·N ·V₃/h + K_tv·n₃ · t_{3_В}· 60) (3.12)



Учитывая, что:

t₁ = t₂ = t₃ = t - средняя длительность разговора в секундах;

f₃ = f₂ = f₁ = f - число вызовов в ЧНН;

Получим:

N_У = n₁ · t · f ·N · (₁+₂ +₃)+N/h · ( ₂·V₂+₃·V₃)+K_tv· n₃ · t_{3_В}· 60

Учитывая, что

₁ + ₂ + ₃ = 1

N_У = N · (n₁ · t_Т · f + ( ₂·V₂ + ₃·V₃)/h) + K_tv· n₃ · t_{3_В} · 60 (3.14)

При N = 4000 абонентов, n₁ = 50 пакетов в секунду, t =120 секунд, f = 5 вызовов в час, V₂ = 10 Мбайт, V₃ = 100 Мбайт, t_{3_В} = 60 минут, n₃ = 1600, ₁ = 80%, ₂ = 15%, ₃ = 5% получим:

N_У = 4000 · (50·120· 5+ (0,15· 10⁷+0,05·10⁸)/160) + 40·1600· 60· 60 = 5,129·10⁸ , пакетов в ча

Среднее число пакетов в секунду равно:

N_{У_сек} = N_У/3600,

N_{У_сек} = 142472, пакетов/сек

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

3.4.6 Требования к полосе пропускания

Требования к полосе пропускания определяются гарантиями качества обслуживания, предоставляемыми оператором пользователю. Параметры QoS описаны в рекомендации ITU Y.1541. В частности, задержка распространения из конца в конец при передачи речи не должна превышать 100 мс, а вероятность превышения задержки порога в 50 мс не должна превосходить 0,001, т.е.

, мс,

p{t_p > 50 мс} ? 0,001

Задержка из конца в конец складывается из следующих составляющих:

t_p = t_пакет + t_ад + t_core + t_ад + t_буф (3.17)

где t_p - время передачи пакета из конца в конец; t_пакет - время пакетизации (зависит от типа трафика и кодека); t_ад - время задержки при транспортировке в сети доступа; t_core - время задержки при распространении в транзитной сети; t_буф - время задержки в приёмном буфере.

Допустим, что задержка сети доступа не должна превышать 5 мс. Время обработки заголовка IP-пакета близко к постоянному. Распределение интервалов между поступлениями пакетов соответствует экспоненциальному закону. Поэтому для описания процесса, происходящего на агрегирующем маршрутизаторе, можно воспользоваться моделью M/G/1.

Для данной модели известна формула, определяющая среднее время вызова в системе (формула Полячека - Хинчина).

, (3.18)

где - средняя длительность обслуживания одного пакета; - квадрат коэффициента вариации, 0,2; - параметр потока, = 142472; - среднее время задержки пакета в сети доступа, = 0,005 с.

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

Из формулы (4.1.1) следует зависимость максимальной величины для средней длительности обслуживания одного пакета от среднего времени задержки в сети доступа длительности обслуживания одного пакета от среднего времени задержки в сети доступа.

(3.19)

Интенсивность обслуживания связана со средним временем задержки пакета в сети доступа обратно пропорционально:

(3.20)

При норме задержки = 5 мс среднее время обслуживания пакета (для рассчитанной выше пропускной способности) будет равно

, секунд

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

При среднем значении задержки в сети доступа 5 мс коэффициент использования равен:

, (3.21)

При таком высоком использовании малейшие флуктуации параметров могут привести к нестабильной работе системы. Определим параметры системы при её использовании на 50%. Средняя длительность обслуживания будет равна:

, (3.22)

, секунд

Интенсивность обслуживания при этом:

(3.23)

А задержка в сети доступа:

, секунд

Рассчитывать вероятность s(t)= при известных л и ф нецелесообразно, т.к. в Y.1541 вероятность P{t>50мс} < 0,001 определена для передачи из конца в конец.

При известном среднем размере пакета h = 200 байт получаем требуемую полосу пропускания:

ц = вh, бит/с (3.25)

ц = 2,84910⁵ 200= 5,699·10⁷ (байт/с) = 4,559 · 10⁸ , бит/с

Данная пропускная способность обеспечивается системами передач не ниже STM-4.

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

Число пакетов, возникающих в ЧНН, будет равно:

N_tel = n· t ·f ·N, (3.24)

где N_tel - число пакетов, генерируемое всеми абонентами в час наибольшей нагрузки; n - число пакетов, генерируемых в секунду одним абонентом при использовании кодека G.711; t - средняя длительность разговора в секундах; f - число вызовов в час наибольшей нагрузки; N - общее число пользователей.

Число пакетов в секунду:

N_{tel_сек} = N_tel/3600 = n· t ·f ·N/3600,

N_{tel_сек} = 50 · 120 · 5 · 4000/3600 = 33333, пакетов/с

Среднее время обслуживания одного пакета при норме задержки 5 мс:

Коэффициент использования:

При использовании системы на 50%:

, секунд

Требуемая пропускная способность:

ц = 6,66710⁵200= 1,33·10⁷ байт/с = 1,07·10⁸ , бит/с

Такой концентратор можно подключать по интерфейсу 100BaseTX.



Заключение

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

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

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

1) уровень искажения голоса;

2) частота «пропадания» голосовых пакетов;

3) время задержки (между произнесением фразы первого абонента и моментом, когда она будет услышана вторым абонентом).

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

Задержки можно уменьшить благодаря следующим трем факторам:

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

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

3) в-третьих, развивается сама сеть Интернет - современный Интернет не был рассчитан на коммуникации в режиме реального времени. Хотя на обновление роутеров по всему миру и на организационные мероприятия (например, решить вопрос, как в денежном выражении оценить сервис более высокого качества) потребуется некоторое время, мир Интернета, вне зависимости от вышесказанного, двигается очень быстро и в правильном направлении [15].

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

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



Список используемых источников

1 IP - телефония. Мифы и реальность. //Компьютер-пресс. 1999г., №4.

2 Новые системы связи. //Hard & Soft, 2000г., №5.

3 Менеджмент Организации, учебное пособие, под ред. д.э.н. З.П.Румянцевой, д.э.н., проф. Н.А. Соломатина, Москва, Инфра-М, 1995

4 Для подготовки данной работы были использованы материалы с сайта http://referat2000.bizforum.ru/.

5 Интернет-телефония./ Компьютер пресс, 1999г №10 с 50.

6 Протоколы Internet. С. Золотов. - СПб.: BHV - Санкт-Петербург, 1998.

7 Менеджмент Организации, учебное пособие, под ред. д.э.н. З.П.Румянцевой, д.э.н., проф. Н.А. Соломатина, Москва, Инфра-М, 1995.

8 Сети ЭВМ: протоколы стандарты, интерфейсы. Ю. Блэк; перев. с англ. - М.: Мир, 1990.

9 Коммутация и маршрутизация IP/IPX трафика. М. В. Кульгин, АйТи. - М.: Компьютер-пресс, 1998.

10 Журнал «Мобильные системы» №12, стр. 10 (декабрь 1999).

11 С. В. Глушаков, Д. В. Ломотько «Работа в сети Internet», Харьков «Фолио», 2001.

12 Материалы сервера Международного Совета по Электросвязи.

13 Управление проектами, под общей редакцией В.Д.Шапиро, СПб, 1996.

Размещено на Allbest.ru