Задача, которую нужно решать
Программное обеспечение Программное обеспечение

В настоящее время на рынке средств автоматизированного управления CPE1 работает достаточно много производителей ПО. Несложный анализ позволяет сгруппировать все решения в три основные группы.

Главная>Программное обеспечение>Задача, которую нужно решать
Программное обеспечение Обзор

Задача, которую нужно решать

Дата публикации:
11.08.2010
Посетителей:
492
Просмотров:
399
Время просмотра:
2.3
В настоящее время на рынке средств автоматизированного управления CPE1 работает достаточно много производителей ПО. Несложный анализ позволяет сгруппировать все решения в три основные группы:

 

 

  • Решения компаний-производителей CPE.
  • Решения независимых производителей.
  • Решения на базе ПО с открытым кодом (Open Source Software).

 

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

 

 

Краткий (далеко не полный) перечень решений компаний-производителей:

 

Наименование компании-производителя
Наименование решения
Сайт производителя
Alcatel-LucentMotive Home Device Manager
Motive WiMAX Device Manager
www.alcatel-lucent.com
Cisco SystemsBroadband Access Centerwww.cisco.com
Pirelli Broadband SolutionsPirelli Management Platformwww.pirellibroadband.com
Sagem CommunicationsSAS Gigaset Software Suitewww.sagemcom.com

 

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

 

Краткий перечень независимых производителей решений по управлению CPE:

 

Наименование компании-производителяНаименование решенияСсылка на описание решения
AVSystem CorporationVoiceIP-ACSvoiceip.pl
AxirosAxess Device Management Solutionswww.axiros.com
DrayTekVigorACSwww.draytek.com
Fine Point TechnologiesReach5000www.finepoint.com
Fiendly TechnologiesFriendlyTR69 Solutionwww.friendly-tech.com
Works SystemsOne Network Management Systemwww.workssys.com

 

Поскольку TR-069 является открытой спецификацией, естественно ожидать появления решений на базе ПО с открытым кодом. Аналогией в данном случае может являться протокол SNMP, для работы с которым существует множество решений класса Open Source Software, в том числе свободно распространяемых, таких как Nagios, ZenOSS, MRTG и др. В настоящее время существует и развивается проект OpenACS, статус проекта – бета-тестирование. Информацию о OpenACS можно получить на сайте проекта – http://openacs.sourceforge.net.

 

О компании AVSystem Corporation

Компания AVSystem Corporation основана в 2004 году. Головной офис компании находится в г. Краков, Польша. Область компетенции компании – программные решения собственной разработки для телекоммуникационного рынка. В первые годы своего существования, компания концентрировалась на разработке решений в области IP-телефонии: VoiceIP-PBX, VoiceIP-BX.lite, VoiceIP-CC Contact Center. В 2005 году началась разработка собственного решения по управлению CPE. В настоящее время в портфель решений по управлению CPE входят:

  • VoiceIP-ACS, представляющий собой программный Auto-Configuration Server;
  • VoiceIP-TR69.stack, представляющий собой комплект библиотек для реализации поддержки TR-069 в CPE различного типа.

Решения компании успешно используются в сетях операторов Европы (Польша, Финляндия, Бельгия) и Новой Зеландии.

 

Мы, в качестве примера решения автоматизации управления CPE, выбрали систему управления VoiceIP-ACS, предлагаемую компанией AVSystem Corporation. Мы не готовы выделить этот продукт как наилучший или наиболее универсальный, поскольку у каждого из предлагаемых на рынке решений есть свои достоинства. На его примере мы лишь постараемся проиллюстрировать реализацию протоколов BroadBand Forum и показать те особенности, которыми их дополняют производители ПО.

 

Система VoiceIP-ACS

 

Система VoiceIP-ACS представляет собой платформу для централизованного управления CPE. Система обеспечивает возможность управления как CPE, поддерживающими TR-069, так и CPE, без поддержки TR-069. В рамках управления реализуются все функции, определенные спецификацией TR-069. VoiceIP-ACS является масштабируемым, высокопроизводительным решением, обеспечивающим возможность управления (по результатам лабораторного тестирования) более 5 млн. CPE в рамках одной инсталляции.

 

