Контакты
Подписка
МЕНЮ
Контакты
Подписка

В рубрику "Решения операторского класса" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Особенности сетей нового поколения (NGN)Часть 3
Next Generation Network (NGN) peculiarities
Part 3

В ранее опубликованных частях данной статьи речь шла о Next Generation Network (NGN) и их особенностях на базе уже опубликованных ранее стандартов. В части 3 автор дает краткий обзор мультимедийных сервисов и примеров их конвергенции.

In previously published parts of this article, the issue was a Next Generation Network (NGN) and its features on the basis of earlier published standards. In Part 3, the author gives an overview of multimedia services and examples of their convergence.

Николай Слепов
К.т.н., с.н.с. РАН
Nikolay Slepov
PhD Tech., senior staff scientist of the RAS
Ключевые слова:
NGN
Keywords:
NGN

Мультимедийные сервисы

Поддержка большого набора сервисов – одна из фундаментальных характеристик NGN (рек. Y.2001). Поэтому функциональная архитектура NGN должна включать методы сервисного доступа и требовать ресурсной поддержки.

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

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

Абонентская служба операторов связи спроектирована на основе принципов "управления вызовом" (или сессией) и использовании серверов вызова, серверов управления сессией или других подобных средств. Так, технология "голос поверх IP" базируется на протоколах H.323 или SIP, а приложения сервис-провайдера включают в себя менеджеры шлюзов (Gatekeepers) и прокси-серверы SIP. В отличие от этого, сервисы данных достигаются, главным образом, через сессию связи, установленную между терминалами и сервисными платформами. Эти сессии могут быть установлены с помощью таких средств, как IP-адреса рабочих адресных платформ (начальное обеспечение IP-адреса в ПО ПК) или (после сессии) доступа через Web-портал с помощью таких протоколов, как HTTP.

В общем случае, абонентская служба поддерживается ресурсами, установленными с помощью сигналов, сформированных и переданных терминалами конечных пользователей, а сервисы данных – ресурсами, установленными по запросу сервисных платформ. Следовательно, архитектура сетей NGN должна быть приспособлена к обоим типам сервиса. В частности, в обоих случаях запросы ресурсов должны быть одобрены сетью NGN. На рис. 5 показано, как может быть обеспечен доступ к сервису и требуемая поддержка. Линия 1 показывает доступ к сервисам и запрос поддержки с помощью процедур, генерируемых терминалами конечных пользователей и элементами управления сессией. Линия 2 показывает доступ к сервисам и запрос поддержки от сервисных платформ. Поддержка мультимедийных сервисов пока изучается.


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

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


Тогда формируются временные связи с временными пользователями и устройствами, а также связи с пользователями и местоположениями. Сложные и индивидуальные сервисы допускают использование различных схем идентификации как для вызываемой, так и для вызывающей сторон. Эти схемы обычно не имеют фиксированных связей с конкретными местоположениями. В общем случае признают наличие трех логических понятий: пользователи, устройства, местоположения, где пользователи и/или устройства могут быть найдены. Более детально (с учетом решений, использующих агентов) см. рек. Y.130.

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

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

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

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

Сеть NGN должна обрабатывать много типов сервисов, поддерживающих QoS. Чтобы предложить QoS-сервисы, нужно определить: 1) QoS-классы сервиса переносчика (Bearer service), передающего данные между интерфейсами "абонент-сеть"; 2) механизмы управления QoS; 3) функциональную архитектуру управления QoS; 4) управление/передачу сигнала QoS.

Классы QoS
Телесервисы могут работать через терминалы и сети (например, терминалы "mouth-ear" (микрофон-наушник) для голоса) и сервисы переносчика, исключающие терминалы (от UNI до UNI, рис. 7). На практике не всегда можно управлять домашней установкой аппаратных средств пользователя. В среде NGN нужно принимать во внимание рабочие характеристики сети, реализуемые на уровне сервиса переносчика (см. рис. 7 и рек. Y.1541), а также помнить о мобильных сетях. Классы UMTS QoS определяются в 3GPP TS 23.107. Так как NGN должны поддерживать различные типы сетей доступа, нужна гармонизация этих спецификаций, чтобы управлять QoS из конца в конец в гетерогенной сети.


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

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

Независимо от механизма запроса QoS от терминала существуют несколько механизмов распространения запроса QoS в сети и через сети.

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

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

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

Сценарий 3: неавторизованный пользователь, запрашивающий QoS
Здесь терминал пользователя или домашний шлюз способен передать сигнал и управлять QoS-ресурсами. Терминал посылает специальный сигнал для запроса резервирования ресурса контроллеру сетевых ресурсов.

