Проектирование и расчет фрагментов модельной системы технической эксплуатации

Интерфейс Q 3характеризуется частью информационной модели, которая разделяется в знаниях между операционной системой (OS) и теми элементами TMN, с которыми она имеет прямую связь.Интерфейс Q X характеризуется частью информационной модели, которая разделяется между медиаторами и теми сетевыми элементами и Q-адаптерами, которые он поддерживает.Интерфейс X поддерживает взаимосвязь TMN и других внешних систем, включая иные TMN, а также используется для управления предоставлением коммерческих услуг. Это возможно при наличии в соответствующих системах интерфейсов, взаимодействующих с TMN. Для передачи информации во внешнее окружение уровень информационной безопасности для X-интерфейса должен быть выше, чем для Q-интерфейса. По аналогии с Q-интерфейсом X-интерфейс определяет для внешних систем видимую часть “айсберга” TMN и порядок доступа к её ресурсам.F-интерфейс позволяет соединить рабочую станцию WS и физические блоки TMN, которые поддерживают реализацию OSF и TF. Соединение осуществляется через сеть передачи данных. В настоящее время интерфейс F определён рекомендацией M.3300.4.2Протокол управления оборудованием SNMP4.2.1 Характеристика протокола SNMPSNMP - это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (ManagementInformationBase). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB II. Кроме того, сам протокол SNMP также весьма несложен.Агент в протоколе SNMP - это обрабатывающий элемент, который обеспечивает менеджерам, размещенным на управляющих станциях сети, доступ к значениям переменных MIB и тем самым дает им возможность реализовывать функции по управлению и наблюдению за устройством.Основные операции по управлению вынесены в менеджер, а агент SNMP выполняет чаще всего пассивную роль, передавая в менеджер по его запросу значения накопленных статистических переменных. При этом устройство работает с минимальными издержками на поддержание управляющего протокола. Оно использует почти всю свою вычислительную мощность для выполнения своих основных функций маршрутизатора, моста или концентратора, а агент занимается сбором статистики и значений переменных состояния устройства и передачей их менеджеру системы управления.SNMP - это протокол типа «запрос-ответ», то есть на каждый запрос, поступивший от менеджера, агент должен передать ответ. Особенностью протокола является его чрезвычайная простота - он включает в себя всего несколько команд.- Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.- Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.- С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.- Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие - отключить порт, приписать порт определенной VLAN и т. п. Команда Set пригодна также для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.- Команда Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.- Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.4.2.2 Описание сообщения Get_requestСообщения SNMP, в отличие от сообщений многих других коммуникационных протоколов, не имеют заголовков с фиксированными полями. В соответствии с нотацией ASN.1 сообщение SNMP состоит из произвольного количества полей, и каждое поле предваряется описателем его типа и размера.Любое сообщение SNMP состоит из трех основных частей: версии протокола (version), идентификатора общности (community), используемого для группирования устройств, управляемых определенным менеджером, и области данных, в которой собственно и содержатся описанные выше команды протокола, имена объектов и их значения. Область данных делится на блоки данных протокола (ProtocolDataUnit, PDU).Рисунок 4.4 – Формат SNMP-сообщенийSNMP предоставляет следующие пять основных операций:- операция Get: операция Get-это запрос, отправленный NMS агенту для получения одного или нескольких значений от агента.-  операция GetNext: операция GetNext-это запрос, отправленный NMS для получения значения следующего OID в дереве.- операция набора: операция набора-это запрос, отправленный NMS агенту для установки одного или нескольких значений агента.- операция ответа: операция ответа является ответом, отправленным агентом в NMS.- операция прерывания: операция прерывания является незапрошенным ответом, отправленным агентом для уведомления NMS о произошедших событиях.Устройство отправляет первые четыре типа пакетов на UDP-порт 161, а агент отправляет ловушки на UDP-порт 162. Используя два разных номера портов, одно устройство может одновременно выступать в качестве агента и NMS.Рисунок 4.5 - Взаимодействие клиент-сервера SNMP. Приведены все пять типов сообщений.При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:Если имя переменной не совпадает в точности с именем одной из переменной, доступных для операции get в нашей MIB, передаем отправителю запроса аналогичное PDU GetResponse, указывая в поле кода ошибки значение noSuchName (2-нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении (=1, в SNMPv1 - ограничение данной реализации SNMP).Если размер PDU GetResponse, созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение (Реализация SNMP не обязана принимать сообщения, размер которых превышает определенное значение. Однако по возможности желательна поддержка дейтаграмм больших размеров (RFC1157 SNMP).), передаем отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение TooBig, а в поле error-index — 0. Это обычно происходит, если запрошено больше 1 переменной или длина PDU или общая длина пакета больше стандартных пределов.Если для любой переменной, содержащейся в поле связанные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, SNMP агент передает отправителю аналогичное PDU GetResponse, указав в поле error-status значение GenErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.Если все нормально, передаем SNMP менеджеру, отправившему полученное сообщение, ответ - GetResponse, в котором для каждой переменной в поле связанные переменные подставлены запрошенные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.Пример использования GET запросаВ примере показана простая HTML форма фильтра по нескольким параметрам.HTML код формы, генерирующей GET запрос:После отправки формы браузер переведет пользователя по ссылке:Ссылка содержит URL документа, отвечающего за обработку и блок параметров. Знак "?" отмечает начало блока параметров GET запроса. Далее находятся пары "имя-значение", разделенные знаком "&". Имена параметров отделены от значений знаком "=".Переход по ссылке, приведенной выше, будет равнозначен отправке формы с указанными параметрами.4.2.3 Анализ трассировки с помощью Wiresharkсообщений в рамках сценария 4.2.4 Пример обработки дерева MIBManagementInformationBase (MIB, база управляющей информации) - виртуальная база данных, используемая для управления объектами в сети связи. Наиболее часто это понятие связывают с SimpleNetworkManagementProtocol (SNMP), но также оно используется в более широком смысле - в контексте модели управления сети OSI/ISO. Хотя термин MIB предназначен для обозначения всей доступной информации об объекте, он также часто используется для обозначения конкретного подмножества, которое правильнее называть MIB-модулем.Объекты в MIB, согласно RFC 2578, определяются с помощью подмножества "StructureofManagementInformationVersion 2" (SMIv2) стандарта ASN.1. Программное обеспечение, выполняющее разбор, называется MIB-компилятором.База данных имеет иерархическую (древовидную) структуру. К записям можно обратиться через идентификаторы объектов (англ. objectidentifier, OID). Базы MIB обсуждаются в документациях RFC, в частности в RFC 1155 и сопутствующих ему RFC 1213 и RFC 1157.Рисунок 4.6 – Примеры деревьев MIB4.3 Расчет параметров контроля элемента сети1) Рассчитать допустимое количество отказавших функциональных блоков (ФБ) системы коммутации, наличие которых не ухудшает ниже допустимого качество обслуживания нагрузки.2) Определить оптимальный период контроля работоспособности для каждого типа ФБi, i = 1…11.3) Выбрать и обосновать надлежащий метод технического обслуживания, для каждого типа ФБ. Исходные данные:ФБ1Ri/ViФБ2Ri/ViФБ3Ri/ViФБ4Ri/ViФБ5Ri/ViФБ6Ri/ViФБ7Ri/ViФБ8Ri/ViФБ9Ri/ViФБ10Ri/ViФБ11Ri/Vi700/662600/501390/285370/3731200/627101/19106/21230/5930/10800/87200/17РД, i0,90,990,990,990,6----0,90,9КУП, i1,51,521,71,61,41----1,7-τПР, i, ч-----1,120,510,670,491,690,72ТККМ, СУТ9090303090151515151010Y, Эрл3702801802101750------Авт.конт.естьнетестьнетестьнетестьестьестьестьПродолжительность сбора статических данных о неисправностях составляет 5 лет.РешениеРасчет допустимого количества отказавших устройствНеисправности, появляющиеся в оборудовании станции, приводят к увеличению потерь вызовов. Основная задача системы техобслуживания – обнаруживать неисправности, определять их место и причину, а затем устранять неисправности. При этом возможно наличие некоторого количества неисправностей, когда потери еще не превышают допустимую величину. Требуется оценить возможность накопления нескольких неисправностей, чтобы при этом потери были ниже допустимой нормы. Особенно это важно при централизованной эксплуатации. С точки зрения влияния отказов на потери вызовов оборудование систем коммутации можно разделить на два вида:1. Блоки входящие в тракт переноса (передачи) пользовательской информации. Например, приборы разговорного тракта в АТСК: ИШК, ВШК, РСЛВ, РСЛИ, МКС; оборудование ЦКП в цифровых системах коммутации с TDM или элементы оборудования уровня IP-транспорта, медиашлюзов и доступа в структуре сети NGN/IMS, в частности такие сетевые элементы как SBC, MGW.2. Блоки управления, в том числе эксплуатационного, серверы приложений. Например, управляющие устройства (маркеры и регистры) в АТСК; блоки подсистем управления и сигнализации в СК с TDM; оборудование уровня управления и приложений: CSCF, AS в домене IMS. Потери вносимые одним отказывающим прибором разговорного тракта Р0,i можно оценить следующим соотношением:,гдеVi – количество приборов оборудования i-го вида.Отказавшие приборы разговорного тракта, как правило, сразу не блокируются, продолжают участвовать в обслуживании вызовов. Это явление называется “ложным обслуживанием”. Причем время занятия неисправного прибора меньше времени занятия исправного, то есть справедливо соотношение:tЗНtЗИ,гдеtЗН – время занятия неисправного прибора,tЗИ – время занятия исправного прибора.Для того, чтобы учесть увеличение потерь, вносимых отказавшим незаблокированным прибором разговорного тракта с учетом данного соотношения, используется коэффициент увеличения потерь КУП,i. Тогда уточненные потери, вызванные отказом одного прибора, определяются следующим образом:Р0,i,У = Р0,i∙КУП,iЗначение коэффициента КУП зависит от величины удельной нагрузки на данный вид оборудования и задан в исходных данных.Р0,ФБ1,У = 0,151∙1,5 = 0,227%Р0,ФБ2,У = 0,199∙1,52 = 0,302%Р0,ФБ3,У = 0,351∙1,7 = 0,597%Р0,ФБ4,У = 0,268∙1,6 = 0,429%Р0,ФБ5,У = 0,159∙1,41 = 0,224%Далее полученные значения Р0,i,Усравниваются для каждого вида оборудования с допустимой проектной нормой РД,i,Допустимое количество неисправных приборов определяется как.4.3.2 Определение оптимального периода контроляПериод контроля ТКопределяется методом подбора с помощью соотношения:гдеi – интенсивность отказов:;Т – продолжительность сбора статистики:Т = ∙ с ∙ ч;Т0 – среднее время наработки на отказ:;ТПР – время проверки устройств данного типа:ТПР = ПР,i ∙Vi;ПР,i - время проверки одного устройства данного типа.Т = 5 ∙ 365 ∙ 24 = 43800 ч4.3.3 Определение оптимального периода контроля для приборов разговорного тракта Оптимальный период контроля для приборов разговорного тракта рассчитывается методом подбора по формуле:,где= 0,001,m = VДОП, i.ТК ФБ1= 17000 ч = 708 сутТК ФБ2 = 13000 ч = 542сутТК ФБ3 = 1400 ч = 58сутТК ФБ4 = 8000 ч = 333сутТК ФБ5 = 4300 ч = 179сут4.3.4 Выбор надлежащего метода техобслуживанияВ настоящее время на телефонных сетях существуют следующие методы технического обслуживания:- профилактический;- восстановительный;- контрольно-корректирующий (ККМ).Выбор метода ТО определяется следующими основными факторами:- надежностью оборудования (надежность характеризуется интенсивностью отказов i ТК);- наличием автоматических средств контроля и диагностики;- особенностями построения и функционирования контролируемого оборудования.При выполнении контрольного задания для выбора метода ТО сравним найденное значение ТК с заданным значением ТККМ. Если ТК ТККМ, то может быть использован метод ККМ. Если ТК ТККМ, то выбирается профилактический метод.Результаты выбора метода ТО представлены в таблице 4.1.Таблица 4.1 – Выбор метода ТОВид оборудованияТК, сутокТККМ, сутокНаличие средств автоматического контроляМетод ТОФБ170890АвтотренерККМФБ254290АвтотренерККМФБ35830АвтотренерККМФБ433330АвтотренерККМФБ517990АвтотренерККМФБ624,215УАКККМФБ717,915УАКККМФБ839,215УАКККМФБ91515УАКККМФБ1047,510УАКККМФБ1112,110УАКККМСПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫСамуйлов К. Е., Серебренникова Н.В., Чукарин А.В., Яркина Н.В. Системы следующего поколения для поддержки операционной деятельности инфокоммуникационной компании: Учеб. пособие. – М.: РУДН, 2008. – 123 с.: ил. 2. А.А. Атцик, А.Б. Гольдштейн, М.А.Феноменов. ЭКСПЛУАТАЦИОННОЕ УПРАВЛЕНИЕ ИНФОКОММУНИКАЦИЯМИ: учебное пособие / ГОУВПО СПбГУТ. СПб,2013 – 68 с. http://niits.ru/public/metod/3. Проектирование и техническая эксплуатация цифровых телекоммуникационных систем и сетей. Учебное пособие для вузов / Е.Б. Алексеев и др.; Под редакцией В.Н. Гордиенко.- М.: Горячая линия – Телеком, 2008. – 392 с. 4. Бизнес-процессы и информационные технологии в управлении современной инфокоммуникационной компанией / А.В. Чукарин, К.Е. Самуйлов, Н.В. Яркина. - M. : Альпина Паблишер, 2016. - 512 с. 5. Лекции Шалаев А.Я. 6. К.Е. Самуйлов, Н.В. Серебренникова, А.В. Чукарин, Н.В. Яркина. Расширенная карта процессов деятельности телекоммуникационной компании. Учебное пособие, М.: РУДН, 2008. – 183 с. http://web-local.rudn.ru/web-local/uem/iop_pdf/10-Samulov.pdf7. Теория и практика автоматизации бизнес-процессов современного оператора связи : учебное пособие / АтцикА.А.,ГольдштейнА.Б.,Никитин А.В. СПбГУТ., 2016.-92 с. http://rt-itt.sut.ru/sites/default/files/docs/metod-bk/30_atcik_goldshteyn_nikitin.pdf8. Надежность и техническое обслуживание АМТС с программным управлением. Справочное. пособие/Под ред. Дедоборща В.Г. и СуторихинаН.Б.-М.:Радио и связь,1989. 9. Гребешков А.Ю. Управление сетями электросвязи по стандарту TMN: Учеб. Пособие.- М.: Радио и связь, 2004. 155 с. http://aes.psuti.ru/wp-content/uploads/2010/03/GrebeshkovAUTMN.pdf