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

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

Аннотация

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

The summary

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 Особенности построения сетей NGN

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

.3 Топология сети

.4 Архитектура сети

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

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

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

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

.2 Аппаратура сетей NGN

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

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

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

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

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

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

.3 Расчет цены НИР

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

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

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

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

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

.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, предоставляемым с помощью специализированных серверов, осуществляется через оконечные и оконечно-транзитные узлы, выполняющие функции узлов служб.

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

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

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

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

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

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

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

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

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

Сети 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-полей, которые идентифицируют источники данных.поддерживается протоколом управления транспортировкой в реальном времени 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), так как он еще не осведомлен о том, по какому адресу и каким образом ему следует передавать информацию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.        После приема ответа на команду 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 и передается вызывающей стороне.

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

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

14.    Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения, в ходе которой оборудование вызвавшего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала терминала вызванного абонента, а тот передает пакетированную речевую информацию на транспортный адрес RTP-канала терминала вызвавшего абонента. При помощи канала RTCP ведется контроль передачи информации по RTP каналу.

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

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

17.    Кроме того, контроллер передает к шлюзу команду DLCX.

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

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

20.    От АТС-А приходит подтверждение разъединения RLC, после чего соединение считается разрушенным.

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

Заметим, что алгоритм взаимодействия протоколов SIP и MGCP, например, не сильно отличается от вышеописанного алгоритма.

Сравнение протоколов.

Приведём сравнительную характеристику рассмотренных выше протоколов.

Таблица 1.1. Сравнительные характеристики протоколов

2.2 Обзор услуг в сетях NGN

, предоставляет новые возможности благодаря прикладным программным интерфейсам API, основанным на открытых стандартах. Архитектура Softswitch дает возможность Операторам и/или провайдерам услуг интегрировать в сети NGN приложения как от производителя Softswitch, так и от разных сторонних производителей, а также самостоятельно разрабатывать свои собственные приложения. В дополнение к функциональной совместимости шлюзов и Softswitch, интерфейсы API стандартизованы для того, чтобы любой независимый сторонний разработчик мог создавать приложения на верхнем уровне архитектуры Softswitch. Услуги сетей нового поколения должны компоноваться чрезвычайно оперативно по принципу plug and play, что значительно сократит время и трудозатраты на разработку услуг. Среда создания услуг позволяет разрабатывать новые программные блоки услуг и компоновать услуги из этих программных блоков, обычно используя специальные инструментальные средства, такие как, например, реализованная в отечественной платформе «Протей» интегрированная среда разработки IDE (Integrated Development Environment,). Заложенные в таких инструментальных средствах принципы модульности позволяют провайдеру услуг самостоятельно комбинировать и настраивать компоненты в своей сети, не согласуя все это с производителями оборудования Softswitch. Ушли в прошлое времена монолитных коммутационных узлов TDM-сетей с оборудованием одного единственного поставщика.

Сегодня используются открытые стандартные API - Parlay, JAIN (Java Advanced Intelligent Network), CORBAfCommon Object Request Broker Architecture), XML (Extensible Markup Language), CPL (Call Processing Language), CGI (Common Gateway Interface) и сервисные Java-приложения. Все эти API, расположенные в Softswitch и в серверах приложений, обеспечивают предоставление провайдеру услуг NGN среды, в которой могут быстро развертываться разнообразные услуги. На рис. 1.1 уже была показана взаимосвязь интерфейсов API с другими компонентами создания услуг. Рассмотрим их здесь несколько подробнее.платформа для разработки, интеграции и развертывания приложений на базе технологии Java, первоначально ориентированная на сети крупных предприятий. Соединение ее функциональных возможностей с масштабируемостью современных сетей позволяет обеспечить поддержку разнообразных типов передаваемых данных, приложений и клиентских сред и облегчить быструю разработку услуг путем использования распределенных и расширяемых компонентов на базе технологии Java. Разработку стандартов Parlay ведет Parlay Group, представляющая собой консорциум разработчиков программного обеспечения инфокоммуникационных услуг.

Сетевая топология JAIN обязана своим появлением тому, что многие Softswitch размещаются на серверах производства Sun Microsystems, а в качестве API компания Sun и ее партнеры выбрали JAIN (развитую интеллектуальную сеть на базе Java). Обеспечивая новый уровень абстракции и имея соответствующие Java-интерфейсы для создания услуг в сетях ТфОП, IP или ATM, технология JAIN позволяет осуществлять интеграцию протоколов IP и IN. К тому же, JAIN обеспечивает переносимость услуг, конвергенцию сетей и защищенный доступ как к телефонным сетям, так и к сетям передачи данных. В ней поддерживаются распространенные телефонные протоколы, используемые между различными сетевыми элементами в сетях ТфОП/IN и IP, что иллюстрирует рис. 2.2.1. На нем показано, как Softswitch отображает интерфейсы управления обслуживанием вызовов/сеансовые интерфейсы в API базовых протоколов SIP, MGCP, MEGACO/H.248, Н.323 или стека ОКС7 с тем, чтобы обеспечить взаимодействие с телефонной сетью.

Рис 2.2.1 Архитектура JAIN.