Функциональная архитектура NGN с QoS должна поддерживать механизмы управления QoS в указанных трех сценариях.

Управление/передача сигнала QoS в сети NGN должна использовать уже известные протоколы (например, RSVP, COPS и др.), чтобы выполнить требования управляющей функциональной архитектуры NGN QoS в конкретных сценариях.

Конвергенция сервисов

Пример конвергенции: объединение дистанционного обучения с телеконференц-связью.

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


Конфигурация системы
Широкополосная конвергентная сеть объединяет транспортную сеть, сеть C-HcN (конвергентная сеть до уличного распределительного шкафа) в качестве сети абонента FTTH и серверов приложений. Учет требований QoS гарантируется благодаря использованию MPLS (вместе с технологией ATM). Доступ абонента может быть осуществлен по беспроводной среде или с помощью технологий FTTH, ADSL, VDSL или кабельного модема.

Цифровое мультимедиа радиовещание (DMB) было разработано, чтобы обеспечить прием ТВ- и радиопрограмм на мобильный телефон, ноутбук и другие устройства через спутник и/или по линиям наземной связи, когда пользователь может принять сигнал, находясь на мобильном объекте. Таким образом, непрерывный сервис может быть обеспечен между фиксированными и мобильными терминалами. Такие терминалы для беспроводной и проводной связи соединяются с оборудованием контент-провайдера (CP) по широкополосной магистральной сети, которая доставляет им видеоконтент.

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

  • функции ONU (оптического сетевого блока) для соединения сети с уличным распределительным блоком абонента;
  • функции BSB (широкополосной ТВ-приставки) для соединения уличного блока абонента с домашней сетью;
  • интерфейсы между ONU и BSB и схемами передачи;
  • модель сервиса, занимающегося доставкой конвергентных сервисов;
  • функции терминального оборудования TE фиксированной и мобильной связи;
  • приемлемое рассогласование скорости передачи потока в проводных и беспроводных секциях, соответствующее требованиям контента;
  • функции видеосервера, системы редактирования видео и Web-сервера.

Типичные требования на полосу пропускания для поддержки каждого из сервисов на рис. 8 таковы:

  • HDTV: 20 Мбит/сЧ3 канала, Видеофон: 4 Мбит/с×4 канала, сервис Интернета: 20 Мбит/с, голосовой сервис высокого качества: 2 Мбит/с;
  • Пример с выделением полной ширины полосы: примерно 100 Мбит/с.

Взаимодействие между окружением сетей NGN и не-NGN

Введение
Важный аспект обеспечения "гладких" операций – возможность взаимодействия между сетями NGN и между сетями NGN и другими сетями, такими как ТфОП (PSTN) (рис. 9).


Предполагается, что сеть NGN будет взаимодействовать с другими сетями, чтобы обеспечивать:

  • резервирование возможности связи из конца в конец для пользователей таких сетей, как ТфОП;
  • возможность доставки контента для пользователей Интернета, ТВ-сетей и т.д.;
  • последовательное (шаг за шагом) развертывание сетей NGN;
  • наследование "богатых" сервисов для традиционных сетей.

Принципы действия функций IWF между сетями NGN
Указывалось, что модель NGN состоит из двух слоев: сервисного и транспортного, причем каждый из них охватывает плоскости пользователя, управления и менеджмента. Взаимодействие между сетями NGN или между сетью NGN и другими сетями может быть двух типов: взаимодействие сервисов или взаимодействие сетей, как это определено в рек. Y.1251. На рис. 10 показано взаимодействие между двумя сетями NGN.


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

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

Агенты
Воспользуемся следующим определением понятия агент. Агент – элемент/объект, выполняющий задачу от имени какого-то субъекта (то есть пользователя, приложения или другого агента), вместо того, чтобы доверить ее выполнение самому субъекту. Термин "субъект" относится к клиенту или серверу приложений, вовлеченному в общение с другими участниками взаимодействия. Предполагается, что многие сервисы и технологии могут удовлетворить требованиям пользователей, которые больше озабочены типом сервиса, его качеством (QoS) и стоимостью. Задача агентов, работающих в рамках программно-аппаратных сервисов, – облегчить пользователям процесс выбора и использования связных сервисов.

Модель взаимодействия через агентов
Несмотря на наличие уровней и плоскостей в архитектуре, функция взаимодействия IWF может быть разложена на три составляющие ее агента, если представить модель взаимодействия в виде архитектуры инфокоммуникаций ICA (Information Communication Architecture), использующей агентов, как показано на рис. 11 в соответствии с рек. Y.130.


