Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Міністерство освіти і науки, молоді та спорту України
Державний університет інформаційно-комунікаційних технологій
Навчально-науковий інститут телекомунікацій та інформатизації
КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ
Для проведення лекції з навчальної дисципліни “Глобальна інформаційна інфраструктура”
Модуль 1 Основи глобальної інформаційної інфраструктури
ТЕМА 2. Місце мереж NGN в структурі сучасних мереж
Лекція 3. Мережа NGN в транспортних мультисервісних мережах
Міністерство освіти і науки, молоді та спорту України
Державний університет інформаційно-комунікаційних технологій
Навчально-науковий інститут телекомунікацій та інформатизації
КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ
Завідуючий кафедрою
_______к.т.н., доцент М.П. Гніденко
(підпис, прізвище)
“ ____ “ _____________ 2012 року
Для проведення лекції з навчальної дисципліни “Глобальна інформаційна інфраструктура”
Модуль 1 Основи глобальної інформаційної інфраструктури
ТЕМА 2. Місце мереж NGN в структурі сучасних мереж
Лекція 3. Мережа NGN в транспортних мультисервісних мережах
Обговоренo на засіданні кафедри
Протокол №
« » 2012р. .
1. Засвоїти склад побудови транспортної мережі NGN
2. Вивчити архітектуру мережі NGN
ЧАС: 2 навчальних години
МІСЦЕ: ауд 210.
1. Комплект слайдів до лекції № 1.
2. Наічальний сайт.
Вступна частина 5 хв.
Перевірка підготовки студентів до заняття 5 хв.
Навчальні питання
1. Побудова транспортної мережі NGN 25 хв.
2. Побудова мереж доступа . 30 хв.
3. Архітектура NGN 20 хв.
Висновок, завдання на СРС 5 хв.
Виконати самостійне завдання № 1.
1. Стеклов В.К., Беркман Л.Н. Телекомунікаційні мережі. Київ, “Техніка”, 2001-с.5-13.
4. Оліфер В.Г. Комп’ютерні мережі. Принципи, технології, протоколи. Посібник для Вузів. 2-е вид. –СПБ. Пітер. 2005. -с.22-34.
Основу NGN составляет универсальная транспортная сеть, реализующая функции транспортного уровня и уровня управления коммутацией и передачей .
В состав транспортной сети NGN входить:
Контроллеры сигнализации могут быть вынесены в отдельные устройства, предназначенные для обслуживания нескольких узлов коммутации. Использование общих контроллеров позволяет рассматривать их как единую систему коммутации, распределенную по сети. Такое решение не только упрощает алгоритмы установления соединений, но и является наиболее экономичным для операторов и поставщиков услуг, так как позволяет заменить дорогостоящие системы коммутации большой емкости небольшими, гибкими и доступными по стоимости даже мелким поставщикам услуг.
Оконечные и оконечно-транзитные узлы транспортной сети могут выполнять функции узлов служб, т.е. состав функций граничных узлов может быть расширен благодаря добавлению функций предоставления услуг. Для построения таких узлов может использоваться технология гибкой коммутации (Softswitch). Структура мультипротокольной транспортной сети представлена на рисунке 1.
Классификация сетей доступа может проводиться по ряду характеристик:
Передаваемая информация делится по своему назначению на следующие виды:
При классификации по уровням в соответствии с уровневой моделью услуги соответствуют функциям протокола конкретного уровня:
С точки зрения вышележащих уровней, в доступе реализуются только услуги сигнализации (С) и управления (М). Для их поддержки устройства доступа могут содержать функциональные узлы для обработки всего стека протоколов в плоскости С или М.
Услуги верхних уровней в плоскости U реализуются, как правило, за пределами сети доступа – а именно в конечных терминалах пользователей (TE, CPE) и сетевых серверах (узлах служб – SN). В этом смысле в плоскости U сеть доступа выполняет только функции транспортировки информации пользователя между интерфейсами UNI и SNI (т.е. услуги протоколов нижних уровней).
В узле доступа должны быть реализованы технологии доставки информации для любого терминального устройства, подключаемого с помощью:
Безусловно, ни одна из перечисленных технологий не может в полной мере удовлетворить потребности мультисервисного доступа. Необходим абонентский концентратор, объединяющий все эти технологии. Такие концентраторы уже существуют:
Перечисленные технологии обеспечивают доступ к ресурсам сети и передачу данных разного вида, но не обеспечивают требуемого качества доставки информации, так как не устанавливают соединений для доставки данных, чувствительных к задержке и потерям.
Наиболее подходящими решениями здесь можно считать протоколы сигнализации и стандартизованные интерфейсы:
Протокол RSVP – это протокол сигнализации, который обеспечивает резервирование ресурсов для предоставления в IP-сетях услуг эмуляции выделенных каналов. Протокол позволяет запрашивать, например, гарантированную пропускную способность такого канала, предсказуемую задержку, максимальный уровень потерь. Но резервирование выполняется лишь в том случае, если имеются требуемые ресурсы.
Чтобы обеспечить требуемый уровень эффективности обслуживания трафика речевых и видео-приложений, необходим механизм, позволяющий источникам информировать службу о своих требованиях. На основе этой информации сеть может резервировать ресурсы, чтобы гарантировать выполнение требований к качеству доставки. При отсутствии ресурсов служба отказывает приложению, вынуждая его либо пересмотреть требования, либо отложить сеанс связи.
Отправитель данных, использующий протокол RSVP, передает на индивидуальный или групповой адрес получателя сообщение Path, в котором указываются желательные характеристики качества доставки данных:
Сообщение Path пересылается маршрутизаторами IP-сети в сторону получателя данных с использованием таблиц маршрутизации в узлах сети до ближайшего маршрутизатора MPLS транспортной сети NGN (рисунок 2).
Каждый маршрутизатор, поддерживающий протокол RSVP, получив сообщение Path, фиксирует адрес предыдущего маршрутизатора как элемент “структуры пути”. Таким образом, в сети создается фиксированный маршрут. Поскольку сообщения Path содержат те же адреса отправителя и получателя, что и пакеты данных, пакеты будут маршрутизироваться корректно даже через сетевые области, не поддерживающие протокол RSVP.
Сообщение Path содержит шаблон данных отправителя (Sender Template), описывающий тип этих данных. Шаблон специфицирует фильтр, который может отделять пакеты этого отправителя от других пакетов в пределах сессии.
Кроме того, сообщение Path должно содержать спецификацию потока данных отправителя Tspec, которая определяет характеристики этого потока. Спецификация Tspec используется для того, чтобы предотвратить избыточное резервирование.
Шаблон данных отправителя имеет тот же формат, что и спецификация фильтра в сообщениях Resv (Reservation).
В зависимости от идентификатора протокола, заданного для сессии, шаблон может специфицировать только IP-адрес отправителя или (но не обязательно) также и UDP/TCP-порт.
Приняв сообщение Path, получатель передает к маршрутизатору, от которого пришло это сообщение (т.е. по направлению к отправителю), запрос резервирования ресурсов – сообщение Resv.
В дополнение к информации Tspec, сообщение Resv содержит спецификацию запроса (Rspec), в которой указываются нужные получателю параметры качества доставки и спецификацию фильтра (filterspec), которая определяет, к каким пакетам сессии относится данная процедура (рисунок 3).
Вместе Rspec и filterspec представляют собой дескриптор потока, используемый маршрутизатором для идентификации каждой процедуры резервирования ресурсов.
Когда получатель данных передает запрос резервирования, он может запросить передачу ему ответного сообщения, подтверждающего резервирование.
При получении сообщения Resv каждый маршрутизатор в резервируемом пути, поддерживающий протокол RSVP, определяет, приемлем ли этот запрос, для чего выполняются две процедуры:
С помощью механизмов управления доступом проверяется, имеются ли у маршрутизатора ресурсы, необходимые для поддержки запрашиваемого качества доставки информации, а с помощью процедуры режимного контроля (policy control) – правомерен ли запрос резервирования ресурсов. Если запрос не может быть удовлетворен, маршрутизатор отвечает на него сообщением об ошибке.
Если запрос приемлем, маршрутизатор передает сообщение Resv следующему маршрутизатору, находящемуся ближе к отправителю данных.
Сообщение Resv содержит спецификацию flowspec, в которую входит два набора параметров:
Когда маршрутизатор, ближайший к инициатору процедуры резервирования, получает сообщение Resv и выясняет, что запрос приемлем, он передает подтверждающее сообщение получателю данных.
После окончания описанной процедуры ее инициатор начинает передавать данные и на их пути к получателю будет обеспечено требуемое качество доставки информации.
Совместное использование двух протоколов – RSVP на уровне доступа и MPLS на уровне транспортной сети – позволяет предоставлять пользователям конвергентной сети гарантированное качество доставки информации.
Взаимодействие существующих сетей с NGN
На начальном этапе ССОП может стать частью конвергентной сети, а на стыках между ССОП и транспортной сетью IP/MPLS будут устанавливаться шлюзы VoIP – устройства, которые предназначены для преобразования потока информации, поступающего от сети связи общего пользования, к виду, пригодному для передачи по IP-сетям.
Кроме того, в конвергентную сеть войдут сети IP-телефонии альтернативных операторов, использующие для установления соединений протоколы Н.323 и SIP. Сегодня такие сети используются, в основном, для междугородной и международной связи, но в условиях конвергентной сети они станут альтернативой ССОП.
Для управление взаимодействием сетей, входящих в конвергентную сеть, используется многофункциональный и весьма ответственный узел Softswitch.
Этот узел призван управлять соединениями при межсетевой связи, шлюзами и сетевым трафиком. В процессе управления соединениями Softswitch решает задачи поддержки систем сигнализации взаимодействующих сетей. Следует отметить, что Softswitch управляет обслуживанием вызовов и не отвечает за соединение через маршрутизаторы IP-сети. Известны российские разработки: Tario.Net Softswitch и Протей-Softswitch.
На рисунке 4 приведен пример установления соединения абонента ССОП с пользователем сети IP-телефонии в мультисервисной сети, использующей Softswitch и транспортную сеть с технологией IP/MPLS.
Рассмотрим случай, когда нужно связать двух пользователей, один из которых является абонентом ССОП, а второй – пользователем сети IP-телефонии. Пусть инициатором соединения будет VoIP-пользователь (абонент А), а сеть IP-телефонии использует протокол Н.323.
С помощью сообщения Setup протокола сигнализации H.225.0 стека Н.323 абонент А сообщает узлу Softswitch номер абонента ССОП (абонента Б). Softswitch должен определить местонахождение вызываемого абонента и, так как это абонент ССОП, найти ближайший к нему шлюз VoIP.
Терминал абонента А с помощью протокола RSVP запрашивает у маршрутизатора MPLS и получает в сети доступа требуемые ресурсы связи, необходимые ему для гарантированной передачи речевой информации в реальном масштабе времени с соответствующим качеством доставки информации.
Терминал абонента А далеко не всегда имеет прямой доступ к сети MPLS. Доступ к ней может обеспечиваться через Internet общего пользования, которая не обеспечивает гарантированного качества доставки информации. Поэтому в сети доступа необходимо использовать протокол RSVP.
Если в ССОП/ISDN используется система сигнализации ОКС №7, Softswitch посылает сигнальное сообщение IAM (начальное адресное сообщение) в сторону вызываемой станции (которая может находиться в зоне действия другого Softswitch, и тогда сначала сообщениями протокола SIP будут обмениваться узлы Softswitch, а уже потом сообщение IAM будет транслироваться на АТС вызываемого абонента).
Получив от вызываемой станции сообщение ANM об ответе вызываемого абонента, Softswitch транслирует это сообщение в сторону вызывающего абонента А.
Между шлюзом VoIP, который был найден узлом Softswitch, и ближайшим к нему маршрутизатором MPLS устанавливается RSVP-соединение.
Так образуется цепочка: VoIP терминал – маршрутизаторы домена IP/MPLS – шлюз VoIP – АТС – терминал ССОП, и на всем ее протяжении действуют механизмы обеспечения гарантированного качества доставки информации.
Затем начинается передача речевой информации между абонентами через IP-сеть с использованием протоколов RTP/RTCP.
После завершения сеанса соединение разрушается. Для этого абоненты (абонент А взаимодействует с Softswitch, а абонент Б - с АТС) информируют об окончании разговора, после чего резервирование ресурсов протоколом RSVP отменяется.
Предложенный симбиоз технологий MPLS и RSVP пока не может решить проблемы характерного для IP-сетей негарантированного режима доставки информации, применение которого будет негативно влиять на абонентов телефонной сети, которые привыкли к норме потерь по вызовам порядка 3-5 процентов и к малым задержкам в получении сигнала "ответ станции".
Архитектура сети связи, построенной в соответствии с концепцией NGN, представлена на рисунке 5.
Компоненты NGN:
Основные функции Softswitch таковы:
В последнее время ряд крупных фирм, в частности, Alcatel, под Softswitch понимает гибкий коммутатор, поддерживающий функции управления гибридной коммутацией, т.е. оценивающий входящий трафик по различным характеристикам и направляющий его через соответствующие этим характеристикам сéти (включая сети с КК, КП, ATM). По крайней мере, такие возможности управления заложены в протоколе Н.248.
Проблемы перехода к NGN:
Проблемы внедрения услуг в NGN:
Инфокоммуникационные услуги предполагают взаимодействие поставщиков услуг и операторов связи, которое может обеспечиваться на основе функциональной модели распределённых (региональных) баз данных, реализуемых в соответствии с Рекомендацией ITU-T X.500 [4]. Доступ к базам данных организуется с использованием протокола LDAP (Lightweight Directory Access Protocol).
Базы данных позволяют решить следующие задачи:
Базы данных могут использоваться также поставщиками услуг для организации платных информационно-справочных услуг.
Концепция NGN во многом опирается на технические решения, уже разработанные международными организациями стандартизации. Так, например, взаимодействие серверов в процессе предоставления услуг предполагается осуществлять на базе протоколов, специфицированных IETF (MEGACO), ETSI (TIPHON), Форумом 3GPP2 (2-ой проект партнерства по системам мобильной связи 3-го поколения) и т.д.
Для управления услугами могут использоваться протоколы:
В качестве технологической основы построения транспортного уровня мультисервисных сетей рассматриваются технологии АТМ, MPLS, 10GE, IP с возможным применением в будущем оптической коммутации [7].
Мультисервисные сети представляют собой самостоятельный класс сетей, строящихся на основе концепции NGN, на базе которых может быть осуществлено предоставление широкого набора как традиционных, так и новых услуг.
Определение мультисервисных сетей как самостоятельного класса означает, что их регламентация должна осуществляться на основе нормативно-технической базы, учитывающей особенности интеграции различных услуг и системно-технических решений в рамках одной сети.
Базовые услуги, предоставляемые существующими сетями связи и мультисервисными сетями (например, услуги телефонии) должны обладать идентичными характеристиками. Это означает, что мультисервисные сети должны обеспечивать выполнение принятых норм и требований для каждого типа услуг, включая показатели качества, параметры интерфейсов, адресацию/нумерацию и т.д.
Для новых типов услуг (таких как услуги ИСС, услуги мультимедиа, инфокоммуникационные услуги) мультисервисные сети должны обеспечивать возможность взаимодействия с аналогичными услугами других сетей.
Построение мультисервисных сетей должно соответствовать двухуровневой архитектуре: регионального и магистрального (включая межрегиональный) уровней (рисунок 6). Это создаст условия для повсеместного внедрения инфокоммуникационных услуг и решения таких задач, как обеспечение структурной надежности, нормирование показателей качества услуг и т.п.
На региональном уровне мультисервисная сеть должна обеспечивать подключение терминалов абонентов и предоставление им как транспортных, так и инфокоммуникационных и других услуг, а также обеспечивать возможность взаимодействия с аналогичными услугами других региональных сетей.
На магистральном уровне мультисервисная сеть должна обеспечивать предоставление услуг переноса для взаимодействия мультисервисных региональных сетей, а также для всех существующих сетей (при необходимости).
Решение указанных задач связано с формированием сетей доступа, которые бы позволили, с одной стороны, обеспечить разделение трафика на участке, где не накладываются жесткие ограничения на скорость передачи, и, с другой стороны, не осуществляется концентрация трафика. Сеть доступа это системно-сетевая структура, состоящая из абонентских линий, узлов доступа, систем передачи, служащая для подключения пользователей к ресурсам региональных сетей.
Доступ к ресурсам мультисервисной сети осуществляется через граничные узлы, к которым подключается оборудование сети доступа или осуществляется связь с существующими сетями. В последнем случае граничный узел выполняет функции межсетевого шлюза.
Классификация стеков протоколов доставки информации в транспортной сети (рисунок 7).
В транспортной сети могут использоваться разнообразные наборы протоколов для доставки информации различных служб и поддержки приложений:
Выбор того или иного набора протоколов определяется предпочтениями оператора, которые зависят от:
PAGE \* MERGEFORMAT 1
Мультипротокольная транспортная сеть
EMBED Visio.Drawing.11
Ядро транспортной
сети
EMBED Visio.Drawing.11
EMBED Visio.Drawing.11
EMBED Visio.Drawing.11
EMBED Visio.Drawing.11
EMBED Visio.Drawing.11
EMBED Visio.Drawing.11
Оконечный узел/
узел служб
Оконечный узел/
узел служб
Контроллер сигнализации
Контроллер сигнализации
Транзитный узел
Шлюзы
Оконечный
узел
Оконечный
узел
Рисунок 1. Структура мультипротокольной транспортной сети
Получатель
IP-net
Domain MPLS
IP-net
IP-router
LER
LSR
LSR
LER
Path
Path
Path
Отправитель
IP-router
Рисунок 2 – Запрос характеристик качества доставки данных
IP-net
Domain MPLS
IP-net
IP-router
LER
LSR
LSR
LER
Path
Path
Path
Отправитель
IP-router
Рисунок 3 – Запрос характеристик качества доставки данных
Получатель
Resv (Tspec; Rspec)
Рисунок 4. Пример установления соединения абонента ССОП с пользователем сети IP-телефонии в мультисервисной сети, использующей Softswitch и транспортную сеть с технологией IP/MPLS
Мультипротокольная транспортная сеть
Ядро транспортной
сети
Оконечный узел/
узел служб
Оконечный узел/
узел служб
Контроллер сигнализации
Контроллер сигнализации
Транзитный узел
Оконечный
узел
Оконечный
узел
Рисунок 5. Архитектура NGN
Узел служб
Узел управления услугами
Сервер
приложений
Сеть доступа
Сеть доступа
Сеть доступа
Сеть доступа
CCОП
СПД
ССПС
Рисунок 6. Двухуровневая архитектура
мультисервисных сетей
Магистраль-ная сеть 2
ССОП
Магистраль-ная сеть 1
Региональ-ная сеть 1
Региональ-ная сеть 2
Шлюз
Шлюз
Узел служб
Узел служб
Оконечный узел/ узел служб
Оконечный узел/ узел служб
Сеть доступа
Сеть доступа
Рисунок 7. Стеки протоколов доставки
информации в транспортной сети