Архитектура брокера запросов к объектам CORBA - открытая, независимая от поставщиков архитектура и инфраструктура, которую используют прикладные вычислительные системы для обеспечения их совместной работы в компьютерных сетях. Используя стандартный протокол Internet Inter-ORB Protocol (HOP), программа на базе CORBA любого поставщика может работать совместно с программой на базе CORBA этого же или другого поставщика практически на любом другом компьютере, с другими операционной системой и языком программирования и в другой сети.

Расширяемый язык разметки XML - язык HTML нового поколения, который рассматривается как стандартный способ обмена информацией в средах, не использующих общие платформы. Система сетевого управления на базе XML использует язык W3C XML для управления механизмом передачи данных по сети. Построение API вокруг механизма дистанционного вызова процедуры RPC(Remote Procedure Call) на базе XML дает простой и расширяемый способ обмена этими данными с устройством.

Описанные выше интерфейсы API размещаются на показанных рис. 2.1.1 серверах приложений, обеспечивая доступ к инфокоммуникационным услугам NGN. Используя эти API и протокол SIP, можно легко разрабатывать и вводить услуги. Кроме этого, на сервере приложений могут, в принципе, размещаться модели традиционной Интеллектуальной сети и необходимые для нее протоколы TCAP/INAP стека ОКС7, как показано на рис. 2.2.2.

Рис 2.2.2 Соответствие архитектуры Интеллектуальной сети и NGN.

Медиасервер MS обеспечивает специализированные ресурсы для услуг, такие как интерактивную речевую систему IVR, средства конференцсвязи и факсимильной передачи. Медиасерверы и серверы приложений являются независимыми устройствами и могут разворачиваться на отдельных физических платформах или на одной платформе. Сервер приложений может использовать ресурсы, расположенные на медиасервере MS, для обеспечения услуг, которые требуют доступа к мультимедийной информации пользователя. При этом, когда сервер приложений используется в сочетании с медиасервером, логика услуг в сервере приложений имеет доступ ко всем событиям в процессе обслуживания вызова, обычно - посредством сигнализации SIR Сервер приложений взаимодействует по протоколу SIP с медиасервером, чтобы получить доступ к потоку информации пользователя с целью обнаружения цифр DTMF, воспроизведения и записи речевых сообщений пользователя, создания комбинаций пользовательской информации разных видов (мультимедийной информации), обнаружения и пересылки факсимильных сообщений, передачи записанных объявлений и акустических сигналов, а также для выполнения процедур распознавания речи. Этот доступ к мультимедиа позволяет поддерживать комплексные и сложные услуги, такие как универсальная почта, конференцсвязь, обслуживание телефонных дебетных карт, а также приложения Call-центра. Некоторые транспортные шлюзы могут также включать в себя функции медиасервера. Если на транспортном шлюзе имеются требуемые ресурсы, сервер приложений может запросить эти транспортные функции через сетевой элемент управления обслуживанием вызовов - Softswitch. Как правило, это функции приема и генерирования сигналов DTMF, генерирования и распознавания акустических сигналов, а также воспроизведения и записи аудиоинформации. Обработка пользовательской информации может производиться либо на транспортном шлюзе, либо на медиасервере. Шлюзы всегда размещаются на границе сети, в то время как медиасерверы могут располагаться на границе сети или в ее ядре.

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

Рис. 2.2.3 Интерфейсы между сервером приложений и медиасервером.

Одна из уникальных услуг, появившихся на рынке приложений Softswitch, которую не поддерживают АТС с коммутацией каналов, - Web provisioning, позволяющее операторам Softswitch создавать собственные настройки через Web-сайт, выбирать свои сочетания услуг и включать или выключать индивидуальные услуги по своему усмотрению. Среди других услуг, поддерживаемых Softswitch, предусматриваются: преобразование сообщений речевой почты в сообщения электронной почты, просмотр сообщений речевой почты, «говорящий календарь» (который вслух сообщает о запланированных мероприятиях), речевая передача номера, гибкая маршрутизация вызовов в зависимости от внешних событий, вызов с помощью иконки на экране PC, дистанционное управление маршрутизацией вызова (в том числе, его переадресация) через Web-страницу и др.

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

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

Потоковое видео (IPTV) и видео по запросу (VOD).- цифровое интерактивное телевидение в сетях ПД по протоколу IP.

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

·        Большое количество телеканалов - до 300.

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

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

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

Привлекательные возможности IPTV - видео-по-запросу и виртуальный кинозал. Видео-по-запросу позволяет абоненту, не покупая DVD диск и не беря в прокат, посмотреть его дома.

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

IPTV позволяет внедрить множество услуг. Например услуга time shift позволяет поставить передачу “на паузу”, после чего можно продолжить просмотр с момента остановки, так же можно перематывать передачу как DVD видео.

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

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

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

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

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

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

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

Абонент имеет возможность не только смотреть и управлять всеми телевизионными ресурсами, но и одновременно может быть пользователем сети Интернет. С помощью IP Set-Top-Box возможно использование любых платежных систем: «Сберкарт», “VISA” и т.д.

Для организации IPTV необходимы приемник цифрового/аналогово сигнала, шлюз IP, и кодер (в случаи приёма аналогово сигнала), сервер VOD, и серверы хранения контента.

