Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Лекции - Системы управления сетями связи - файл 1.doc


Лекции - Системы управления сетями связи
скачать (819.5 kb.)

Доступные файлы (1):

1.doc820kb.17.11.2011 00:15скачать

содержание
Загрузка...

1.doc

1   2   3   4
Реклама MarketGid:
Загрузка...

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


1. Расшифруйте аббревиатуру TMN?

2. Что является объектами управления в TMN;

3. Какие интерфейсы применяются при обмене командами управления?

4. Поясните функции прикладного уровня TMN;

5. Каковы минимальные возможности TMN;

6. Область применения TMN. Приведите примеры;

7. Перечислите функциональные группы задач управления;

8. Какие характеристики являются основными при исследовании архитектуры TMN;

9. Что понимается под архитектурой TMN?

10. Из каких основных компонентов состоит функциональная архитектура TMN?

11. Какие функции TMN описаны в NEF?

12. Какие функции выполняет бок TF?

13. Назначение физической архитектуры TMN;

14. Перечислите функции Q-адаптера и Х-адаптера. В чем их различие?

15. Какие интерфейсы в сети управления используются в опорных точках X, F, Q?

16. Поясните различие между интерфейсом Q3 и Qx;

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

18. Что такое логическая архитектура TMN?

19. Какие функции TMN исполняются на уровне управления элементом сети?

20. Какие показатели являются примером перспективности TMN?

21. Какие недостатки имеет TMN?

5 УПРАВЛЯЮЩИЕ ПРОТОКОЛЫ  TMN


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

К одним из наиболее известных и распространённых управляющих протоколов относятся протоколы SNMP (Simple Network Management Protocol –простой протокол сетевого управления) и CMIP (Common Management Information Protocol –протокол общей управляющей информации).

Рассмотрим подробнее каждый из перечисленных протоколов.


5.1 Общие сведения о протоколе SNMP


В системах управления, построенных на основе протокола SNMP, стандартизируются следующие элементы:

  • протокол взаимодействия агента и менеджера;

  •  язык описания моделей MIB и сообщений SNMP - ASN.1 (стандарт ISO 8824: 1987, рекомендации ITU-T X.208);

  • несколько конкретных моделей MIB.

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

SNMP – это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB. Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIBI и MIBII.

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

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

В настоящее время существуют две версии SNMP: SNMPv1 и SNMPv2. Обе версии имеют много общего, однако SNMPv2 предоставляет некоторые преимущества, например дополнительные операционные возможности протокола. Стандартизация версии SNMPv3 в целом завершена, но версия 3 не нашла пока широкого применения.

SNMP использует дейтаграммный транспортный протокол UDP, не обеспечивающий надёжной доставки сообщений. А протокол TCP весьма загружает управляемые устройства, которые на момент разработки SNMP были не очень мощные, поэтому пришлось отказаться от TCP .

К недостаткам протокола SNMP можно отнести следующее:

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

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


5.2 Протокол общей управляющей информации CMIP


Доступ к управляющей информации, хранящейся в управляемых объектах, обеспечивается с помощью элемента системы управления, называемого элементом услуг общей управляющей информации CMISE (Common Management Information Service Element). Служба CMISE построена в архитектуре распределённого приложения, где часть функций выполняет менеджер, а часть – агент. Взаимодействие между менеджером и агентом осуществляется по протоколу CMIP. Услуги, предоставляемые службой CMSIE, называются услугами CMIS (Common Management Information Services –общие услуги информации управления).

Протокол CMIP и услуги CMIS определены в стандартах X.710 и X.711 ITU-T.

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

CMIP основан на базе данных управления (Management Information Base, MIB), то есть на совокупности управляемых объектов. Эти объекты имеют атрибуты, обладают некоторым поведением, могут быть созданы и удалены и инициируют в прикладной программе специфические действия, которые запрашиваются менеджером.

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