Эта архитектура имеет следующие особенности:

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

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

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

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

  • Contact Agent – агент контакта, используемый для идентификации взаимодействующих сторон;
  • Exchange Agent – агент обмена, используемый для менеджмента сессий;
  • Transport Agent – агент транспорта, используемый для выбора транспорта.

Эти особенности и концепции формируют схему взаимодействия в архитектуре ICA:

Contact Agent - > Exchange Agent - > Transport Agent.

В этой схеме (дополнительно к указанному выше):

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

Такая организация компонентов программно-аппаратного сервиса дает возможность:

  • а) прикладным функциям общаться через интерфейс прикладного программирования (API);
  • б) интерфейсу API воспользоваться программно-аппаратным обеспечением (ПАО);
  • в) распределенным функциональным объектам ПАО кооперироваться с другими функциональными объектами ПАО;
  • г) программно-аппаратному обеспечению ПАО общаться через интерфейс базового программного обеспечения (БПО);
  • д) интерфейсу базового программного обеспечения (BWPI/ИБПО) воспользоваться БПО.

На рис. 12 роль агентов, приведенных на рис. 11, отражена более точно, благодаря показу используемых между ними слоев-интерфейсов ПАО: API (интерфейса прикладного программирования), MPI (программно-аппаратного интерфейса) и BPI (базового программного интерфейса).


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

Приложения - > API - > Агент контакта - > MPI - > Агент обмена - > MPI - > Агент транспорта - > BPI - > БПО

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

Стек протоколов сетей NGN: исходная модель

Сервисы обеспечиваются созданием стека протоколов, то есть нескольких уровневых протоколов. Есть два подхода к использованию этих протоколов: вертикальный и горизонтальный. На рис. 13 показан стек уровневых протоколов. На нем конец стека сетевых протоколов и начало стека прикладных протоколов обозначен одним уровнем n. Так, например, в контексте сети Интернет уровень n был бы уровнем IP, а уровень n+1 – уровнем TCP или UDP. Множество лежащих ниже слоев – от n-1 до n-i – зависит от определяемых ими технологий, используемых для поддержки IP (например, технологии FR, передаваемой поверх ATM или технологии ATM поверх SDH). Каждый уровень, лежащий ниже или выше, имеет свой собственный набор функций. Согласно общему принципу, желательно не дублировать функции на каждом уровне, хотя это и не всегда возможно или желательно. Адресация и управление потоком различных уровней стека протоколов могут быть (в ряде случаев) отнесены к категории, для которой необходимо дублирование. Общая функциональность, обеспечиваемая уровню n+i, эквивалентна суммарному вкладу функций всех лежащих ниже уровней.

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

Базовая уровневая архитектура стека протоколов
Уровень n+1 – уровень, который обеспечивает требования сервиса пользователя и связанные с ними операционные параметры. Это та информация, что дает возможность выбрать протокол для уровня n и соответствующие операционные политики. Уровень n – уровень, представляющий интерес как для пользователя сервиса, так и провайдера, называется уровнем первичного протокола. Этот уровень обеспечивает протокольный мост между примерами сервиса и транспортными сессиями в виде сессий связи. Выбор протокола осуществляется динамически и сохраняется на весь жизненный цикл этого сервиса. Уровень n+1 – это наивысший уровень, имеющий отношение к транспортному сервису пользователя и провайдера. Уровень n+1 поддерживает связь между приложениями и не должен рассматриваться транспортным сервисом провайдера. Уровни ниже уровня первичного протокола рассматриваются вместе со сквозными транспортными функциями, связанными с сессиями связи, и не должны рассматриваться пользователями приложений.

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

Эволюция сетей связи и систем управления

Цифровые сети связи за пятьдесят лет своего развития, используя технологию PDH в сетях ТфОП, достигли высокого уровня и стали управляться системами/сетями уровня TMN (Telecommunication Management Network). Они использовались как в сетях PDH, так и SDH, имели иерархическую вертикально интегрированную структуру с моделью типа четырехуровневой иерархической модели управления сетью и собственной сетью передачи управляющих данных [3]:

  • бизнес-менеджмент (BM) – верхний уровень управления экономической эффективностью сети – BOS;
  • сервис-менеджмент (SM) – уровень управления сервисом сети – SOS;
  • сетевой менеджмент (NM) – уровень систем управления сетью – NOS;
  • элемент-менеджмент (EM) – нижний уровень элемент-менеджеров, систем управления элементами – EOS.

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

ТфОП - > ISDN - > IN/AIN - > IP-ТфОП - > NGN.

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

CAS - > CCS - > SS6 - > SS7.