Рис. 2.2.4 Схема организации цифрового телевидения и видео по запросу.

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

Топология "точка-точка".

Сегмент сети, связывающий два узла А и В, или топология "точка-точка", является наиболее простым примером базовой топологии сети (рис.2.3.1).

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

Рис.2.3.1. Топология «точка-точка».

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

Топология "последовательная линейная цепь".

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

Топология “кольцо”.

Эта топология, см. рис.2.3.2, широко используется для построения сетей SDH. Основное преимущество этой топологии - легкость организации защиты типа 1+1.

Рис.2.3.2. Топология "кольцо" с защитой 1+1 на уровне трибных блоков TU-n.

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

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

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

Базовые сетевые технологии.

Под сетевыми технологиями будем понимать совокупность технологий цифровых систем передачи, обеспечивающих создание всего разнообразия каналов связи от пользователей сети к сетевым узлам и между узлами сети. Базовые сетевые технологии для цифровых транспортных сетей обеспечивают организацию транспортных магистралей и интеграцию различных видов трафика в сети. На базе цифровых транспортных сетей формируется и создается все разнообразие выделенных цифровых кагалов передачи (ЦКП) или связи (ЦКС), которые и образуют цифровые сети с коммутацией каналов. Базовыми сетевыми технологиями для транспортных сетей являются ПЦИ/PDH и ЩИ/SDH. В транспортных сетях используется иерархия скоростей передачи в соответствии с международными Рек. ITU-T и получившим наибольшее распространение европейским стандартом, который применяется на сетях связи Российской Федерации (РФ).

Технология ПЦИ/PDH поддерживает следующие уровни иерархии цифровых каналов: абонентский или основной канал ЕО (64 кбит/с) и пользовательские каналы уровней Е1 (2,048 Мбит/с), Е2 (8,448 Мбит/с), ЕЗ (34,368 Мбит/с), Е4 (139,264 Мбит/с). Уровень цифрового канала Е5 (564,992 Мбит/с) определен в Рек. ITU-T, но на практике обычно не используется. При этом цифровые каналы ПЦИ/PDH являются входными (полезной нагрузкой) для пользовательских интерфейсов сетей СЦИ/SDH. Применительно к европейскому стандарту интерфейс передачи Е1 (по стандарту G.703) ЦСП ПЦИ/PDH является входным каналом (полезной нагрузкой) для транспортной сети СЦИ/SDH, в которой они передаются по сетевым трактам в магистралях сети в виде виртуальных контейнеров соответствующего уровня.

Технология СЦИ/SDH, как это уже указывалось, поддерживает уровни иерархии каналов (по европейскому стандарту) со скоростями передачи 2,048 Мбит/с (пользовательский интерфейс Е1 по стандарту G.703) и 155,520 Мбит/с, 622,080 Мбит/с, 2,488 Гбит/с, и т.д. (интерфейсы передачи, соответствующие синхронным транспортным модулям STM-N (N= 1, 4, 16, ...)). В транспортной сети пользовательские интерфейсы, соответствующие синхронным транспортным модулям STM-N более низкого уровня, могут служить полезной нагрузкой для сетевых элементов сети СЦИ/SDH более высокого уровня иерархии.

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

На основе транспортной сети СЦИ/SDH можно создавать наложенные сети с коммутацией каналов, например, цифровые с интеграцией служб (ЦСИС/ISDN) и коммутацией пакетов, в частности, сети Frame Relay (FR), сети ATM ((Asynchronous Transfer Mode) или асинхронного режима передачи (АРП/АТМ)). Технология ATM облегчила эту задачу, взяв за основу стандарты СЦИ/SDH в качестве стандартов физического уровня. Поэтому в транспортной сети СЦИ/SDH сеть ATM может быть интегрирована поверх сети СЦИ/SDH, как наложенная сеть, при этом образуются одновременно и транспортная, и вторичные сети и осуществляются функции сети доступа.

Технология ATM разрабатывалась как единая универсальная транспортная технология нового поколения сетей с интеграцией услуг, так называемых широкополосных цифровых сетей с интеграцией служб (Ш-ЦСИС или B-ISDN). Однако технология ATM, к сожалению, не стала в полной мере технологией транспортных сетей по целому ряду причин, которые в различных аспектах будут обсуждены ниже.

Уникальность технологии ATM состоит в том, что она как транспортная технология совместима со всеми базовыми сетевыми технологиями глобальных сетей - сети Интернет, основой которой является стек протоколов TCP/IP, СЦИ/SDH, ПЦИ/PDH, Frame Relay и с сетевыми технологиями локальных сетей. Технология ATM обеспечивает передачу в рамках одной транспортной сети различных видов трафика (голоса, видео, данных), имеет иерархию скоростей передачи в широком диапазоне (в настоящее время 25 Мбит/с... 10 Гбит/с) с гарантированной пропускной способностью для ответственных приложений.

