Глава 3. Тестирование протоколов MTP
3.1 Основные принципы тестирования
Для проверки корректности реализации протоколов MTP требованиям соответствующих стандартов на систему сигнализации ОКСО существуют спецификации двух типов тест к проверки соответствия (VAT, validation) и проверки совместимости (CPT, compatibility).
Тесты соответствия (VAT) предназначены для проверки реализации одного протоки в тестируемой системе на соответствие спецификациям международных или национальных стандартов.
Тесты совместимости (CPT) предназначены для проверки правильности взаимодействия двух или более реализаций одного протокола, выполненных в соответствии со спецификациями международных или национальных стандартов.
Тесты VAT всегда предшествуют проверке совместимости CPT и выполняются в лунами сигнализации, не находящемся в обслуживании. Для выполнения тестов VAT необходимо использовать симулятор встречного пункта сигнализации. В тестовых спецификациях тестируемый пункт сигнализации обозначается как SP «А».
Целью тестов CPT является проверка корректности взаимодействия между реализациями протокола в пунктах сигнализации разных производителей или при замене версии программного обеспечения в одном из взаимодействующих пунктов одного производителя, Тестирование совместимости может проводиться не только во вновь вводимом пункте сигнализации, но также и в пункте, уже введенном в обслуживание. При проведении тестов CPT все входящие в тестовую конфигурацию пункты сигнализации представляют собой одну тестируемую систему, и любой из них может рассматриваться в тестовых спецификациях как SP «А».
При разработке тестовых спецификаций протокола МТР используются следующие критерии:
• тесты не должны оказывать влияния на тестируемую реализацию;
• требования к тестированию должны быть независимы от применяемых средств тестирования.
Перечень рекомендаций МСЭ-Т по проведению тестирования подсистемы МТР:
• Q.781: Тестовые спецификации уровня МТР2 (проверки соответствия Q.703).
• Q.782: Тестовые спецификации уровня МТРЗ (проверки соответствия Q.704 — Q.707). В тестовых спецификациях для выбранного уровня МТР подразумевается, что протоколы нижележащих уровней в тестируемой системе реализованы корректно, и поэтому указанные в спецификации тесты касаются только протокола уровня, подлежащего тестированию. Тестовые спецификации предназначены для проверки основных функций рассматриваемого протокола, включая поведение системы в нормальных и нештатных ситуациях.
3.1.2.1 Структура рекомендаций по тестированию
Каждая рекомендация по тестированию протокола одной из подсистем ОКС7 содержит следующие разделы:
• Введение, в котором дается общий обзор тестовой спецификации.
• Область применения, где перечисляются функции, подлежащие тестированию.
• Цели тестирования, где объясняются базовые принципы выбора перечня тестов или
тестовых конфигураций.
Тестовая среда, где описываются необходимые для проведения тестов внешние контрольно-измерительные устройства.
Тестовая конфигурация, где описываются конфигурации пунктов сигнализации и сигнальных звеньев или сигнальные связи, необходимые для проведения тестов.
ПРЕДСТАВЛЕНИЕ ТЕСТОВОЙ НАГРУЗКИ, где иллюстрируется формат сообщений для тестирования, например, тип адреса и содержимое отдельных полей данных.
ПЕРЕЧЕНЬ ТЕСТОВ, где представлен список тестов, сгруппированных по определенным критериям.
ОПИСАНИЕ ТЕСТА, где приводится подробное описание теста, включая его заголовок, цель, предварительные условия, конфигурацию, типы пунктов сигнализации, тип
теста, ссылки на соответствующие параграфы рекомендаций по данному просто стрелочные диаграммы последовательности сообщений.
Тестовые конфигурации для тестов типов VAT и СРТ схожи, но не идентичны.
При проведении тестов VAT тестируемый пункт включается в тестовую среду и становиться частью тестовой конфигурации. Тестовая конфигурация при этом должна удовлетворять следующим трем критериям:
• тестируемый пункт подсоединяется к тестовой среде одним или несколькими пучками звеньев;
• имеется возможность генерации и приема тестовой нагрузки;
• имеются возможности выполнения теста и средства хранения и подробного анализа сообщений.
При проведении тестов СРТ все пункты сигнализации объединяются в одну большую тестируемую систему, которая должна удовлетворять следующим четырем требованиям:
• пункты тестируемой системы соединяются друг с другом одним или несколькими пучками звеньев;
• имеется возможность генерации и приема тестовой и реальной нагрузки;
• имеются возможности выполнения тестов, заданных спецификациями по тестированию, и средства хранения и подробного анализа сообщений;
• имеются возможности мониторинга процесса обслуживания вызова и наблюдения за каналами.
3.2 Принципы тестирования подсистемы МТР
3.2. 1 Элементы тестовой среды
Симулятор уровня MTP3 — это необходимое для проведения тестирования уровня MTP2 средство, позволяющее передавать сообщения и индикации состояния от/к тестируемому уровню MTP2. Желательно, чтобы используемые в симуляторе функции были наиболее близки к реальным функциям уровня MTP3, а также чтобы имелись дополнительные возможности, необходимые для тестирования.
Симулятор тестов уровня MTP2 — это средство, позволяющее при тестировании уровня MTP2 передавать как правильные, так и некорректные сигнальные единицы. Дополнительно симулятор тестов должен принимать и проверять сигнальные единицы, поступающие от тестируемого уровня MTP2, а также генерировать определенные нештатные последовательности сигнальных единиц.
Симулятор верхних уровней — средство, дающее возможность при тестировании уровня MTP3 подавать на этот уровень сигнальные сообщения с целью имитировать определенные ситуации, например, ситуации потери сообщения во время перехода на резервное звено. Желательно, чтобы используемый симулятор как можно ближе соответствовал реальной под- системе верхнего уровня.
Симулятор сети сигнализации совместно с симулятором тестов уровня MTP3 представляют собой средство, позволяющее при тестировании уровня MTP3 формировать как правильные, так и некорректные сообщения для передачи к встречному пункту сигнализации. Симулятор тестов должен принимать и проверять сообщения, поступающие от тестируемого уровня MTP3, а также предоставлять возможность генерации определенных нештатных последовательностей сообщений.
Монитор сигнального звена — это оборудование, которое используется при тестировании для подробного декодирования сигнальных единиц. Требования к степени подробности декодирования для двух типов тестов могут различаться. Так, при проведении тестов соответствия требуется подробная расшифровка всех полей сообщений, а при проведении тестов соответствия достаточно бывает расшифровки только на уровне сообщений.
3.2.1.1 Принципы тестирования МТР1
Спецификация тестирования уровня МТР1 подразумевает наличие звена передачи данных, обладающего характеристиками и значениями параметров, определенными в рекомендациях МСЭ Q.702 и G.821.
3.2.1.2 Принципы тестирования MTP2
3.2.1.2.1 Тесты соответствия уровня MTP2
Среда для проведения тестов соответствия реализации MTP2 содержит следующие элементы (рисунок 3-1):
• симулятор MTP3;
• симулятор тестов МТР2;
• монитор сигнального звена;
• звено передачи данных.
3.2. 1.2.2 Тесты совместимости MTP2
При проведении тестов СРТ уровня MTP2 предполагается, что обе реализации прошли тестирование их соответствия спецификации. Тестовая среда для проведения тестов совместимости реализаций MTP2 содержит следующие элементы (рисунок 3-2):
• симуляторы МТРЗ;
• две разные реализации (А и В) уровня МТР2;
• монитор сигнального звена;
• звено передачи данных сигнализации.
3.2.1.3 Принципы тестирования MTP3
3.2.1.3.1 Тесты соответствия MTP3
При проведении тестов соответствия уровня MTP3 предполагается, что реализация
уровня MTP2 успешно прошла тестирование ее соответствия спецификации. Тестовая среда для проведения тестов соответствия уровня MTP3 содержит следующие элементы (рисунок 3-3):
• симулятор верхних уровней;
• симулятор сети, включая симулятор тестов и звенья передачи данных;
• монитор(ы) сигнального звена.
3.2.1.3.2 Тесты совместимости MTP3
При проведении тестов совместимости уровня MTP3 предполагается, что реализации уровня MTP2 и уровня MTP3 в обеих подсистемах, совместимость которых проверяется, соответствуют спецификациям. Тестовая среда для проверки совместимости уровня MTP3 содержит следующие элементы (рисунок 3-4):
• симуляторы верхних уровней;
• реализации (А и В) уровня МТР2;
• реализации (А и В) уровня МТРЗ;
• звенья передачи данных;
• монитор(ы) сигнального звена.
3.3.1 Тестовая конфигурация и перечень тестов
Для проведения тестов уровня 2 используется одно сигнальное звено между пунктами сигнализации SP А и SP В. Тестируемый уровень MTP2 находится в пункте сигнализации SP А (рисунок 3-5).
В описаниях тестов сигнальные звенья обозначаются двумя цифрами по следующему шаблону: «номер пучка сигнальных звеньев» — «номер звена в пучке» (например, 1 — 1 означает Звено 1 в пучке 1). Это обозначение не зависит от идентификатора звена SLC.
Набор тестов уровня MTP2 предназначен для проверки реализации уровня 2 в тестируемой системе. Каждый тест обеспечивает проверку одной из элементарных функций протокола. Ниже приводится полный перечень тестов, в котором тесты совместимости отмечены как CPT. Полное описание далее будет приведено только для тестов CPT, как наиболее часто проводимых при технической эксплуатации сети ОКСО.
Использование сокращений:
Sl (status indication) — индикатор статуса,
PO (processor outage) — отказ процессора,
(L)PO (local processor outage) — отказ локального процессора,
(R)PO (remote processor outage) — отказ удаленного процессора,
ЕМ (emergency delay of acknowledgement) — аварийная задержка подтверждения,
EDA (expected delay of acknowledgement) — ожидаемая задержка подтверждения.
3.3.2. Описание тестов совместимости МТР2
Тесты уровня МТРЗ предназначены для проверки правильности реализации протокола соответствии со спецификациями, описанными в рекомендациях МСЭ-Т Q.704 и Q.707, При тестировании требуется обеспечить тестовую нагрузку между тестируемым пунктом сигнализации тестовым окружением. Для этого используются сообщения переменной для структурой, приведенной на рисунке 3-6.
При проведении тестов уровня MTP3 предполагается, что тестируемый пункт сигнализации помещается в тестовое окружение, называемое тестовой конфигурацией. В описании Каждого теста указывается тип тестовой конфигурации, согласно которой ведется проверка. Для выполнения всех тестов требуется четыре типа тестовых конфигураций: А, В, С и О. В каждом тесте указывается тип пункта сигнализации, для которого проводится проверка. Возможны три варианта:
• тест применим для пункта сигнализации без функций транзита: SP
• тест применим для пункта сигнализации с функциями транзита: STP
• тест применим для пунктов сигнализации всех типов: ВСЕ
В описаниях тестов сигнальные звенья обозначаются двумя цифрами по следующему
шаблону: «номер пучка звеньев» — «номер звена в пучке» (например,1 — 1 означает звено в лучке 1). Это обозначение не зависит от идентификатора звена SLC.
Когда номер звена указывается как Х, это означает, что сообщение может использовать любое звено в пучке. Когда в поле «номер звена в пучке» указывается последовательность цифр, например «1, 2, ...», это означает что все указанные звенья используются для обслуживания сигнального трафика. Когда звенья идентифицируются как ВСЕ, это означает, что для обслуживания трафика могут быть использованы все звенья данного пункта сигнализации.
Эта конфигурация предназначена для тестирования всех процедур, относящихся к одному или более сигнальным звеньям, входящих в один и тот же пучок. Конфигурация А (рисунок 3-7) используется в следующих группах тестов:
- включение в работу и выключение из работы сигнальных звеньев;
- процедуры перехода на резервное звено и обратно;
- запрет и отмена запрета доступа к сигнальным звеньям;
- прием неправильных сообщений.
Пучок звеньев 1 (L1) содержит четыре сигнальных звена для проверки, например, процедур перехода на резервные звенья в пределах одного пучка.
В конфигурации А пункт сигнализации SP С используется во всех тестах соответствия и не используется в тестах совместимости.
Процедуры, проверяемые с помощью конфигурации А, воздействуют на обслуживанию рассматриваемым звеном трафика в обоих направлениях, поэтому потоки тестового трафик маршрутизируются согласно маршрутной этикетке следующим образом:
• ОРС=А, DPC=B и ОРС=В, DPC=A
• ОРС=А, DPC=C и ОРС=С, ОРС=А (только для тестов VAT).
Конфигурация В используется для тестирования всех процедур, относящихся к нескольким пучкам сигнальных звеньев. Конфигурация В (рисунок 3-8) используется в следующих группах тестов:
• обработка сигнальных сообщений;
• переход на резервное звено и обратно;
• принудительная и управляемая ремаршрутизация.
В конфигурации В тестируемый пункт SP А соединяется с внешним окружением тремя пучками сигнальных звеньев. Это минимально необходимое количество пучков для проверки функций разделения нагрузки между пучками и перехода на резервный пучок и обратно.
Данная конфигурация использует пункт SP D во всех тестах соответствия и не использует его в тестах совместимости.
Некоторые процедуры (переход на резервное звено и обратно), проверяемые с помощью этой конфигурации, воздействуют на обслуживание рассматриваемыми пучками звеньев трафика в обоих направлениях передачи, поэтому потоки тестового трафика маршрутизируются согласно маршрутной этикетке следующим образом:
• ОРС=А, DPС=Е и ОРС=Е, DРС=А
• ОРС=А, DРС=D и ОРС=D, DРС=А (только для тестов VAT).
Конфигурация С (рисунок 3-9) используется для проверки некоторых функций, характерных для транзитного пункта сигнализации:
• функция транзитной передачи сообщений;
• передача сообщения TFC;
• тест нагрузки.
В конфигурации С тестируемый пункт SP А пропускает тестовый трафик, направляемый от пункта SP В к пункту SP С и от пункта SP С к пункту SP В.
Пучок звеньев L1 содержит два звена, что является минимально необходимой конфигурацией для создания ситуации перегрузки, при которой можно организовать передачу TFC независимо от того, реализована или нет процедура управления потоком.
Для выполнения тестов при помощи данной конфигурации, требуется, чтобы трафик проходил через STP в обоих направлениях, поэтому потоки тестового трафика маршрутизируются согласно маршрутной этикетке:
• ОРС=В, ОРС=С и ОРС=С, DPC=B.
Конфигурация D (рисунок 3-10) предназначена для проверки соответствия реализации
тех процедур управления сигнальными маршрутами, которые относятся исключительно к транзитным пунктам сигнализации.
Конфигурация используется только для проверки процедур запрета и входящих в функции управления сигнальными маршрутами, поэтому все пучки конфигурации содержат только по одному звену.
Тестируемый пун кт SP А (типа STP) подсоединяется к внешнему окружению тремя звеньев: один пучок — к пункту без транзитных функций, и два пучка — между пунктом ST двумя другими STP. Такая структура является минимально необходимой для проверки раза, аспектов передачи сообщений TFP и TFA.
Рассматриваемая конфигурация включает в себя пункты SP D и SP Е, что необходимо для проверки передачи сообщения TFP по альтернативному пучку: правила для пункта STP А таковы, что пучки и L2 определены для доступа к пункту SP D основного/альтернативного маршрутов, а для доступа к пункту SP Е — с использованием режима разделения нагрузки, поэтому передача сообщения TFP применяется в первом случаях и не применяется во втором.
Для выполнения проверки процедур сигнальных маршрутов в данной конфигурации требуется, чтобы тестовый трафик проходил по нужным сигнальным маршрутам, поэтому необходимо использовать маршрутную этикетку следующего вида:
• OPC=F, DPC=D, OPC=D, DPC=F
• OPC=F, DPC=E, ОРС=Е, DPC=F
• ОРС=А, DPC=D, ОРС=А, DPC=E
Тесты совместимости в приводимом ниже перечне отмечены как СРТ. Полное описание будет приведено далее только для тестов СРТ, как наиболее часто проводимых при технической эксплуатации сети сигнализации.
Первая группа тестов нацелена на проверку способности тестируемого пункта сигнализации выполнять основные функции, т.е. связываться с внешним окружением и обмениваться сигнальными сообщениями.
Вторая группа тестов нацелена, в основном, на проверку выполнения функции обработки сигнальных сообщений тестируемым пунктом сигнализации. Главный акцент здесь делается на проверку правильности выполнения процедур разделения нагрузки.
3.4.3 Описание тестов совместимости
Глава 4. Тестовое оборудование
4.1 Принципы и архитектура аттестационного тестирования
В условиях современного рынка средств связи, на котором присутствуют много различных поставщиков, решающим фактором качественной совместной работы коммутационного оборудования разных производителей, является совместимость коммуникационных протоколов. В связи с этим особо актуальной становится наличие специализированных инструментальных средств для тестирования разных реализаций протоколов МТР с целью определить, отвечает ли та или иная реализация требованиям национальных и/или международных спецификаций.
Сложность этой задачи обусловлена и сложностью самих задаваемых стандартами протоколов, и допускаемой стандартами многовариантностью реализаций протоколов, и рядом ограничений, которые накладывают на возможности и способы тестирования особенности тестируемых реализаций. Корректность взаимодействия коммутационных систем одного и того же производителя означает всего лишь то, что протоколы, реализованные в оборудовании этого производителя, работоспособны. Но для корректного взаимодействия систем разных производителей нужно, чтобы реализация протоколов в каждой из них соответствовала эталонным спецификациям, определенным международными и национальными стандартами.
Протоколы МТР системы сигнализации ОКСО структурированы по уровням. Распределение функций по уровням системы, в основном, соответствует семиуровневой мо- дели взаимодействия открытых систем. Для проверки пригодности разных реализаций протоколов ОКСО к совместной работе в одной сети сигнализации требуется их аттестационное тестирование (conformance testing). Общие принципы аттестационного тестирования протоколов OSI сформулированы в рекомендации МСЭ Х.290. Рекомендация делит все требования к соответствию реализации протокола OSI его спецификации на две группы — требования к статическому соответствию и требования к динамическому соответствию.
В качестве документа, содержащего информацию производителя о том, каким именно требованиям к статическому соответствию удовлетворяет представляемая этим производителем реализация протокола, используется ведомость соответствия протоколу (PIGS, Protocol
Тестовая архитектура, состоящая из тестера, тестируемой реализации (IUT, Implementation under test), тестового контекста, точек контроля и наблюдения PCO и точек доступа к реализации, представляет собой описание среды, в которой проводится проверка реализации протокола. Тестер выполняет эксперименты над системой и наблюдает за результатами.
В тестере выделяются две части, именуемые нижним и верхним тестером. Нижний тес- тер (LT, Lower tester) абстрактно определяется как средство, которое в процессе тестирования воздействует на тестируемую реализацию и наблюдает за ней в PCO, находящейся на нижней границе этой реализации. Определяемый подобным образом верхний тестер (UT, Upper tester) взаимодействует с тестируемой реализацией в PCO на верхней границе этой реализации. При необходимости верхний и нижний тестеры взаимодействуют между собой с помощью процедур координации тестирования (ТСР, Test coordination procedures). В
Нижний тестер сложнее верхнего, поскольку он выполняет функции контроля и наблюдения за протокольными блоками данных (PDU, Protocol data units). Эти блоки являются частями абстрактных примитивов ASP, которые нижний тестер передает и принимает во время выполнения теста. Для тестирования конкретной системы специфицируются последовательности тестовых событий, воздействующих на эту систему и ожидаемых в качестве ее реакции на воздействия. Последовательность таких событий, исчерпывающая определенную задачу тестирования, представляет собой отдельный reer(test case). Полный набор тестов для тестирования определенного протокола называется комплектом тестов (test suite).
Воздействие на тестируемую реализацию протокола и наблюдение за ее реакцией могут производиться либо локально, когда PCO, доступные тестеру, находятся внутри тестируемой системы на верхней и нижней границах (в смысле модели OSI) тестируемой реализации, либо извне, например, через звено ОКСО. Для тестирования реализаций открытых систем определены следующие четыре категории методов:
а) методы локального (local) тестирования;
b) методы внешнего распределенного (external distributed) тестирования;
с) методы внешнего координированного (coordinated) тестирования;
d) методы внешнего дистанционного (remote) тестирования.
Методы локального тестирования характеризуются, как уже было сказано, тем, что PCO, к которым подключаются верхний и нижний тестеры, располагаются внутри системы на границах тестируемой реализации. Все методы внешнего тестирования ориентированы на то, что связь между нижним тестером и тестируемой системой поддерживается услугами нижних уровней, предоставляемыми другой системой, причем подразумевается, что названные услуги достаточно надежны. Методы различаются возможностями доступа к верхней границе тестируемой реализации, требованиями к верхнему тестеру и требованиями к процедурам координации действий верхнего и нижнего тестеров. Методы b) и с) требуют, чтобы функции верхнего тестера были вполне определенными, методы d) этого не требуют. Методы с) требуют координации действий верхнего и нижнего тестеров с использованием протокола административного управления тестированием, методы b) и d) не предусматривают процедур координации. Методы Ь) предполагают наличие доступа к верхней границе тестируемой реализации, методы с) и d) такого доступа не требуют.
Нетрудно видеть, что любая версия реального средства тестирования протокола сигнализации будет реализацией некоторого нового протокола, представляющего собой расширение протокола, для тестирования которого это средство предназначено. Указанное расширение протокола, реализуемого средством тестирования, следует понимать так, что это средство, кроме нормальных протокольных процедур (режим эмулятора), должно еще распознавать и идентифицировать определенные нештатные для тестируемого протокола ситуации (режим монитора), а также иметь возможность создавать их (режим симулятора). Такого рода расширение, фактически являющееся спецификацией протокол-тестера, к настоящему моменту никакими международными стандартами не определено.
Данное обстоятельство порождает следующую проблему: одна и та же реализация протокола, тестируемая с помощью одного и того же тестового комплекта, но разными тестовыми средствами, может получить разные оценки соответствия. Это неизбежно ставит вопрос о необходимости стандартизации инструментальных средств тестирования, что проще всего обеспечить, если создание таких средств идет одновременно с разработкой соответствующих спецификаций протокола.
Тестирование качества работы и совместимости компонентов современной телекоммуникационной сети приобретает важное значение в последние годы. При этом особое внимание уделяется наблюдению за состоянием элементов сети и проверке корректности реализации протоколов сигнализации.
Новые технологии предоставления услуг предполагают установку сетевых элементов, взаимодействующих между собой по новым протоколам, а с существующими сетями по достаточно давно применяемым протоколам, что влечет необходимость проверки как правильности реализации новых протоколов, так и корректности их взаимодействия с уже применяемыми. Добавление новых услуг и возможностей в существующее оборудование также влечет за собой новые группы протоколов и необходимость тестирования не только их самих, но и тестирование взаимодействия с существующими, уже однажды проверенными протоколами.
На каждом из этапов, через которые проходит любой компонент сети связи, начиная от разработки и заканчивая эксплуатацией в условиях реальной нагрузки, используются специальные методы тестирования и анализа качества функционирования, которые реализуются специализированными программно-аппаратными средствами, представляющими собой автономные приборы (протокол тестеры или анализаторы) и целые системы распределенного наблюдения.
4.3 Платформа тестового оборудования SNT
Платформа тестового оборудования систем и сетей сигнализации SNT разработана для
создания приборов и систем, необходимых при проведении всех видов тестирования сетевых элементов, использующих для взаимодействия между собой протоколы и системы сигнализации разных типов. Платформа SNT предоставляет унификацию средств для проведения функционального тестирования, тестирования соответствия, производительности, совместимости и взаимодействия (рисунок 4-2). Интуитивно-понятный и удобный пользовательский русскоязычный интерфейс позволяет задавать значения параметров процесса тестирования и конфигурировать систему. Большое число сервисных функций дает возможность максимально автоматизировать процесс тестирования, вместе с тем оставляя пользователю возможность изменять все необходимые параметры системы с целью полной имитации реального окружения тестируемого оборудования. Наличие различных библиотек кодирования/декодирования сообщений позволяет проводить тестирование реализации как национальных российских, так и международных версий протоколов.
Платформа реализована в соответствии с принципами тестирования протоколов и моделью OSI, что предполагает отдельную проверку функционирования каждого уровня.
Платформа SNT может быть использована для решения оперативных и среднесрочных задач эксплуатационного управления, а также для проведения пуско-наладочных работ.
Платформа тестирования SNT является базой для создания полной линейки тестового оборудования, а которую кроме системы распределенного мониторинга и аудита сети ОКС7 СПАЙДЕР входят профессиональный многопортовый анализатор/симулятор SNT-7531 и компактный анализатор SNTlite.
Система распределенного мониторинга и аудита сети ОКС7 СПАЙДЕР предназначена для постоянного наблюдения за состоянием элементов сети, контроля качества связи, сбора информации о возникающих в сети событиях, архивирования и статистической обработки информации по различным критериям, трассировки вызовов в пределах сети, генерации CDR/TDR, а также удаленного мониторинга и анализа протоколов ОКС7, применяемых в сетях ТФОП/ISDN/IN и/или GSM/GPRS.
Архитектура СПАЙДЕР позволяет гибко наращивать мощность системы, начиная от одного центра мониторинга и анализа до сложной иерархической системы с несколькими региональными и национальным центрами наблюдения и контроля. Система состоит из не- скольких удаленных модулей (пробников) и одного или нескольких (по числу операторов) центральных серверов, образующих центры наблюдения и контроля. Компоненты системы мониторинга соединяются между собой по выделенной технологической сети передачи данных. Архитектурная концепция системы позволяет осуществлять как горизонтальное расширение на региональных уровнях с использованием дополнительных серверов, так и вертикальное расширение на национальном уровне.
Приложения трассировки вызовов, обнаружения несанкционированного доступа к ресурсам сети, обнаружения фактов мошенничества, удаленного мониторинга, журнала событий, сбора статистики и генерации CDR/TDR позволяют пользователю системы, работающему за терминалом центра наблюдения, заблаговременно выявлять тенденции, ведущие к снижению качества работы сети, оперативно реагировать на возникновение отказов в элементах сети, получать информацию об использовании ресурсов, в том числе оперативно выявлять факты их несанкционированного использован
ия в реальном времени.
4.3.1.1 Функции системы СПАЙДЕР
4.3. 1. 1. 1 Мониторинг состояний
Функция мониторинга состояний используется для отображения аварийных ситуаций,
возникающих в элементах сети сигнализации. Определение аварийных и текущих состояний производится посредством анализа сообщений о статусе звеньев сигнализации (LSSU).
Пользовательский интерфейс выполнен в виде графических карт, отображающих как всю сеть сигнализации в целом, так и отдельные ее фрагменты.
Информация об изменении состояний звеньев и пучков звеньев выводится в журнал событий и выделяется цветом в соответствии с уровнем важности. Собранная информация архивируется и сохраняется в течение длительного времени.
При мониторинге интенсивности нагрузки или качества функционирования сигнальных звеньев пользователь имеет возможность задавать граничные значения (пороги аварийной ситуации).
4.3. 1. 1.2 Статистика функционирования сети ОКСО
Эта функция позволяет получить статистические данные о состоянии пучков звеньев, о количестве отказов и восстановлений звеньев, об общей загрузке звеньев и загрузке их отдельными подсистемами, а также проследить зависимости изменения загрузки от времени и получить данные о количестве сообщений каждого типа.
Перечень измерений для сбора данных соответствует рекомендации МСЭ-Т О.751. Интервал измерений — 5 минут.
4.3. 1. 1.3 Статистика функционирования разговорных каналов
Эта функция обеспечивает сбор данных по отдельным направлениям, за заданный период времени (например, нагрузка разных пучков каналов, количество/процент успешных вызовов, количество/ процент вызовов, встретивших занятость, количество/процент вызовов без ответа). Кроме того, имеется возможность получить распределение неуспешных вызовов по разным классам причин. Перечень измерений соответствует рекомендации МСЭ-Т Е.422.
Производится статистическая обработка сообщений по их типу, анализ относительной доли сообщений разных протоколов и кодов причин разъединений. Статистические данные позволяют пользователю оценить загрузку канала сигнализации и качество обслуживания вы- зовов по отдельным направлениям.
4.3. 1. 1.4 Трассировка вызовов
Эта функция позволяет пользователю системы отслеживать последовательности сообщений, связанные с прохождением вызовов по нескольким сетям (ТРОП, ISDN, GSM или IN), обслуживаемых системой сигнализации ОКС7, задав триггер», срабатывающий, если в определенное время происходит определенное событие, например, такое как появление сообщения с определенными цифрами телефонного номера или его части. Возможности трассировки вызова используются для обнаружения фактов несанкционированного доступа.
Функция генерации CDR/TDR (Call Transaction detailed record) позволяет формировать статистические данные об интенсивности потока вызовов и о длительности их обслуживания. Функция основана на записи информации о вызовах в базу данных, которая хранится на специальном сервере CDR. Запись CDR создается системой для каждого вызова, и содержит такие данные, как продолжительность обслуживания вызова, номера вызывающего и вызываемого абонентов, тип услуги, дата/время начала и окончания обслуживания вызова и другие параметры.
Анализ и фильтрация записей позволяют получить данные о наиболее долго обслуживавшихся вызовах, об активных (находящихся в обслуживании) вызовах, о суммарной продолжительности разговора по отдельным направлениям связи, о положении ЧНН, о труднодоступных направлениях и т.п.
4.3. 1. 1. 6 Декодирование и анализ сообщений
Эта функция позволяет анализировать обмен сообщениями по каждому сигнальному звену и отображать результаты анализа в расшифрованном виде с управляемой степенью детализации и с предоставлением встроенной функции интерактивной помощи в отношении сообщений и параметров выбранного протокола. Предусмотрена возможность настройки фильтров и загрузки нужных значений их параметров из центрального модуля в один или несколько удаленных модулей.
Периодический или постоянный мониторинг интерфейса между сетевыми элементами обеспечивает:
• выявление ошибок при взаимодействии разных протоколов и сетевых элементов и не обнаруженных на других этапах тестирования;
• обнаружение несанкционированного доступа к ресурсам со стороны отдельных абонентов,
• обнаружение зацикливания сообщений,
• контроль источников и маршрутов прохождения трафика.
При декодировании и анализе проверяется соответствие принимаемых сигналов и сообщений заданной спецификации. Сигналы и сообщения (или их отдельные параметры), не соответствующие спецификации, выделяются красным цветом. Анализаторы производят побитовое декодирование каждого сообщения с разбивкой по уровням протокола.
Так, если в сообщении протокола, заявленного как ISUP-В, будет обнаружен параметр или значение параметра, не предусмотренные спецификацией ISUP-R, анализатор автоматически выделит это сообщение из общей массы сообщений. Наличие даже одного не предусмотренного параметра может непредсказуемо повлиять на встречную АТС и значительно ухудшить качество обслуживания вызовов.
Развитая система фильтрации по разным критериям позволяет выделить из нескольких
десятков тысяч сообщений, накопленных, например, за сутки наблюдения, только сообщения, содержащие информацию, которую пользователь хочет проанализировать. Фильтры позволяют пользователю провести детальное исследование обнаруженной анализатором проблемы, сокращая до минимума нужное для этого время.
Возможность одновременного анализа сообщений разных протоколов позволяет визуально оценить правильность взаимодействия систем сигнализации разных типов (например, ISUP и 0$81), что имеет первостепенную важность при соединении разнородного оборудования.
4.3.1.1.7 Обнаружение фактов несанкционированного использования ресурсов сети
Эта функция обеспечивает как сбор и обработку информации о вызовах в реальном времени, так и пост-обработку полученных в результате наблюдения данных, сравнивая их с заранее установленными параметрами фильтрации, сведениями об абонентских профилях и определенными пользователем пороговыми значениями временных интервалов.
Система имеет возможность обработки практически неограниченного числа параметров, полученных из записей CDR и/или из сигнальных звеньев ОКС7 и из разговорных каналов.
Пользователь системы имеет возможность создавать свои критерии фильтрации данных, комбинируя разные параметры, и устанавливать пороговые значения. В случаях совпадения критериев или превышения пороговых значений система автоматически генерирует соответствующее оповещение.
4.3.2 Многопортовый анализатор протоколов SNT-7531
SNT-7531 предназначен для профессионального тестирования телекоммуникационного оборудования ТФОП/ISDN, сетей GSM, региональных сетей передачи данных WAN, локальных сетей LAN, выделенных и частных сетей. Прибор выполняет мультипротокольные полнодуплексный мониторинг и анализ протоколов сигнализации в 8 трактах ИКМ для их проверки на предмет соответствия российским спецификациям, рекомендациям МСЭ-Т и стандартам ETSI. Внешний вид прибора представлен на рисунке 4-3.
Анализатор/симулятор SNT-7531 включает поддержку стеков протоколов ОКС7, ISDN
PRI/BRI, GSM/GPRS, IN, CAMEL, V5.1 и V5.2, QSIG, TCP/IP, FR, Х.25, Н323 VoIP, а также сигнализации по 2ВСК.Прибор используется для задач, требующих одновременного мониторинга нескольких направлений и/или протоколов и анализа их взаимодействия.
На этапе системного проектирования прибора были определены наиболее характерные для средств тестирования функциональные возможности:
• наличие, в виде сменных модулей, аппаратных средств поддержки стандартных ин- терфейсов;
• возможность одновременного мониторинга нескольких протоколов в разных интер- фейсах;
• наличие пакетов стандартизированного тестового программного обеспечения;
• наличие средств ввода и редактирования тестовых сценариев через графический интерфейс пользователя и средств трансляции сценариев в исполняемые тесты;
• удобный пользовательский интерфейс и возможность сохранения результатов тестирования на дисках и вывода их на принтер;
• возможность дистанционного управления тестером, обеспечивающая объединение нескольких тестеров в одном тестовом стенде.
Именно этим требованиям соответствует анализатор протоколов сигнализации SNT-7531. В приборе предусмотрена возможность подключения параллельно первичному тракту ИКМ для работы в режиме мониторинга, а также возможность подключения его в режиме эмуляции и симуляции. Прибор обеспечивает одновременное наблюдение за корректностью взаимодействия нескольких систем сигнализации в произвольном их сочетании.
В режиме анализатора SNT-7531 производит мониторинг и запись протокольных блоков данных, передаваемых через межстанционный интерфейс, и отображает их на экране в расшифрованном виде, предоставляя пользователю возможность гибкого конфигурирования режимов тестирования разных подсистем. Пользователь может с помощью меню включать необходимые фильтры и выбирать характеристики вывода информации для каждого протокола — в шестнадцатеричном коде, в сокращенной или в подробной форме представления. Пример использования окна настроек пучков сигнальных звеньев, отдельных звеньев в пучке и соответствующих протоколов сигнализации изображен на рисунке 4-4.
В режиме симуляции с помощью готовых наборов тестовых сценариев можно моделировать последовательности сообщений для проверки корректности реализации протокола в тестируемой системе. При обнаружении некорректной реакции тестируемой системы на экран прибора выводятся соответствующие сообщения. Пользователю предоставляется возможность создавать собственные тестовые сценарии. Результаты тестирования могут сохраняться в текстовых файлах или выводиться на принтер.
Пользователь может контролировать процесс тестирования, производить необходимые настройки (выбор сигнального канала, редактирование тестовых сценариев и т.д.), получать контекстную помощь как в отношении специфики тестируемых протоколов, так и в отношении самой системы тестирования, сохранять и распечатывать результаты тестов.
Графический интерфейс пользователя (рисунок 4-5) содержит два основных конфигурируемых экранных элемента:
• основное окно мониторинга
• вспомогательное окно мониторинга
Основное окно мониторинга используется для вывода декодированных сообщений в полном виде — каждое поле представлено в форме «номер байта- битовая маска-имя поля значение поля». Степень детализации просматриваемой информации можно изменять посредством подменю Детализация», с помощью левой клавиши манипулятора «мышь» или кнопками управления детализацией.
Вспомогательное окно мониторинга предназначено для отслеживания последовательности приходящих сообщений и быстрого просмотра основных полей. Каждое сообщение представляется одной строкой вида «время, направление, протокол, ОРС/ТЕ, DPC, CIC/CR, название сообщения, дополнительные параметры».
Встроенное в прибор программное обеспечение интерактивного обучения и помощи позволяет получать в процессе эксплуатации исчерпывающую контекстную помощь на русском или английском языке в отношении любого выбранного элемента (сообщения или параметра), отображаемого на экране. Эта функция помогает в ходе работы изучить особенности используемых протоколов связи. Пример использования окна интерактивного обучения представлен на рисунке 4-6.
SNT-7531 позволяет производить побитовое декодирование сообщений всех поддерживаемых протоколов сигнализации. Пользователю предоставляется возможность контролировать степень детализации отображаемой информации, при этом никакая часть полученной информации не будет потеряна или искажена.
Полученный грейс можно сохранить в двоичном или текстовом виде с возможностью дальнейшего просмотра в других приложениях (Microsoft Word, Norton, FAR и т д.) и вывода на печать.
Пользователю предоставляется также возможность отслеживать необходимую информацию в ходе тестирования или при просмотре сохраненного грейса, используя функции фильтрации. Интерфейс для настройки фильтров представлен на рисунке 4-7.
Чтобы получить общее представление о состоянии сигнального звена, пользователь имеет возможность сбора статистики на базе полученных грейсов. Пользователю выдается информация о:
• количестве сообщений всех типов, принятых за время наблюдения за каналом при тестировании МТР,
• количествах сообщений, содержащих каждое значение параметра «Cause Value»
(« Причина разъединения»),
• загрузке звена ОКС7.
Функции дистанционного доступа позволяют пользователю управлять работой SNT-7531 через локальную сеть с другого компьютера, на котором установлена программная оболочка SNT-7531.
Режим эмулятора МТР/симулятора ISUP предназначен для выполнения следующих функций:
• проверка на соответствие национальным российским спецификациям ОКС7
• эмуляция функций сигнального звена МСЭ-Т Q.703, Белая книга
• проверка на соответствие рекомендациям МСЭ-Т Q.761-Q.764, Q.767 Белая книга
• создание и редактирование сценариев
• комплект тестовых сценариев МСЭ-Т Q.784, Белая книга
• комплект сценариев для тестирования национальных российских особенностей протоколов МТР и ISUP
• мониторинг и декодирование в реальном времени
• проверка разговорного тракта.
Графический интерфейс пользователя в режиме эмулятора МТР/симулятора ISUP
представлен на рисунке 4-8. Если сценарий не содержит ошибок, и нет логических ошибок в параметрах установок, то после загрузки в окне симулятора отобразится обмен сообщениями согласно выбранному сценарию. Кроме сообщений появляются комментарии, поясняющие цель теста (ссылки на пункты рекомендации Q.764), и перечень проверок, которые необходимо сделать во время выполнения сценария.
Сразу после загрузки становятся доступны команды запуска сценария и команда пошагового выполнения в управляющем меню и на панели инструментов.
При тестировании последовательно выполняются все действия, описанные в сценарии. Исполнение сценария в любой момент можно прервать командой «остановка» или приостановить командой «пауза». В режиме паузы сценарий может выполняться по шагам для более детального анализа тестируемого оборудования. Все сообщения, поступающие в симулятор в режиме паузы, помещаются во временную очередь и хранятся там до очередного запуска.
Имеется возможность в любой момент узнать результаты выполненных сценариев. Нажатие кнопки отображения отчета вызовет к загрузке html-файл с таблицей результатов прохождения тестовых сценариев.
Генератор вызовов SNT-7531 предназначен для создания сигнальной нагрузки на телефонную станцию и проверки правильности приключения разговорных каналов. Функционально генератор вызовов представляет собой устройство, эмулирующее работу цифровой ATC. Имеется возможность задавать ряд параметров, таких как интенсивность потока вызовов и длительность их обслуживания, ОРС, DPC, SLS, CIC, телефонные номера вызывающих и вызываемых абонентов. После успешного исходящего или входящего соединения проверяется целостность разговорного тракта путем генерации тональной частоты и попытки обнаружить эту частоту в разговорном тракте в течении заданного промежутка времени. Данные о результатах приключения разговорных каналов и проверки целостности разговорного тракта динамически отображаются в процессе работы и сохраняются в файле отчета.
4.3.3 Компактный анализатор SNTlite
SNTlite предназначен для оперативной диагностики неисправностей, возникающих при эксплуатации коммутационных систем и требующих выезда специалиста на место установки оконечного коммутационного оборудования (PATC, концентраторов, учрежденческих ATC или оборудования беспроводного доступа). Внешний вид SNTIite представлен на рисунке 4-9.
Анализатор SNTlite выполнен в виде ноутбука с малогабаритным внешним интерфейсным модулем для подключения к первичному тракту ИКМ и с программным обеспечением для мониторинга и анализа протоколов российских версий систем сигнализации ОКС7, ISDN PRI, V5.1/V5.2 и 2ВСК, применяемых в BCC РФ. Анализатор определяет состояние и проверяет качество тракта ИКМ (BERT).
Поскольку сигнальный трафик и сложность сетей сигнализации постоянно возрастают, для поддержания должного уровня качества предоставления современных услуг операторы сетей стремятся получить полный контроль сетей ОКС7. В этих условиях система сигнализации ОКС7 становится все более важным объектом технической эксплуатации сетей связи, требующим постоянного наблюдения и адекватных средств анализа и отображения.
4.4 Сетевые аспекты мониторинга ОКСО
Принципы технической эксплуатации сетей ОКС7 (рисунок 4-10) учитывают, что эти сети работают под управлением системы сигнализации, представляющей собой многоуровневую систему с обилием протоколов. Рекомендации МСЭ-T Q.750 детализируют общие объектно-ориентированные принципы наблюдения за открытыми системами применительно к технической эксплуатации сетей ОКС7 и выделяют три основные группы функций:
а) функции, относящиеся к сети TMN (Telecommunication Management Network), которая специфицирует многоуровневую архитектуру для эксплуатационного управления средствами электросвязи;
б) функции, являющиеся частью протокола самой системы сигнализации ОКС7 (например, переключение на резервное сигнальное звено или принудительная ремаршрутизация);
в) функции, нужные для проверки правильности таблиц маршрутизации, кодов идентификации каналов и т.п., поддержка которых требует взаимодействия внутри сети сигнализации посредством отдельного прикладного протокола.
Функции группы б) выполняются подсистемой МТР системы ОКС7. Для реализации функций управления групп а) и в) рекомендациями МСЭ-Т Q.750-Q.754 определена специальная прикладная подсистема эксплуатационного управления (ОМАР — Operation, Maintenance and Administration Part) и связанные с ней категории управления.
Категория УПРАВЛЕНИЕ НЕИСПРАВНОСТЯМИ (Fault Management) обеспечивает обнаружение, изоляцию и исправление ситуаций нештатного функционирования сети ОКС и включает в себя:
• обработку аварийных ситуаций, например, таких как отказ пучка сигнальных звеньев, ведущий к недоступности пункта сигнализации;
• активизацию тестов или необходимых измерений;
• сбор статистики в масштабах сети ОКС7 для планирования и проведения превентивных мероприятий;
• сбор статистики о состоянии элементов сети с целью обнаружить те из них, которые, возможно, работают в критическом режиме.
Неисправности отдельных элементов могут привести к неспособности всей сети ОКС выполнять свои функции с необходимым качеством. Явно «видимые» неисправности ведут к неспособности обслужить весь сигнальный (и, как следствие, разговорный) трафик, а «скрытые» неисправности снижают надежность сети сигнализации.
Категория УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ (Configuration Management) обеспечивает управление ресурсами, сбор данных о сети ОКС и ее компонентах и включает в себя:
• формирование статической конфигурации сети ОКС, включая активизацию ее элементов, и изменение конфигурации сети во время работы;
• индикацию изменений статической конфигурации во время работы.
Среди основных функций этой категории можно выделить формирование маршрутных таблиц в соответствии с заданным оператором сети планом маршрутизации; формирование и ввод в действие пучков сигнальных звеньев и отдельных звеньев внутри пучков и проверку соответствия имен на обеих сторонах сетевых ресурсов (например SLC и CIC).
Категория КОНТРОЛЬ ПОКАЗАТЕЛЕЙ КАЧЕСТВА (Performance Management) предполагает сбор статистических данных с целью оценить динамику изменения состояния сетевых элементов и эффективности работы сети в нормальных условиях и в условиях перегрузки и включает в себя, главным образом:
• активизацию измерений и сбор результатов за короткие (5 мин.) и большие (30 мин.) периоды (например, наблюдение за авариями, за использованием пучков звеньев и сигнальных маршрутов);
• управление сигнальным трафиком в реальном времени (например, модификацию маршрутных таблиц и активизацию дополнительных сигнальных звеньев и пучков звеньев).
Для решения задач контроля за сетями ОКС на основе концепции TMN в начале 90-х- годов МСЭ предложил оснастить пункты сигнализации ОКСО прикладной подсистемой ОМАР. Однако допускаемая рекомендациями по TMN многовариантность реализации и сложность протокола CMIP, лежащего в основе ОМАР и предлагаемого МСЭ-Т для поддержки взаимодействия между сетевыми элементами и системами технической эксплуатации, привели к тому, что производители коммутационного оборудования предпочитают использовать свои, более простые, но не совместимые между собой протоколы для наблюдения и дистанционного управления элементами сети ОКСО.
.