Протокол CMIP используется CMISE для сбора, обмена и изменения информации об управляемых объектах. Это позволяет осуществлять управление элементами всех уровней модели ВОС. CMIP – это протокол, у которого нет “интеллектуальных” программ-агентов, напротив, агенты CMIP на объектах управления более интеллектуальны, чем их аналоги в других стандартах сетевого управления.

CMIP формирует протокольные блоки данных (PDU) и осуществляет обмен PDU между одноуровневыми услугами CMISE, чтобы реализовать сервисы CMIS. CMIP используется для обеспечения услуг управления операциями и услуг передачи уведомлений CMISE (рисунок 13).

Услуги CMIS разделяются на две группы – услуги, инициируемые менеджером (запросы), и услуги, инициируемые агентом (уведомления).

Услуги, инициируемые менеджером, включают следующие операции:

-M-CREAT инструктирует агента о необходимости создать новый экземпляр объекта определённого класса или новый атрибут внутри экземпляра объекта;

-M-DELETE инструктирует агента о необходимости удаления некоторого экземпляра объекта определённого класса или атрибута внутри экземпляра объекта;

-M-GET инструктирует агента о возвращении значения некоторого атрибута определённого экземпляра объекта;

-M-SET инструктирует агента об изменении значения некоторого атрибута определённого экземпляра объекта;

-M-ACTION инструктирует агента о необходимости выполнения; определённого действия над одним или несколькими экземплярами объектов.

Агент инициирует только одну операцию: M-EVENT-REPORT –отправка уведомления менеджеру.

CMIP определяет функции управления сетью и предоставляет следующие виды услуг:

-управление конфигурацией – внешним очертанием, взаимным расположением компонентов сети;

-управление защитой данных;

-контроль безопасности данных;

-проведение учёта работы сети;

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

-ведение службы каталогов.




Рисунок 13 – Взаимосвязь протокольных блоков CMIS и CMIP

Теоретически CMIS/CMIP обеспечивают намного более мощные средства управления, чем коммерчески более успешный SNMP. Стандарты CMIS/CMIP обеспечивают управление на всех уровнях модели ВОС, однако более удобны для управления верхними уровнями. CMIS/CMIP позволяют в рамках модели ВОС предлагать жизнеспособные стандарты для прикладных программ управления сетями связи. Протоколы CMIS/CMIP разрабатывались при финансовой поддержке правительств ведущих западных стран и крупных поставщиков сетевого и вычислительного оборудования.

Стандарты CMIS/CMIP превосходят конкурирующий стандарт SNMP по уровню решений проблем информационной безопасности. В частности, поэтому в версии 3 протокола SNMP существенное внимание уделено именно вопросам информационной безопасности. Стандарты CMIS/CMIP имеют много функций контроля, управления и поддержки сложных инфраструктур современных сетей связи. Ориентация на объекты управления и объектно-ориентированный подход позволяет стандартам CMIS/CMIP оставаться базовыми в концепции TMN.

Из имеющихся недостатков CMIS/CMIP основным считается отсутствие полного набора реализаций стека сетевых протоколов ВОС на основе принципов управления, заложенных в CMIS/CMIP.


5.3 Сравнение протоколов SNMP и CMIP


- Применение протокола SNMP позволяет строить как простые, так и сложные системы управления, а применение протокола CMIP определяет некоторый, достаточно высокий начальный уровень сложности системы управления, так как для его работы необходимо реализовать ряд вспомогательных служб, объектов и баз данных объектов.

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

- Уведомления (traps) агента SNMP посылаются менеджеру без ожидания подтверждения, что может привести к тому, что важные сетевые проблемы останутся незамеченными, так как соответствующее уведомление окажется потерянным, в то время как уведомления агента CMIP всегда передаются с помощью надёжного транспортного протокола и в случае потери будут переданы повторно.