Ключевые преимущества системы VoiceIP-ACS:

 

  • Возможность виртуализации системы – т.е. возможность использования одной инсталляции несколькими операторами независимо друг от друга.
  • Поддержка широкого спектра существующих протоколов управления.
  • Высокая доступность и отказоустойчивость решения.
  • Гибкий механизм настройки правил конфигурирования CPE.
  • Мощная система определения и контроля прав доступа на любом этапе управления CPE в комплексе с гибкими механизмами журналирования действий пользователей системы.

 

Архитектура системы

 

Архитектура приложения

VoiceIP-ACS имеет трехуровневую архитектуру и реализована на базе технологии J2EE. В состав прикладного программного обеспечения системы входят следующие программные модули:

 

  • VoiceIP-ACS Engine.
  • VoiceIP-ACS Manager.
  • VoiceIP-ACS Adapter.
  • VoiceIP-SMG (Subscriber Manager).
  • VoiceIP- Reporting.
  • VoiceIP- Monitor.

 

Архитектура системы представлена на рисунке.

 

Рис. 5. Архитектура системы VoiceIP-ACS

 

Для понимания работы решения, кратко рассмотрим входящие в него модули:

 

VoiceIP - ACS Engine представляет собой основной модуль системы, реализующий функции управления CPE, такие как обнаружение и классификация новых CPE по группам, управление их конфигурацией, управление ПО и мониторинг. Инициация управляющих воздействий осуществляется либо на основе внешней команды (другие модули системы – VoiceIP-ACS Manager, VoiceIP-Monitor, VoiceIP-SMG или внешние системы класса OSS/BSS2), либо в соответствии с предварительно заданным расписанием. Все операции, выполняемые модулем, журналируются.

 

Модуль содержит описание моделей данных протокола CWMP, включая описание параметров, шаблоны возможных значений. Реализован интерфейс для оперативной, без остановки системы, загрузки новых моделей, как разработанных BroadBand Forum, так и самим оператором. Управление CPE (возможность определения тех или иных услуг, параметров) осуществляется на основе информации о соотнесении CPE с одной или несколькими моделями данных по одному или нескольким уникальным признакам CPE (IP, MAC и т.п.).

 

Рис. 6. Схема работы модуля VoiceIP-ACS

 

Управление последовательностью операций при выполнении тех или иных управляющих воздействий осуществляется либо с использованием скриптов VoiceIP-ACS Engine, либо за счет интеграции с модулями управления workflow (VoiceIP-SMG или внешние системы, интегрированные с использованием «северного» интерфейса).

 

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

 

VoiceIP - ACS Manager – модуль представляет собой консоль администратора системы, обеспечивающий возможность ее тонкой настройки. Взаимодействие модуля с VoiceIP-ACS Engine осуществляется с использованием RMI3 (в целях безопасности используется SSL/TLS). Авторизация и аутентификация пользователей осуществляются на уровне VoiceIP-ACS Engine.

 

VoiceIP - ACS . Adapter – дополнительный модуль, позволяющий работать с CPE, не поддерживающими TR-069. Модуль содержит карты соответствия для преобразования CWMP-вызовов в вызовы других протоколов и обратно. Поддерживаются адаптеры к протоколам SNMP, TFTP, SSH, Telnet. Возможна разработка адаптеров к любым другим частным протоколам. Реализованная схема позволяет полностью изолировать специфику работы с конкретным CPE от самой системы. Все CPE, представленные в сети, отображаются пользователю в качестве CPE с поддержкой TR-069. Преимущества такого подхода особенно хорошо проявляются при наличии планов миграции на CPE, поддерживающие TR-069. Изменения, производимые на системе при осуществлении подобной миграции – минимальны. Схема работы модуля VoiceIP-ACS.Adapter представлена на рисунке 2.

 

VoiceIP - SMG – модуль Subscriber Manager представляет собой пользовательский интерфейс системы для работников службы технической поддержки и call-centre. SMG представляет собой веб-портал и обеспечивает учет взаимосвязей между абонентами, принадлежащими им CPE и предоставляемыми им услугами. Взаимодействие с другими модулями системы осуществляется с использованием SOAP/RMI и JMS. SMG обеспечивает возможности удаленной реконфигурации CPE, подготовки профилей, обновления ПО CPE, загрузки и отслеживания журнальных файлов CPE. Все действия, выполняемые оператором в интерфейсе SMG, фиксируются в журнальных файлах, используемых в дальнейшем для диагностики проблем и контроля информационной безопасности. Модуль обеспечивает возможность резервного копирования конфигураций CPE. Поддерживается механизм возврата изменяемой конфигурации CPE к предыдущему состоянию, что позволяет оператору при решении проблем в предоставлении услуг вернуться к последней рабочей конфигурации CPE. Или выбрать любую другую конфигурацию из сохраненных.

 

