2. ОСНОВНЫЕ СОСТАВЛЯЮЩИЕ КОМПОНЕНТЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ OSS
Для автоматизации отдельных процессов телекоммуникационного оператора могут применяться самые различные средства. ИТ-инженеры «на местах» могут применять разнообразные инструменты для упрощения поддержки функционирования, не придерживаясь никаких стандартов. Особенно часто это встречается у операторов «быстрорастущих» сетей, при объединении сегментов, находившихся в управлении у разных лиц. При первой же попытке объединить несколько независимых частей подобной «лоскутной» автоматизации в рамках общей системы автоматизации, технические специалисты сталкиваются с препятствиями, которые могли бы быть решены только при сквозном проектировании единой информационной системы с поддержкой если не стандартов разработки, то хотя бы общих рекомендаций.
Стандартизацией систем подобного рода (OSS/BSS) и разработкой концепций их дальнейшего развития на международном уровне занимается
TeleManagement Forum.
Функциональность OSS и BSS часто пересекается, поэтому на рынке существует ряд интегрированных решений. В связи с этим, для обозначения общего рынка употребляется аббревиатура OSS/BSS, иногда BOSS.
В целом OSS/BSS-решения предназначены для комплексной автоматизации операционной деятельности телекоммуникационных компаний в рамках бизнес-процессов, услуг и функций управления. Существуют различные подходы к реализации подобных решений, большинство из которых так или иначе основаны на концепциях, предложенных TMF.
2.1. Общий взгляд: TMF Application Framework (TAM)
TM Forum (TeleManagement Forum) – это отраслевая некоммерческая ассоциация, объединяющая предприятия электросвязи и их поставщиков, с целью выработки стандартов, рекомендаций и моделей для информационных технологий в телекоммуникационной отрасли. Основана в 1988 г. по инициативе British Telecom и AT&T под наименованием OSI/Network Management Forum, в 1992 г. переименована в Network Management Forum, а с 1998 г. Называется Tele Management Forum или TM Forum.
Согласно TMF Application Framework [17] (ранее Telecom Application Map, TAM), в состав OSS могут входить модули (приложения), реализующие следующие основные функции автоматизации:
управление инвентаризацией (Resource/Inventory Management) – от-
вечает за учет физических и логических ресурсов сети;
14
модуль планирования и развития услуг (Service Provisioning Management) – позволяет прогнозировать развитие событий и моделировать разнообразные сценарии;
управление нарядами на активацию услуг (Order Management) – необходимо для отслеживания всех этапов исполнения заказа на предоставление услуги;
контроль выполнения задач по устранению неисправностей (Trouble Ticketing);
управление качеством предоставляемых услуг (SLA Management) – обеспечивает оперативный мониторинг сервисов, доступных внутренним и внешним пользователям;
управление безопасностью (Security Management) – обеспечивает контроль доступа к ресурсам сети;
системы предупреждения мошенничества (Fraud Management) – предназначены для пресечения и упреждения случаев несанкционированного и неоплаченного использования услуг операторов связи;
управление неисправностями (Fault Management) – представляет собой систему контроля и управления аварийными сигналами, которая предназначена для их фильтрации и корреляции с целью выявления первопричины, породившей поток взаимосвязанных аварийных сообщений;
средства взаимодействия (mediation) – обеспечивают сопряжение решений OSS/BSS с разнородным оборудованием различных производителей;
модуль учета (Accounting Management) – регистрирует время использования различных ресурсов сети.
Перечисленные модули должны использовать общую понятийную базу (базовый набор сущностей и отношений между ними), а также взаимодействовать между собой унифицированным образом (использовать для интеграции общий транспорт).
Для решения данных задач в концепции Frameworx предлагаются:
Information Framework [18], также известный как «модель SID» (Shared Information and Data model), описывает базовый набор сущностей,
пользуясь которыми, отдельные компоненты OSS-системы смогут оперировать одинаковыми понятиями
Integration Framework [19], ранее известный как «TNA (Technology Neutral Architecture)» и «Инициатива OSS/J», описывает набор стандартизированных интерфейсов для интеграции между компонентами OSS-систем
Frameworx не накладывает ограничений на выбор конкретных способов реализации, поэтому для реализации компонентов OSS-систем и их интеграции могут быть выбраны практически любые из современных распространенных средств и технологий программирования, например:
15
Enterprise Java Beans (для бизнес-логики и управляемых сущностей);
Web Services (для интеграционных служб);
хранимые процедуры БД (для бизнес-логики и контроля непротиворечивости хранимых данных) и др.
2.2. Способы построения каркаса OSS-системы
Для создания базовой архитектуры типовой OSS-системы можно выбрать подход, рекомендуемый в книге Colin Ashford, Pierre Geuthier «OSS Design Patterns» [20].
Там предлагается:
рассмотреть целевую модель развертывания OSS-системы: часто она бывает распределенной, в силу распределенности самого оборудования и отдельных интегрируемых систем управления; похожий случай отображен на рис. 5 «размещение модулей» в разделе «Классификация»;
рассмотреть отдельные компоненты и разделить их на уровни в соответствии с предназначением и местонахождением в карте Application Framework. При определенном упрощении, результат декомпозиции может привести к диаграмме, представленной на рис. 7 [21].
Рис. 7. Декомпозиция общей архитектуры OSS-системы на несколько уровней функционирования
Чтобы лучше понять класс системных требований и решений (в нашем случае это управление телекоммуникациями), часто полезно разработать эталонную модель. Эталонная модель – общепринятая функциональная декомпозиция на основе класса требований; части модели взаимодействуют друг с другом для удовлетворения этих требований. Это важный инструмент, который помогает перейти от требований системы к ее реализации.
16
Эталонная модель OSS, показанная на рис. 7, является моделью с пятью уровнями, которая анализирует функциональные аспекты решений управления.
Функциональное разбиение следующее:
Presentation liner – уровень представления. Отвечает за все аспекты взаимодействия через интерфейс с операторами, такими как администраторы сети, отдел технической поддержки или отдел по работе с клиентами;
Operator-support layer – этот слой несет ответственность за рабочий процесс оператора – задачи и проверки ввода оператора; он генерирует все запросы о функциональности управления или обращается непосредственно
куровню приложений OSS. Примеры задач оператора: решают заявки на устранение неисправностей, формируют и предоставляют отчеты;
OSS integration layer – слой отвечает за координацию различных приложений OSS для реализации решений по управлению и адаптации существующих приложений оператора. Примеры: решение проблем, настройка end-to-end и выполнение услуг. Уровень интеграции OSS реализует эти задачи, обращаясь к уровню приложений OSS;
OSS application layer – прикладной уровень OSS ответственен за функциональность уровня приложений OSS и обеспечивает непротиворечивое представление об аспектах управления ресурсами. Это управление заявками на устранение неисправностей, управление связью и управление приложениями конечного пользователя;
Adaptation and persistence layer – уровень адаптации и персистентно-
сти – ответственен за адаптацию управляемых ресурсов к представлению, требуемому прикладным уровнем OSS и сохранением состояния управления сети.
После этого разбиения необходимо определить общую архитектуру системы в соответствии с распределением компонентов как по уровням TMF TAM, так и по целевой модели развертывания [22] (рис. 8).
Рис. 8. Общая архитектура OSS-системы
с учетом деления компонентов по развертываемым модулям
17