Технология ATM не определяет новые стандарты для физического уровня сети, а использует существующие. Основным стандартом для технологии ATM является физический уровень каналов сетевых технологий СЦИ/SDH и ПЦИ/PDH. Именно потому, что технология ATM поддерживает все основные существующие виды трафика, она выбрана в качестве транспортной среды сетей Ш-ЦСИС или B-ISDN. С другой стороны, технология ATM имеет общие транспортные протоколы для локальных (ЛВС) и глобальных сетей и обеспечивает их взаимодействие.

Технологии сети Интернет или сети на основе стека протоколов TCP/IP (Transmission Control Protocol/Internet Protocol - протокол управления передачей/протокол сети Интернет) занимают особое положение среди сетевых технологий. Они играют роль сетевой технологии, объединяющей сети любых типов и технологий, включая глобальные транспортные сети всех известных технологий. Таким образом, сети на основе стека протоколов TCP/IP относятся к сетевым технологиям более высокого уровня, чем сетевые технологии собственно глобальных транспортных сетей. При этом, цифровые транспортные сети СЦИ/SDH, являясь основой для создания большинства наложенных телекоммуникационных сетей, позволяют интегрировать различные сетевые технологии в единую мультисервисную телекоммуникационную и информационную (инфокоммуникационную) сеть на физическом и канальном уровнях.

Появление оптических транспортных сетей с использованием технологии спектрального или волнового мультиплексирования (ВМП/WDM (Wave Division Multiplexing)) и потного волнового мультиплексирования (ПВМП/DWDM (Dense Wave Division Multiplexing)) расширило возможности сетевых технологий в построении транспортных сетей. Указанные сетевые технологии ВМП/WDM и ПВМП/DWDM уже вышли из исследовательских лабораторий и находятся среди освоенных промышленных технологий, которые органично сочетаются и интегрируются с технологией СЦИ/SDH .

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

·        TCP-IP - технология сети Интернет, основой которой является стек протоколов TCP/IP или протокол управления передачей/протокол сети Интернет;

·        ATM - технология асинхронного режима передачи (переноса);

·        SDH - технология СЦИ;

·        WDM - технология волнового мультиплексирования (ВМП);

·        DWDM - технология плотного волнового мультиплексирования (ПВМП).

На рис. 2.4.1. представлены варианты архитектуры интегрированной мультисервисной сети на основе рассмотренных базовых сетевых технологий.

Рис. 2.4.1 Варианты архитектуры мультисервисной сети

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

Построение сети доступа (СД) должно удовлетворять трем видам предоставляемых пользователям услуг мультисервисной сети:

.1.      передача речи (звука, телефонная связь, речевая почта и т.д.);

.2.      передача данных (Интернет, факс, электронная почта, компьютерные файлы, электронные платежи и т.д.);

.3.      передача видеоинформации (телевидение, видео по запросу, видеоконференции и т.д.).

Поэтому изначально необходимо определиться с моделью и архитектурой сети доступа.

Место сети доступа во взаимодействии с другими сетями определяет общая архитектура (рис. 2.5.1) и модель этой сети, рассмотренные в Рекомендации ITU-T G.902 (11/95).

Рис. 2.5.1 Общая архитектура сети доступа.

Рис. 2.5.2 Протокольная модель сети доступа

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

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

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

Уровень поддержки доступа чаще всего ассоциируется с сигнальными системами, например, для доступа в телефонную сеть, в сеть N-ISDN, в сеть B-ISDN.

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

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

Протокольная модель сети доступа позволяет более точно определить функции сети доступа: пользовательских интерфейсов; транспортные функции; сервисных портов (интерфейсов) коммутации; встроенные функции; функции системы управления. Примеры функций интерфейсов пользователей (UNI):

·        подключение терминалов пользователей;

·        аналого-цифровое и цифро-аналоговое преобразование;

·        преобразование сигналов (интерфейсов);

·        активация/деактивация UNI;

·        тестирование;

·        контроль, управление, обслуживание. Примеры функций интерфейсов узлов услуг (SNI):

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

·        концентрация функций контроля, управления, обслуживания в сети Доступа;

·        помещение протоколов для части SNI;

·        тестирование;

·        Управление, контроль и обслуживание интерфейса.

Примеры встроенных функций сети доступа:

·        концентрация каналов пользователей СД;

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

·        эмуляция каналов для ATM транспортных функций;

·        функции контроля и управления. Примеры транспортных функций СД:

·        мультиплексирование;

·        функции кроссирования и конфигурации;

·        функции управления;

·        функции физической среды (кодирование, контроль ошибок, образование сигналов, регенерация и усиление, и т.д.).

Примеры функций системы управления СД:

·        конфигурирование и контроль;

·        координация ресурсов;

·        обнаружение и индикация аварий;

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

·        контроль безопасности;

·        координация управления критичного по времени;

·        управление ресурсами (каналами, трактами, секциями, интерфейсами).

Примеры типов сервисных узлов:

а) индивидуальные подключения пользователей:

·        телефонные узлы;

·        узлы N-ISDN;

·        узлы B-ISDN;

·        узлы пакетной коммутации;

·        узлы услуг видео;

б) индивидуальные подключения по выделенным линиям и каналам:

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

·        сервис по выделенным линиям на основе ATM;

·        сервис пакетной передачи по выделенным линиям;

в) сервисные узлы видео и радиопрограмм вещания и по запросу;

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