Здесь протокол CAS использовал 4 бита abcd на 1 канал (для формирования 16 команд) в общем логическом поле 16×8 (TS16) в 128 битах 16-фреймового мультифрейма (PDH). Протокол CCS отличался от CAS тем, что не был привязан к тайм-слоту TS16 и мог занимать любой тайм-слот TS или же вообще мог использовать внешний канал управления емкостью 120 (30×4) бит для управления E1 [3]. В системе сигнализации SS6 для передачи команд управления был использован протокол CCS на базе системы модемной связи со скоростью 4800 бит/с. В системе сигнализации SS7 отказались от модемной связи и использовали поток 64 кбит/с канала TS16 для управления 30 каналами E1.

Революционным в дальнейшем развитии SS7 было то, что сеть сигнализации фактически отделилась от сети коммутации ТфОП и сформировалась на базе четырехуровневой модели сети сигнализации, предложенной компанией Bellcore (1991) для продвинутой интеллектуальной сети (AIN). Ее модель включает четыре уровня: TUP (подсистема пользователя ТфОП) и три подсистемы передачи сигнальных сообщений MTP: MTP-3 (ISO, нижний подуровень уровня 3), MTP-2 (ISO, уровень 2) и MTP-1 (ISO уровень 1), рис. 14 [4].


Сеть ISDN использовала ряд протоколов сигнализации вызова, учитывая множество местных реализаций основной технологии: ISDN-1,2 (Bellcore, США); ISDN 5ESS (AT&T, США); EuroISDN (ETSI, Европа); ISDN 30 (DASS-2, Великобритания); ISDN NTT (INS-NET, Япония); QSIG (ECMA), а также множество протоколов сигнализации, разработанных ITU-T: для OSI уровня 1 – I.430, 431, 461-463, 465, V.120; уровня 2 – I.440, 441, 462, X.25; уровня 3 – I.450, 451, 461-463, X.25. Ее модель включает четыре уровня (рис. 14): ISUP (подсистема пользователя ISDN) и три уровня MTP или пять уровней (с дополнительным уровнем SCCP – верхним подуровнем уровня 3 OSI).

Интеллектуальные сети IN/AIN, появившиеся в процессе эволюции сетей в результате развития системы сигнализации SS7, предусматривали разделение функций внутри SS7 на функции обмена сигнальными сообщениями и функции доступа к новым сервисным услугам. Их модель включает уже шесть уровней: INAP (прикладной протокол IN), TCAP (подсистемы средств транзакций), SCCP и три уровня подсистемы передачи сигнальных сообщений MTP-1, 2, 3 (рис. 14).

Уровни 4-уровневой модели сети сигнализации SS7: (снизу вверх)

  • SP – уровень оконечных узлов/пунктов сигнализации (АТС/PBX; ISDN BRI/PRI; Residential; ТА)
  • SSP – уровень узлов/пунктов коммутации сигнала;
  • STP – уровень транзитных узлов/пунктов передачи сигнализации;
  • SCP – уровень узлов/пунктов управления сигналом/сервисом.

Дальнейшая эволюция сетей связи, приведшая к возникновению IP-телефонии, продемонстрировала возможность пакетной передачи голоса (VoIP). Это потребовало организации не только сетевой передачи сигнализации, но и конвертации IP-адресов ЛС в адреса ТфОП (согласно рек. E.164), а также необходимости шлюзования сигналов между IP-сетями и сетями ТфОП, то есть их более тесного взаимодействия. Такое усложнение задач, решаемых гибридными, по сути, сетями IP-ТфОП, привело к появлению более сложной системы сигнального управления, ядром которой стал Softswitch – программный коммутатор. В его задачи входило: управление вызовами (включая сигнализацию вызовов), управление соединением, маршрутизация и передача сигналов (включая все виды шлюзования), а также управление услугами и системами биллинга. Итогом этой эволюции на данном этапе и принято считать появление сетей NGN.

Литература

  1. Бакланов И.Г. NGN: Принципы построения и организации. – М.: Эко-Трендз, 2007. – 400 с.
  2. Сети следующего поколения NGN. Под ред. А.В.Рослякова. – М.: Эко-Трендз, 2008. – 424 с.
  3. Слепов Н.Н. Современные технологии цифровых оптоволоконных сетей связи (АТМ, PDH, SDH, SONET и WDM). – 2-е изд. – М.: Радио и связь, 2003. – 468 с.
  4. Слепов Н.Н. Современные цифровые технологии глобальных сетей связи. – М.: Астра-полиграфия, 2011. – 298 с.

Опубликовано: Журнал "Технологии и средства связи" #4, 2014
Посещений: 20185

Статьи по теме


  Автор
Николай Слепов

Николай Слепов

Независимый эксперт

Всего статей:  23

В рубрику "Решения операторского класса" | К списку рубрик  |  К списку авторов  |  К списку публикаций