stringtranslate.com

Система поддержки операций

Системы поддержки операций ( OSS ), системы поддержки операций в британском использовании или операционная система ( Operation System ( OpS ) в NTT [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 у Digital Equipment Corporation для различных приложений OSS. Системы OSS, используемые в Bell System, включают AMATPS , CSOBS, EADAS , Remote Memory Administration System (RMAS), Switching Control Center System (SCCS), Service Evaluation System (SES), Trunks Integrated Record Keeping System (TIRKS) и многие другие. Системы OSS той эпохи описаны в Bell System Technical Journal , Bell Labs Record и Telcordia Technologies (теперь часть Ericsson ) SR-2275. [2]

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

Архитектура

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

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

Пятый уровень иногда упоминается как сами элементы, хотя стандарты говорят только о четырех уровнях. Это было основой для более поздней работы. Управление сетями было далее определено ISO с использованием модели FCAPS — Fault, Configuration, Accounting, Performance и Security. Эта основа была принята стандартами 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 определила протокол управления CPE WAN (CWMP), подходящий для управления устройствами и терминалами домашних сетей на интерфейсе EML-NML.

Форум ТМ

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

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

Модели Frameworx

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

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

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

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

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

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

Ссылки

  1. ^ NTT Access Network Service Systems Laboratories (апрель 2003 г.). "Операционная система". ANSL R&D Times #32 . Получено 25.01.2021 .[ мертвая ссылка ]
  2. ^ Latonia Gist (2013). Телекоммуникационные системы и стандарты (PDF) . Мировые технологии. стр. 16. ISBN 978-81-323-4238-0.
  3. ^ «Открытая цифровая архитектура».

Внешние ссылки