В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
Часть 2*
А.Б. Гольдштейн, к.т.н., доцент СПб ГУТ им. Бонч-Бруевича
Н.А. Соколов, к.т.н., профессор СПб ГУТ им. Бонч-Бруевича
Системные исследования принципов создания NGN, фрагменты которых изложены в первой части этой статьи, свидетельствуют о сложности построения сети. К этому следует добавить не менее актуальный вопрос: "Из чего строить сеть следующего поколения?". Множество красивых аббревиатур, новых технологий и оригинальных подходов на самом деле часто лишь скрывают непонимание. Для того чтобы создать действительно Сеть следующего поколения (или, как остроумно переводят термин "Next Generation Network" некоторые авторы, "Сеть ДЛЯ следующего поколения"), надо следовать не "букве" пока не созданных правил, а "духу" концепции.
Введение № 2
Начать вторую часть статьи целесообразно с проблемы применения оборудования NGN в единой системе электросвязи Российской Федерации (ЕСЭ РФ). Читателю, знакомому с ситуацией, известно, что сегодняшняя концепция ЕСЭ РФ и, следовательно, техническая политика Администрации связи не приемлет понятий, ассоциируемых с NGN (например, Softswitch). Некоторые специалисты оперируют понятием "узел коммутации", просто не вдаваясь в подробности его работы, - TDM или NGN. Главное, чтобы выполнялись требуемые функции. Нам этот подход представляется правильным для тех аспектов анализа инфокоммуникационной системы, которые рассматривались в первой части статьи. Во второй части статьи мы попробуем посмотреть "с другой колокольни": что же именно будет скрываться "под маской" NGN?
Истоки NGN
Прежде чем перейти непосредственно к рассмотрению основных элементов, ассоциируемых с NGN, необходимо вспомнить об организациях, создающих идеологию этих сетей. Из первой части статьи читатель уже знает о семинарах, проводимых Международным союзом электросвязи (МСЭ) по NGN. Кроме того, в июне 2004 г. начала работу фокус-группа по NGN (Focus Group on NGN, FGNGN), в составе которой были организованы семь рабочих групп. Чуть позже к работам FGNGN присоединилась 13-я Исследовательская комиссия МСЭ (Study Group 13, SG13), взяв на себя руководство и координацию проводимых исследований. Параллельно шли работы в ETSI (Европейский институт телекоммуникационных стандартов) - проект TISPAN, создавались документы в консорциуме 3GPP, Форуме ATM, IPCC и в ряде других объединений.
В какой-то степени именно из-за параллельности работ развитие сетей NGN шло медленнее и сложнее, чем ожидалось. Часто появление новой идеи захватывало умы, и развитие "старых" идей останавливалось. Яркий пример - появление IMS (IP Multimedia Subsystem). Практически сразу большая часть производителей назвала свои NGN-решения IMS, консорциум IPCC был переименован в IMS Forum.
Нечто подобное наблюдалось в начале текущего десятилетия, когда появилось понятие "Softswitch", а теперь происходит и с IMS. И этот пример не единственный. Что же это: дань моде или эволюция? Нам кажется, что правильный ответ на данный вопрос во многом определит и развитие NGN.
Оборудование сетей NGN
Этот раздел статьи в целом призван раскрыть технологические аспекты сценариев, изложенных в первой части статьи. Наивно полагать, что эти аспекты окажутся столь же конкретными: если сценарии первой части статьи более или менее четко описывают действия Оператора, то используемое оборудование может быть различным. Однако некоторые положения должны быть реализованы в обязательном порядке.
Каким бы ни был путь создания NGN, присутствие элемента, отвечающего за управление процессом установления соединения, неизбежно. Речь идет о классической связи между двумя системами: управляющей и управляемой (рис. 1).
Долгое время единственным кандидатом на роль управляющей системы был сигнальный коммутатор Softswitch. Сейчас у него появились конкуренты, основным из которых выступает уже упоминавшаяся технология IMS. Правда, являются ли они конкурентами на самом деле - вопрос спорный; ему посвящена отдельная статья [1]. А для объединения различных IP-сетей и доменов, которое обсуждается в первой части статьи, необходим граничный контроллер сессий - SBC (Session Border Controller).
Сигнальные коммутаторы Softswitch
Напомним, что термин "Softswitch" используется не только для идентификации одного из элементов сети. С ним связаны и сетевая архитектура, и даже в определенной степени сама идеология построения сети. Для нас же важны выполняемые коммутатором Softswitch функции и его способность решить ряд задач, присущих узлам с коммутацией каналов.
Функции оборудования
В первую очередь коммутатор Softswitch управляет обслуживанием вызовов, то есть установлением и разрушением соединений. Точно так, как это имеет место в традиционных АТС с коммутацией каналов, если соединение установлено, то эти функции гарантируют, что оно сохранится (с установленной вероятностью) до тех пор, пока не даст отбой вызвавший или вызванный абонент. В этом смысле коммутатор Softswitch можно рассматривать как управляющую систему.
В число функций управления обслуживанием вызова входят распознавание и обработка цифр номера для определения пункта назначения; а также распознавание момента ответа, момента, когда один из абонентов кладет трубку, и регистрация этих действий для начисления платы. Таким образом, Softswitch фактически остается все тем же привычным коммутационным узлом, только без цифрового коммутационного поля и абонентских комплектов, что позволяет легко интерпретировать его функции в различных сценариях модернизации телефонной сети общего пользования (ТФОП). Ответственность за перечисленные выше операции Softswitch возложена на входящий в его состав функциональный элемент Call Agent.
Другой термин, часто ассоциируемый с Softswitch, - контроллер транспортного шлюза MGC. Это название подчеркивает факт управления транспортными шлюзами и шлюзами доступа по протоколу H.248 или другому. Softswitch координирует обмен сигнальными сообщениями между сетями, то есть поддерживает функциональность шлюза
сигнализации - Signalling Gateway (SG). Он координирует действия, обеспечивающие соединение с логическими объектами в разных сетях, и преобразует информацию в сообщениях. Подобное преобразование необходимо, чтобы сигнальные сообщения были одинаково интерпретированы на обеих сторонах несходных сетей, обеспечивая с первого этапа модернизации работу с автоматическими телефонными станциями (АТС).
На рис. 2 показано место Softswitch в ЕСЭ РФ и его взаимодействие с различными существующими и перспективными элементами сетей общего пользования по соответствующим протоколам. Описание функциональной структуры Softswitch можно найти, например, в [2].
Архитектура
С точки зрения сценариев модернизации ТФОП и ЕСЭ РФ в целом нас также интересует архитектура построения Softswitch и разделение этого оборудования на 4-й и 5-й классы. Исторически сложившееся разделение на классы автоматически было перенесено на Softswitch, однако на самом деле это заслуживает внимания только в случае внедрения Softswitch вместо узла с коммутацией каналов. C точки зрения передачи речи по IP-сети (Voice over IP, VoIP) это разделение будет не совсем корректным. При работе по любому сигнальному протоколу VoIP нет различий, например, между SIP-телефоном и Proxy-сервером SIP. Поэтому разделение на транзитные и местные устройства для Softswitch важно лишь при работе в ТФОП.
Эталонная же архитектура сетей на базе Softswitch, созданная уже упомянутым IPCC (ныне ISM Forum), состоит из четырех условных функциональных уровней (рис. 3).
Как видно, деление довольно свободное и оставляющее пространство для маневра. Это, вероятно, вызвано желанием охватить многочисленные вариации оборудования Softswitch различных производителей. В центре каждого из таких решений находится сам Softswitch, который теоретически относится к уровню управления вызовами и сигнализации, но в практических решениях в той или иной степени захватывает функции остальных уровней архитектуры.
Таким образом, при фактическом соблюдении принципа функциональной декомпозиции шлюза можно наблюдать различные варианты его реализации. Первые Softswitch-решения представляли собой единый блок, то есть физической декомпозиции шлюза не было, но существовало разделение функций программных или аппаратных модулей. Иными словами, оборудование имело интегрированную архитектуру. В другом варианте физически отделялся лишь медиа-шлюз, а контроллер медиа-шлюзов и шлюз сигнализации составляли единый комплекс. Такое решение можно считать частичной физической декомпозицией.
Вопросы дальнейшего развития
Вместе с тем при всех достоинствах Softswitch оставалось несколько проблем, без решения которых дальнейшее развитие этой технологии существенно осложнялось. Основными из них стала реализация функции системы оперативно-розыскных мероприятий (СОРМ), отслеживание показателей QoS (особенно в случае заключения соглашений об уровне обслуживания SLA - Service Level Agreement) и преодоление межсетевых экранов. Появление контроллеров SBC стало решением этих проблем.
Использование контроллеров SBC
Основная задача SBC - интерактивное соединение отдельных IP-сетей. В большей степени их преимущества проявляются при передаче через границы сетей голосового, видео- или мультимедийного трафика, то есть трафика реального времени.
Функциональность
Традиционно провайдеры IP-телефонии взаимодействовали между собой, используя голосовые шлюзы (Media Gateway), подключенные к телефонным коммутаторам. Такая схема работы позволяет обеспечить безопасность соединения и предоставить всю необходимую биллинговую информацию. Правда, за счет дополнительного преобразования в кодеках снижается качество голоса и повышается стоимость пропуска трафика. К тому же такая схема не дает возможности пропускать трафик других мультимедиа приложений (таких, как Instant Messaging и видеопотоки). Но пока трафика IP-телефонии в мире было немного и он в основном носил характер соединений типа "точка - точка", это не вызывало больших проблем.
Для решения проблемы межоператорского взаимодействия и был создан SBC, после чего вместо схемы "IP-TDM-IP" стало использоваться прямое соединение "IP-IP". Кроме того, SBC берет на себя обеспечение взаимодействия сетей:
Это означает, что контроллер SBC устанавливается на границе сети и выполняет те функции, которые нецелесообразно возлагать на Softswitch. В этом идея применения контроллеров SBC напоминает введение периферийных устройств управления для улучшения работы первого поколения АТС с программным управлением, в которых функции управления были реализованы в двухмашинном комплексе специализированных ЭВМ. Также надо понимать, что SBC работает с такими сетевыми устройствами, как Softswitch, межсетевой экран (Firewall), устройство преобразования сетевых адресов NAT, но не замещает их.
Функциональность SBC значительно шире, чем это необходимо "помощнику" Softswitch. Следует отметить, что разделение функциональности между системами Softswitch и SBC очень размыто. Softswitch может брать на себя большинство функций SBC, оставляя последнему лишь функцию нормализации трафика, то есть согласования кодеков, сигналов DTMF (многочастотный набор) и пр. Задачи Softswitch фокусируются на управлении медиа-шлюзами и маршрутизации вызовов между ТФОП и IP-сетью или внутри IP-сети. SBC изначально ориентирован на гораздо большее количество услуг реального времени (видео, мультимедиа, Instant Messaging), реализуемых в IP-сети. Трафику, пропускаемому через SBC, обеспечивается управление качеством обслуживания, безопасностью, полосой пропускания, но SBC не выполняет функции маршрутизации. Поэтому для взаимодействия сетей необходимо одновременное использование обоих видов оборудования - Softswitch и SBC.
Архитектура
Продукты SBC могут иметь распределенную архитектуру. Она включает в себя центральный узел CSBC (Core SBC), находящийся в границах сети провайдера, и оконечные устройства ESBC (Edge SBC), которые устанавливаются на границе сети. При этом CSBC распределяет трафик между ESBC.
Логически SBC можно разделить на два функциональных модуля, один из которых занимается всем, что связано с сигнализацией (SBC-SIG), а другой работает с пользовательским трафиком (SBC-MEDIA). На рынке представлены два варианта построения SBC:
Интегрированные решения SBC представляют обычно двухпортовые устройства: один из портов обращен к внешней сети, а второй - к внутренней. При этом каждый порт используется как для данных, так и для сигнализации, что создает риск отброса сигнальных пакетов.
В случае распределенной архитектуры SBC-SIG располагается в сети провайдера, а модули SBC-MEDIA выносятся на границу сети. Весь сигнальный VoIP-трафик из внешних сетей направляется к SBC-SIG. При этом центральное устройство SBC-SIG может обрабатывать сигнализацию, поступающую с нескольких точек доступа, и управлять находящимися в них SB C-MEDIA. Последние представляют собой более дешевые устройства, чем SBC-SIG, поэтому распределенная архитектура позволяет эффективно строить крупномасштабные решения. Кроме того, функция SBC-SIG может быть реализована в коммутаторе Softswitch, управляющем сетью провайдера, что зачастую уже имеет место в существующих Softswitch-решениях.
Проблемой распределенной архитектуры становится, конечно же, совместимость. MSF (Multiservice Switching Forum) для обеспечения совместимости этих устройств рекомендует придерживаться стандарта H.248, однако производители иногда используют другие протоколы, например COPS-PR (Common Open Policy Service protocol Usage for Policy Provisioning).
SBC vs. Softswitch?
Мы не будем подробно разбирать каждую функцию SBC. Вместо этого зададимся следующим вопросом: нужен ли Softswitch при использовании SBC? Можно применить схему, состоящую из Softswitch и SBC-media на границах сети. А можно использовать распределенную архитектуру SBC и обойтись без Softswitch. Ведь расширение функциональности SBC может практически уравнять его с простейшими Softswitch-решениями 4-го класса.
Возможно, это и стало бы очередной проблемой в концепции NGN. И мы получили бы два различных решения, но, к счастью, нашлись два аргумента в пользу применения Softswitch. Во-первых, взаимодействие с устройствами ТФОП явно выходит за рамки функциональности SBС. Во-вторых, появление нового отдельного устройства в сети вряд ли целесообразно: проще доработать Softswitch модулем SBC-SI G. Правда, надо отметить, что Softswitch может обслуживать конечное число вызовов в единицу времени. В этом плане применение SBC имеет важное значение, поскольку характеризуется лучшими показателями по масштабируемости. По этим соображениям симбиоз Softswitch и SBC представляется весьма удачным союзом.
Концепция мультимедийной подсистемы IMS
История развития
Исторически к IMS вели два направления. Эту технологию можно воспринимать как продолжение эволюции интеллектуальных платформ, которая началась более десяти лет назад, когда были утверждены первые стандарты в этой области.
Второй вариант развития событий берет начало в технологии Softswitch. Технология IMS стала продолжением эволюции устройств управления NGN, но теперь к фиксированным сетям присоединились подвижные, и был сделан акцент на 3G.
Концепция IMS была разработана в 2002 г. консорциумом 3rd Generation Partnership Project (3GPP) для сетей 3G/W-CDMA и стандартизована в спецификациях 3GPP R.5. Позднее созданной моделью воспользовались сразу несколько организаций: 3GPP2, занимающаяся разработками для сетей CDMA2000, ETSI, группа Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN), работающая в области конвергенции фиксированных сетей. Альянс Open Mobile Alliance (OMA) определил приложения и услуги, работающие поверх IMS, а Internet Engineering Task Force (IETF) -протоколы сетевого уровня. ETSI, отраслевые группы Форума мульти-сервисной коммутации (Multiservice Switching Forum, MSF) и Альянса для продвижения решений для телекоммуникационной отрасли (Alliance for Telecommunications Industry Solutions, ATIS) одобрили IMS в качестве основы сетевой инфраструктуры следующего поколения.
Ключевые отличия
Производители, как правило, делают акцент на нескольких ключевых отличиях IMS от предыдущих конвергентных решений. Для начала специалисты отмечают, что основное преимущество и отличие концепции IMS от других технологий NGN заключается в возможности мульти-стандартного доступа к услугам, когда одни и те же услуги можно получать при помощи разных сетей доступа -от широкополосной xDSL до Wi-Fi или UMTS. При этом смена сетей доступа происходит незаметно.
Потребителю переход на IMS сулит появление персонализированных услуг, основанных на передаче речи, текста, графики и видео в любой комбинации, создание новых сервисов, а также объединение и совершенствование существующих. IMS открывает дорогу услугам Push-to-Talk (полудуплексная связь, когда сотовый телефон используется как терминал системы профессиональной мобильной радиосвязи) с функцией определения присутствия вызываемого абонента, технологии UMA (Unlicensed Mobile Access), PhotoTalk ("фоторазговору"), Instant Messaging, MultiChat и многим другим.
Архитектура
IMS обеспечивает архитектуру (рис. 4), в которой многие функции могут быть использованы с различными приложениями и у разных провайдеров. Это позволяет быстро и эффективно создавать новые услуги и непосредственно предоставлять их. В основе концепции этого стандарта лежит способность IMS передавать сигнальный трафик и трафик в канале через IP-уровень, а также выполнять функции маршрутизатора или механизма управления сессиями абонентов с использованием информации об их состоянии.
IMS включает в себя блок интерфейсов, SIP-прокси-серверов и обычных серверов, а также медиа-шлюзов (для подсоединения к сетям с протоколом, отличным от IP). Сервисная архитектура представляет собой набор логических функций, которые можно разделить на три уровня:
Функциональность
1. На уровне транспорта и абонентских устройств инициируется и терминируется сигнализация SIP, необходимая для установления сеансов и предоставления базовых услуг, таких, как преобразование речи из аналоговой или цифровой формы в IP-пакеты с использованием протокола RTP (Realtime Transport Protocol). На этом уровне функционируют медиа-шлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM.
2. На следующем уровне располагается функция управления вызовами и сеансами CSCF (Call Session Control Function), которая регистрирует абонентские устройства и направляет сигнальные сообщения протокола SIP к соответствующим серверам приложений. Функция CSCF связана с уровнем транспорта и доступа для обеспечения качества обслуживания по всем сервисам.
Уровень управления вызовами и сеансами включает в себя сервер абонентских данных HSS (Home Subscriber Server), где централизованно хранятся уникальные сервисные профили всех абонентов. На уровне управления вызовами и сеансами также располагается функция управления медиа-шлюзами MGCF (Media Gateway Control Function), которая обеспечивает взаимодействие сигнализации SIP с сигнализацией других медиа-шлюзов (например, H.248). Функция MGCF управляет распределением сеансов по множеству медиа-шлюзов; для медиасерверов это выполняется функцией MSFC (Media Server Function Control).
Функция CSCF в IMS разделена на три подфункции:
3. Уровень услуг состоит из серверов приложений и контент-серверов для предоставления абонентам дополнительных услуг. Базовые средства предоставления услуг, как это определено стандартом IMS (например, управление присутствием или управление списками групп), реализованы в качестве услуг на сервере SIP-при-ложения.
Серверы приложений обеспечивают обслуживание конечных пользователей. Архитектура IMS и сигнализация SIP обеспечивают достаточную гибкость для поддержки разнообразных телефонных и других серверов приложений. Так, разработаны стандарты SIP для услуг телефонии и сервисов IMS.
Архитектура IMS поддерживает множество серверов приложений для телефонных сервисов. Сервер телефонных приложений TAS (Telephony Application Server) принимает и обрабатывает сообщения протокола SIP, а также определяет, каким образом должен быть инициирован исходящий вызов. Сервисная логика TAS обеспечивает базовые сервисы обработки вызовов, включая анализ цифр, маршрутизацию, установление, ожидание и перенаправление вызовов, конференц-связь и т.д.
Функция коммутации услуг IM-SSF (IP Multimedia - Services Switching Function) обеспечивает взаимодействие сообщения SIP с соответствующими сообщениями CAMEL, ANSI-41, подсистем INAP (Intelligent Network Application Protocol) или TC AP (Transaction Capabilities Application Part). Это взаимодействие позволяет поддерживаемым IMS IP-телефонам получать доступ к сервисам определения имени вызывающей стороны, бесплатного номера 800, переноса локального номера и др.
Гибкость архитектуры IMS позволяет сервис-провайдерам добавлять услуги в сеть VoIP путем взаимодействия с действующими приложениями или же путем интеграции собственных или разработанных третьими фирмами серверов приложений на базе SIP. Кроме того, сервис-провайдеры могут предоставить своим клиентам возможность разрабатывать и внедрять сервисы, использующие ресурсы сети VoIP.
Небольшой анализ
Еще раз напомним, что для нас важно понимать, какое именно оборудование будет использоваться при модернизации сети.
Softswitch и IMS: сходства...
Если сравнить архитектуры Softswitch и IMS, то из приведенных рисунков видно, что и та и другая архитектуры имеют трехуровневое деление, причем границы уровней проходят на одних и тех же местах. Для архитектуры Softswitch изображены в первую очередь устройства сети, а архитектура IMS определена на уровне функций. Идентичны также идея предоставления всех услуг на базе IP-сети и разделение функций управления вызовом и коммутации. По сути, к уже известным функциям Softswitch добавляются функции шлюза OSA и сервер абонентских данных.
... и различия
Посмотрев на приведенные выше списки функций в обеих архитектурах, можно заметить, что состав функций практически не отличается. Можно было бы заключить, что обе архитектуры почти тождественны. Это верно, но только отчасти: они идентичны в архитектурном смысле. Если же разобрать содержание каждой из функций, то обнаружатся значительные различия в системах Softswitch и IMS. Например, функция CSCF: из ее описания уже видно отличие от аналогичных функций в Softswitch. К тому же если в архитектуре Softswitch функции имеют довольно условное деление и описание, то в документах IMS дается довольно жесткое описание функций и процедур их взаимодействия, а также определены и стандартизированы интерфейсы между функциями системы.
Поскольку было сказано, что функции в рамках архитектуры Softswitch определены достаточно свободно, то почему бы не рассматривать IMS как Mobile Softswitch? Иными словами, расширить возможности коммутаторов Softswitch для сетей мобильной связи.
Различие начинается с основной концепции систем. Softswitch - это в первую очередь оборудование конвергентных сетей. Функция управления шлюзами (и соответственно протоколы MGCP/MEGACO) является в нем доминирующей (протокол SIP для взаимодействия двух Softswitch/ MGC). IMS проектировалась в рамках сети 3G, полностью базирующейся на IP. Основным ее протоколом является SIP, позволяющий устанавливать одноранговые сессии между абонентами и использовать IMS лишь как систему, предоставляющую сервисные функции по безопасности, авторизации, доступа к услугам и т.д. Функция управления шлюзами и сам медиа-шлюз здесь лишь средство для связи абонентов 3G с абонентами фиксированных сетей. Причем имеются в виду лишь ТФОП. Для общения абонентов 3G с абонентами фиксированных VoIP-сетей и абонентами других 3G-сетей архитектура IMS предусматривает использование функции Security Gateway Function, которую реализуют граничные контроллеры SBC.
Также к особенностям IMS относится ориентированность на протокол IPv6: многие специалисты считают, что популярность IMS послужит толчком к затянувшемуся внедрению шестой версии протокола IP. Но пока это представляет некоторую проблему: сети UMTS поддерживают как IPv4, так и IPv6, в то время как IMS -только IPv6. Поэтому на входе в IMS-сеть необходимо наличие шлюзов, преобразующих формат заголовков и адресную информацию. Эта проблема присуща не только IMS, но и всем сетям IPv6.
Продолжая тему проблем IMS, следует сказать о протоколе SIP. Дело в том, что SIP разработан и специфицирован комитетом IETF, но для использования в IMS он был частично доработан и изменен. В результате может возникнуть ситуация, когда при получении запросов SIP или отправке их во внешние сети подфункция S-CSCF может обнаружить отсутствие поддержки соответствующих расширений протокола SIP и/или отказать в установлении соединения, а также обработать его некорректно.
Резюме
Указав различия между IMS и SS, следует еще раз вернуться к схожести этих систем. Архитектурное подобие позволяет строить и те и другие сети, используя общее оборудование, отличаться будет лишь ПО этого оборудования либо только некоторые элементы систем.
В заключение этого раздела стоит указать на то, что проведенный выше анализ делался с учетом именно IMS, а не IMS/TISPAN. Более подробно сравнение этих двух подходов изложено в уже упомянутой статье [1].
Эксплуатационные процессы ВNGN
Актуальность вопроса
До последнего времени проблема эксплуатации была, наверное, самым малообсуждаемым вопросом из перечня тем по NGN. Безусловно, важность эффективной системы эксплуатации пока оценивается далеко не в полной мере. Впрочем, можно ожидать, что практика заключения соглашений об уровне обслуживания (SLA) радикально изменит ситуацию. На рис. 5 показана диаграмма распределения штрафов, выплаченных Операторами из-за нарушения соглашений SLA по допустимому времени простоя сети. Численные значения штрафов определены с учетом информации, приведенной в [3], а также в других материалах. В российской инфокоммуникацион-ной системе, скорее всего, будут приняты существенно меньшие штрафы. Но и они тем не менее смогут стать стимулом для реализации современной системы эксплуатации.
Оператору связи недостаточно просто построить сеть и продать услуги, надо еще и поддерживать сеть и управлять ею. Поэтому сейчас вопросам эксплуатационного управления стали уделять должное внимание. Тактика и стратегия разработки и внедрения решений для управления и эксплуатации сети, описание бизнес-процессов Оператора, максимальная автоматизация работ, сокращение эксплуатационных затрат - все это хотя и не выходит на первый план, но приобретает все более важное значение.
Решение задач такого рода даже в масштабах сети одного Оператора -достаточно длительный и трудоемкий процесс, так как необходимо учитывать взаимосвязь всех процессов: как чисто технологических, касающихся только телекоммуникационной сети, так и бизнес-процессов эксплуатационной компании. Снова возникает необходимость создания некой модели эксплуатационного управления, учитывающей все аспекты задачи.
Общие подходы
Идеология эксплуатации и управления известна под термином OSS (Operation Support System) и уже довольно давно разрабатывается и внедряется в операторских сетях. Для определения и оптимизации процессов существует несколько моделей, концепций и инструментов (ITIL, eTOM, TMN), позволяющих четко сформировать единый (для каждой модели) вид на все бизнес-процессы оператора.
Оптимальным сегодня считается подход еТОМ, разработанный Tele-Management Forum и принятый затем ITU-T в качестве альтернативы заполнения функциональности в сети TMN, которая была изначально призвана решить все проблемы OSS для операторов связи. Производителей подобных систем сегодня не так уж и мало - TTI (Netrac), HP (Open View) и другие.
Российская специфика
Эксплуатация сетей связи в РФ имеет свои особенности и требования, которые наряду с требованиями NGN необходимо учитывать при внедрении систем OSS. Организация российского оператора связи обусловливает определенное функциональное разделение системы OSS.
В сегодняшних условиях введение новых видов инфокоммуникационных услуг и переход к NGN требуют новых, более эффективных подходов к эксплуатационному управлению сетью, а также к работе с абонентами. Логика построения OSS для сети доступа должна закладываться исходя из реальных нужд текущего управления и модернизации сети и должна развиваться в соответствии с идеологией построения сети самого Оператора.
Наличие точной информации о ситуации в сети (учет оборудования и отслеживание всех производимых изменений в реальном времени) позволило бы Оператору по-новому подойти к планированию сети, а также к оптимизации затрат и ресурсов. Повышение качества процессов, связанных с обслуживанием абонентов (например, предоставление новых услуг, оперативная реакция на запрос абонента и устранение повреждений), повлекло бы за собой расширение абонентской базы и повышение доходов.
Однако используемые сегодня системы редко удовлетворяют даже требованиям "традиционной" сети, а возможности и оборудование NGN не учитывают вовсе. Да и взаимодействие управляющей системы и установленного оборудования в случае муль-тисервисности меняется принципиально. Российскому Оператору нужна система, которая бы закрывала вопросы NGN и при этом учитывала специфику эксплуатации ЕСЭ РФ. И если для сети доступа есть вариант (OSS АРГУС), то полномасштабного решения (для сети в целом) пока не существует. На данный момент Операторы вынуждены внедрять подобные системы по частям.
Очевидно, что данная тема заслуживает отдельного внимания и самостоятельной публикации, а здесь авторы просто обращают внимание читателя и на эту сторону эволюции сетей.
Выводы ко второй части статьи
Как и было обещано в первой части, дифирамбы в адрес NGN не звучали. С другой стороны, можно сказать, что статья направлена на продвижение идеи NGN. Вместе с тем мы бы хотели призвать осторожнее и тщательнее продумывать шаги по ее созданию.
Сценарии создания NGN, темпы модернизации ЕСЭ РФ (постепенные или радикальные) и характеристики соответствующего оборудования должны быть тщательно проанализированы всеми игроками телекоммуникационного рынка. Для того чтобы новая сеть появилась на свет в том виде, который действительно будет нужен Операторам связи, необходимо объединение усилий всех заинтересованных сторон. Должна быть выработана такая концепция построения NGN, которая позволит осуществить переход плавно, сможет гармонично вписаться в существующую структуру ЕСЭ РФ и будет функционально наполнена именно в той степени, в какой она будет востребована абонентами на каждом этапе развития инфокоммуникационной системы.
Литература
* - 1-я часть статьи была опубликована во 2-м номере журнала "Технологии и средства связи" за 2006 г.
Опубликовано: Журнал "Технологии и средства связи" #3, 2006
Посещений: 20873
Автор
| |||
Автор
| |||
В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
