Мультисервисные сети2

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

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

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

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

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

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

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

Рис. 8.3. Разделение процессов на группы «Выполнение, Обеспечение, Биллинг» (FAB)

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

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

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

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

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

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

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

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

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

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

имодействия) (NGOSS Components);

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

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

отделение специфических технологических деталей (Technology Specific Architectural Framework) от общей концептуальной модели орга-

низации управления (Technology Neutral Architectural Framework). NGOSS не только определяет и пропагандирует вышеуказанные

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

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

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

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

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

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]:

сбор, обработка и ввод первичных данных о предоставленных услугах;

абонентский учет;

регистрация и контроль оплат;

ведение нормативно-справочной информации;

тарификация и расчет;

формирование счетов абонентам;

информационно-справочное обслуживание абонентов;

формирование статистических и аналитических документов;

поддержка взаиморасчетов с операторами-партнерами;

управление коммутационным оборудованием.

Всоответствии с современными требованиями к системам поддержки операций этот список можно дополнить следующими пунктами [7]:

учет и контроль качества предоставляемых услуг (Quality of Service, QoS);

контроль выполнения пользовательского соглашения (Service License Agreement, SLA);

Fraud-контроль и управление безопасностью связи.

Отметим особую важность fraud-контроля. По данным [13], ежегод-

ные потери от fraud (англ. – мошенничество) в телекоммуникациях составляют $13 млрд. С появлением более сложных технических решений и услуг ожидается рост еще на 20%.

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

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

та ANSI-124.

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

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

Вусловиях управления мультисервисными сетями связи такое положение, прямо скажем, недопустимо. Между тем, TM Forum вот уже несколько лет предлагает четко формализовать процесс управления по принципу «разделяй и властвуй», используя уже описанную выше концепцию NGOSS. Биллинговая система, в «классическом» толковании этого понятия, должна обеспечивать процесс расчета стоимости услуги, формирование счетов абонентам и регистрацию оплат этих счетов [14]. Все остальные перечисленные и вновь появляющиеся функции должны взять на себя независимые модули Системы Поддержки Операций.

Особенности биллинговых систем для мультисервисных се-

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

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

Гетерогенность, как уже отмечалось, свойственна не только

мультисервисным сетям. С проблемами биллинга услуг гетерогенных сетей столкнулись все региональные операторы связи, такие как бывшие «xГТС» и АО «Электросвязь x области». Кратко напомним об этих трудностях.

288Глава 8. Управление мультисервисными сетями связи

Всвязи с использованием на сетях оборудования различных поставщиков, при создании системы управления, как правило, существует два варианта ее построения [15]:

1.Применение отдельных программных приложений управления для конфигурирования технических средств, мониторинга, диагностики

итестирования ряда элементов сети (например, оборудования одного поставщика) или сети одного вида (например, только сети SDH, только сети ATM и т.д.).

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

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

Следовательно, необходим некий программный продукт класса

EAI (Enterprise Application Integration), который определил бы еди-

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

Существенен также следующий момент: достаточно велик объем информации от сетевых элементов. Методов оптимизации трафика может быть несколько и использовать их можно в любых комбинациях:

1.Размещение Q-адаптера в непосредственной близости от сетевого элемента для уменьшения длины требуемого «широкого» канала передачи первичных данных.

2.Уменьшение трафика за счет преобразования данных с выделением наиболее существенной и отбрасыванием несущественной информации Записей об измеренном использовании услуги (Usage Metering Record, UMR).

3.Использование алгоритмов сжатия передаваемых в центр обработки данных. Эффективность сжатия в среднем такова, что позволяет уменьшить объем данных на 60%.

4.Интеграция многих UMR в одну запись о транзакции (агрегация), например, при сборе информации с коммутаторов пакетных сетей передачи данных. Нет необходимости выставлять абоненту счет за каждый переданный по IP-сети пакет – эти данные можно суммировать за некоторый промежуток времени.

5.Создание «интеллектуальных» устройств-посредников (Mediation Device, MD), обладающих функциональностью предбиллинговых модулей и взаимодействующих с более широким кругом подсистем системы управления, чем стандартные устройства этого класса, например,

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

Всвязи с разделением в современной телекоммуникационной концепции понятий «сеть» и «услуга», с точки зрения управления услугами возникают следующие проблемы:

1.Поставщики разделились на провайдеров услуг передачи информации и контент-провайдеров.

2.Поставщики услуг (особенно контента) могут находиться в любом месте сети, или даже в сети оператора-партнера.

3.Каждый оператор связи имеет большое количество взаимодействующих с ним компаний-операторов. Необходимо обеспечить оперативную систему взаиморасчетов по оказанным «гостевым» абонентам услугам.

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

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

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

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

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

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

Контрольные вопросы

1.Каковы особенности модели TMN?

2.Перечислите название логических уровней архитектуры TMN и дайте их характеристику.

3.Какова особенность сетей NGN с точки зрения управления?

4.Почему реализация модели управления сетью электросвязи «снизувверх» не удовлетворяет требованиям операторов?

5.По какому пути в реализации модели управлении электросвязи пошел международный консорциум TMF? В чем заключается достоинство подхо-

да TMF?

6.Дайте краткую характеристику OSS нового поколения (NGOSS).

7.Каковы особенности биллинговых систем для мультисервисных сетей.

Список литературы

1.Иванов П. Управление сетями связи // Сети, № 08-09, 1999.

2.Концептуальные положения по построению мультисервисных сетей на ВСС России. – ЛОНИИС, 2001.

3.Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. – М.: Бином, 1998.

4.Гончаров В.Н. Выбор системы расчетов для предприятий электросвязи с точки зрения теории больших систем // Биллинг, № 6, 2002. – С. 24-26.

5.Официальный сайт TeleManagement Forum // http://www.tmforum.org.

6.Засецкий А.В., Иванов А.Б., Постников С.Д. и др. Контроль качества в телеком-

муникациях и связи. Часть II, под ред. А.Б. Иванова. – М.: Компания САЙРУС СИС-

ТЕМС, 2001.

7.GB910. Telecom Operations Map/TeleManagement Forum. – March, 2000. – Approved version 2.1.