д) узлы Интернет. На рис. 2.5.3 представлена базовая структура сети доступа, в котором обозначены все ее участки и составляющие элементы, блоки и системы:

·        сеть доступа СД (Access Network, AN) - совокупность абонентских линий и оборудования (станций) местной сети, обеспечивающие доступ абонентских терминалов к транспортной сети и местную связь без выхода на транспортную сеть;

·        центральный распределительный узел (головная станция) (Cente Distribution Node, CDN) обеспечивает доступ абонентских устройств к узлам услуг;

Рис. 2.5.3 Базовый прототип сети доступа.

Рис. 2.5.4 Схема построения абонентской сети ГТС.

·        сетевой блок (Network Unit, NU) обеспечивает первичный доступ через мультиплексирование и концентрацию трафика и каналов!

·        сетевое окончание (Network Termination, NT) позволяет подключать один или несколько пользовательских терминалов (Termination Element ,TE);

·        система управления и контроля сетью доступа (Telecommunication Management Network, TMN), связанная с другими компонентами (устройствами) СД через интерфейсы управления, стандартизированными ITU-T.

Линия передачи абонентов (Subscriber Transmission Line, STL) соединяет узел предоставления услуг с терминалом сети и проходит сеть доступа. Она может быть образована физической цепью, каналом (аналоговым или цифровым), составным каналом, виртуальным каналом или группой каналов для одинаковых или различных услуг. Линия передачи проходит через абонентскую линию (Subscriber Line, SL), интерфейс UNI, сетевой блок NU, распределительную сеть (Distribution Network, DN), узел распределения CDN, соединительную магистраль (Backbone Network, BN). Наиболее проблемными участками линии передачи абонента являются SL, называемая в литературе «последней милей», и распределительная сеть DN.

Базовая структура сети доступа существенно отличается от структуры абонентской линии телефонной сети, в частности, на городской телефонной сети (ГТС) (рис. 2.5.4).

В сравнительной оценке с сетью ГТС, СД - это универсальная сеть, в которой могут быть гарантированны любые телекоммуникационные услуги с полосой частот передаваемых сигналов от тональных (0,3...3,4 кГц) до десятков и сотен МГц (для телевизионных сигналов аналогового и цифрового форматов). Для реализации универсальных возможностей СД могут быть использованы оптические системы передачи, системы передачи по медным линиям и радиосистемы. Сети телефонных линий непригодны для предоставления широкополосных услуг, однако они могут частично входить в сети доступа на различных участках, например, на участке распределения (рис. 2.5.4), соответствующем участку SL сети доступа (рис. 2.5.3). Для реализации услуг нетелефонного типа, например N-ISDN, потребуется замена абонентской проводки (рис. 2.5.4), выполненной чаще всего кабелем ТРП или ПРППМ, на кабель с высокочастотными витыми парами (категории 5).

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

Рис. 2.5.5. Типовые архитектуры сети доступа

а) архитектура «каскад» (дерево); б) архитектура «звезда»; в) архитектура «кольцо»

Среди различных архитектурных решений для СД необходимо выделить пассивную оптическую сеть ПОС (Passive Optical Network, PON), которая отличается относительно низкими расходами на реализацию и обеспечивает интерактивный трафик с широкополосными сигналами на одной или нескольких оптических частотах в одном стекловолокне. В качестве ключевых элементов разветвления в PON могут быть использованы оптические устройства разделения мощности сигнала, которые способны разделять и объединять системы различных направлений передачи оптических частот. Пример PON приведен на рис. 2.5.6.

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

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

Обозначения и сокращения на рис. 2.5.7: ТфОП, телефонная сеть общего пользования; КТВ, кабельное телевидение;, Integrated Service Digital Network - цифровая сеть с интеграцией служб (ЦСИС);, Local Area Network - локальная вычислительная сеть (ЛВС); xDSL, Digital Subscriber Line - цифровая абонентская линия; OAN, Optical Access Network - оптическая сеть доступа; Ethernet, Fast Ethernet, Gigabit Ethernet - компьютерные технологии передачи данных на скоростях 10 Мбит/с, 100 Мбит/с, 1000 Мбит/с; FDDI, волоконно-оптический распределительный интерфейс, сеть кольцевого типа с защитой от повреждений;, HDSL, SDSL - технология симметричных абонентских линий (I-ISDN, Н-высокоскоростная линия (2,048 Мбит/с), S-симметричная однопарная линия со скоростными режимами от 128 кбит/с до 2320 кбит/с);

Рис. 2.5.6. Пример пассивной оптической сети PON.

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

, RADSL, G.Lite - несимметричные абонентские линии со скоростями передачи к абоненту не ниже 1 Мбит/с, от абонента 512 кбит/с, с адаптацией к линии и приспособлением скорости в зависимости от помех;, FTTH, FTTB, FTTC, FTTCab - активные технологии оптического доступа в дом, в рабочую зону, в шкаф и т.д.;

PON, APON, EPON, BPON, GPON - технологии пассивных оптических сетей (ATM PON, Ethernet PON, Broadband PON, Gigabit rate PON).

Технологии передачи по медным проводам xDSL

