Главная  Системы коммутации 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [ 67 ] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103]

теля, является маршрутная этикетка, содержащая два поля с дан ными об SP-отправителе (ОРС - Originating Point Code) и об SP-no-лучателе (DPC - Destination Point Code). Анализируя этикетку сообщения, принятого от уровня 2, блок сортировки определяет, куда его нужно направить - к блоку распределения (если DPC совпадаете кодом «своего» SP) или к блоку маршрутизации (если совпадения нет). Блок распределения, приняв от блока сортировки сообщение с этикеткой, содержащей в поле DPC код «своего» SP, направляет сообщение к подсистеме-адресату. Блок маршрутизации, приняв сообщение от блока сортировки (или от подсистемы-отправителя, размещенной в «своем» SP), использует DPC для выбора маршрута, по которому нужно направить это сообщение к SP-получателю. Третьим элементом маршрутной этикетки является поле селектора сигнального звена (SLS - Signaling Link Selection), которое служит для выбора звена, по которому должно пересылаться данное сообщение. Это звено МТР либо выбирает сама, либо делает выбор, следуя указанию «сверху», те. от подсистемы-пользователя.

Подсистемы уровня 4

Уровень 3 МТР

Уровень 2 МТР

Сетевые функции

Обработка сигнальных сообщений

Распределение сообщений

Э сплуатационное управление сетью ОКС

Сортировка сообщений

Маршрутизация сообщений

Управление сигнальным трафиком

Управление сигнальными маршрутами

Управление сигнальными звеньями

Тестирование и техобслуживание (МТР)

Потоки Сигнальных сообщений Контрольная и управляюоя информация

Рис 8 8 Функции уровня 3 МТР



функции эксплуатационного управления сетью ОКС тоже пред ставлены в уровне 3 МТР тремя функциональными блоками:

• блоком управления сигнальным трафиком,

• блоком управления,сигнальными звеньями,

• блоком управления сигнальными маршрутами.

Эти функции обеспечивают пребывание сети ОКС в состоянии, когда она способна предоставлять услуги своим пользователям, и восстановление такого состояния при нарушениях работы сигнальных звеньев или SR Нарушения могут проявляться либо в виде полного отказа звена или SP, либо в ухудшении условий доступа к ресурсу (звену или SP) из-за его перегрузки.

8.4.2 Подсистема управления сигнальными соединениями SCCP

Подсистема SCCP дополняет уровень 3 МТР функциями, которых тому не достает для того, чтобы соответствовать уровню 3 модели OSI. МТР и SCCP образуют тн. подсистему сетевых услуг NSP (Network Service Part). NSP поддерживает создание между SP как сигнальных связей, нужных для управления соединениями в сети коммутации каналов, которую обслуживает сеть ОКС7, так и связей, не относящихся к таким соединениям - в том числе сигнальных связей между несмежными SP. Важную роль здесь играет наличие в SCCP собственной системы адресации, не привязанной, как в МТР, к номерам телефонных каналов.

SCCP предоставляет своим пользователям как услуги, не предусматривающие создания в сети ОКС виртуального соединения, так и услуги, ориентированные на соединение. Имеется четыре класса услуг SCCP:

0 - базовый класс услуг без соединения; доставка сигнальных со-

общений в заданной последовательности не гарантируется.

1 - класс услуг без соединения; доставка сигнальных сообщений

в заданной последовательности гарантируется.

2- базовый класс услуг, ориентированных на соединение, без управления потоком сообщений.

3 - класс услуг, ориентированных на соединение, с управлением потоком сообщений.

Заметим, что класс 1 сохраняет порядок следования сообщений, используя упомянутый в п.8.4.1 механизм присвоения «сверху» значения SLS в маршрутной этикетке Благодаря этому на каждом уча стко маршрута от SCCP отправителя к SCCP-получателю все сооб щопия SCCP, п[5инпдлежащие одному потоку, проходят через одно



и то же сигнальное звено, что гарантирует сохранение очередности их следования по всему маршруту.

Сообщение SCCP содержит маршрутную этикетку, код типа сообщения и параметры. Параметры дополняют данные, определяемые кодом типа сообщения. В общем случае параметр состоит из названия, индикатора длины и поля данных. Название кодируется одним байтом и однозначно определяет параметр. Индикатор длины указывает количество байтов в параметре, а поле данных содержит информацию (заметим, что не в каждом параметре имеются все эти поля).

Существуют параметры трех видов - обязательные с фиксированной длиной, обязательные с переменной длиной и необязательные. Обязательные параметры с фиксированной длиной содержатся в сообщениях любого типа. Положение и длина каждого из этих параметров определяются типом сообщения, а поэтому их названия и индикаторы длины в сообщения не включаютсОбязатель-ные параметры переменной длины также содержатся в сообщениях всех типов. Название любого такого параметра тоже определяется типом сообщения. Необязательные параметры могут включаться или не включаться в сообщение того или иного типа. Каждый необязательный параметр содержит название (один байт) и индикатор длины (один байт) перед полем данных, передающим содержание параметра.

Формат сообщения SCCP в общем виде показан на рис.8.9. Всего на сегодня специфицировано 19 сообщений (пять из них - для нужд эксплуатационного управления). Из экономии места сообщения здесь не описываются и перечень их не приводится; сведения об этом можно почерпнуть, например, из [41]. Автор считает более важным обратить внимание читателя на то обстоятельство, что принцип свободного использования в формате сообщения полей необязательных параметров позволяет гибко модифицировать как перечень сообщений SCCP, так и содержание любого из них, когда и если в будущем возникнет потребность в такой модификации.

8.4.3 Подсистема средств транзакций

Средства транзакций ТС - Transaction Capabilities - предназначены для поддержки взаимодействия между прикладными процессами (или между разными элементами одного процесса), размещенными в территориально разнесенных узлах сети связи. Любой такой процесс (или элемент процесса) внутри одного узла сети связи является пользователем услугами ТС, размещенных на этом узле. С другой стороны, сами ТС того или иного узла являются пользователем сетевыми услугами, предоставляемыми размещенной на нем подсистемой NSP.



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [ 67 ] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103]

0.0009