Подсистема МНР содержит следующие типы сообщений группы LGF о данных местоположения, передаваемых в прямом направлении, каждое из которых идентифицируется кодом заголовка Ш: сообщение обновления данных местоположения (LUM - location updating message) и сообщение отмены данных местоположения (LCM -location cancellation message).

мир содержит следующие сообщения прямого направления группы CSF о данных категории/дополнительных услугах, каждое из которых кодируется определенным заголовком HI: сообщение обновления категории/дополнительных услуг (CSU -category/supplementary services updating message); сообщение регистрации/отмены дополнительных услуг (SRM - supplementary services registration/cancellation message); сообщение регистрации/отмены предыдущих дополнительных услуг (PSR - рге-supplementary services registration/cancellation message).

В подсистеме МНР используются следующие типы сообщений из группы LBD, каждое из которых определяется следующим кодом заголовка Ш: сообщение подтверждения обновления данных местоположения (LUA - location updating accepted message); сообщение отказа в обновлении данных местоположения (LUR - location updating rejected message) и сообщение подтверждения отмены данных местоположения (LCA - location cancellation accepted message).

мир содержит следующие сообщения группы CSB, каждое из которых кодируется собственным заголовком HI: сообщение о доступных категориях/дополнительных услугах (CSA- category/supplementary services accepted message); сообщение регистрации дополнительных услуг/подтверждения отмены (SRA supplementary services registration/cancellation acknowledgement message); сообщение предварительной регистрации дополнительных услуг/подтверждения отмены (PSA - pre-supplementary services registration/cancellation acknoweledgement message).

В мир включены следующие два типа сообщений технического и административного управления, имеющие следующие коды заголовка HI:

сообщение с информацией о рестарте (RES - restart information message) и сообщение подтверждения информации о рестарте (REA - restart information acknoweledgement message).

Другая рассматриваемая в этом параграфе подсистема пользователя HUP протокола 0КС7 предназначена для сигнализации при передаче соединения (хенд-овер) между обслуживающими вызов телефонными станциями подвижной связи (МТХ) стандартаММТ-4501. Сигнализация HUP осуществляется только между МТХ, непосредственно соединенными прямыми телефонными каналами для передачи речи.

Функции HUP охватывают случаи сигнализации из «конца в конец» между МТХ для следующих основных ситуаций: межузловое обновление данных (сигнализация, не связанная с телефонным соединением) и межузловой хенд-овер (сигнализация, связанная с конкретным соединением).

Сигнализация HUP передается через сеть посредством значащих сигнальных единиц. Для сообщений о проведении хенд-овера в поле служебной информации (SIF) этих сигнальных единиц используется стандартная этикетка, которая имеет длину 40 бит и размещена в начале поля служебной информации. Структура этикетки следующая:

Телефонный канал, используемый для установления соединения (12 бит)

Код пункта источника сигнального сообщения (14 бит)

Код пункта назначения сигнального сообщения (14 бит)

Рис. 10.24. Структура этикетки HUP

Для сообщений о проведении измерений этикетка также имеет длину 40 бит и размещена в начале поля служебной информации. Структура этикетки аналогична рис. 10.24 и также содержит код пункта назначения DPC сигнального сообщения (14 бит) и код пункта источника сигнального сообщения ОРС (14 бит). Вместо CIC в этикетке HUP размещается код логического канала LOC, который однозначно указывает логический канал, предназначенный для проведения одного из многих диалогов HUP, и также имеет длину 12

бит.

Код логического канала определяет логический канал, относящийся к определенному порядковому номеру диалога и придаваемый прямому сигнальному сообщению исходящим МТХ. Для обратного сигнала, относящегося к этому же диалогу, используется тот же код LOC. Четыре наименее значащих бита в LOC используются для идентификации одной (среди нескольких) сигнальных линий, связывающих исходящий пункт и пункт назначения.

10.9. ПОДСИСТЕМА ЭКСПЛУАТАЦИИ И ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ ОМАР

Как уже отмечалось ранее в данной главе, пользователем ТСАР является подсистема эксплуатации и техобслуживания (ОМАР). ОМАР позволяет персоналу техобслуживания и эксплуатации контролировать и управлять оборудованием, связанным с сетью сигнализации 0КС7. Таким образом, эксплуатационный персонал может управлять сетью сигнализации из центра технической эксплуатации с помощью протокола, обеспечивающего средства обмена со всеми другими узлами сети. ТСАР же используется для обеспечения передачи информации, не относящейся к каналу, между пунктом управления и узлом (узлами), задействованным для обеспечения функций технического обслуживания и эксплуатации.

К обеспечиваемым ОМАР функциям относятся следующие: управление данными маршрутизации, аттестационные испытания канала, проверочное тестирование маршрутизации МТР и выдача данных об измерениях. Многие элементы ОМАР находятся еще в стадии специфицирования, например, некоторые типы форматов сообщений.

К числу относительно полностью специфицированных функций следует отнести управление данными маршрутизации. Каждый пункт сигнализации в сети хранит данные маршрутизации, используемые для передачи сообщения от одного узла другому. Для эффективной работы сети сигнализации в целом важно, чтобы эксплуатационный персонал мог дистанционно наблюдать и управлять такими данными. В ОМАР специфицированы процедуры для добавления, изменения или удаления данных маршрутизации, хранящихся в удаленных пунктах сигнализации. Также определены процедуры для проверки достоверности таблиц маршрутизации (МТР, SCCP) и кодов исходных точек (MRVT, OMASE). Все эти процедуры базируются на подсистеме ТСАР.

В качестве примера рассмотрим тестирование достоверности маршрутизации МТР (МТР Routing Verification Test - MRVT), базирующееся на рекомендациях Q.753 и Q.754 Белой книги ITU-T. Каждая станция в сети сигнализации 0КС7 хранит данные, используемые МТР для передачи сообщений. Эти данные могут быть сложными, особенно если используется несколько транзитных пунктов сигнализации. Цель MRVT заключается в обеспечении согласованности данных по всей сети. Так, тестом проверяется, чтобы сообщения никогда не передавались по петле, чтобы при возможности посылки сообщения одним пунктом сигнализации другому имелась бы также и обратная маршрутизация. MRVT также определяет слишком длинные пути в сети, слишком большие задержки при передаче сигнальной информации в сети. MRVT может инициироваться всякий раз, когда вводятся новые данные МТР (или изменяются существующие данные), периодически или по запросу персонала эксплуатации и техобслуживания.

Процедура включает в себя посылку пунктом сигнализации сообщения MRVT (проверочное тестирование маршрутизации МТР) по всем возможным направлениям согласно указателю пункта назначения. Сообщение направляется через сеть и фиксирует перечень используемых транзитных пунктов сигнализации. Когда сообщение поступает в пункт сигнализации назначения, направляется сообщение подтверждения достоверности маршрутизации MRVA (МТР Routing Verification Acknowledgement), содержащее результат проверки. При необходимости весь список узлов с детальными результатами проверки возвращается инициатору процедуры для сверки данных с хранимыми записями с помощью сообщения MRVR (МТР Routing Verification Result). На рис. 10.25 представлен пример сценария успешной проверки. Процедура работает посредством генерирования кода индикации канала (CIC) на каждой станции. Две величины сравниваются, и если они одинаковы, сигнальные данные, используемые в канале, можно считать правильными. Если

две величины не одинаковы, можно предположить, что сигнальные данные на одной из станций искажены и надо предпринять дальнейшие шаги.

Для подтверждения корректности данных в каналах связи используются аттестационные испытания канала. Рассмотрим две станции, соединенные трактами передачи. Каждая станция хранит данные об определенных временных каналах, используемьгх для обслуживания вызова.

SP SP SP

Рис. 10.25. Пример тестирования маршрутизации МТР подсистемой ОМАР

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

Для эффективного управления сетью сигнализации необходимо измерять эксплуатационные характеристики и характеристики готовности соответствующего оборудования. В ОМАР определены процедуры для инициирования и завершения проводимых измерений. Измерения могут производиться периодически на регулярной основе (например, для общего управления сетью) либо по запросу (например, во время исследования эффективности сети или работы в условиях неисправностей). Средства выдачи данных об измерениях обеспечивают возможность сбора данных измерений из различных частей сети сигнализации.

Сложность и разнообразие аспектов технического обслуживания, эксплуатации, тестирования и управления сетью сигнализации являются столь широкомасштабными, что даже существующие рекомендации ITU-T еще не могут считаться завершенными. Тем более, автору вряд ли целесообразно пытаться сейчас предложить читателю более подробное описание ОМАР в ограниченном объеме данной книги.

Глава 11

АНАЛИЗ, ТЕСТИРОВАНИЕ И ПРЕОБРАЗОВАНИЕ ПРОТОКОЛОВ СИГНАЛИЗАЦИИ

The proofofthe pudding is in the eating, англ. Проверка пудинга состоит в том, что его съедают

11.1. АНАЛИЗ ВЕРОЯТНОСТНО-ВРЕМЕННЫХ ХАРАКТЕРИСТИК СКАНИРОВАНИЯ И ОБРАБОТКИ СИГНАЛИЗАЦИИ

В предыдущих главах автору удавалось игнорировать известную формулировку лорда Кельвина: «Когда вы в состоянии измерять то, о чем вы говорите, и выражать это в числах, значит вы что-то знаете в данной области; но если вы не можете ни измерить, ни выразить свои знания в числах, то ваши знания по обсуждаемому вопросу неудовлетворительны» [34]. Это было обусловлено тем, что использованные в этих главах методы более оперируют логическими символами, чем числами, что характерно для теории телекоммуникационных протоколов, и что рассматривалось в главе 2.

Однако для проектирования программно-управляемых блоков сигнализации в цифровых узлах коммутации, для разработки эффективных алгоритмов сканирования соединительных