- Решение части проблем SNMP может быть достигнуто за счёт применения более интеллектуальных MIB, но для многих устройств и ситуаций таких MIB нет.

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

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


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

1. Кой уровень согласно OSI занимают протоколы управления?

2. Какую модель TMN поддерживают протоколы управления?

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

4. Укажите недостатки и достоинства SNMP;

5. Поясните основное назначение CMIP и CMIS. Объясните их взаимосвязь;

6. Приведите примеры команд, инициируемые менеджером;

7. Проведите сравнение CMIP и CMIS. Выделите основные достоинства и недостатки каждого;

^ 6 ТЕНДЕНЦИИ РАЗВИТИЯ СТАНДАРТОВ И ТЕХНОЛОГИЙ УПРАВЛЕНИЯ СЕТЯМИ СВЯЗИ

6.1 Понятие телеком-модели операций (TOM)


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

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

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

Официально, вопросами стандартизации в области управления телекоммуникациями занимаются около пяти различных организаций. Из них можно особо выделить три института: ITU, ETSI и ANSI. Кроме официальных организаций, существуют еще множество промышленных консорциумов и некоммерческих объединений, которые занимаются разработкой альтернативных документов и соглашений, регламентирующих принципы и технологии построения систем управления телекоммуникационными сетями и услугами. К числу альтернативных структур можно отнести TMForum (TeleManagement Forum). Наиболее весомый вклад в дело дальнейшего развития идеалогии TMN вносит TMForum (TMF). Новые индустриальные стандарты TMF ориентированы на реализацию бизнес-процессов.

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

Активность TMF распределяется по следующим областям исследований и разработок:

  • моделирование и автоматизация бизнес процессов;

  • управление сетевыми технологиями следующего поколения;

  • интеграция и практическая реализация аппаратных систем;

  • управление услугами;

  • организация систем "customer-care" на базе Web;

  • управление электронной коммерцией;

  • регламентирование взаимодействия с потребителями услуг.

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

  • TMF является некоммерческой организацией, членами которой может стать любая другая организация;

  • разработка документов TMF происходит при непосредственном участии всех членов TMF, а также широкой общественности;

  • все документы TMF разрабатываются и утверждаются исходя из непосредственных практических нужд телекоммуникационных провайдеров;

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

Основным практическим документом TMF, который определяет всю остальную деятельность организации, является Telecom Operations Map (TOM) (Схема телекоммуникационных операций).

В частности, TM Forum решает следующие задачи:

- Разработка операционных инструкций в области бизнес-процессов.

-Принятие соглашений об информации, необходимой для "передачи" от одной бизнес-операции к другой.

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

-Развитие рынка и разработка реальных продуктов интеграции и автоматизации телекоммуникационных операционных процессов.

Членами TM Forum являются сервисные провайдеры, сетевые операторы и поставщики аппаратного и программного обеспечения для коммуникационной индустрии. Благодаря такому взаимодействию потребителей и поставщиков систем операционной поддержки TMF способен достигать результатов прагматическим образом, который ведет к предложению как продуктов (компаний - членов TM Forum), так и их спецификаций в бумажной форме. Деятельность FM-Forum охватывает новое поколение систем поддержки операций СПО (System of Support Operation, OSS) и программное обеспечение ПО (Software, SW) – новое поколение OSS (New Generetion System of Support Operation, NGOSS) .

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

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

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

  • при разработке TOM использовался подход "сверху-вниз" (т.е. от бизнес- нужд оператора к технологическим составляющим сетевого управления) в отличие от TMN, где рассмотрение управления ведется по принципу "снизу-вверх", т.е. сначала регламентируются технологии и функции управления на уровне сетевых элементов, затем на уровне сети и далее.

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

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

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

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

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

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

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




Рисунок 14 – Рамочная TOM-модель бизнес-процессов для отрасли
телекоммуникаций.

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

  • наблюдается частая повторяемость основных информационных процессов;

  • существуют высокие требования к скорости реакции;

  • требуется высокое качество (точность и полнота).