Технология ADSL позволяет организовать передачу по паре проводов существующих абонентских линий UTP категории 3 передачу данных на расстояние до 5,5 км от АТС со скоростью до 8 Мбит/с к абоненту и до 1 ...1,5 Мбит/с от него. В ADSL применяются два типа линейного кодирования САР и DMT. При этом телефонные и цифровые сигналы при передаче по линии не мешают друг другу, так как занимают разные полосы частот.

Технология ADSL - lite или G.lite поддерживает более низкие скорости (в 1,5 Мбит/с к абоненту и 384 кбит/с от него), но не требует установки специального разветвителя (сплиттера) телефонии и цифровой передачи. Невысокая скорость компенсируется простой установкой и низкой стоимостью развертывания. Расстояние передачи соответствует ADSL.

Технология RADSL представляет собой вариант технологии ADSL автоматической настройкой скорости передачи (в зависимости от стояния линии). На рис. 2.5.8 приведен пример использования ADSL.

Рис. 2.5.8 Пример использования ADSL

Рис 2.5.9 Варианты применения технологии HDSL:

а) HDSL в сети доступа; б) HDSL в межстанционных линиях цифровых АТС; г) HDSL в межстанционных линиях аналоговых АТС.

Технология MDSL обеспечивает передачу цифровых сигналов по одной паре проводов со скоростью 128 кбит/с ... 2,3 Мбит/с при модуляции 2B1Q. Кодирование 2B1Q обеспечивает не самую большую дальность передачи, но на сильно зашумленных линиях оно позволяет установить более качественное соединение, чем при использовании САР.

Технология HDSL достаточно давно применяется на сетях связи. Обеспечивает работу по паре проводов с фиксированной скоростью 2,048 Мбит/с в двух направлениях. Как правило, применяется 4-проводный вариант с дуплексной передачей по каждой паре на расстояние около 4,5...6,5 км по кабелю UTP категории 3. В HDSL применяются следующие виды кодирования: 2B1Q, САР64, САР1.28. На рис. 2.5.9 приведены примеры использования HDSL.

Технология SHDSL представляет собой стандарт высокоскоростной симметричной передачи данных (по терминологии ITU-T G.shdsl). Скорость передачи по одной медной паре достигает 2,3 Мбит/с, по двум медным парам до 4,6 Мбит/с. Скорость может быть фиксированной или адаптивной в диапазоне 192 кбит/с- 2,320 Мбит/с. Дальность передачи на каждой паре проводов с жилами 0,4 мм кабеля UTP категории 3 может составлять от 2 до 6 км.

Технология SDSL аналогична HDSL, однако, для организации соединения достаточно применения двухпроводной абонентской линии. При этом протяженность линии до 3 км и скорость обмена данными до 2,048 Мбит/с.

Технология MSDSL предусматривает высокоскоростную дуплексную, т. е. симметричную, передачу синхронного цифрового потока по одной медной паре с изменяемой линейной скоростью. Скорость передачи автоматически корректируется во время работы в соответствии с состоянием линии и качеством сигнала. В зависимости от скорости (144 кбит/с - 2,064 Мбит/с) используется кодирование с САР 8 по САР 128. Максимально перекрываемое расстояние по паре кабеля UTP категории 3 до 6,5км.

Технология VDSL представляет ряд перспективных решений по передаче данных на скоростях от 10 до 50 Мбит/с к абоненту и до 8 Мбит/с от абонента. Для реализации VDSL необходима пара проводов, на которой гарантируется дальность передачи 300-1200 м.

Технологии оптической передачи в волоконных световодах.

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

Активная оптическая технология базируется на различных мультиплексорах (PDH, SDH, ATM), кольцевых и линейных конфигурациях с Гарантированной защитой трафика. Пример такой конфигурации приведен на рис. 2.5.10.

Рис. 2.5.10 Примеры сети доступа с применением активной оптической технологии.

(Optical Line Terminal) - оптическое линейное окончание (Optical Network Unit) - оптический сетевой блок (доступа)

NMS (Network Management System) - система управления сетью (Element Management System) - элемент системы управления

Рис 2.5.11 Пример сети доступа с PON.

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

Значительно большее применение получили технические решения с пассивными волоконно-оптическими сетями (рис. 2.5.12), предназначенными для широкополосной передачи (Broadband Passive Optical Network, B-PON).

Рис. 2.5.12. Синхронная передача циклических групповых сигналов в PON:

а) Синхронный метод передачи с разделением во времени TDM (Time Division Multiplexing); б) метод синхронного доступа с разделением во времени передаваемых временных групп (слотов) TDMA (Time Division Multiplexing Access)

Технология Ethernet.

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

2.6 Управления и удалённое администрирование

Модель сети управления телекоммуникациями

Одной из основополагающих моделей в сфере управления сетями телекоммуникаций является модель Сети Управления Телекоммуникациями (Telecommunication Management Network, TMN), подробно описанная в рекомендациях ITU-T серии М.3000-М.3100. Кратко напомним ее основные положения.

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

В спецификациях TMN управляемые ресурсы имеют общее название «сетевые элементы» (Network Element, NE). Функции управления возложены на системы поддержки операций (Operations Support System, OSS).можно описать, используя три архитектуры, каждая из которых выражает свой аспект управления сетями электросвязи.

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

