Материал: Глава 10 СИСТЕМА ОБЩЕКАНАЛЬНОЙ СИГНАЛИЗАЦИИ №7

Рис. 10.21. Функционирование сети сигнализации ОКС7 для поддержки услуг мобильной связи

Рис. 10.22. Структура прикладной части BSSAP

10.8. Подсистемы мобильной связи mup и hup стандарта nmt

Подсистема MUP OKC7 предназначена для обеспечения связи при передвижении абонентов между центрами коммутации МТХ сотовых сетей связи стандарта NMT-450 или NMT-900, т.е. для обеспечения роуминга, уже рассмотренного в параграфе 10.7. MUP поддерживает сигна­лизацию «из конца в конец» между коммутационными узлами МТХ для обновления данных о местоположении подвижного абонента, регистрации и отмены дополнительных услуг, информации маршрутизации и др. Сигнализация MUP передается с помощью тех же сигнальных единиц MSU, структура которых приведена на рис. 10.23. Читателю рекомендуется сопоставить этот рисунок с рис. 10.2 и рис. 10.12 данной главы.

Номер транзакции всегда назначается инициирующим транзакцию МТХ и состоит из идентификатора МТХ (12 бит), четырех резервных бит и непосредственно уникального номера транзакции (16 бит).

Рис. 10.23. Формат единицы сигнального сообщения

Код заголовка НО идентифицирует специфику группы сообщений, в то время как код заголовка Н1 определяет сообщение в группе.

Используются следующие коды заголовка НО:

0001 - сообщения прямого направления о данных местоположения (LDF - location data forward messages);

0010 - сообщения прямого направления о категории/дополнительных услугах (CSF - category/supplementary services forward messages);

0011 - сообщения обратного направления о данных местоположения (LDB - location data backward messages);

0100 - сообщения обратного направления: категория/дополнительные услуги (CSB - category/supplementary services backward messages);

0101 - резерв;

0100 - сообщения управления и администрирования (МАМ -management and administration messages);

ОНО - сигнальные сообщения роуминга (RSM - roaming signalling messages).

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

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

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

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

В MUP включены следующие два типа сообщений технического и административного управления, имеющие следующие коды заголовка HI: сообщение с информацией о рестарте (RES - restart information message) и сообщение подтверждения информации о рестарте (REA - restart information acknowledgement message).

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

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

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

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

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

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

10.9. Подсистема эксплуатации и технического обслуживания омар

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

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

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

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

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

Для подтверждения корректности данных в каналах связи использу­ются аттестационные испытания канала.

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

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

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

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