В сумме основные направления использования TOM провайдерами услуг сводятся к следующему:

  • регулирование внутренних и внешних дискуссий;

  • для управления бизнес процессами - разработка и реинжиниринг;

  • идентификация потребностей, разработка требований;

  • разработка требований к интерфейсам и информационным моделям;

  • ведение переговоров с партнерами об автоматизации интерфейсов;

  • определение места поставщиков в структуре TOM- модели.

Только некоторые из ключевых TOM-направлений провайдеры использовали и продолжают использовать в целях:

  • лучшего понимания, как провайдеры услуг осуществляют разработку и поставку решений и продуктов, которые соответствуют потребностям клиентов;

  • идентификации интерфейсов; 

  • определения признаков соответствия клиентов;

  • общения с клиентами на одном языке.



6.2 Технология CORBA


В 1991 году Группой объектного управления OMG (Object Management Group) была представлена одна из перспективных технологий управления CORBA (Common Object Request Broker Archiecture) – общая архитектура брокера объектных запросов. Технология CORBA является основным решением, преодолевающим недостатки TMN и SNMP и обладающим заметно меньшей стоимостью в реализации.

Технология CORBA выполняет функции промежуточного программного обеспечения в системе “клиент-сервер” (“менеджер-агент”). В роли клиента выступает удалённое приложение (прикладной процесс управления). Сервер является управляющей системой с реализацией соответствующих процессов. Взаимодействие клиент-сервер происходит через механизм объектного вызова удалённой процедуры ORPC (Object Remote Procedure Call).

Технология CORBA реализует три основных принципа:

- независимость от физического размещения объекта;

-независимость от платформы;

-независимость от языка программирования.

В ITU-T серьёзно рассматривается вопрос о введении архитектуры CORBA как альтернативного средства поддержки интерфейса Q . CORBA даёт возможность обеспечивать связь между распределёнными по сети объектами с использованием объектно-ориентированного подхода. Именно это было заложено в протокол CMIP, не принятый компаниями-производителями в качестве магистральной компьютерной технологии. Что касается CORBA, задачей которой является обеспечение работы и взаимодействия разнородных (написанных на разных языках) приложений в распределённой среде, то доступность и дешевизна этого альтернативного средства делают его предпочтительным для использования в TMN. В среде разработчиков TMN уже имеется шутливое, но не лишённое оснований мнение: нужно просмотреть все стандарты для TMN и везде вычеркнуть упоминание о протоколе CMIP, поменяв его на CORBA.

К достоинствам данной технологии можно отнести такой фактор, как возможность создания интегрированных приложений для систем управления. CORBA обладает более понятными пользователю средствами описания объектов информационных процессов и потоков. Средствами являются: язык описания интерфейсов IDL (Description Language Interface) и универсальный язык моделирования UML (Universal Language of Modeling), который описывает объекты и процессы с помощью диаграмм.

Недостатком же является то, что использование CORBA интерфейсов требует очень трудоёмкой работы по адаптации специфических особенностей управления в иные технологии (особенно это касается адаптации информационных моделей и баз данных MIB).


6.3 Новое поколение систем операций и программного обеспечения NGOSS


Работа в рамках системного контекста осуществляется под "зонтиком" управления со стороны TM Forum с целью создания нового поколения операционных систем и программного обеспечения (New Generation of Operations Systems and Software - NGOSS™), которые более адекватно поддерживают функции Plug & Play. NGOSS™ управляется работами, осуществляемыми в бизнес областях, и требованиями к системной инфраструктуре.

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

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

NGOSS™ - работа и структуры также направляют исполнение TM Forum-проектов, т.е. проектов, которые разрабатывают спецификации контрактов, и каталитических проектов (проектов, сфокусированных на применение). Наиболее ценными TM Forum-проектами являются те проекты, которые комбинируют строгую работу по моделированию или использованию общих объектов с бизнес и системным контекстом в каталитическом применении .