В архитектуре TMN предусмотрены пять типов функциональны блоков: - функции сетевых элементов (Network Element Functions, NEF): базовые телекоммуникационные функции, которые обеспечивают обмен данными между пользователем и сетью связи (в спецификациях TMN не конкретизируются), и функции управления, позволяющие сетевому элементу выступать в роли агента;

Информационная архитектура определяет алгоритмы передачи управляющей информации между функциональными блоками TMN, которые унаследовали у Модели Взаимодействия Открытых Систем (Open System Interconnection, OSI) два важнейших элемента, объектную ориентацию и архитектуру «менеджер - агент».

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

Объектная ориентация информационной архитектуры TMN выражается в том, что телекоммуникационные ресурсы представляются в виде классов управляемых объектов, которые могут создаваться и изменяться с использованием интерфейсов TMN. В один класс входят объекты с похожими характеристиками - атрибутами, выполняемыми над объектом операциями, поведением (реакцией на операции) и генерируемыми уведомлениями. При таком подходе детали реализации объекта скрыты от «внешнего мира». Граничный интерфейс объекта обязан поддерживать набор услуг, разрешенных операций, ответных сообщений и уведомлений, связанных с характеристиками данного объекта. Набор объектов, который может использоваться для управления произвольной сетью связи, получил название универсальной сетевой информационной модели (Generic Network Information Model, GNIM).

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

Помимо функциональной, физической и информационной архитектур, концепция TMN предлагает и другой принцип распределения функциональных компонентов и процедур, относящихся к управлению сетями связи. Тот факт, что одни и те же административные функции могут быть реализованы на разных уровнях абстракции, позволяет определить логическую иерархическую архитектуру (Logical Layered Architecture, LLA). Фактически, архитектура LLA (называемая иногда TMN-пирамидой, рис. 2.6.1) отражает иерархию ответственности за выполнение административных задач.

Рис. 2.6.1 Пирамида TMN.

В настоящее время архитектурой LLA предусмотрены пять уровней управления:

·        Уровень сетевых элементов (Network Element Layer, NEL) играет роль интерфейса между базой данных со служебной информацией (Management Information Base, MIB), находящейся на отдельном устройстве, и инфраструктурой TMN. К этому уровню относятся Q-адаптеры и собственно сетевые элементы.

·        Уровень управления элементами (Element Management Layer, EML) соответствует функциям систем поддержки операций, контролирующим работу групп сетевых элементов. На этом уровне реализуются управляющие функции, которые специфичны для оборудования конкретного производителя, и эта специфика маскируется от вышележащих уровней. Примерами таких функций могут служить: выявление аппаратных ошибок, контроль за энергопотреблением и рабочей температурой, сбор статистических данных, измерение степени использования вычислительных ресурсов, обновление микропрограммных средств. Данный уровень включает в себя посреднические устройства (хотя физически они могут принадлежать и к более высоким уровням).

·        Уровень управления сетью (Network Management Layer, NML) формирует представление сети в целом, базируясь на данных об отдельных сетевых элементах, которые передаются системами поддержки операций предыдущего уровня и не привязаны к особенностям продукции той или иной фирмы. Другими словами, на этом уровне осуществляется контроль за взаимодействием сетевых элементов, в частности, формируются маршруты передачи данных между оконечным оборудованием для достижения требуемого качества обслуживания (Quality Of Service, QoS), вносятся изменения в таблицы маршрутизации, отслеживается степень утилизации пропускной способности отдельных каналов, оптимизируется производительность сети и выявляются сбои в ее работе.

·        Уровень управления услугами (Service Management Layer, SML) охватывает те аспекты функционирования сети, с которыми непосредственно сталкиваются пользователи (абоненты или другие сервис-провайдеры). В соответствии с общими принципами LLA на этом уровне используются сведения, поступившие с уровня NML, но непосредственное управление маршрутизаторами, коммутаторами, соединениями и т.п. здесь уже невозможно. Вот некоторые функции, относящиеся к управлению услугами: контроль за QoS и выполнением условий соглашений об уровне обслуживания (Service Level Agreement, SLA), управление регистрационными записями и подписчиками услуг, добавление или удаление пользователей, присвоение адресов, биллинг, взаимодействие с управляющими системами других провайдеров и организаций.

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

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

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

Особенностью Сетей связи Нового Поколения (Next Generation Networks, NGN), с точки зрения управления является то, что эти сети состоят из большого числа разнотипных компонентов.

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

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

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

Здесь возникает резонный вопрос: ведь концепция TMN как раз и направлена на управление с использованием объектных моделей и распределенной архитектуры, почему же в таком случае возникла необходимость пересмотра принципов управления?

