Система оперативной поддержки - Operations support system

Для использования в других целях см. OSS.

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

Вместе с Системы поддержки бизнеса (BSS), они используются для поддержки различных услуг сквозной связи. BSS и OSS имеют свои собственные обязанности в отношении данных и обслуживания. Эти две системы вместе часто обозначаются сокращенно OSS / BSS, BSS / OSS или просто B / OSS.

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

Различные подразделения OSS были предложены TM Forum, промышленные исследовательские лаборатории или поставщики OSS. Как правило, OSS выполняет как минимум следующие пять функций:

История

Примерно до 1970 года многие операции OSS выполнялись вручную. Однако стало очевидно, что большую часть этой деятельности можно заменить компьютеры. В следующие 5 лет или около того телефонные компании создал ряд Компьютерные системы (или же программные приложения ), что автоматизировало большую часть этой деятельности. Это было одним из движущих факторов развития Unix операционная система и Язык программирования C. В Bell System приобрели собственную линейку продуктов PDP-11 компьютеры из Корпорация цифрового оборудования для различных приложений OSS. Системы OSS, используемые в Bell System, включают: AMATPS, CSOBS, EADAS, Система удаленного администрирования памяти (RMAS), Система центра управления коммутацией (SCCS), Система оценки услуг (SES), Интегрированная система учета соединительных линий (TIRKS) и многое другое. Системы OSS этой эпохи описаны в Технический журнал Bell System, Bell Labs Record, и Telcordia Technologies (теперь часть Ericsson ) СР-2275.

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

Архитектура

Большая часть работы над OSS была сосредоточена на определении его архитектуры. Проще говоря, есть четыре ключевых элемента OSS:

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

В 1990-х годах новые определения архитектуры OSS были сделаны Сектор стандартизации электросвязи МСЭ (ITU-T) в своем Сеть управления телекоммуникациями (TMN) модель. Это установило четырехуровневую модель TMN, применимую в OSS:

  • Уровень управления бизнесом (BML)
  • Уровень управления услугами (SML)
  • Уровень управления сетью (NML)
  • Уровень управления элементами (EML)

Пятый уровень иногда упоминается как сами элементы, хотя стандарты говорят только о четырех уровнях. Это было основой для дальнейшей работы. Управление сетью было дополнительно определено ISO с использованием FCAPS модель - неисправность, конфигурация, учет, производительность и безопасность. Эта основа была принята стандартами ITU-T TMN в качестве функциональной модели для технологической базы стандартов TMN серий M.3000 - M.3599. Хотя модель FCAPS была первоначально задумана и применима для корпоративной сети ИТ, она была адаптирована для использования в сетях общего пользования, которыми управляют поставщики телекоммуникационных услуг, соблюдающие стандарты ITU-T TMN.

Большой проблемой управления сетью и услугами является способность управлять и контролировать сетевые элементы доступ и опорные сети. Исторически сложилось так, что на форумах по стандартизации (ITU-T, 3GPP) было потрачено много усилий, чтобы определить стандартный протокол для управления сетью, но без успеха и практических результатов. С другой стороны IETF SNMP протокол (Simple Network Management Protocol) стал де-факто стандартом для Интернета и телекоммуникационная компания менеджмент на уровне коммуникации EML-NML.

Начиная с 2000 года и позже, с ростом новых услуг широкополосного доступа и VoIP, управление домашними сетями также входит в сферу OSS и сетевого управления. DSL Forum TR-069 В спецификации определен протокол управления WAN CPE (CWMP), подходящий для управления устройствами и терминалами домашних сетей через интерфейс EML-NML.

TM Forum

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

К 2005 году разработки в архитектуре OSS стали результатом работы TM Forum Операционные системы и программное обеспечение нового поколения (NGOSS), которая была создана в 2000 году. Она установила набор принципов, которые должна принять интеграция OSS, а также набор моделей, обеспечивающих стандартизованные подходы. NGOSS был переименован в Frameworx.

Модели Frameworx

TM Forum описывает Frameworx как архитектуру, которая:

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

Вначале работа TM Forum в рамках NGOSS была сосредоточена на создании эталонных моделей для поддержки взглядов заинтересованных сторон на процессы, информацию и взаимодействие приложений. Параллельно выполнялись мероприятия, которые поддерживали точку зрения заинтересованных сторон на реализацию спецификаций интерфейса для обеспечения доступа к возможностям OSS (в первую очередь, MTNM). Работа MTNM превратилась в набор веб-сервисов, обеспечивающих интерфейсы мульти-технологической операционной системы. MTOSI. Совсем недавно,[когда? ] инициатива OSS через Java (OSS / J) присоединился к TMF для предоставления BSS / OSS на базе NGOSS API.

Текущая работа - Открытая цифровая архитектура (ODA)

Открытая цифровая архитектура (ODA) предлагает согласованный в отрасли план, язык и набор ключевых принципов проектирования, которым необходимо следовать. Он предоставит практические пути перехода от поддержки монолитных унаследованных программных решений к управлению гибкими облачными возможностями, которые можно организовать с помощью AI. Это эталонная архитектура, которая отображает Открытые API против технических и бизнес-функций платформы.[2]

Смотрите также

Рекомендации

  1. ^ См. Статью в Википедии Исследование операций.
  2. ^ https://www.tmforum.org/resources/whitepapers/open-digital-architecture/

внешняя ссылка