Портал SMG может использоваться в двух режимах (в том числе одновременно) – в режиме портала технических служб оператора связи и в режиме портала самообслуживания для абонентов.

 

В режиме портала технических служб, SMG обеспечивает доступ к полному функционалу системы, в том числе:

 

  • Первичная регистрация информации об абонентах, принадлежащих им CPE, соответствующих услугах (также возможна автоматизация регистрации этой информации за счет интеграции с системами класса OSS/BSS, например – CRM).
  • Просмотр детальной информации о принадлежащих абоненту CPE, параметрах их конфигурации, текущем состоянии, событиях и т.д.
  • Выполнение операций по перезагрузке CPE, планированию и инициированию тех или иных задач управления конфигурацией CPE, загрузкой новых версий ПО на CPE.

 

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

 

Техническая архитектура системы

Для хранения данных системы используется реляционная система управления базами данных. В настоящее время система поддерживает работу с PostgreSQL и Oracle. В качестве платформы используются серверы под управлением ОС Linux Debian. Система может быть развернута и на других платформах, поддерживающих выполнение Java – Windows, Solaris, Linux и др. Конфигурация комплекса технических средств определяется требованиями к производительности и отказоустойчивости системы.

 

Увеличение производительности системы достигается за счет выноса модулей VoiceIP-Reporting и VoiceIP -SMG на отдельные серверы. Отказоустойчивость – за счет дублирования сервера ACS системы и выноса СУБД на отдельный кластер.

 

Схема подобной конфигурации показана на рисунке 3. Система поддерживает дублирование основного сервера. При этом оба сервера работают в режиме active-active. Распределение нагрузки между серверами осуществляется программными или аппаратными балансировщиками нагрузки. Общая информа ция (журнальные файлы, файлы образов ПО CPE и т.д.) хранится на тех же или отдельных серверах и доступна по NFS. В процессе работы серверы обмениваются между собой контрольными информационными сообщениями (heartbeats). В случае выхода из строя одного сервера обслуживание всех CPE осуществляется вторым сервером. При этом все процессы управления CPE, начатые одним сервером, будут завершены вторым.

 

 

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

 

Интерфейс портала может быть локализован и адаптирован к имиджу оператора. За счет поддержки интеграционных интерфейсов, а также за счет наличия API, возможна тесная интеграция модуля SMG с существующими у оператора порталами и системами, такими как системы класса OSS/BSS, системы личных кабинетов и т.д.

 