Ответ можно получить, рассматривая не саму модель TMN, а возможность ее реализации и внедрения на реально работающих предприятиях связи. Практически все производители программного обеспечения биллинговых систем и систем класса OSS пытались в той или иной мере реализовать предлагаемые TMN подходы, однако столкнулись с трудностями реализации и внедрения своих продуктов. Дело в том, что если рекомендации ITU-T достаточно четко декларируют интерфейсы и протоколы для нижних уровней модели (до уровня управления сетью включительно), то для верхних уровней нет не только четких указаний, но и полного понимания, какими они должны быть, поскольку изначально проблемам взаимодействия внутри TMN уделялось мало внимания. В результате, каждый поставщик получает в лице заказчика львиную долю сизифова труда по интеграции своей системы с уже имеющимися модулями. Оператор связи, в свою очередь, затрудняется выбрать достойного поставщика, поскольку предлагаемые системы имеют различную функциональность, часто не удовлетворяющую все потребности конкретного предприятия. Решение проблемы выбора, опирающееся не на волевое решение, а на математическую модель потребностей оператора связи.

Из всего вышесказанного следует вывод, что реализация модели управления сетью электросвязи «снизу вверх», как это сделано в TMN, не удовлетворяет современным требованиям реальных операторов связи и сервис-провайдеров. Существует другой путь, которым пошел международный консорциум TeleManagement Forum (TMForum, TMF) - моделирование «сверху вниз», от логики бизнес-процессов к самим процессам.

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

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

·        новое поколение операционных систем и программного обеспечения (New Generation of Operation Systems and Software, NGOSS);

·        моделирование и автоматизация бизнес-процессов;

·        принятие соглашений о составе информации, которая передается от одного процесса к другому;

·        управление сетевыми технологиями следующего поколения;

·        интеграция и практическая реализация аппаратных систем;

·        управление услугами;

·        управление электронной коммерцией;

·        регламентирование взаимодействия с потребителями услуг. Среди участников TMF - сервис-провайдеры, операторы связи и поставщики аппаратного и программного обеспечения для отрасли телекоммуникаций. В такой комбинации из разработчиков и потребителей Систем Поддержки Операций, у ТМ Forum'a есть возможность достичь реальных результатов в разработке спецификаций действительно нужных программных продуктов.

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

Некоторое время TMForum работал над улучшенной концепцией TMN под названием SMART TMN, однако спустя некоторое время после начала работы было признано, что TMN не совсем подходит для решения задач управления бизнесом и услугами. Анализируя сложность и дороговизну внедрения систем управления на базе TMN, указывается следующее: «Модель TMN имеет простой и очень общий смысл, но ее конкретная практическая реализация - депо сложное. Все множество разработанных в настоящее время стандартов, касающихся TMN и описывающих всевозможные интерфейсы, затрудняет видение и понимание общей картины, так как эти стандарты разрабатывались ITU-T постепенно в направлении от элементного управления, что делает крайне затруднительным их применение в качестве стандартов для построения системы управления бизнес-процессами».

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

Рис. 2.6.2 Схема телекоммуникационных операций.

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

Биллинг услуг сетей нового поколения

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

·        сбор, обработка и ввод первичных данных о предоставленных у лугах;

·        абонентский учет;

·        регистрация и контроль оплат;

·        ведение нормативно-справочной информации;

·        тарификация и расчет;

·        формирование счетов абонентам;

·        информационно-справочное обслуживание абонентов;

·        формирование статистических и аналитических документов;

·        поддержка взаиморасчетов с операторами-партнерами;

·        управление коммутационным оборудованием.

В соответствии с современными требованиями к системам поддержки операций этот список можно дополнить следующими пунктами:

·        учет и контроль качества предоставляемых услуг (Quality of Service, QoS);

·        контроль выполнения пользовательского соглашения (Service License Agreement, SLA);

·        Fraud-контроль и управление безопасностью связи.

Отметим особую важность fraud-контроля. Ежегодные потери от fraud (англ. - мошенничество) в телекоммуникациях составляют 13 млрд. долл. С появлением более сложных технических решений и услуг ожидается рост еще на 20%.

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

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

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

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

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

Особенности биллинговых систем для мультисервисных сетей.

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

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

Гетерогенность, как уже отмечалось, свойственна не только мультисервисным сетям. С проблемами биллинга услуг гетерогенных сетей столкнулись все региональные операторы связи, такие как бывшие «xГТС» и АО «Электросвязь x области». Кратко напомним об этих трудностях.

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

1.       Применение отдельных программных приложений управления для конфигурирования технических средств, мониторинга, диагностики и тестирования ряда элементов сети (например, оборудования одного поставщика) или сети одного вида (например, только сети SDH, только сети ATM и т.д.).

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

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

Следовательно, необходим некий программный продукт класс EAI (Enterprise Application Integration), который определил бы единые правила для всех используемых информационных подсистем, что и предлагается вторым подходом. Создание данного продукт силами оператора связи практически невозможно - в битвах за «преимущества» «доморощенного» биллинга сломано уже немал копий. Остается надежда на системного интегратора. Чаще всего им выступает поставщик биллинговой системы, как ключевого решения - сторонний интегратор может лишь ухудшить и без тог запутанное положение. В результате получаем полную зависимость данной интеграции от квалификации сотрудников фирмы поставщика биллинга. С одной стороны это неплохо, поскольку большинство серьезных компаний, поставляющих системы класса OSS, на сегодняшний день имеют готовые решения для подобны действий. Однако риск получить «гетерогенность гетерогенности» все же имеется.

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

1.