Обратимся теперь к программе NGOSS. Если SmartTMN призвана облегчить оператору/провайдеру ориентацию в уже сложившейся на рынке систем управления ситуации, то NGOSS нацелена на будущее (приблизительно на 5-10 лет вперед). Программа NGOSS очень амбициозна. Но в современном информационном мире есть все необходимые предпосылки для того, чтобы эта амбициозность была оправдана и принесла в конечном итоге выгоды всем игрокам рынка телекоммуникационного и ИТ менеджмента. Посредством NGOSS члены TMF ставят себе целью кардинально изменить философию и архитектуру технологической организации автоматизированных комплексов, управляющих ресурсами телекоммуникационного предприятия. Обратите внимание на слова "ресурсы телекоммуникационного предприятия". Это означает что NGOSS нацелена на удовлетворении потребностей в менеджменте всего телекоммуникационного предприятия в целом того или иного оператора/провайдера. Нужно, отметить, что на данный момент NGOSS сосредоточена ни на то, как и чем управлять, а на том, как организовывать программно-аппаратную инфраструктуру автоматизированных систем управления оптимальным образом, для того чтобы достигнуть следующих характеристик:

-интероперабельности на уровне близком к "plug'n'play";

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

-высокой степени масштабируемости при дальнейшем совершенствовании.

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

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

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

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

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

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

NGOSS не только определяет и пропагандирует вышеуказанные теоретические принципы, но и на базе этих принципов строит конкретные системные модели различного типа и уровней абстракции. Например, в документе GB920 определяется общая независимая от технологий модель организации программных компонент с распределением функциональности между отдельными компонентами. Модель также определяет общую логику/алгоритм взаимодействия различных компонент в пределах одной или нескольких систем управления отдельного оператора (провайдера). На основании общей архитектуры, описанной в GB920, затем определяются (путем отображения) зависимые от технологий архитектуры реализации программной логики системы управления. Способы отображения и адекватность применения тех или иных технологий для реализации независимой архитектуры NGOSS определяются в части первой уже упомянутой нами "Technology Integration Map". Семантика объектов и процессов управления определяется в "Telecom Operations Map" и документах серии "System Integration Map". В общем и целом NGOSS инкорпорирует большую часть работы, проделанной в рамках программы SmartTMN. Однако сама программа NGOSS является сравнительно молодой инициативой, и многие ее аспекты только начинают прорабатываться членами TMF. Поэтому делать какие-либо выводы или обобщения по поводу этой программы довольно сложно. Возможно лишь дать небольшой прогноз дальнейшего развития NGOSS. Ввиду того, что данную программу поддерживает большое количество довольно известных производителей программного и аппаратного обеспечения можно надеется, что NGOSS имеет вполне определенное и, если можно так выразиться, "официальное" будущее. Катализирующие проекты, которые выгодным образом отличают TMF от других организаций, поддержат теоретические начинания рабочих групп по поводу технологий NGOSS. Также обнадеживающим является тот факт, что вся "software"-индустрия переходит на принципы "компонентности" и взаимодействия программных составляющих через общие сервисы и "промежуточное" ПО.

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


^ 6.4 Технология SMART TMN


TMForum опубликовал первые документы, касающиеся новой технологии SMART TMN (Расширенная технология TMN) (“SMART TMN. Technology Integration Map”, ”Technology Direction Statement” и др.). Причины необходимости разработки нового подхода взамен TMN кроются:

  •  в неудачах решения многих проблем создания систем управления;

  • в появлении совершенно новых технологий, таких как, например, CORBA, JAVA и др.