VoiceIP - Reporting – дополнительный модуль, обеспечивающий возможность генерации отчетов в соответствии с расписанием или по требованию. Модуль построен на базе решения BIRT Project (Business Intelligence and Reporting Tool, http://eclipse.org/birt/phoenix/). Система обеспечивает возможность формирования отчетов на основе данных мониторинга, данных о результатах выполнения задач управления конфигурацией CPE. Существуют предустановленные формы отчетов, например, по конфигурации CPE, событиям реконфигурации, событиям на CPE, отчеты по активным (подключавшимся к ACS) CPE за период и т.д. Набор шаблонов отчетов может быть расширен пользователем.

 

Модуль поддерживает:

 

  • Технологию OLAP, что обеспечивает возможность быстрого формирования сложных статистических отчетов.
  • Язык Multidimensional Expressions, как инструмент создания сложных аналитических отчетов.

 

VoiceIP - Monitor – модуль, отвечающий за сбор в режиме реального времени событий о работе CPE. Реализована поддержка не только событий TR-069, но и трапов SNMP, записей syslog. Поддерживается функция автоматической группировки событий по заданным признакам. Возможен мониторинг значений параметров TR-069, контроль их пороговых значений. Информация мониторинга отображается в виде графиков и таблиц с возможностью просмотра исторической информации. Поддерживается возможность настройки оповещений о значимых событиях, в том числе, с использованием шины JMS для интеграции с внешними приложениями.

 

Как уже указано выше, система VoiceIP-ACS поддерживает взаимодействие с внешними системами. «Северный» (northbound) интерфейс системы представляет собой API SOAP, RMI и .NET. Интеграция возможна как непосредственно с VoiceIP-ACS Engine, так и с VoiceIP-SMG. Компания-производитель рекомендует использовать API VoiceIP-SMG для интеграции с внешними системами класса OSS/BSS.

 

Функциональные возможности системы

 

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

 

Группировка CPE

 

Основным инструментом управления конфигурацией CPE и распространением ПО является механизм логической группировки CPE по различным признакам. Именно принадлежностью к той или иной группе определяется, какая конфигурация будет загружена на CPE. Каждый CPE может принадлежать к одной или нескольким группам. Для каждого CPE определяется одна домашняя группа. Все группы в системе организованы в иерархическую структуру. По умолчанию в системе определена группа root, являющаяся корнем иерархии и, соответственно, родительской группой для любой другой группы. С каждой группой ассоциированы следующие объекты:

 

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

 

Поддерживается механизм наследования свойств (связанных объектов) группы вниз по иерархии.

 

Рис. 8. Пример иерархии групп

 

Пример иерархии групп представлен на рисунке 8 .

 

Представленная иерархия групп ориентирована на настройку на CPE сервиса VoIP. Состав групп учитывает различия в значениях параметров VoIP для основной и тестовой конфигурации CPE, а также, особенности настройки VoIP для разных абонентов (в примере – абонент А и абонент B). С точки зрения конфигурирования CPE логика работы групп выглядит следующим образом:

 

  • Группа root.voip определяет параметры сервиса VoIP для всех CPE, входящих в эту группу или в одну из дочерних групп.
  • Группа root.voip.test определяет (как вариант – переопределяет) параметры сервиса VoIP, специфичные для тестовой конфигурации CPE.
  • Группы root.voip.customer.A и root.voip.customer.B определяют значения параметров, уникальные для каждого из абонентов с учетом, например, определенного с ним SLA.

 

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

 

  • Географический признак – группировка CPE в зависимости от их физического расположения (Россия, Англия, Москва, Санкт-Петербург, Екатеринбург, Владивосток и т.д.).
  • Соответствие абоненту – CPE, используемые одним абонентом, могут быть объединены в отдельную группу. Такая группировка необходима для реализации, например, механизмов самообслуживания.
  • Общность конфигурации – CPE группируются по возможности использования единых конфигурационных шаблонов. Этот механизм группировки используется наиболее часто, поскольку, в том числе с учетом механизмов наследования групп, обеспечивает основные возможности массового управления конфигурациями CPE.

 

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

 

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

 

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

 

Управление конфигурацией CPE

 

Рассказав о механизмах группировки, перейдем к описанию реализации функций управления конфигурацией CPE.

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

 

Определение конфигурации CPE, точнее – ее формирование и загрузка на устройство, строится на базе механизма группировки. Для каждой группы определяется профайл – набор параметров CWMP и их значений. За счет наличия механизма наследования, профайлы действительны не только для заданной группы, но и для всех дочерних групп. При определении параметров, составляющих профайл, поддерживаются следующие свойства наследования параметров:

 

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

 

Определение целевой конфигурации CPE осуществляется помещением его в соответствующую группу на необходимом уровне иерархии групп.

 

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

 

Резервное копирование конфигураций CPE может осуществляться также, как и их распространение: по запросу пользователя системы (например, перед выполнением каких-либо сложных вариантов реконфигурации) или по расписанию. Поддерживается резервное копирование конфигурации как одного CPE, так и всех CPE, входящих в группу. Конфигурация CPE хранится в виде файла формата .CSV на локальном сервере системы или на внешнем ftp-сервере. Для каждой копии конфигурации указывается версия ПО CPE (firmware), для которой она использовалась. Это позволяет избежать попытки автоматического восстановления конфигурации на новой версии firmware, не поддерживающей те или иные параметры предыдущей версии.

 

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

 

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

 

Защита данных в системе

 

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

 

Защита данных системы реализована в следующих областях:

 

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

 

Все взаимодействие между компонентами системы осуществляется с использованием RMI, работающего через сокеты SSL4, что обеспечивает защищенную транспортировку вызовов и данных. При работе через API доступны веб-сервисы, также защищенные SSL.

 

Доступ пользователей к ресурсам (функции и данные) системы определяется его правами. Информация об учетной записи пользователя хранится в БД системы в зашифрованном виде. Поддерживается интеграция с LDAP.

 

Права пользователя определяются по отношению к двум типам объектов системы:

 

  • Группы CPE, по отношению к которым он может выполнять какие-либо действия.
  • Состав операций, которые может выполнять пользователь в системе – около 100 атомарных операций (в том числе – изменение параметров CWMP), выполнение которых может быть разрешено или запрещено пользователю.

 

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

 

Необходимо отметить, что в системе реализованы два уровня определения прав.

 

Первый уровень, являющийся основным, реализован в модуле VoiceIP-ACS Engine. Определены следующие типы ролей (в порядке убывания прав): superuser (root), root admin, group admin, group operator, group user.

 

Второй уровень, расширяющий первый, реализован в модуле VoiceIP-SMG. Определены роли (в порядке убывания прав): root, administrator, operator, subscriber. Пользователь SMG может иметь выделенную учетную запись в VoiceIP-ACS Engine либо несколько пользователей SMG могут работать с ресурсами системы под одной учетной записью VoiceIP-ACS Engine, имея отдельные учетные записи в SMG. Права, определяемые учетной записью VoiceIP-ACS Engine, являются определяющими и приоритетными для соответствующих учетных записей SMG.

 

Реализованная система назначения прав позволяет организовывать следующие схемы доступа:

 

  • Самообслуживание – пользователю предоставляются права доступа только к принадлежащим ему CPE. При этом права в целом даны только на чтение. Исключение могут составлять только некоторые параметры, доступные для реконфигурации пользователем, такие как настройки DHCP сервера, параметры линии и т.д.
  • Использование системы для работы нескольких виртуальных операторов – каждому виртуальному оператору может быть выделена домашняя группа в рамках которой, например, с учетом предоставляемых услуг, оператор имеет полные права на работу с соответствующими CPE и их параметрами. Владелец системы может определить базовые профайлы, параметры которых будут едиными и недоступными для изменения виртуальными операторами.
  • Совместное использование системы несколькими операторами – каждый оператор может иметь полные права в рамках своей группы и входящих в нее подгрупп. При этом все другие группы для него недоступны.

 

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

 

  • Оператор заранее определяет те или иные уникальные параметры CPE в системе (например, при выдаче CPE в аренду или при продаже в комплекте с услугой). При обнаружении CPE и соответствии его предварительно заданным параметрам, VoiceIP-ACS Engine регистрирует информацию о CPE и соотносит его с одной или несколькими группами для загрузки на него соответствующей конфигурации.
  • В случае обнаружения нового CPE, информация о котором предварительно в систему не загружалась, VoiceIP-ACS Engine регистрирует информацию об устройстве и включает его в группу неавторизованных CPE. При этом CPE не получит никакой конфигурационной информации для доступа к тем или иным услугам. По каждому CPE, входящему в эту группу, пользователь системы, наделенный соответствующими правами, должен принять решение о включении в систему или игнорировании. Этот процесс также может быть автоматизирован за счет интеграции с системами класса OSS/BSS.

 

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

 

Сценарии работы системы

 

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

 

Подключение новых CPE

 

Система поддерживает два основных сценария подключения новых CPE5 – с участием абонента («one touch») и без его непосредственного участия («zero touch»). При любом из сценариев возможность использования DHCP при подключении CPE существенно упростит задачу абонента и технической службы оператора, поскольку позволит избежать предварительной установки параметров доступа к ACS на каждом CPE.

 

В первом случае, купив и установив CPE, абонент должен ввести в портале самообслуживания (SMG или другая система, интегрированная с VoiceIP-ACS) данные, уникальным образом идентифицирующие CPE (OUI – Organizationally Unique Identifier , MAC, Serial Number и т.п.).

 

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

 

Этапы сценария:

 

  1. На этапе предоставления абоненту CPE идентифицирующая CPE информация (OUI, MAC, Serial Number) о нем заносится в соответствующую систему (CRM, Order Management и т.п.).
  2. SMG получает от внешней системы информацию, идентифицирующую CPE, а также информацию о привязке CPE к учетной записи абонента. На основе полученной информации инициируются подготовительные операции: регистрация информации о CPE в VoiceIP-ACS Engine, осуществляется запрос и получение информации о сервисах, на которые подписан абонент, выполняется подготовка соответствующего конфигурационного профиля (соотнесение с существующими группами в случае, если сервисы являются типовыми).
  3. Абонент, получив CPE, включает его в сеть. По DHCP или в соответствии с заранее заданным url CPE подключается к серверу ACS (VoiceIP-ACS Engine).
  4. CPE инициирует сессию CWMP, распознается системой VoiceIP-ACS и получает подготовленный конфигурационный профиль.
  5. По завершении сессии CWMP VoiceIP-ACS Engine формирует событие, содержащее информацию о результатах активации CPE. Соответствующие оповещения о результатах сессии могут быть получены пользователем системы для оперативной реакции в случае некорректного завершения сессии.
  6. После завершения всех операций CPE настроен в соответствии с перечнем сервисов, заказанных абонентом, и готов к работе.

 

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

 

Сценарий активации нового сервиса

 

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

 

Рис. 9. Сценарий подключения новых CPE
 

 

Рассмотрим по какому сценарию происходит динамическое включение нового сервиса на CPE абонента:

 

  1. Абонент формирует запрос на подключение нового сервиса в интерфейсе SMG.
  2. SMG размещает запрос на подключение во внешних интегрированных системах (биллинг, управление заказами и т.п.) и ожидает подтверждения возможности включения новой услуги.
  3. После получения подтверждения SMG формирует конфигурационный профиль, ассоциируя CPE с одной или несколькими группами.
  4. SMG уведомляет VoiceIP-ACS Engine о необходимости посылки вызова типа «ACS connection initiation request» на каждое устройство, подлежащее реконфигурации.
  5. CPE инициирует сессию с VoiceIP-ACS Engine.
  6. VoiceIP-ACS Engine выполняет загрузку новой конфигурации на CPE.
  7. Запрошенный сервис становится доступен абоненту.

 

Длительность выполнения подобного сценария (без учета специфики интегрируемых систем OSS/BSS, реализации TR-069 на CPE) составляет несколько секунд.

 

О выборе ACS

При выборе средства автоматизации задачи управления CPE по протоколу TR-069 каждый оператор определяет свой набор критериев. Тем не менее, по результатам анализа выполненных внедрений, а также запросов операторов на проработку решения можно сформулировать набор основных критериев, которые необходимо принимать во внимание при выборе системы:

 

  • Совместимость используемых абонентами CPE с системой. Оценка соответствия реализованных на CPE интерфейсов TR-069 соответствующей спецификации может быть осуществлена с использованием программных средств, предоставляемых обычно производителем прикладного ПО системы.
    В случае выявления несовместимых (не полностью совместимых) CPE, а также в случае наличия CPE, не поддерживающих TR-069, необходимо принять во внимание способность системы адаптироваться к используемым CPE, степень сложности выполнения подобной адаптации на этапе внедрения и в процессе эксплуатации системы.
  • Производительность системы. Необходимо оценивать количество CPE, подключаемых к одной инсталляции системы, скорость выполнения операций реконфигурирования и обновления ПО CPE. При оценке желательно соблюсти баланс между реальными и перспективными потребностями и возможностями системы, поскольку более производительная система при равной стоимости может оказаться не самой функционально насыщенной.
  • Возможность интеграции с внешними системами класса OSS/BSS. ACS является компонентом сквозных процессов конфигурирования услуг для абонентов. Его функционирование невозможно без интеграции с внешними системами. Учитывая изменчивость прикладной архитектуры операторов связи (модернизация существующих, внедрение новых прикладных систем), необходимо принимать во внимание не только готовность команды внедрения выполнить интеграцию на этапе развертывания, но и наличие у системы открытых, документированных интерфейсов.
  • Адаптивность пользовательских интерфейсов. Возможность локализации интерфейса, изменения стилистики интерфейса в соответствии со стилистикой оператора. Возможность полностью отказаться от стандартных пользовательских интерфейсов за счет тесной интеграции с другими прикладными системами оператора. Соблюдение подобных условий позволит оператору интегрировать разворачиваемую систему не только на уровне данных, но и на уровне интерфейсов, что существенно повысит эффективность ее использования.
  • Стоимость системы, которая складывается из собственно стоимости прикладного программного комплекса и соответствующего аппаратного обеспечения, стоимости работ по внедрению (независимо от того, будет ли осуществляться внедрение собственными силами или приглашенным подрядчиком), стоимости эксплуатации и сопровождения, включая стоимость доработки системы для поддержки новых CPE, интеграции с новыми прикладными системами.

 

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

 

Заключение

 

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

 

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

 

Практика внедрений подобных систем в Европе и мире показывает возможность их окупаемости уже в первые 6-8 месяцев (для сетей с большим количеством абонентов).

 

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

Читайте также

TR-069

Уведомления об обновлении тем – в вашей почте

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня