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

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

>#<

8.1.3. Соответствие моделей управления

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

Применительно к уровням пирамиды TMN (см. рис. 8.1), рассмотренные группы задач охватывают следующие уровни: NEL (отдельные физические устройства и работа с ними), EML (средства конфигурирования и контроля отдельных устройств и подсистем сети), NML (контроль процессов внесения изменений в структуру сети, а также ряд операций по измерению загрузки и восстановлению сети после сбоев), SML (контроль процессов предоставления сетевых услуг на

основе информации уровня NML). Вместе с тем, информация, полученная с уровней NML и SML о процессах и особенностях работы сети за определенный период, может быть (и, как правило, бывает) достаточно полезной при решении вопросов планирования, развития и оптимизации сети. Тем самым она влияет и на процессы принятия решений о политике и приоритетах развития сети на самом верхнем уровне модели TMN - уровне управления бизнесом (BML). Таким образом, все уровни модели TMN тесно связаны между собой, и построение эффективной системы управления бизнес-процессами внутри компании-оператора оказывается невозможным при отсутствии инструментальных систем для интеграции основных функций, рассмотренных в предыдущем разделе.

Основные отличия ТОМ от общих подходов, регламентированных в TMN, заключаются в следующем:

- ТОМ демонстрирует процессный подход к управлению, не декларируя просто функции или наборы функций, а представляя управление на каждом уровне как набор процессов, каждый из которых хорошо соотносится с реальными процессами, происходящими у провайдера;

- при составлении схемы сетевых операций использовался подход сверху-вниз , т. е. от бизнес-нужд оператора к технологическим составляющим сетевого управления, в отличие от TMN, где рассмотрение управления ведется по принципу снизу-вверх - сначала регламентируются технологии и функции управления на уровне сетевых элементов, затем на уровне сети и далее. При этом в рекомендациях ITU-T серии М не раскрывается сущность уровней выше управления сетью;

- в ТОМ выделен уровень взаимодействия с абонентами (клиентами), что отражает специфику современной работы оператора связи;

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

Функциональные группы бизнес-процессов можно разбить на три большие группы задач - выполнения, обеспечения и биллинга (Fulfillment, Assurance, Billing - FAB) [6, 8]. Поэтому иногда такую модель Называют FAB (рис. 8.3). Каждый ее блок представляет собой бизнес-процесс и состоит из совокупности операций, параметров и Функций.

Выполнение

Обеспечение

Биллинг

Продажи

Управление заказами

Управление претензиями

Управление качеством обслуживания абонента

Выписка счетов и сбор оплаты

Планирование и формирование услуги

Конфигурирование услуги

Решение проблем обслуживания

Управление качеством услуг

Тарифы и скидки

Планирование и развитие сети

Строительство сети

Управление парком оборудования

Профилактика и ремонт

Управление сетевыми данными

Рис. 8.3. Разделение процессов на фуппы Выполнение, Обеспечение,

Биллинг (FAB)

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

8.1.4. Новое поколение операционных систем и программного обеспечения

На основе разработанной структуры операций (Telecom Operations JVlap) TMF ведет разработку концепции NGOSS (Next Generation Operation Support System). Также TeleManagement Forum вырабатывает нормативные документы, которые призваны дополнять и развивать TMN и как концепцию, и как технологию с тем, чтобы обеспечить оптимальные варианты организации систем управления в реальном телекоммуникационном бизнесе. Это попытка TMF разработать принципиально новую архитектуру автоматизированных систем управления путем внедрения так называемого компонентного подхода в орга-

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

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

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

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

Основными принципами NGOSS являются:

- использование распределенных программных компонентов (объектов) с хорошо определенными контрактами (интерфейсами взаимодействия) (NGOSS Components);

- использование механизма трейдинга (обмена) атрибутов компонент на базе открытых контрактов (интерфейсов);

- использование разделяемых информационных сервисов (Stiared Information Services);

- отделение специфических технологических деталей (Technology Specific Architectural Framework) от общей концептуальной модели организации управления (Technology Neutral Architectural Framework). NGOSS не только определяет и пропагандирует вышеуказанные

теоретические принципы, но на базе этих принципов строит конкретные системные модели различного типа и уровней абстракции. Например, в документе TeleManagement Forum GB920 определяется общая независимая от технологий модель организации программных Модулей с распределением функциональности между отдельными Компонентами. Модель также определяет общую логику взаимодействия различных компонент в пределах одной или нескольких систем Управления отдельного оператора связи. На основании общей архитектуры, описанной в GB920, определяются зависимые от технологий

архитектуры реализации программной логики системы управления. Способы отображения и адекватность применения тех или иных технологий для реализации независимой архитектуры NGOSS определяются в концепции Technology Integration Мар . Семантика объектов и процессов управления определяется в Те1есот Operations Мар и документах серии System Integration Мар .

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

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

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

8.1.5. Принципы реализации архитектуры NGOSS

Ниже кратко перечислены основные и дополнительные принципы реализации технологически нейтральной архитектуры NGOSS (NGOSS Technology Neutral Software) [9].

Основные принципы:

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

2. Использование готовых системных решений (Commercial Off-the-Shelf, COTS) выигрывает в споре купить или разработать , если учитывать сроки реализации проекта, его стоимость и необходимый уровень квалификации разработчиков.

3. Разделение бизнес-процессов и программных компонентов. Бизнес-логика управления предприятием в целом или его подразделениями является стратегией компании и с прямой очевидностью не должна зависеть от используемых систем автоматизации деятельности.

4. Предоставление разделенного доступа к информации (Shared Information Services). Необходимо определить общие схемы данных, механизмы их обработки и доступа к ним.

5. Использование общих сервисов коммуникации (Common Communication Services). Технологией организации программного обеспече-

ния NGOSS предполагается использование общей шинной структуры для передачи сообщений между взаимодействующими системами.

6. Определение взаимодействия между модулями системы посредством контрактов (Contract Interfaces/Trading). Необходимо разрабатывать контракты взаимодействия подсистем, в которых будут четко описаны интерфейсы и протоколы взаимодействия. Таким образом можно достичь независимости от поставщика программного обеспечения NGOSS, избежать двусмысленности в формальном представлении служб, получить возможность построения системы электронного наблюдения за модулями системы, а также гибкости, модульности и масштабируемости системы в целом.

7. Интеграция сервисов на ходу (Plug and Play) предполагает возможность остановить ту или иную службу (подсистему) без потери информации, с возможностью продолжить в дальнейшем ее работу с места остановки или подключать к работе новые модули без перезапуска каких-либо других компонентов системы. Некоторые дополнительные принципы:

1. Общая форма управления системой подразумевает принятие единой политики и использование единых инструментов администрирования системы.

2. Общие подходы к безопасности системы включают в себя защиту взаимодействия подсистем, механизмы авторизации и журнализа-ции всех выполняемых в системе действий.

3. Связь с бизнес-процессами и системными определениями требует введения четкой методологии зависимости программного обеспечения от бизнес-логики и требований к системе.

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

Интеллектуальный интерфейс с сетевыми элементами или системами управления сетевыми элементами различных поставщиков обеспечивается с использованием стандартов распределенного управления CORBA, Java/RMI и т.д. [10,11].

8.2. Биллинг услуг сетей нового поколения

Общие требования к биллинговым системам. На сегодняшний день в России существует несколько десятков биллинговых систем, ориентированных на сети связи различной емкости. В соответствии с Общими Техническими Требованиями, утвержденными в 1998 г Минсвязи России, эти системы выполняют широкий диапазон функций. Включающий в себя следующие [12]: