В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
Поддержка большого набора сервисов – одна из фундаментальных характеристик 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 механизмы имеют большое влияние на архитектуру, которая может понадобиться, чтобы обеспечить их. Фактически, существует несколько альтернатив, зависящих, например, от возможностей терминала пользователя или от запросов сервиса. Можно выделить три сценария:
Независимо от механизма запроса 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. Ясно, что нужно продолжать исследование в плане определения функций и их распределения среди сетевых элементов и интерфейсов между ними. Здесь интересны следующие функции и интерфейсы:
Типичные требования на полосу пропускания для поддержки каждого из сервисов на рис. 8 таковы:
Введение
Важный аспект обеспечения "гладких" операций – возможность взаимодействия между сетями NGN и между сетями NGN и другими сетями, такими как ТфОП (PSTN) (рис. 9).
Предполагается, что сеть NGN будет взаимодействовать с другими сетями, чтобы обеспечивать:
Принципы действия функций IWF между сетями NGN
Указывалось, что модель NGN состоит из двух слоев: сервисного и транспортного, причем каждый из них охватывает плоскости пользователя, управления и менеджмента. Взаимодействие между сетями NGN или между сетью NGN и другими сетями может быть двух типов: взаимодействие сервисов или взаимодействие сетей, как это определено в рек. Y.1251. На рис. 10 показано взаимодействие между двумя сетями NGN.
Точное физическое положение блока взаимодействия (IWU), содержащего функцию взаимодействия (IWF), определяется в процессе реализации. Функции IWF уникальны для каждого конкретного случая взаимодействия. В качестве примера IWF ниже рассмотрены следующие варианты:
Агенты
Воспользуемся следующим определением понятия агент. Агент – элемент/объект, выполняющий задачу от имени какого-то субъекта (то есть пользователя, приложения или другого агента), вместо того, чтобы доверить ее выполнение самому субъекту. Термин "субъект" относится к клиенту или серверу приложений, вовлеченному в общение с другими участниками взаимодействия. Предполагается, что многие сервисы и технологии могут удовлетворить требованиям пользователей, которые больше озабочены типом сервиса, его качеством (QoS) и стоимостью. Задача агентов, работающих в рамках программно-аппаратных сервисов, – облегчить пользователям процесс выбора и использования связных сервисов.
Модель взаимодействия через агентов
Несмотря на наличие уровней и плоскостей в архитектуре, функция взаимодействия IWF может быть разложена на три составляющие ее агента, если представить модель взаимодействия в виде архитектуры инфокоммуникаций ICA (Information Communication Architecture), использующей агентов, как показано на рис. 11 в соответствии с рек. Y.130.
Эта архитектура имеет следующие особенности:
Указанные особенности показывают, что архитектура ICA может быть основана на следующих трех ключевых функциях:
Транспортные технологии и провайдеры
Подход, используемый для обеспечения этих трех функций, состоит в организации соответствующей подготовки агентов в рамках архитектуры ICA. В частности, применительно к данной проблеме могут быть предложены три типа агентов, см. рек. Y.130:
Эти особенности и концепции формируют схему взаимодействия в архитектуре ICA:
Contact Agent - > Exchange Agent - > Transport Agent.
В этой схеме (дополнительно к указанному выше):
Такая организация компонентов программно-аппаратного сервиса дает возможность:
На рис. 12 роль агентов, приведенных на рис. 11, отражена более точно, благодаря показу используемых между ними слоев-интерфейсов ПАО: API (интерфейса прикладного программирования), MPI (программно-аппаратного интерфейса) и BPI (базового программного интерфейса).
В результате схема взаимодействия агентов может быть представлена более точно:
Приложения - > API - > Агент контакта - > MPI - > Агент обмена - > MPI - > Агент транспорта - > BPI - > БПО
Роль агентов в том, чтобы дать возможность сторонам (участвующим в схеме взаимодействия) легко и эффективно общаться в среде различных сетевых доменов. В плане совместного действия сервис агентов должен быть направлен на объединение/концентрацию возможностей инфраструктуры в рамках сессии связи для достижения целей, поставленных взаимодействующими сторонами. Термин "агент" используется также для того, чтобы акцентировать тот факт, что "делегирование функций" служит для изоляции каждого слоя от деталей, лежащих под ним. Это разделение вопросов, требующих решения, гарантирует, что такая архитектура отвечает многим ключевым принципам проектирования архитектуры ICA.
Сервисы обеспечиваются созданием стека протоколов, то есть нескольких уровневых протоколов. Есть два подхода к использованию этих протоколов: вертикальный и горизонтальный. На рис. 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]:
Кроме управления типа 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: (снизу вверх)
Дальнейшая эволюция сетей связи, приведшая к возникновению IP-телефонии, продемонстрировала возможность пакетной передачи голоса (VoIP). Это потребовало организации не только сетевой передачи сигнализации, но и конвертации IP-адресов ЛС в адреса ТфОП (согласно рек. E.164), а также необходимости шлюзования сигналов между IP-сетями и сетями ТфОП, то есть их более тесного взаимодействия. Такое усложнение задач, решаемых гибридными, по сути, сетями IP-ТфОП, привело к появлению более сложной системы сигнального управления, ядром которой стал Softswitch – программный коммутатор. В его задачи входило: управление вызовами (включая сигнализацию вызовов), управление соединением, маршрутизация и передача сигналов (включая все виды шлюзования), а также управление услугами и системами биллинга. Итогом этой эволюции на данном этапе и принято считать появление сетей NGN.
Литература
Опубликовано: Журнал "Технологии и средства связи" #4, 2014
Посещений: 27014
Статьи по теме
Автор
| |||
В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