В упомянутых документах с самого начала указываются три основные причины, вызвавшие к жизни необходимость разработки SMART TMN:

  • Автоматизация полномасштабного управления процессом с момента его инициализации начала до момента завершения (например, процессом предоставления услуги).

  • Организация обмена информацией между подпроцессами для обеспечения прозрачности управления.

  • Разрабатываемые технологии должны эффективно обеспечивать построение специализированных систем (систем расчета пользователей, систем финансового и бухгалтерского расчета и т.п.) так, чтобы программные приложения различных производителей легко и надежно (по методу "plug and play") совмещались в единой системе управления. С точки зрения управления бизнес-процессами эти приложения должны восприниматься как органические части единого целого и их работа должна выглядеть "прозрачной".

SMART TMN состоит из следующих частей:

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

  • Основные информационные средства CIF – это набор инструментов и методик для моделирования процессов и объектов в TOM.

  • Модель интеграции технологий TIM (Model to Integrations Technology), в которой на основании практических исследований и анализов отбирается группа наиболее технически адекватных и рентабельных технологий для построения реальных систем управления по концепции TMN.

  • Катализирующие процессы CP (Catalyzising Processes), через которые TMF проверяет жизнеспособность своих технических стандартов.


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


  1. Расшифруйте аббревиатуру ТОМ;

  2. Какие основные организации занимаются вопросами стандартизации?

  3. Перечислите основные отличия ТОМ –модели от регламентированных в TMN;

  4. В чем смысл разрабатываемых технологических карт?

  5. Перечислите основные направления использования ТОМ-модели;

  6. Какие основные принципы управления реализует технология CORBA?

  7. Какие недостатки и достоинства имеет технология CORBA?

  8. Расшифруйте аббревиатуру NGOSS. Поясните назначение NGOSS;

  9. Каковы основные принципы NGOSS?

  10. Дайте краткую характеристику технологии SMART TMN.



ЛИТЕРАТУРА


  1. Van Landegem T., De Prycker M., Vandem Brande F. 2005: a vision of the network of the future//Electrical Communication/-1994.-3 rd Quarter.-P.231-240.

  2. Kretsch Werner A., Little Artur D/ Telekommunications in the year 2010//Telcom report international/-1995/-№4.-Р.10-13.

  3. Дымарский Я.С., Крутякова Н.П., Яновский Г.Г. Управление сетями связи:принципы, протоколы, прикладные задачи. //Серия изданий «Связь и бизнес», М.: ИТЦ «Мобильные коммуникации», 2003.-384с.

  4. Гребешков А.Ю. Стандарты и технологии управления сетями связи. - М.: Экотрендз, 2003.-288с.

  5. Основы управления связью Российской Федерации /Булгак В.Б., Варакин Л.Е., Крупнов А.Е.и др.; Под. Ред. А.Е.Крупнова и Л.Е.Варакина.-М.: Радио и связь, 1998.-184с.

  6. Телекоммуникационные системы и сети. Том 1. Современные технологии. – М.: Горячая линия – Телеком, 2003 – 647с

  7. Теория сетей связи под редакцией В.Н. Рогинского. – М.: Радио и связь, 1981 – 192 с.

  8. А.В.Засецкий, А.Б.Иванов, С.Д.Постников, И.В.Соколов Контроль качества в телекоммуникациях и связи. Часть II, под.ред. А.Б.Иванова – М.: Компания САЙРУС СИСТЕМС, 2001- 342с.



Михаил Михайлович Егунов,

Ольга Григорьевна Шерстнева,

Елена Анатольевна Абзапарова


^ СИСТЕМЫ УПРАВЛЕНИЯ СЕТЯМИ СВЯЗИ


Учебное пособие





Подписано в печать 02.11.09

формат бумаги 62х84/16, отпечатано на ризографе,

шрифт № 10

печ. л. 2,89 тираж 200, заказ 582

Типография УрТИСИ ГОУ ВПО «СибГУТИ»

620109, Екатеринбург, ул. Репина, 15


1   2   3   4



Скачать файл (819.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru