Эксплуатационное управление
Кто способен - делает.
Кто не способен делать — учит других.
Кто не способен учить — управляет.
Закон Менкена
10.1. Эволюция функций эксплуатационного управления системами коммутации
Понятию эксплуатационное управление (по крайней мере, применительно к системам связи) соответствует то, что в англоязычной литературе принято называть словом Management. Общая задача эксплуатационного управления состоит в том, чтобы обеспечить нормальную работу системы связи, ее адаптацию к изменениям как внешних, так и внутренних условий, ее развитие в количественном и в качественном отношении, а также расчеты с пользователями за предоставляемые им услуги. Все это предполагает наличие нескольких частных задач, в числе которых управление ресурсами (Operations), административное управление (Administration), техническое обслуживание (Maintenance) и ввод новых ресурсов (Provisioning). Первые буквы английских слов, приведенных в скобках, образуют аббревиатуру OAM&P, обозначающую то же, что и Management, а первые три из этих букв в сочетании с буквой С (от слова Center) — аббревиатуру ОАМС, которая по-русски расшифровывается как центр технической эксплуатации.
Эксплуатационное управление охватывает, помимо узлов коммутации, баз данных и пунктов сигнализации ОКСО, также и другие компоненты сети связи, но их рассмотрение выходит за пределы этой книги.
Развитие средств эксплуатационного управления в коммутационных станциях и узлах все время шло эволюционным путем. По мере введения в АТС новых функций и новых программно-аппаратных средств, возникали новые эксплуатации но технические задачи, для решения которых создавалось новое программное обеспечение.
Первоначально эксплуатационное управление выполнялось вручную, но постепенно оно автоматизировалось. В 1970-х годах каждая группа действий, связанных с технической эксплуатацией коммутационного оборудования, выполнялась приложением, предназначенным исключительно для этой цели, и все такого рода приложения разрабатывались независимо друг от друга. Они имели простой текстовый пользовательский интерфейс — в распоряжении эксплуатационного персонала были телетайпные терминалы, подключаемые прямо к контролируемым объектам АТС. Постепенно на смену телетайпам пришли компьютеры, появилось программное обеспечение человек-машина» и специальные приложения технической эксплуатации. Определились основные функции каждой из названных выше составных частей эксплуатационного управления.
Функции управления ресурсами АТС включают в себя назначение и модификацию станционных параметров, характеризующих все логические и физические ресурсы в станции (под физическим ресурсом подразумевается любое станционное устройство, а логическим ресурсом считается любой объект — такой как пучок соединительных линий или направления маршрутизации, — который является значащим с точки зрения технической эксплуатации станции); сбор данных для начисления платы; сбор и анализ статистических данных о нагрузке, обслуживаемой станцией. Как уже упоминалось, станционное ПО имеет сведения о физических и функциональных реалиях своей станции через параметры конфигурации, которые являются переменными величинами, определяемыми специально для этой цели.
Функции административного управления АТС включают в себя ведение абонентских данных (номера и категории абонентских линий, начисление платы) и аналогичных по смыслу данных, относящихся к взаимодействию с УПАТС и с другими сетями, а также принятие решений, связанных с развитием сети связи, и передачу соответствующих указаний функциям управления ресурсами.
Функции технического обслуживания включают в себя контроль работоспособности станции; обнаружение неисправностей с как можно более точным определением их местоположения; блокировку последствий неисправностей (диагностика первого уровня); удаление неисправных элементов и их восстановление (диагностика второго уровня). Это делается без прерывания работы станции, а для того чтобы обеспечивалась возможность глубокой диагностики станционного устройства, неисправность которого может являться причиной серьезных нарушений функционирования, устройства такого типа, как правило, резервируются. Когда диагностика первого уровня определяет, что неисправно одно из резервированных устройств, процедуры техобслуживания обеспечивают автоматическую реконфигурацию станции, выводя из обслуживания устройство, которое оказалось неисправным, и переключая его функции на резервирующее устройство.
Статистический контроль ведется на основе наблюдения за обслуживанием реального потока вызовов, для чего используется комплект счетчиков, с помощью которых наблюдаемые последовательности фаз обслуживания вызовов и обработки сигнализации сравниваются с типовыми последовательностями. Когда текущие показания счетчиков выходят за статистически установленные пределы, генерируются коды аномальных ситуаций для диагностики первого уровня.
Наряду со статистическим, ведется и периодический контроль оборудования АТС с помощью программ, запускаемых по таймеру. Эти же программы могут быть запущены с помощью команд оператора станции в соответствии с плановыми проверками, периодичность которых определяется соответствующими инструкциями. Тестовые программы имеют низкий приоритет и выполняются в периоды низкой нагрузки АТС
Кроме этого, с системой эксплуатационного управления АТС взаимодействуют следующие службы операторской компании:
• служба технической поддержки, которая создает спецификации для развития и модернизации АТС, взаимодействует с техническим отделением поставщика коммутационного оборудования и с группой трафика с целью выработки технических решений;
• биллинговый центр, который ведет обработку учетной информации станции для составления абонентских счетов;
• служба безопасности, занимающаяся предотвращением несанкционированного доступа и злоупотреблениями при пользовании услугами телефонной связи;
• абонентская группа, главная функция которой состоит в назначении линий и ведении станционных баз данных;
• группа трафика, которая изучает и моделирует телефонный трафик АТС; по ее Рекомендациям, базирующимся на динамике межстанционного трафика, добавляются и/или удаляются соединительные линии в станции.
Для каждой из рассмотренных групп функций эксплуатационного управления разрабатывались соответствующие программные системы, которые назывались системами эксплуатационной поддержки OSS (Operations Support Systems), причем, как правило, в каждой из этих первых OSS использовались собственные протоколы.
В контексте этой главы термин OSS относится к системам, выполняющим функции эксплуатационного управления, включая инженерную поддержку, планирование и техническое обслуживание коммутационных узлов и станций. И если первоначально OSS представляли собой автономные системы, предназначенные для поддержки технического персонала АТС в его повседневной эксплуатационной работе, то в настоящее время для поддержки эксплуатационного управления используются OSS нового поколения,. базирующиеся на передовых информационных технологиях.
Усилия, направленные на создание механизма, пригодного для использования всеми приложениями технической эксплуатации, привели к появлению стандарта сети эксплуатационного управления телекоммуникациями TMN (Telecommunications Management Network), который был разработан совместно ISO и ITU-Т, и входящего в этот стандарт протокола передачи общей управляющей информации CMIP (Common Management Information Protocol). О концепции TMN и о CMIP мы еще поговорим в параграфе 10.6.
Следует подчеркнуть, что здесь речь идет только об уровне эксплуатационного управления системами коммутации в рамках модели TMN, хотя современные концепции OSS гораздо шире и смыкаются с системами поддержки бизнеса оператора связи (BSS). Последнее время такой подход обозначается BSS/OSS.
Точно так же, из-за недостатка места здесь не рассматриваются и разработанные IETF стандарты обмена сообщениями для эксплуатационного управления сетью связи. Но два стандарта следует назвать: протокол облегченного доступа к сетевому каталогу LDAP (Lightweight Directory Access Protocol) и простой протокол эксплуатационного управления сетью SNMP (Simple Network Management Protocol), которые используются практически во всех новых разработках АТС и оборудования абонентского доступа.
Параллельно с развитием OSS и концепции TMN возрастало значение другой проблемы — качества обслуживания (QoS), — что, в частности, привело к включению в TMN подсистемы управления сетевым трафиком NTM (network traffic management). Традиционно качество обслуживания в ТФОП определялось такими факторами, как время ожидания после набора номера и вероятность потери вызова. В главе 1 говорилось о том, что было бы непозволительно дорого проектировать АТС и всю телефонную сеть таким образом, чтобы одновременно могли быть связаны попарно все телефонные абоненты. Да в этом и нет необходимости, поскольку абоненты не все сразу и не все время пользуются телефоном. Исследованиями установлены и среднее число вызовов одного абонента в час наибольшей нагрузки (ЧНН), и средняя длительность разговора, и вероятности того, что абонент занят или не может ответить на вызов. Производительность АТС проектировалась на основе этих данных с некоторым запасом, учитывающим возможные колебания трафика. И все же, проблема QoS существует именно по этой причине, а одна из задач эксплуатационного управления как раз и состоит в поддержании заданного качества обслуживания. В цифровых АТС решение проблем эксплуатационного управления и QoS в значительной степени обеспечивается программными средствами.
10.2. Сопровождение программного обеспечения.
В этом параграфе будет затронута важная тема сопровождения программного обеспечения АТС, по мнению автора, оставленная специалистами без должного внимания. В предыдущей главе отмечалось, что на программное обеспечение приходится почти 80% стоимости разработки станции, но достаточно глубокие исследования методов его технического обслуживания не проводились. А ведь нужно, кроме прочего, иметь в виду, что сопровождение ПО цифровой АТС выполняет как ее производитель (действия, связанные с коррекцией или модернизацией текущей версии ПО, включая «заплаты» и корректировки для исправления ошибок в текущей версии), так и оператор станции (регламентное обслуживание, диагностика, корректировка таблиц станционных файлов, добавление линий и трактов в базу данных АТС).
Нормальная работа системы программного управления АТС может нарушаться по следующим причинам:
• ошибки программного обеспечения, включая «жучки» (bugs) вызывающие ошибки доступа к оперативной памяти, или программные сбои, которые могут быть исправлены только с помощью перезагрузки системы;
• аппаратные сбои, связанные с неисправностями аппаратных средств управляющих компьютеров;
• некорректное восстановление, когда из-за ошибки в программном обеспечении и/или в документации невозможно правильно детектировать неисправность и изолировать неисправный блок;
• процедурные ошибки, связанные, например, с вводом неправильных данных оператором или с неправильным действием во время процедур восстановления, расширения и корректировки. Смена версий ПО большой цифровой АТС обычно происходит Один-два раза в год; между этими сменами корректировки ПО производятся с помощью «заплат» (patches), которые представляют собой модификации программы без перекомпиляции всей версии.
Сложность любой версии станционного ПО настолько высока, что избежать ошибок при ее проектировании и реализации практически невозможно. Опыт прошедших десятилетий показал, что не существует универсальной методики производства абсолютно безошибочного ПО АТС при допустимых ценах и при разумных затратах времени на разработку. Вероятно, такой методики не появится и в ближайшее десятилетие, тем более, что сложность станционного ПО обусловлена, прежде всего, его объемом, который может выражаться более чем миллионам строк исходного текста программы. 25 — 30% этого объема занимают программы обработки телефонного трафика, порядка 20% — операционная система, а рассматриваемое в этой главе ПО эксплуатационного управления — порядка 50%.
В отличие от разработки аппаратных средств, где те или иные решения часто бывают обусловлены технологическими ограничениями, программное обеспечение проектируют специалисты, чей подход к работе в большей степени обусловлен доброй волей и свободой выбора, нежели необходимостью, которую диктуют возможности технологии. В то же время, затраты на программирование превышают затраты на аппаратные средства. И то, и другое вместе часто побуждает руководителей проектов сокращать объем проектирования ПО, откладывая на завтра реализацию в нем тех или иных функций, в частности, функций его обслуживания. Следствием такой ориентации руководства иногда оказывается значительное ухудшение качества ПО. А куда разумнее было бы не экономить хотя бы на разработке простых и ясных программных средств сопровождения ПО в течение всего жизненного цикла АТС.
Ограниченный объем книги не позволяет рассмотреть эту проблематику более детально, но весьма полезно сопоставить кратко изложенные здесь соображения с материалом о качестве программного обеспечения, приведенном в предыдущей главе.
10.3. Задачи ФОРМ и информационной безопасности
Отдельная группа функций эксплуатационного управления связана с двумя, на первый взгляд, противоположными задачами цифровой АТС. Первая задача состоит в поддержке функций оперативно-розыскных мероприятий (СОРМ), а вторая — в том, чтобы обеспечить информационную безопасность.
Функции СОРМ включают в себя:
• контроль всех входящих/исходящих вызовов определенных абонентов станции, находящихся под наблюдением,
• контроль вызовов, направленных к заранее заданным номерам телефонной сети от абонентов данной станции,
• получение (по запросу) информации о категории абонента о предоставляемых ему дополнительных услугах.
Такие функции в АТС существуют довольно давно. Сведения о первых реализациях, согласно [141], касаются установки импортного оборудования СОРМ в помещении IV Государственной думы в 1913 году.
Сегодня специфические функции СОРМ выполняют так называемые пункты управления (ПУ), рассмотрение которых выходят за рамки этой книги, а обязательным требованием к цифровой АТС является организация речевого канала для передачи в ПУ информации, проходящей по контролируемому разговорному тракту, и канала для передачи с использованием сетевого протокола Х.25 команд управления от ПУ к станции и информации о фазах контролируемых соединений — от станции к ПУ. Оператору ПУ предоставлена возможность взаимодействия со станционным ПО с помощью специальных команд и сообщений. По этому же каналу станция транслирует к ПУ аварийные сообщения о тех событиях, которые могут влиять на работу СОРМ.
Подробное описание форматов команд и сообщений, передаваемых по каналам передачи команд и данных, приводится в специальных документах, с которыми можно познакомиться в сети Интернет. Суть этих команд и сообщений заключается в том, что к ПУ передается информация о следующих состоявшихся фазах обслуживания каждого контролируемого вызова: прием запроса соединения (с момента вызова станции абонентом до окончания приема ею номера вызываемого абонента и/или кода дополнительной услуги); установление соединения (с момента окончания приема номера до ответа вызываемого абонента); завершение соединения, Передаваемая информация содержит телефонные номера абонентов, участвующих в разговоре, время, номер соединительной линии и ряд служебных параметров. Контролируемому абоненту может быть назначен один из двух режимов контроля: полный или статистический.
При полном контроле в ПУ передаются в реальном времени данные о контролируемых вызовах, а также информация, проходящая по разговорному тракту. При статистическом контроле разговорный тракт к ПУ не подключается, а передаются в реальном времени только данные о контролируемых вызовах.
Упрощенная структурная схема реализации СОРМ в АТС приведена на рис. 10.1, где представлен также протокол-тестер ТОР-2, выполненный на той же платформе SNT, что и упомянутые в главе 8 тестеры систем сигнализации.
Существует много аргументов против реализации этой функции, начиная со сформулированного царем Соломоном тезиса «He стремись слышать все, ибо услышишь, как твой раб злословит тебя». В техническом же смысле противоположные, в какой-то степени, требования к АТС предъявляют задачи информационной безопасности. Термины, в которых описываются эти требования — угроза, атака, нарушитель, риск, уязвимые места — не очень соответствуют стилю этой книги. Тем не менее, при проектировании современной АТС необходимо учитывать угрозу несанкционированного доступа, являющуюся следствием неадекватности контроля доступа, или угрозу потери важных функций системы, для чего необходимо планирование нештатных ситуаций, и т. п.
Разработка рассмотренных в главе 6 отечественных коммутационных узлов и станций снимает часть проблем, связанных с информационной безопасностью, которые возникают при покупке и вводе в эксплуатацию цифровых станций зарубежного производства, особенно, для объектов специального назначения. Отчасти это связано с большей уверенностью в том, что в отечественном ПО отсутствуют преднамеренно внесенные закладки» и, следовательно, нет необходимости в разработке специальной стратегии контроля, как при установке АТС, так и при смене версий программного обеспечения.
Другим способом обеспечить информационную безопасность и защиту от несанкционированного доступа является установка внешних технических средств, которые, по аналогии с компьютерными сетями, можно назвать «телефонным брандмауэром». На рис. 10.2 показан такой вариант защиты.
Оплата услуг связи может быть фиксированной (ежемесячная абонентская плата), по разговорной (с ограничением продолжительности разговора, как при пользовании таксофоном), повременной (например, с использованием тарифных импульсов), с помощью предоплаченных телефонных карт и др. Вводимая операторами ВСС РФ повременная оплата предусматривает запись необходимой информации (даты, часа, минут и секунд начала разговора, длительности разговора и индикаторов услуг) с последующей ее обработкой для выписки счетов абонентам.
Рассмотрим структурные подразделения некой типовой автоматизированной системы расчетов с абонентами (АСР), представленной на рис. 10.3:
• абонентский отдел (АО) производит всю работу с клиентами и операторами-партнерами, вводит информацию о новых клиентах, информирует клиентов о новых услугах, ведет историю клиентов и их договоров; производит прием платежей, ведет учет оказанных клиент услуг;
• отдел расчетов (ОР) производит расчет с клиентами, формирует счета и квитанции, составляет списки должников и списки для включения/отключения услуг отделом эксплуатации, контролирует счета операторов-партнеров;
• информационно-технический отдел (ИТО) занимается сопровождением системы. В задачи отдела входят: регистрация новых устройств и услуг, определение скидок и субсчетов, разработка новых тарифов и тарифных планов, ведение статистических и аналитических данных об использовании услуг и доходах предприятия;
• отдел эксплуатации (ОЭ) занимается поддержкой работоспособности системы в части сбора и обработки первичной учетной информации и взаимодействием с системами техобслуживания станций и оповещения абонентов;
• администратор системы (AC) решает все вопросы сопровождения и работы системы, определяет и изменяет уровень доступа пользователей к ресурсам системы, отслеживает изменения, производимые пользователями в базе данных, производит резервное копирование базы данных и архивирование.
Практически все АСР предназначены для расчета за услуги телефонной связи, но наиболее «продвинутые» системы помимо этого имеют возможность ведения расчетов и за другие услуги связи применительно к разным типам устройств (телефонный аппарат, входящий пучок, исходящий пучок, без устройства). Каждому устройству присваивается определенная категория оплаты. С помощью параметра «категория оплаты» для разных устройств можно устанавливать разные тарифы. Например, для устройства телефонный аппарат можно ввести категории индивидуальный, спаренный, учрежденческий и т.д.
Другим основополагающим понятием, на котором строится система начисления платы, является понятие услуга». Предусмотрены три типа услуг: основная, определяемая функциональным назначением устройства; дополнительная постоянная, предоставляющая на определенный период времени владельцу этого же устройства дополнительные возможности, которые для устройств данного типа не являются обязательными; дополнительная разовая, аналогичная предыдущей, но предоставляемая клиенту всякий раз по его запросу. Отключение основной услуги автоматически приводит к отключению всех дополнительных услуг. Например, отключение основной услуги телефонная связь, закрепленной за устройством телефонный аппарат, приведет к отключению всех дополнительных услуг, связанных с этим устройством (например, услуги переадресация).
Цена тарифной единицы услуги определяется в зависимости от следующих параметров: категория клиента; тип устройства; категория оплаты; категория дня (с учетом особенных дней); суточный график распределения тарифов; срок действия этого графика; тарифная зона и тип услуги. Все параметры, влияющие на тарификацию, носят исторический характер, т.е. имеют срок действия. При изменении этих параметров в таблицах изменяются только сроки действия параметров. Это позволяет производить перерасчет за прошлый период.
Для организации оплаты предлагаемых услуг все они разбиваются на группы. Каждой группе соответствует часть лицевого счета клиента (клиентский субсчет). Можно создать несколько разных комбинаций такого разбиения, называемых клиентскими группами субсчетов. Возможность деления общего счета клиента на отдельные субсчета позволяет контролировать оплату каждой группы услуг и оперативно принимать решение относительно отключения и включения одной группы услуг, не затрагивая другие услуги. Таким образом, при превышении порога оповещения и отключения будут блокироваться не все услуги, предоставленные клиенту, а только те, которые входят в субсчет с превышенным порогом.
За клиентом закрепляются параметры, влияющие и не влияющие на начисление платы. К параметрам, от которых плата не зависит, относятся фамилия, имя, отчество; паспортные данные; адрес; адрес рассылки и др. Параметрами, от которых плата зависит, являются: категория клиента; клиентская группа субсчетов; список имеющихся у клиента устройств; список предоставляемых клиенту услуг, закрепленных за определенными устройствами.
10.5. Взаимодействие «человек-машина»
Для доступа технического персонала к функциям эксплуатационного управления коммутационными станциями и узлами используются специализированные рабочие места операторов. Разрабатываются специальные программные средства диалога человек-машина, которые должны сочетать психологический комфорт работы оператора с предоставлением ему возможности решать практические задачи технической эксплуатации современной АТС. Когда оператору требуется запустить со своего рабочего места некоторую функцию, он запрашивает интерактивный сеанс работы со станцией. При этом оператор обычно сообщает свой пароль и вводит некоторые параметры, определяющие вид функции, которую он хочет выполнить. Если станционное ПО устанавливает, что сообщенные оператором данные являются разрешенными, запрашиваемый сеанс открывается. В противном случае оператор получает отказ.
Диалог оператора с системой представляет собой последовательность запросов/ответов. Каждый запрос содержит соответствующие параметры, и станционное ПО проверяет, находится ли ответ на этот запрос среди тех, на которые оператор имеет разрешение.
Правильность запросов и надлежащая их последовательность поддерживается формализованным языком человек-машина», специфицированным ITU-Т. Язык этот называется MML и описывается в Рекомендациях серии Z.300.
Рабочие места операторов могут подключаться к станции либо непосредственно, либо дистанционно, через линии передачи данных, как выделенные, так и коммутируемые. В программном обеспечении АТС существует набор переменных (обычно несколько сотен), с помощью которых кодируются операционные состояния физических и логических устройств станции. Эти переменные, формирующие таблицу предупреждений и состояний, автоматически корректируются в процессе работы программного обеспечения АТС. Во время сеанса оператор имеет возможность со своего рабочего места точно определить ситуацию в ATC на основе совокупности переменных состояния, а также и корректировать некоторые из этих переменных.
Суть этой концепции состоит в том, что для эксплуатационного управления телекоммуникационной системой любого назначения создается специальная сеть TMN (Telecommunications Management Network), использующая технологию многоуровневого иерархического управления. Серию стандартов для TMN разрабатывают совместно несколько международных организаций — ITU-Т, ISO, ANSI и ETSI. Цель разработки — объединить с помощью TMN разрозненные подсистемы эксплуатационного управления в единую интегрированную систему. Основная идея состоит в том, что интеллектуальные средства TMN связываются с разными элементами телекоммуникационной системы выделенными каналами управления через стандартизованные Q-интерфейсы, для чего каждый элемент, независимо от того, какая фирма его изготовила, должен содержать либо встроенные средства формирования такого интерфейса, либо так называемый Q-адаптер.
Базовый стандарт М.3010 представляет архитектуру TMN в виде четырех слоев» — функционального, информационного, физического и логического, которые, по сути дела, описывают TMN с разных точек зрения. В целом же, все предложения по TMN сводятся к определению:
• логической структуры взаимодействия TMN с подконтрольными объектами,
• средств поддержки этого взаимодействия (протоколов),
• средств структурного, объектно-ориентированного описания данных и операций,
• принципа работы с распределенными объектами (информационная база данных).
Эту исходную систему можно рассматривать как набор базовых аксиом, на основе которых строится здание управления распределенными объектами сетевой среды в идеологии TMN.
Развитие информационных технологий показало, что для решения провозглашенной TMN задачи есть и другие средства (другой набор аксиом). Эти новые средства (CORBA, JAVA, DCOM), в отличие от теоретических построений ITU-T, были быстро поняты и приняты многими потребителями [92].
Рассмотрим существо названных базовых аксиом и обратим внимание на альтернативные пути построения системы управления распределенными объектами.
Первая аксиома связана с подключением сетевого элемента к TMN, для чего используется принцип Агент/Менеджер. Агент (в сетевых элементах) и Менеджер (в центре управления) являются активными взаимодействующими компонентами TMN, которые распределены по сети и общаются путем обмена сообщениями. Сообщения со стороны Менеджера переносят запросы выполнения операций, которые предусмотрены в информационных структурах обслуживаемых Агентом объектов. Агент может передавать уведомления, генерируемые либо в ответ на запрос Менеджера, либо автономно. В теле уведомления могут передаваться атрибуты, характеризующие состояние объекта. Структура такого взаимодействия приведена на рис. 10.4. Процесс Агент является ключевым звеном любого сетевого элемента, совместимого с TMN, — телефонной станции, маршрутизатора, центра эксплуатационного управления и т.д.
Вторая аксиома предполагает наличие иерархического стека протоколов. Протокол на каждом уровне стека отвечает за обмен блоками данных этого уровня. Стек протоколов обеспечивает последовательное преобразование информации, начиная от абстрактного описания объектов и операций на некотором языке высокого уровня. Далее, по специальным правилам преобразования в бинарную форму, формируются наборы данных сетевого уровня, которые с помощью протоколов транспортного (и, далее, пакетного и физического) уровней передаются в сеть для отправки адресату. При получении адресатом предназначенного ему пакета происходит обратное восстановление данных/операций.
Основные проблемы с реализацией стека протоколов TMN возникают на верхнем уровне при переходе от абстрактного структурного описания объектов на языке высокого уровня к бинарному набору данных. На момент формирования основных принципов TMN за основу был принят стандарт Х.711 — CMIP (протокол передачи общей управляющей информации). Другим кандидатом на использование в среде TMN был упоминавшийся ранее протокол SNMP. В концепциях этих двух протоколов много общего (принцип Менеджер/Агент, объектно-ориентированный подход, иерархические уровни, структура операций-примитивов, описание наборов данных на языке ASN.1). Протокол SNMP проще, требует меньше памяти и выполняется быстрее. Зато SNMP не поддерживает процедуры наследования классов, и для получения доступа ко всем экземплярам объекта требуются последовательные запросы, а с помощью CMIP в одном сообщении можно получить все экземпляры объекта. SNMP поддерживает лишь статические объекты, CMIP позволяет динамически создавать и удалять объекты.
Протокол SNMP, в связи со своей простотой, был быстро реализован и получил широкое распространение в Интернет. Но в качестве стандарта для TMN был принят протокол CMIP, хотя с точки зрения реализации CMIP очень сложен, использует многократно вложенные структуры данных, имеет множество опций, трактовка которых не всегда однозначна. Отрицательное отношение к этому протоколу утвердилось в последние 3-4 года, когда на сцену вышли новые, более простые и прошедшие проверку на практике средства доступа к распределенным сетевым объектам — CORBA, JAVA, DCOM. И, что самое важное, средства разработки на базе новых технологий оказались в 3 — 5 раз дешевле из-за их повсеместного применения и признания пользователями.
Третья аксиома TMN — средства структурного описания наборов данных и операций информационных объектов. Каждый элемент в сети заменяется некоторой абстрактной информационной моделью, которая рассматривает его как сетевой ресурс. Параметры этого ресурса — объекта информационной модели — и передаются средствами используемого протокола (например, CMIP). Информационная модель определяет основные параметры объекта, абстрагируясь от его физической сущности и используя наборы атрибутов, уведомлений и действий.
Для создания информационной модели объекта, который описывается как некоторый класс в терминах объектно-ориентированного подхода, необходимы специальные структуры и язык описания данных. В стандартах TMN для этого используются шаблоны GDMO (Х.722) и язык ASN.1 (Х.680, Х.681). Запутанная структура подачи материала в стандартах, сложность практического освоения GDMO и ASN.1, необходимость привлекать к работе с этими инструментами специалистов высокой квалификации, высокая стоимость средств работы с GDMO/ASN.1 — всё это заставило искать другие языки. Как серьезная альтернатива ASN.1 рассматривается язык IDL, используемый для описания данных в системах CORBA и JAVA, однако для описания информационного объекта, по-видимому, придется придерживаться шаблонов GDMO.
Четвертая аксиома TMN касается информационной базы данных MIB, которая является ресурсом, разделяемым всеми объектами сети, и откуда Менеджер или Агент могут получить информацию о структуре и особенностях любого зарегистрированного в сети объекта. Необходимость иметь такой ресурс сомнения не вызывает.
Агент взаимодействует с Менеджером через сеть. Носителем информации является протокол. Совокупность правил представления информации и ее передачи образует интерфейс. Для связи любого сетевого элемента с TMN служит специальный интерфейс Q. Схема подключения сетевого элемента к среде TMN показана на рис. 10.5.
Под интерфейсом Q понимается стек протоколов, в верхней части которого находится CMIP, плюс передаваемая с его помощью информационная структура данных, описанная по правилам GDMO/ ASN.1. Набор программно-аппаратных средств сетевого элемента, обеспечивающий взаимодействие этого элемента с TMN через интерфейс Q, называется Q- адаптером.
Согласно концепции TMN, интерфейс Q построен на следующих принципах:
• использование в качестве транспортного средства для передачи сообщений между Агентом и Менеджером полного семиуровневого стека протоколов, соответствующего модели OSI, в качестве которого могут применяться стеки ISO/OSI или ТСР/IP;
• использование для передачи сообщений на прикладном уровне протокола CMIP, а для передачи больших объемов данных — протокола FTAM;
• применение поверх CMIP более содержательных протоколов взаимодействия Агент — Менеджер, конкретизирующих отдельные функции эксплуатационного управления, например контроль ошибок, измерение производительности и т.п.
Так как Менеджер связывается с Агентом при помощи полного транспортного стека, то при сборе данных от встроенных Агентов можно использовать промежуточную сеть передачи данных произвольной сложности. Это обстоятельство является одним из важных компонентов открытости архитектуры TMN. Оно дает возможность объединять любые сети, в том числе и такие, которые не могут переносить в своих основных информационных потоках данные, используемые системой эксплуатационного управления. Многим телекоммуникационным сетям предыдущих поколений для организации эксплуатационного управления требуется вспомогательная сеть, в качестве каковой операторы ТФОП, например, чаще всего используют сеть Х.25 или выделенные каналы, хотя некоторые операторы не боятся использовать для этой цели Интернет.
Поддержка стандартов TMN и интерфейса О декларируется практически всеми ведущими разработчиками платформ эксплуатационного управления: Hewlett-Packard, Digital, Sun, Cabletron, IBM, TTI. Этому же, оборудование новых технологий SDH, АТМ, ADSL, WLL и др. сегодня выпускается со встроенной поддержкой интерфейса Q.
Стандарты TMN дают более или менее, детальное описание интерфейса Q для трех верхних уровней OSI. Для нижних уровней рекомендуются распространенные протоколы Х25, Х31, MTP и SCCP ОКСО, TCP/IP и др.
В качестве сетевого средства передачи информации в распределенной среде всё чаще применяют программную шину ORB, предусмотренную архитектурой CORBA. В ITU-Т серьезно рассматривается вопрос о введении архитектуры CORBA как альтернативного средства поддержки интерфейса Q. CORBA дает возможность обеспечивать связь между распределенными по сети объектами c, использованием объектно-ориентированного подхода. Именно это было заложено в протокол CMIP, не принятый компаниями-производителями в качестве магистральной компьютерной технологии. Что касается CORBA, задачей которой является обеспечение работы и взаимодействия разнородных (написанных на разных языках) приложений в распределенной среде, то доступность и дешевизна этого альтернативного средства делают его предпочтительным для использования в TMN. В среде разработчиков TMN уже имеется шутливое, но не лишенное оснований мнение: нужно просмотреть все стандарты для TMN и везде вычеркнуть упоминание о протоколе GMIP, поменяв его на CORBA.
В заключение отметим еще одно направление в. среде программирования для TMN: создание преобразований информационных структур и протоколов друг в друга (рис. 10.6). Наличие подобных преобразований делает бессмысленным спор о том, какому языку реализации отдать предпочтение: нужно пользоваться тем, что дешевле, более знакомо и есть под рукой.
10.7. Системы эксплуатационной поддержки OSS
Рассмотренные в предыдущих параграфах технологии внедрены в новейших разработках OSS, одну из которых иллюстрирует рис. 10.7. Система реализует полный набор функций эксплуатационного управления, включая контроль рабочих характеристик, работу с неисправностями, управление конфигурацией, подготовку и ввод новых ресурсов, анализ результатов учета и контроль уровня предоставления услуг.
В контексте этой книги обратим внимание лишь на два элемента QSS такого рода: мониторинг функционирования рассмотренной в главе 8 сети сигнализации ОКСО и задачи технического обслуживания сети абонентского доступа, рассмотренной в главе 7.
Система мониторинга сети сигнализации ОКСО, стандартом де-факто для которой в ВСС РФ является комплекс СПАЙДЕР, содержащий специализированные зонды сигнализации ISUP, ТСАР, МАР, INAP, а также DSS1/PRA, V5.х, A-bis и др., которые отслеживают трафик в разных пунктах сигнализации сети ОКС, и центр наблюдения и контроля, в котором собираются данные со всех пунктов сигнализации этой сети. Рекомендации ITU-Т серии О.750 детализируют общие объектно-ориентированные принципы наблюдения за открытыми системами применительно к технической эксплуатации сетей ОКСО и выделяют три основные группы функций: а) функции, относящиеся к многоуровневой архитектуре TMN; б) функции, являющиеся частью протокола самой системы сигнализации ОКСО, например, переключение на резервное сигнальное звено или принудительная ре маршрутизация; в) функции, необходимые для проверки правильности таблиц маршрутизации, кодов идентификации каналов и т.п., поддержка которых требует отдельного прикладного протокола. С учетом тематики главы рассмотрим только группу функций а), классификация которых приведена на рис. 10.8.
Для реализации этих функций Рекомендациями Q.750-Q.754 определена специальная прикладная подсистема ОМАР (Operation, Maintenance and Administration Part) и связанные с ней группы функций эксплуатационного управления.
Группа функций работа с неисправностями (Fault Management) обеспечивает обнаружение и исправление ситуаций нештатного функционирования сети ОКС7 и включает в себя:
• обработку аварийных ситуаций, например, отказа пучка сигнальных звеньев, ведущего к недоступности пункта сигнализации;
• активизацию проведения тестов или необходимых измерений;
• сбор статистики о состоянии сети сигнализации для проведения превентивных мер технического обслуживания;
• сбор статистики о состоянии элементов сети с целью обнаружить возможность возникновения критического режима работы. Неисправности отдельных элементов могут привести к тому, что вся сеть ОКС7 окажется неспособной работать с необходимым качеством. Явно «видимые» неисправности ведут к неспособности обслужить в требуемом объеме сигнальный (а как следствие, и разговорный) трафик, а скрытые» неисправности снижают надежность работы сети.
Группа функций управление конфигурацией (Configuration Management) поддерживает управление ресурсами, сбор данных о сети сигнализации и ее компонентах, позволяет задавать статическую конфигурацию сети ОКС, включая активизацию элементов, и изменять конфигурацию сети во время работы, а также предусматривает индикацию изменений статической конфигурации во время работы. Среди основных функций этой группы — формирование маршрутных таблиц в соответствии с заданным оператором сети планом маршрутизации; формирование и активизация пучков сигнальных звеньев и отдельных звеньев внутри пучков, проверка правильности имен сетевых ресурсов между смежными пунктами сигнализации (например, SLC и CIC).
Группа функций контроль рабочих характеристик (Performance Management) обеспечивает сбор статистических данных с целью оценить динамику изменений состояния сетевых элементов и эффективность работы сети в нормальных условиях и в условиях перегрузки и включает в себя активизацию измерений и сбор результатов измерений за короткие (5 мин) и длительные (30 мин) периоды. Сюда же входит наблюдение за авариями, за использованием пучков звеньев и сигнальных маршрутов, а также управление сигнальным трафиком в реальном времени (например, модификация маршрутных таблиц и активизация дополнительных сигнальных звеньев и пучков звеньев).
Представленная на рис. 10.9 базовая конфигурация системы мониторинга и анализа сети ОКСО содержит центральный модуль, где находится упоминавшаяся выше централизованная база данных MIB с информацией об объектах наблюдения, на основе которой создается графическое отображение структуры сети с разными уровнями детализации, и удаленные модули, которые ведут сбор информации, получаемой от отдельных элементов сети ОКС.
Вторым из упоминавшихся в этом параграфе элементов OSS является программно-аппаратная платформа централизованного бюро ремонта (ЦБР), для которого аналогичным стандартом де-факто является система АРГУС. Структура ЦБР АРГУС представлена на рис. 10.10 и состоит из трех систем: а) система программного управления, включающая в себя базу данных сети абонентского доступа, б) измерительные программно-аппаратные комплексы ДИПАЛ и в) центр распределения вызовов ПРОТЕЙ.
К основным функциям ЦБР относятся:
прием, регистрация и оперативное обслуживание заявок, поступающих от абонентов или от линейных монтеров кабельной сети связи, и выдача справок о результатах выполненных работ;
диспетчеризация заявок на текущий ремонт, регистрация неисправностей и формирование нарядов;
тестирование абонентских линий и абонентских установок;
информационная и техническая поддержка деятельности цеха технического обслуживания абонентов, деятельности линейно-кабельного цеха, деятельности станционного цеха (кросса), а также процессов индивидуального и/или массового включения/ выключения телефонных номеров по техническим и административным причинам;
автоматическое формирование и печать необходимых статистических документов, данных для оценки качества предоставляемых услуг и других отчетных документов;
учет, планирование и контроль выполнения профилактических, ремонтных и аварийных работ подразделениями административного узла, обеспечивающими техническую эксплуатацию устройств и сооружений телефонной сети.
Функциональные возможности этих двух элементов современных OSS шире функциональных задач эксплуатационного управления в любой отдельно взятой АТС и заслуживают более подробного рассмотрения в отдельной книге.